| Message ID | 20171207174038.GQ7829@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
Hi all, On Thu, 7 Dec 2017 09:40:38 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote: > > On Thu, Dec 07, 2017 at 05:30:03PM +0000, Bart Van Assche wrote: > > However, what's not clear to me is through which tree this patch should be > > sent to Linus? Should the above patch be sent as a v4.15-rc fix or should > > Martin perhaps queue it in his tree for v4.16-rc1? > > I have to defer to you guys on that one. Left to myself, I will just > push it into the next merge window (as opposed to using my normal process, > which at this point would get it into the one following). > > So please let me know how you would like to proceed. Clearly, it needs to go via Martin's tree as otherwise his tree will not build in some circumstances ... or if it going to cause problems for Paul, then it should be in a separate non-rebasing branch (probably of Paul's tree) that is merged into Pauls main branch and Marin's tree.
On Fri, Dec 08, 2017 at 07:34:39AM +1100, Stephen Rothwell wrote: > Hi all, > > On Thu, 7 Dec 2017 09:40:38 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote: > > > > On Thu, Dec 07, 2017 at 05:30:03PM +0000, Bart Van Assche wrote: > > > However, what's not clear to me is through which tree this patch should be > > > sent to Linus? Should the above patch be sent as a v4.15-rc fix or should > > > Martin perhaps queue it in his tree for v4.16-rc1? > > > > I have to defer to you guys on that one. Left to myself, I will just > > push it into the next merge window (as opposed to using my normal process, > > which at this point would get it into the one following). > > > > So please let me know how you would like to proceed. > > Clearly, it needs to go via Martin's tree as otherwise his tree will > not build in some circumstances ... or if it going to cause problems > for Paul, then it should be in a separate non-rebasing branch (probably > of Paul's tree) that is merged into Pauls main branch and Marin's tree. It is unlikely to cause problems, so please let it go up where convenient. Just please let me know. Thanx, Paul
Stephen, >> I have to defer to you guys on that one. Left to myself, I will just >> push it into the next merge window (as opposed to using my normal >> process, which at this point would get it into the one following). >> >> So please let me know how you would like to proceed. > > Clearly, it needs to go via Martin's tree as otherwise his tree will > not build in some circumstances ... or if it going to cause problems > for Paul, then it should be in a separate non-rebasing branch (probably > of Paul's tree) that is merged into Pauls main branch and Marin's tree. I'm perfectly OK with taking it through the SCSI tree. Probably the path of least resistance.
> I'm perfectly OK with taking it through the SCSI tree. Probably the > path of least resistance. Applied to 4.16/scsi-queue and rebased so it sits before Bart's patch.
On Thu, Dec 07, 2017 at 08:00:50PM -0500, Martin K. Petersen wrote: > > > I'm perfectly OK with taking it through the SCSI tree. Probably the > > path of least resistance. > > Applied to 4.16/scsi-queue and rebased so it sits before Bart's patch. Thank you! I have removed this patch from -rcu. Thanx, Paul
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c index 8d591d8411fe..4c4d26e9a67b 100644 --- a/kernel/rcu/update.c +++ b/kernel/rcu/update.c @@ -422,11 +422,13 @@ void init_rcu_head(struct rcu_head *head) { debug_object_init(head, &rcuhead_debug_descr); } +EXPORT_SYMBOL_GPL(init_rcu_head); void destroy_rcu_head(struct rcu_head *head) { debug_object_free(head, &rcuhead_debug_descr); } +EXPORT_SYMBOL_GPL(destroy_rcu_head); static bool rcuhead_is_static_object(void *addr) {