Merge conflict on RT 4.14 to latest stable

Merge conflict on RT 4.14 to latest stable

[Dan Murphy]

[-- Attachment #1: Type: text/plain, Size: 162 bytes --]

Hello

We have a merge conflict in kernel/softirq.c when upgrading to the latest stable release

Please help resolve this.

Dan
-- 
------------------
Dan Murphy

[-- Attachment #2: linux_stable_rt_merge_conflict.txt --]
[-- Type: text/plain, Size: 1204 bytes --]

diff --cc kernel/softirq.c
index d0688a7,e89c3b0..0000000
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@@ -950,27 -486,15 +950,31 @@@ void __tasklet_hi_schedule(struct taskl
  }
  EXPORT_SYMBOL(__tasklet_hi_schedule);
  
++<<<<<<< HEAD
 +void __tasklet_hi_schedule_first(struct tasklet_struct *t)
 +{
 +	BUG_ON(!irqs_disabled());
 +
 +	__tasklet_hi_schedule(t);
 +}
 +EXPORT_SYMBOL(__tasklet_hi_schedule_first);
 +
 +void  tasklet_enable(struct tasklet_struct *t)
++=======
+ static __latent_entropy void tasklet_action(struct softirq_action *a)
++>>>>>>> 852a96020848659ae7a03ede00d023151d5f79c8
  {
 -	struct tasklet_struct *list;
 +	if (!atomic_dec_and_test(&t->count))
 +		return;
 +	if (test_and_clear_bit(TASKLET_STATE_PENDING, &t->state))
 +		tasklet_schedule(t);
 +}
 +EXPORT_SYMBOL(tasklet_enable);
  
 -	local_irq_disable();
 -	list = __this_cpu_read(tasklet_vec.head);
 -	__this_cpu_write(tasklet_vec.head, NULL);
 -	__this_cpu_write(tasklet_vec.tail, this_cpu_ptr(&tasklet_vec.head));
 -	local_irq_enable();
 +static void __tasklet_action(struct softirq_action *a,
 +			     struct tasklet_struct *list)
 +{
 +	int loops = 1000000;
  
  	while (list) {
  		struct tasklet_struct *t = list;

Re: Merge conflict on RT 4.14 to latest stable

[Julia Cartwright]

On Thu, Mar 01, 2018 at 07:28:42AM -0600, Dan Murphy wrote:
> Hello

Hey Dan-

> We have a merge conflict in kernel/softirq.c when upgrading to the latest stable release

Can you elaborate on what you are merging and into where?  There isn't
enough context here to make sense of what you are trying to do.

Thanks!
   Julia

Re: Merge conflict on RT 4.14 to latest stable

[Dan Murphy]

Julia

On 03/01/2018 07:41 AM, Julia Cartwright wrote:
> On Thu, Mar 01, 2018 at 07:28:42AM -0600, Dan Murphy wrote:
>> Hello
> 
> Hey Dan-
> 
>> We have a merge conflict in kernel/softirq.c when upgrading to the latest stable release
> 
> Can you elaborate on what you are merging and into where?  There isn't
> enough context here to make sense of what you are trying to do.
> 

Sorry for that.  I was attempting to merge in the current Linux 4.14 stable tree 4.14.23 tag into the rt-devel
4.14-rt tree which is at 4.14.20

Dan

> Thanks!
>    Julia
> 


-- 
------------------
Dan Murphy

Re: Merge conflict on RT 4.14 to latest stable

[Sebastian Andrzej Siewior]

On 2018-03-01 15:59:09 [-0600], Julia Cartwright wrote:
> On Thu, Mar 01, 2018 at 03:21:48PM -0600, Dan Murphy wrote:
> > > You're off into Sebastian territory for 4.14-rt conflicts, although I'm
> > > sure he is either already aware, or will shortly be made aware when he
> > > does the merge himself.

the merge has been done v4.14.24-rt19 is out.

> > There is no consistent merge cadence like we have for the stable RT
> > tree.  As GKH points out we all need to be using the latest stable.

be ware that v4.14-RT is not exactly stable maintenance work here. I do
throw new things into it and I am glad about any testing it gets. So I
have a pile of dcache related patches which I did not want to add to the
queue yet. And we had the one or other timer related problem before the
queue hit Linus' tree.

> Now, if there are actually real users asking for a 4.14.y merge on a
> more frequent cadence, then it might be a sign we should transfer
> ownership of this branch to the rt stable team; I'm sure there is
> already an impeding conversation in this direction (maybe at ELC).

It might be good not having multiple people hacking on one branch.
However, given that v4.16 will be out "soon" I will move on.

>    Julia

Sebastian

Re: Merge conflict on RT 4.14 to latest stable

[Dan Murphy]

Sebastian

On 03/05/2018 11:56 AM, Sebastian Andrzej Siewior wrote:
> On 2018-03-01 15:59:09 [-0600], Julia Cartwright wrote:
>> On Thu, Mar 01, 2018 at 03:21:48PM -0600, Dan Murphy wrote:
>>>> You're off into Sebastian territory for 4.14-rt conflicts, although I'm
>>>> sure he is either already aware, or will shortly be made aware when he
>>>> does the merge himself.
> 
> the merge has been done v4.14.24-rt19 is out.
> 

Thank you.  It could not have been at a more perfect time.  We are starting
our test cycle on 4.14 RT.  I was resolving it locally as well and I came to the
same resolution.  But I will merge your branch first before adding our product
branch on top.

Dan

>>> There is no consistent merge cadence like we have for the stable RT
>>> tree.  As GKH points out we all need to be using the latest stable.
> 
> be ware that v4.14-RT is not exactly stable maintenance work here. I do
> throw new things into it and I am glad about any testing it gets. So I
> have a pile of dcache related patches which I did not want to add to the
> queue yet. And we had the one or other timer related problem before the
> queue hit Linus' tree.
> 
>> Now, if there are actually real users asking for a 4.14.y merge on a
>> more frequent cadence, then it might be a sign we should transfer
>> ownership of this branch to the rt stable team; I'm sure there is
>> already an impeding conversation in this direction (maybe at ELC).
> 
> It might be good not having multiple people hacking on one branch.
> However, given that v4.16 will be out "soon" I will move on.
> 
>>    Julia
> 
> Sebastian
> 


-- 
------------------
Dan Murphy

RE: Merge conflict on RT 4.14 to latest stable

[Hindman, Gavin]

> -----Original Message-----
> From: linux-rt-users-owner@vger.kernel.org [mailto:linux-rt-users-
> owner@vger.kernel.org] On Behalf Of Julia Cartwright
> Sent: Thursday, March 01, 2018 1:59 PM
> To: Dan Murphy <dmurphy@ti.com>
> Cc: linux-rt-users@vger.kernel.org; Sebastian Andrzej Siewior
> <bigeasy@linutronix.de>
> Subject: Re: Merge conflict on RT 4.14 to latest stable
> 
> On Thu, Mar 01, 2018 at 03:21:48PM -0600, Dan Murphy wrote:
> [..]
> > >>>> We have a merge conflict in kernel/softirq.c when upgrading to
> > >>>> the latest stable release
> > >>>
> > >>> Can you elaborate on what you are merging and into where?  There
> > >>> isn't enough context here to make sense of what you are trying to do.
> > >>>
> > >>
> > >> Sorry for that.  I was attempting to merge in the current Linux
> > >> 4.14 stable tree 4.14.23 tag into the rt-devel 4.14-rt tree which
> > >> is at 4.14.20
> > >
> > > You're off into Sebastian territory for 4.14-rt conflicts, although
> > > I'm sure he is either already aware, or will shortly be made aware
> > > when he does the merge himself.
> > >
> > > I'm not sure these notifications provide anything but additional
> > > unnecessary noise.
> >
> > How else are we supposed to have this resolved by the RT maintainers?
> 
> First off: sending out an email notification like this doesn't guarantee
> anything, at all.
> 
> > There is no consistent merge cadence like we have for the stable RT
> > tree.  As GKH points out we all need to be using the latest stable.
> 
> I'm actually okay with rt-devel being behind the latest 4.14.y release; stated a
> different way: I would consider the merging of a later 4.14.y to be lower
> priority than doing more meaningful development work, like driving the rt
> patch upstream.  Considering right now Sebastian is doing both, I'm okay with
> being behind.
> 
> Now, if there are actually real users asking for a 4.14.y merge on a more
> frequent cadence, then it might be a sign we should transfer ownership of
> this branch to the rt stable team; I'm sure there is already an impeding
> conversation in this direction (maybe at ELC).
> 

>From an Intel perspective we would have high interest in a 4.14-stable, and could probably round up a maintainer for it.    I would also very much like to see the rt-devel tree more closely track mainline - right now we have the catch-22 of new platform support going into, or at least being developed against, mainline so we don't really have a path for testing new platforms with an rt-enabled kernel without either a painful backport or forward-port.   As you note, we should probably queue this up into the partner meeting in a few weeks.

>    Julia
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

-Gavin