v6.1.y-dovetail-rebase

v6.1.y-dovetail-rebase

[Jan Kiszka]

Hi Philippe,

quick feedback on latest rebasing:

https://source.denx.de/Xenomai/linux-dovetail/-/commit/8f155631c8b51731dfc2ae5145d4dcc68f2ed7ed

This was likely accidentally folded, right?

Furthermore, I will factor this change out into a separate commit in 
merging v6.1.y-dovetail, for better traceability:

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index ce8bdd804bc7..c843bf352999 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1466,7 +1466,7 @@ void do_user_addr_fault(struct pt_regs *regs,
 
 	/* The fault is fully completed (including releasing mmap lock) */
 	if (fault & VM_FAULT_COMPLETED)
-		return;
+		goto out;
 
 	/*
 	 * If we need to retry the mmap_lock has already been released,

To my understanding, this was a dovetail fix that applied to previous 
versions as well. Besides StackRot, another reason to update 6.1 soon.

A tag on the new branch is still missing. I suspect you are still 
testing? CI picked up the head already as well:

https://source.denx.de/Xenomai/xenomai-images/-/jobs/650229

Jan

Re: v6.1.y-dovetail-rebase

[Philippe Gerum]

Hi,

Jan Kiszka <jan.kiszka@siemens.com> writes:

> Hi Philippe,
>
> quick feedback on latest rebasing:
>
> https://source.denx.de/Xenomai/linux-dovetail/-/commit/8f155631c8b51731dfc2ae5145d4dcc68f2ed7ed
>
> This was likely accidentally folded, right?
>

It looks so. This conditional statement appeared upstream during the
v6.0 cycle it seems, and was unfortunately left unfixed in the dovetail
patch for this entire series.

> Furthermore, I will factor this change out into a separate commit in 
> merging v6.1.y-dovetail, for better traceability:
>
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index ce8bdd804bc7..c843bf352999 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -1466,7 +1466,7 @@ void do_user_addr_fault(struct pt_regs *regs,
>  
>  	/* The fault is fully completed (including releasing mmap lock) */
>  	if (fault & VM_FAULT_COMPLETED)
> -		return;
> +		goto out;
>  
>  	/*
>  	 * If we need to retry the mmap_lock has already been released,
>
> To my understanding, this was a dovetail fix that applied to previous 
> versions as well.

Only to v6.0, however this series is not maintained dovetail-wise
anymore, so this stayed under the radar.

> Besides StackRot, another reason to update 6.1 soon.
>
> A tag on the new branch is still missing. I suspect you are still 
> testing? CI picked up the head already as well:
>

Yes, still in the process of testing the latest rebases on -stable for
5.10, 5.15, and 6.1 (armv8).

-- 
Philippe.

Re: v6.1.y-dovetail-rebase

[Florian Bezdeka]

On Thu, 2023-07-06 at 21:00 +0200, Philippe Gerum wrote:
> Hi,
> 
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
> > Hi Philippe,
> > 
> > quick feedback on latest rebasing:
> > 
> > https://source.denx.de/Xenomai/linux-dovetail/-/commit/8f155631c8b51731dfc2ae5145d4dcc68f2ed7ed
> > 
> > This was likely accidentally folded, right?
> > 
> 
> It looks so. This conditional statement appeared upstream during the
> v6.0 cycle it seems, and was unfortunately left unfixed in the dovetail
> patch for this entire series.
> 
> > Furthermore, I will factor this change out into a separate commit in 
> > merging v6.1.y-dovetail, for better traceability:
> > 
> > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> > index ce8bdd804bc7..c843bf352999 100644
> > --- a/arch/x86/mm/fault.c
> > +++ b/arch/x86/mm/fault.c
> > @@ -1466,7 +1466,7 @@ void do_user_addr_fault(struct pt_regs *regs,
> >  
> >  	/* The fault is fully completed (including releasing mmap lock) */
> >  	if (fault & VM_FAULT_COMPLETED)
> > -		return;
> > +		goto out;
> >  
> >  	/*
> >  	 * If we need to retry the mmap_lock has already been released,
> > 
> > To my understanding, this was a dovetail fix that applied to previous 
> > versions as well.
> 
> Only to v6.0, however this series is not maintained dovetail-wise
> anymore, so this stayed under the radar.

FYI: This change fixes a real issue here. The 6.1-rebase branch made it
through a 24h stress test while the "merge" branch failed. Happily
waiting for the next release...

> 
> > Besides StackRot, another reason to update 6.1 soon.
> > 
> > A tag on the new branch is still missing. I suspect you are still 
> > testing? CI picked up the head already as well:
> > 
> 
> Yes, still in the process of testing the latest rebases on -stable for
> 5.10, 5.15, and 6.1 (armv8).
> 

Re: v6.1.y-dovetail-rebase

[Florian Bezdeka]

On Mon, 2023-07-10 at 08:59 +0200, Florian Bezdeka wrote:
> On Thu, 2023-07-06 at 21:00 +0200, Philippe Gerum wrote:
> > Hi,
> > 
> > Jan Kiszka <jan.kiszka@siemens.com> writes:
> > 
> > > Hi Philippe,
> > > 
> > > quick feedback on latest rebasing:
> > > 
> > > https://source.denx.de/Xenomai/linux-dovetail/-/commit/8f155631c8b51731dfc2ae5145d4dcc68f2ed7ed
> > > 
> > > This was likely accidentally folded, right?
> > > 
> > 
> > It looks so. This conditional statement appeared upstream during the
> > v6.0 cycle it seems, and was unfortunately left unfixed in the dovetail
> > patch for this entire series.
> > 
> > > Furthermore, I will factor this change out into a separate commit in 
> > > merging v6.1.y-dovetail, for better traceability:
> > > 
> > > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> > > index ce8bdd804bc7..c843bf352999 100644
> > > --- a/arch/x86/mm/fault.c
> > > +++ b/arch/x86/mm/fault.c
> > > @@ -1466,7 +1466,7 @@ void do_user_addr_fault(struct pt_regs *regs,
> > >  
> > >  	/* The fault is fully completed (including releasing mmap lock) */
> > >  	if (fault & VM_FAULT_COMPLETED)
> > > -		return;
> > > +		goto out;
> > >  
> > >  	/*
> > >  	 * If we need to retry the mmap_lock has already been released,
> > > 
> > > To my understanding, this was a dovetail fix that applied to previous 
> > > versions as well.
> > 
> > Only to v6.0, however this series is not maintained dovetail-wise
> > anymore, so this stayed under the radar.
> 
> FYI: This change fixes a real issue here. The 6.1-rebase branch made it
> through a 24h stress test while the "merge" branch failed. Happily
> waiting for the next release...

Do we have a idea / plan when the next 6.1 dovetail release will
happen? My internal customer is waiting for that and I want to avoid
backporting to 6.1.34.

@Philippe, any news regarding the IRQ issue? Did the VM image help to
reproduce the issue?

Florian

> 
> > 
> > > Besides StackRot, another reason to update 6.1 soon.
> > > 
> > > A tag on the new branch is still missing. I suspect you are still 
> > > testing? CI picked up the head already as well:
> > > 
> > 
> > Yes, still in the process of testing the latest rebases on -stable for
> > 5.10, 5.15, and 6.1 (armv8).
> > 
> 
> 

Re: v6.1.y-dovetail-rebase

[Philippe Gerum]

Florian Bezdeka <florian.bezdeka@siemens.com> writes:

> On Mon, 2023-07-10 at 08:59 +0200, Florian Bezdeka wrote:
>> On Thu, 2023-07-06 at 21:00 +0200, Philippe Gerum wrote:
>> > Hi,
>> > 
>> > Jan Kiszka <jan.kiszka@siemens.com> writes:
>> > 
>> > > Hi Philippe,
>> > > 
>> > > quick feedback on latest rebasing:
>> > > 
>> > > https://source.denx.de/Xenomai/linux-dovetail/-/commit/8f155631c8b51731dfc2ae5145d4dcc68f2ed7ed
>> > > 
>> > > This was likely accidentally folded, right?
>> > > 
>> > 
>> > It looks so. This conditional statement appeared upstream during the
>> > v6.0 cycle it seems, and was unfortunately left unfixed in the dovetail
>> > patch for this entire series.
>> > 
>> > > Furthermore, I will factor this change out into a separate commit in 
>> > > merging v6.1.y-dovetail, for better traceability:
>> > > 
>> > > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>> > > index ce8bdd804bc7..c843bf352999 100644
>> > > --- a/arch/x86/mm/fault.c
>> > > +++ b/arch/x86/mm/fault.c
>> > > @@ -1466,7 +1466,7 @@ void do_user_addr_fault(struct pt_regs *regs,
>> > >  
>> > >  	/* The fault is fully completed (including releasing mmap lock) */
>> > >  	if (fault & VM_FAULT_COMPLETED)
>> > > -		return;
>> > > +		goto out;
>> > >  
>> > >  	/*
>> > >  	 * If we need to retry the mmap_lock has already been released,
>> > > 
>> > > To my understanding, this was a dovetail fix that applied to previous 
>> > > versions as well.
>> > 
>> > Only to v6.0, however this series is not maintained dovetail-wise
>> > anymore, so this stayed under the radar.
>> 
>> FYI: This change fixes a real issue here. The 6.1-rebase branch made it
>> through a 24h stress test while the "merge" branch failed. Happily
>> waiting for the next release...
>
> Do we have a idea / plan when the next 6.1 dovetail release will
> happen? My internal customer is waiting for that and I want to avoid
> backporting to 6.1.34.
>

There is a brewing rebase to v6.1.42 pending tests here, no challenging
source conflict. I pushed the tree untagged to the v6.1.y-rebase branch
if you want to give it a try before Jan updates the stable branch.

> @Philippe, any news regarding the IRQ issue? Did the VM image help to
> reproduce the issue?
>

I did not have a chance to look at this yet although I intend to, no
spare cycles ATM. I'll follow up when I have news. Since it takes ~18h
on average to observe the issue on your end, I would not expect a quick
resolution though.

-- 
Philippe.

Re: v6.1.y-dovetail-rebase

[Jan Kiszka]

On 01.08.23 15:26, Philippe Gerum wrote:
> 
> Florian Bezdeka <florian.bezdeka@siemens.com> writes:
> 
>> On Mon, 2023-07-10 at 08:59 +0200, Florian Bezdeka wrote:
>>> On Thu, 2023-07-06 at 21:00 +0200, Philippe Gerum wrote:
>>>> Hi,
>>>>
>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>
>>>>> Hi Philippe,
>>>>>
>>>>> quick feedback on latest rebasing:
>>>>>
>>>>> https://source.denx.de/Xenomai/linux-dovetail/-/commit/8f155631c8b51731dfc2ae5145d4dcc68f2ed7ed
>>>>>
>>>>> This was likely accidentally folded, right?
>>>>>
>>>>
>>>> It looks so. This conditional statement appeared upstream during the
>>>> v6.0 cycle it seems, and was unfortunately left unfixed in the dovetail
>>>> patch for this entire series.
>>>>
>>>>> Furthermore, I will factor this change out into a separate commit in 
>>>>> merging v6.1.y-dovetail, for better traceability:
>>>>>
>>>>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>>>>> index ce8bdd804bc7..c843bf352999 100644
>>>>> --- a/arch/x86/mm/fault.c
>>>>> +++ b/arch/x86/mm/fault.c
>>>>> @@ -1466,7 +1466,7 @@ void do_user_addr_fault(struct pt_regs *regs,
>>>>>  
>>>>>  	/* The fault is fully completed (including releasing mmap lock) */
>>>>>  	if (fault & VM_FAULT_COMPLETED)
>>>>> -		return;
>>>>> +		goto out;
>>>>>  
>>>>>  	/*
>>>>>  	 * If we need to retry the mmap_lock has already been released,
>>>>>
>>>>> To my understanding, this was a dovetail fix that applied to previous 
>>>>> versions as well.
>>>>
>>>> Only to v6.0, however this series is not maintained dovetail-wise
>>>> anymore, so this stayed under the radar.
>>>
>>> FYI: This change fixes a real issue here. The 6.1-rebase branch made it
>>> through a 24h stress test while the "merge" branch failed. Happily
>>> waiting for the next release...
>>
>> Do we have a idea / plan when the next 6.1 dovetail release will
>> happen? My internal customer is waiting for that and I want to avoid
>> backporting to 6.1.34.
>>
> 
> There is a brewing rebase to v6.1.42 pending tests here, no challenging
> source conflict. I pushed the tree untagged to the v6.1.y-rebase branch
> if you want to give it a try before Jan updates the stable branch.
> 

We are testing against -rebase anyway (but that needs a trigger which I
just provided). The merging branch is only updated once there is a
release tagged.

Jan

>> @Philippe, any news regarding the IRQ issue? Did the VM image help to
>> reproduce the issue?
>>
> 
> I did not have a chance to look at this yet although I intend to, no
> spare cycles ATM. I'll follow up when I have news. Since it takes ~18h
> on average to observe the issue on your end, I would not expect a quick
> resolution though.
> 

-- 
Siemens AG, Technology
Linux Expert Center

Re: v6.1.y-dovetail-rebase

[Jan Kiszka]

On 09.08.23 07:52, Jan Kiszka wrote:
> On 01.08.23 15:26, Philippe Gerum wrote:
>>
>> Florian Bezdeka <florian.bezdeka@siemens.com> writes:
>>
>>> On Mon, 2023-07-10 at 08:59 +0200, Florian Bezdeka wrote:
>>>> On Thu, 2023-07-06 at 21:00 +0200, Philippe Gerum wrote:
>>>>> Hi,
>>>>>
>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>
>>>>>> Hi Philippe,
>>>>>>
>>>>>> quick feedback on latest rebasing:
>>>>>>
>>>>>> https://source.denx.de/Xenomai/linux-dovetail/-/commit/8f155631c8b51731dfc2ae5145d4dcc68f2ed7ed
>>>>>>
>>>>>> This was likely accidentally folded, right?
>>>>>>
>>>>>
>>>>> It looks so. This conditional statement appeared upstream during the
>>>>> v6.0 cycle it seems, and was unfortunately left unfixed in the dovetail
>>>>> patch for this entire series.
>>>>>
>>>>>> Furthermore, I will factor this change out into a separate commit in 
>>>>>> merging v6.1.y-dovetail, for better traceability:
>>>>>>
>>>>>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>>>>>> index ce8bdd804bc7..c843bf352999 100644
>>>>>> --- a/arch/x86/mm/fault.c
>>>>>> +++ b/arch/x86/mm/fault.c
>>>>>> @@ -1466,7 +1466,7 @@ void do_user_addr_fault(struct pt_regs *regs,
>>>>>>  
>>>>>>  	/* The fault is fully completed (including releasing mmap lock) */
>>>>>>  	if (fault & VM_FAULT_COMPLETED)
>>>>>> -		return;
>>>>>> +		goto out;
>>>>>>  
>>>>>>  	/*
>>>>>>  	 * If we need to retry the mmap_lock has already been released,
>>>>>>
>>>>>> To my understanding, this was a dovetail fix that applied to previous 
>>>>>> versions as well.
>>>>>
>>>>> Only to v6.0, however this series is not maintained dovetail-wise
>>>>> anymore, so this stayed under the radar.
>>>>
>>>> FYI: This change fixes a real issue here. The 6.1-rebase branch made it
>>>> through a 24h stress test while the "merge" branch failed. Happily
>>>> waiting for the next release...
>>>
>>> Do we have a idea / plan when the next 6.1 dovetail release will
>>> happen? My internal customer is waiting for that and I want to avoid
>>> backporting to 6.1.34.
>>>
>>
>> There is a brewing rebase to v6.1.42 pending tests here, no challenging
>> source conflict. I pushed the tree untagged to the v6.1.y-rebase branch
>> if you want to give it a try before Jan updates the stable branch.
>>
> 
> We are testing against -rebase anyway (but that needs a trigger which I
> just provided). The merging branch is only updated once there is a
> release tagged.
> 

Passed with the Xenomai 3 tests:

https://source.denx.de/Xenomai/xenomai-images/-/pipelines/17252

But can we update to 6.1.44 directly? Florian mentioned that there are
Downfall-related fixes in that release.

Jan

-- 
Siemens AG, Technology
Linux Expert Center

Re: v6.1.y-dovetail-rebase

[Philippe Gerum]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 09.08.23 07:52, Jan Kiszka wrote:
>> On 01.08.23 15:26, Philippe Gerum wrote:
>>>
>>> Florian Bezdeka <florian.bezdeka@siemens.com> writes:
>>>
>>>> On Mon, 2023-07-10 at 08:59 +0200, Florian Bezdeka wrote:
>>>>> On Thu, 2023-07-06 at 21:00 +0200, Philippe Gerum wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>
>>>>>>> Hi Philippe,
>>>>>>>
>>>>>>> quick feedback on latest rebasing:
>>>>>>>
>>>>>>> https://source.denx.de/Xenomai/linux-dovetail/-/commit/8f155631c8b51731dfc2ae5145d4dcc68f2ed7ed
>>>>>>>
>>>>>>> This was likely accidentally folded, right?
>>>>>>>
>>>>>>
>>>>>> It looks so. This conditional statement appeared upstream during the
>>>>>> v6.0 cycle it seems, and was unfortunately left unfixed in the dovetail
>>>>>> patch for this entire series.
>>>>>>
>>>>>>> Furthermore, I will factor this change out into a separate commit in 
>>>>>>> merging v6.1.y-dovetail, for better traceability:
>>>>>>>
>>>>>>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>>>>>>> index ce8bdd804bc7..c843bf352999 100644
>>>>>>> --- a/arch/x86/mm/fault.c
>>>>>>> +++ b/arch/x86/mm/fault.c
>>>>>>> @@ -1466,7 +1466,7 @@ void do_user_addr_fault(struct pt_regs *regs,
>>>>>>>  
>>>>>>>  	/* The fault is fully completed (including releasing mmap lock) */
>>>>>>>  	if (fault & VM_FAULT_COMPLETED)
>>>>>>> -		return;
>>>>>>> +		goto out;
>>>>>>>  
>>>>>>>  	/*
>>>>>>>  	 * If we need to retry the mmap_lock has already been released,
>>>>>>>
>>>>>>> To my understanding, this was a dovetail fix that applied to previous 
>>>>>>> versions as well.
>>>>>>
>>>>>> Only to v6.0, however this series is not maintained dovetail-wise
>>>>>> anymore, so this stayed under the radar.
>>>>>
>>>>> FYI: This change fixes a real issue here. The 6.1-rebase branch made it
>>>>> through a 24h stress test while the "merge" branch failed. Happily
>>>>> waiting for the next release...
>>>>
>>>> Do we have a idea / plan when the next 6.1 dovetail release will
>>>> happen? My internal customer is waiting for that and I want to avoid
>>>> backporting to 6.1.34.
>>>>
>>>
>>> There is a brewing rebase to v6.1.42 pending tests here, no challenging
>>> source conflict. I pushed the tree untagged to the v6.1.y-rebase branch
>>> if you want to give it a try before Jan updates the stable branch.
>>>
>> 
>> We are testing against -rebase anyway (but that needs a trigger which I
>> just provided). The merging branch is only updated once there is a
>> release tagged.
>> 
>
> Passed with the Xenomai 3 tests:
>
> https://source.denx.de/Xenomai/xenomai-images/-/pipelines/17252
>
> But can we update to 6.1.44 directly? Florian mentioned that there are
> Downfall-related fixes in that release.
>
> Jan

yes, .44 is actually brewing here already.

-- 
Philippe.

Re: v6.1.y-dovetail-rebase

[Jan Kiszka]

On 09.08.23 15:11, Philippe Gerum wrote:
> 
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
>> On 09.08.23 07:52, Jan Kiszka wrote:
>>> On 01.08.23 15:26, Philippe Gerum wrote:
>>>>
>>>> Florian Bezdeka <florian.bezdeka@siemens.com> writes:
>>>>
>>>>> On Mon, 2023-07-10 at 08:59 +0200, Florian Bezdeka wrote:
>>>>>> On Thu, 2023-07-06 at 21:00 +0200, Philippe Gerum wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>>
>>>>>>>> Hi Philippe,
>>>>>>>>
>>>>>>>> quick feedback on latest rebasing:
>>>>>>>>
>>>>>>>> https://source.denx.de/Xenomai/linux-dovetail/-/commit/8f155631c8b51731dfc2ae5145d4dcc68f2ed7ed
>>>>>>>>
>>>>>>>> This was likely accidentally folded, right?
>>>>>>>>
>>>>>>>
>>>>>>> It looks so. This conditional statement appeared upstream during the
>>>>>>> v6.0 cycle it seems, and was unfortunately left unfixed in the dovetail
>>>>>>> patch for this entire series.
>>>>>>>
>>>>>>>> Furthermore, I will factor this change out into a separate commit in 
>>>>>>>> merging v6.1.y-dovetail, for better traceability:
>>>>>>>>
>>>>>>>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>>>>>>>> index ce8bdd804bc7..c843bf352999 100644
>>>>>>>> --- a/arch/x86/mm/fault.c
>>>>>>>> +++ b/arch/x86/mm/fault.c
>>>>>>>> @@ -1466,7 +1466,7 @@ void do_user_addr_fault(struct pt_regs *regs,
>>>>>>>>  
>>>>>>>>  	/* The fault is fully completed (including releasing mmap lock) */
>>>>>>>>  	if (fault & VM_FAULT_COMPLETED)
>>>>>>>> -		return;
>>>>>>>> +		goto out;
>>>>>>>>  
>>>>>>>>  	/*
>>>>>>>>  	 * If we need to retry the mmap_lock has already been released,
>>>>>>>>
>>>>>>>> To my understanding, this was a dovetail fix that applied to previous 
>>>>>>>> versions as well.
>>>>>>>
>>>>>>> Only to v6.0, however this series is not maintained dovetail-wise
>>>>>>> anymore, so this stayed under the radar.
>>>>>>
>>>>>> FYI: This change fixes a real issue here. The 6.1-rebase branch made it
>>>>>> through a 24h stress test while the "merge" branch failed. Happily
>>>>>> waiting for the next release...
>>>>>
>>>>> Do we have a idea / plan when the next 6.1 dovetail release will
>>>>> happen? My internal customer is waiting for that and I want to avoid
>>>>> backporting to 6.1.34.
>>>>>
>>>>
>>>> There is a brewing rebase to v6.1.42 pending tests here, no challenging
>>>> source conflict. I pushed the tree untagged to the v6.1.y-rebase branch
>>>> if you want to give it a try before Jan updates the stable branch.
>>>>
>>>
>>> We are testing against -rebase anyway (but that needs a trigger which I
>>> just provided). The merging branch is only updated once there is a
>>> release tagged.
>>>
>>
>> Passed with the Xenomai 3 tests:
>>
>> https://source.denx.de/Xenomai/xenomai-images/-/pipelines/17252
>>
>> But can we update to 6.1.44 directly? Florian mentioned that there are
>> Downfall-related fixes in that release.
>>
>> Jan
> 
> yes, .44 is actually brewing here already.
> 

Now we are .45 even. Will this one be tagged? CI looks good so far.

Jan

-- 
Siemens AG, Technology
Linux Expert Center

Re: v6.1.y-dovetail-rebase

[Philippe Gerum]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 09.08.23 15:11, Philippe Gerum wrote:
>> 
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>> 
>>> On 09.08.23 07:52, Jan Kiszka wrote:
>>>> On 01.08.23 15:26, Philippe Gerum wrote:
>>>>>
>>>>> Florian Bezdeka <florian.bezdeka@siemens.com> writes:
>>>>>
>>>>>> On Mon, 2023-07-10 at 08:59 +0200, Florian Bezdeka wrote:
>>>>>>> On Thu, 2023-07-06 at 21:00 +0200, Philippe Gerum wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>>>
>>>>>>>>> Hi Philippe,
>>>>>>>>>
>>>>>>>>> quick feedback on latest rebasing:
>>>>>>>>>
>>>>>>>>> https://source.denx.de/Xenomai/linux-dovetail/-/commit/8f155631c8b51731dfc2ae5145d4dcc68f2ed7ed
>>>>>>>>>
>>>>>>>>> This was likely accidentally folded, right?
>>>>>>>>>
>>>>>>>>
>>>>>>>> It looks so. This conditional statement appeared upstream during the
>>>>>>>> v6.0 cycle it seems, and was unfortunately left unfixed in the dovetail
>>>>>>>> patch for this entire series.
>>>>>>>>
>>>>>>>>> Furthermore, I will factor this change out into a separate commit in 
>>>>>>>>> merging v6.1.y-dovetail, for better traceability:
>>>>>>>>>
>>>>>>>>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>>>>>>>>> index ce8bdd804bc7..c843bf352999 100644
>>>>>>>>> --- a/arch/x86/mm/fault.c
>>>>>>>>> +++ b/arch/x86/mm/fault.c
>>>>>>>>> @@ -1466,7 +1466,7 @@ void do_user_addr_fault(struct pt_regs *regs,
>>>>>>>>>  
>>>>>>>>>  	/* The fault is fully completed (including releasing mmap lock) */
>>>>>>>>>  	if (fault & VM_FAULT_COMPLETED)
>>>>>>>>> -		return;
>>>>>>>>> +		goto out;
>>>>>>>>>  
>>>>>>>>>  	/*
>>>>>>>>>  	 * If we need to retry the mmap_lock has already been released,
>>>>>>>>>
>>>>>>>>> To my understanding, this was a dovetail fix that applied to previous 
>>>>>>>>> versions as well.
>>>>>>>>
>>>>>>>> Only to v6.0, however this series is not maintained dovetail-wise
>>>>>>>> anymore, so this stayed under the radar.
>>>>>>>
>>>>>>> FYI: This change fixes a real issue here. The 6.1-rebase branch made it
>>>>>>> through a 24h stress test while the "merge" branch failed. Happily
>>>>>>> waiting for the next release...
>>>>>>
>>>>>> Do we have a idea / plan when the next 6.1 dovetail release will
>>>>>> happen? My internal customer is waiting for that and I want to avoid
>>>>>> backporting to 6.1.34.
>>>>>>
>>>>>
>>>>> There is a brewing rebase to v6.1.42 pending tests here, no challenging
>>>>> source conflict. I pushed the tree untagged to the v6.1.y-rebase branch
>>>>> if you want to give it a try before Jan updates the stable branch.
>>>>>
>>>>
>>>> We are testing against -rebase anyway (but that needs a trigger which I
>>>> just provided). The merging branch is only updated once there is a
>>>> release tagged.
>>>>
>>>
>>> Passed with the Xenomai 3 tests:
>>>
>>> https://source.denx.de/Xenomai/xenomai-images/-/pipelines/17252
>>>
>>> But can we update to 6.1.44 directly? Florian mentioned that there are
>>> Downfall-related fixes in that release.
>>>
>>> Jan
>> 
>> yes, .44 is actually brewing here already.
>> 
>
> Now we are .45 even. Will this one be tagged? CI looks good so far.
>

Nope, .44 was broken due to [1]. .45 looks better with this fix in
place. This issue triggered on kvm/arm64 w/ PROVE_LOCKING enabled.

[1] https://source.denx.de/Xenomai/linux-dovetail/-/commit/60ae6e4ea6a074698be4d999e96e9c3697b18ea1

-- 
Philippe.

Re: v6.1.y-dovetail-rebase

[Jan Kiszka]

On 15.08.23 12:18, Philippe Gerum wrote:
> 
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
>> On 09.08.23 15:11, Philippe Gerum wrote:
>>>
>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>
>>>> On 09.08.23 07:52, Jan Kiszka wrote:
>>>>> On 01.08.23 15:26, Philippe Gerum wrote:
>>>>>>
>>>>>> Florian Bezdeka <florian.bezdeka@siemens.com> writes:
>>>>>>
>>>>>>> On Mon, 2023-07-10 at 08:59 +0200, Florian Bezdeka wrote:
>>>>>>>> On Thu, 2023-07-06 at 21:00 +0200, Philippe Gerum wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>>>>
>>>>>>>>>> Hi Philippe,
>>>>>>>>>>
>>>>>>>>>> quick feedback on latest rebasing:
>>>>>>>>>>
>>>>>>>>>> https://source.denx.de/Xenomai/linux-dovetail/-/commit/8f155631c8b51731dfc2ae5145d4dcc68f2ed7ed
>>>>>>>>>>
>>>>>>>>>> This was likely accidentally folded, right?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It looks so. This conditional statement appeared upstream during the
>>>>>>>>> v6.0 cycle it seems, and was unfortunately left unfixed in the dovetail
>>>>>>>>> patch for this entire series.
>>>>>>>>>
>>>>>>>>>> Furthermore, I will factor this change out into a separate commit in 
>>>>>>>>>> merging v6.1.y-dovetail, for better traceability:
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>>>>>>>>>> index ce8bdd804bc7..c843bf352999 100644
>>>>>>>>>> --- a/arch/x86/mm/fault.c
>>>>>>>>>> +++ b/arch/x86/mm/fault.c
>>>>>>>>>> @@ -1466,7 +1466,7 @@ void do_user_addr_fault(struct pt_regs *regs,
>>>>>>>>>>  
>>>>>>>>>>  	/* The fault is fully completed (including releasing mmap lock) */
>>>>>>>>>>  	if (fault & VM_FAULT_COMPLETED)
>>>>>>>>>> -		return;
>>>>>>>>>> +		goto out;
>>>>>>>>>>  
>>>>>>>>>>  	/*
>>>>>>>>>>  	 * If we need to retry the mmap_lock has already been released,
>>>>>>>>>>
>>>>>>>>>> To my understanding, this was a dovetail fix that applied to previous 
>>>>>>>>>> versions as well.
>>>>>>>>>
>>>>>>>>> Only to v6.0, however this series is not maintained dovetail-wise
>>>>>>>>> anymore, so this stayed under the radar.
>>>>>>>>
>>>>>>>> FYI: This change fixes a real issue here. The 6.1-rebase branch made it
>>>>>>>> through a 24h stress test while the "merge" branch failed. Happily
>>>>>>>> waiting for the next release...
>>>>>>>
>>>>>>> Do we have a idea / plan when the next 6.1 dovetail release will
>>>>>>> happen? My internal customer is waiting for that and I want to avoid
>>>>>>> backporting to 6.1.34.
>>>>>>>
>>>>>>
>>>>>> There is a brewing rebase to v6.1.42 pending tests here, no challenging
>>>>>> source conflict. I pushed the tree untagged to the v6.1.y-rebase branch
>>>>>> if you want to give it a try before Jan updates the stable branch.
>>>>>>
>>>>>
>>>>> We are testing against -rebase anyway (but that needs a trigger which I
>>>>> just provided). The merging branch is only updated once there is a
>>>>> release tagged.
>>>>>
>>>>
>>>> Passed with the Xenomai 3 tests:
>>>>
>>>> https://source.denx.de/Xenomai/xenomai-images/-/pipelines/17252
>>>>
>>>> But can we update to 6.1.44 directly? Florian mentioned that there are
>>>> Downfall-related fixes in that release.
>>>>
>>>> Jan
>>>
>>> yes, .44 is actually brewing here already.
>>>
>>
>> Now we are .45 even. Will this one be tagged? CI looks good so far.
>>
> 
> Nope, .44 was broken due to [1]. .45 looks better with this fix in
> place. This issue triggered on kvm/arm64 w/ PROVE_LOCKING enabled.
> 
> [1] https://source.denx.de/Xenomai/linux-dovetail/-/commit/60ae6e4ea6a074698be4d999e96e9c3697b18ea1
> 

Thanks for tagging v6.1.45-dovetail1 and v5.15.126-dovetail1, I've
updated the merging branches accordingly. How about 5.10?

Jan

-- 
Siemens AG, Technology
Linux Expert Center

Re: v6.1.y-dovetail-rebase

[Philippe Gerum]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 15.08.23 12:18, Philippe Gerum wrote:
>> 
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>> 
>>> On 09.08.23 15:11, Philippe Gerum wrote:
>>>>
>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>
>>>>> On 09.08.23 07:52, Jan Kiszka wrote:
>>>>>> On 01.08.23 15:26, Philippe Gerum wrote:
>>>>>>>
>>>>>>> Florian Bezdeka <florian.bezdeka@siemens.com> writes:
>>>>>>>
>>>>>>>> On Mon, 2023-07-10 at 08:59 +0200, Florian Bezdeka wrote:
>>>>>>>>> On Thu, 2023-07-06 at 21:00 +0200, Philippe Gerum wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>>>>>
>>>>>>>>>>> Hi Philippe,
>>>>>>>>>>>
>>>>>>>>>>> quick feedback on latest rebasing:
>>>>>>>>>>>
>>>>>>>>>>> https://source.denx.de/Xenomai/linux-dovetail/-/commit/8f155631c8b51731dfc2ae5145d4dcc68f2ed7ed
>>>>>>>>>>>
>>>>>>>>>>> This was likely accidentally folded, right?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It looks so. This conditional statement appeared upstream during the
>>>>>>>>>> v6.0 cycle it seems, and was unfortunately left unfixed in the dovetail
>>>>>>>>>> patch for this entire series.
>>>>>>>>>>
>>>>>>>>>>> Furthermore, I will factor this change out into a separate commit in 
>>>>>>>>>>> merging v6.1.y-dovetail, for better traceability:
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>>>>>>>>>>> index ce8bdd804bc7..c843bf352999 100644
>>>>>>>>>>> --- a/arch/x86/mm/fault.c
>>>>>>>>>>> +++ b/arch/x86/mm/fault.c
>>>>>>>>>>> @@ -1466,7 +1466,7 @@ void do_user_addr_fault(struct pt_regs *regs,
>>>>>>>>>>>  
>>>>>>>>>>>  	/* The fault is fully completed (including releasing mmap lock) */
>>>>>>>>>>>  	if (fault & VM_FAULT_COMPLETED)
>>>>>>>>>>> -		return;
>>>>>>>>>>> +		goto out;
>>>>>>>>>>>  
>>>>>>>>>>>  	/*
>>>>>>>>>>>  	 * If we need to retry the mmap_lock has already been released,
>>>>>>>>>>>
>>>>>>>>>>> To my understanding, this was a dovetail fix that applied to previous 
>>>>>>>>>>> versions as well.
>>>>>>>>>>
>>>>>>>>>> Only to v6.0, however this series is not maintained dovetail-wise
>>>>>>>>>> anymore, so this stayed under the radar.
>>>>>>>>>
>>>>>>>>> FYI: This change fixes a real issue here. The 6.1-rebase branch made it
>>>>>>>>> through a 24h stress test while the "merge" branch failed. Happily
>>>>>>>>> waiting for the next release...
>>>>>>>>
>>>>>>>> Do we have a idea / plan when the next 6.1 dovetail release will
>>>>>>>> happen? My internal customer is waiting for that and I want to avoid
>>>>>>>> backporting to 6.1.34.
>>>>>>>>
>>>>>>>
>>>>>>> There is a brewing rebase to v6.1.42 pending tests here, no challenging
>>>>>>> source conflict. I pushed the tree untagged to the v6.1.y-rebase branch
>>>>>>> if you want to give it a try before Jan updates the stable branch.
>>>>>>>
>>>>>>
>>>>>> We are testing against -rebase anyway (but that needs a trigger which I
>>>>>> just provided). The merging branch is only updated once there is a
>>>>>> release tagged.
>>>>>>
>>>>>
>>>>> Passed with the Xenomai 3 tests:
>>>>>
>>>>> https://source.denx.de/Xenomai/xenomai-images/-/pipelines/17252
>>>>>
>>>>> But can we update to 6.1.44 directly? Florian mentioned that there are
>>>>> Downfall-related fixes in that release.
>>>>>
>>>>> Jan
>>>>
>>>> yes, .44 is actually brewing here already.
>>>>
>>>
>>> Now we are .45 even. Will this one be tagged? CI looks good so far.
>>>
>> 
>> Nope, .44 was broken due to [1]. .45 looks better with this fix in
>> place. This issue triggered on kvm/arm64 w/ PROVE_LOCKING enabled.
>> 
>> [1] https://source.denx.de/Xenomai/linux-dovetail/-/commit/60ae6e4ea6a074698be4d999e96e9c3697b18ea1
>> 
>
> Thanks for tagging v6.1.45-dovetail1 and v5.15.126-dovetail1, I've
> updated the merging branches accordingly. How about 5.10?
>

Not done with testing yet.

-- 
Philippe.

Re: v6.1.y-dovetail-rebase

[Jan Kiszka]

On 21.08.23 08:41, Philippe Gerum wrote:
> 
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
>> On 15.08.23 12:18, Philippe Gerum wrote:
>>>
>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>
>>>> On 09.08.23 15:11, Philippe Gerum wrote:
>>>>>
>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>
>>>>>> On 09.08.23 07:52, Jan Kiszka wrote:
>>>>>>> On 01.08.23 15:26, Philippe Gerum wrote:
>>>>>>>>
>>>>>>>> Florian Bezdeka <florian.bezdeka@siemens.com> writes:
>>>>>>>>
>>>>>>>>> On Mon, 2023-07-10 at 08:59 +0200, Florian Bezdeka wrote:
>>>>>>>>>> On Thu, 2023-07-06 at 21:00 +0200, Philippe Gerum wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Philippe,
>>>>>>>>>>>>
>>>>>>>>>>>> quick feedback on latest rebasing:
>>>>>>>>>>>>
>>>>>>>>>>>> https://source.denx.de/Xenomai/linux-dovetail/-/commit/8f155631c8b51731dfc2ae5145d4dcc68f2ed7ed
>>>>>>>>>>>>
>>>>>>>>>>>> This was likely accidentally folded, right?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It looks so. This conditional statement appeared upstream during the
>>>>>>>>>>> v6.0 cycle it seems, and was unfortunately left unfixed in the dovetail
>>>>>>>>>>> patch for this entire series.
>>>>>>>>>>>
>>>>>>>>>>>> Furthermore, I will factor this change out into a separate commit in 
>>>>>>>>>>>> merging v6.1.y-dovetail, for better traceability:
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>>>>>>>>>>>> index ce8bdd804bc7..c843bf352999 100644
>>>>>>>>>>>> --- a/arch/x86/mm/fault.c
>>>>>>>>>>>> +++ b/arch/x86/mm/fault.c
>>>>>>>>>>>> @@ -1466,7 +1466,7 @@ void do_user_addr_fault(struct pt_regs *regs,
>>>>>>>>>>>>  
>>>>>>>>>>>>  	/* The fault is fully completed (including releasing mmap lock) */
>>>>>>>>>>>>  	if (fault & VM_FAULT_COMPLETED)
>>>>>>>>>>>> -		return;
>>>>>>>>>>>> +		goto out;
>>>>>>>>>>>>  
>>>>>>>>>>>>  	/*
>>>>>>>>>>>>  	 * If we need to retry the mmap_lock has already been released,
>>>>>>>>>>>>
>>>>>>>>>>>> To my understanding, this was a dovetail fix that applied to previous 
>>>>>>>>>>>> versions as well.
>>>>>>>>>>>
>>>>>>>>>>> Only to v6.0, however this series is not maintained dovetail-wise
>>>>>>>>>>> anymore, so this stayed under the radar.
>>>>>>>>>>
>>>>>>>>>> FYI: This change fixes a real issue here. The 6.1-rebase branch made it
>>>>>>>>>> through a 24h stress test while the "merge" branch failed. Happily
>>>>>>>>>> waiting for the next release...
>>>>>>>>>
>>>>>>>>> Do we have a idea / plan when the next 6.1 dovetail release will
>>>>>>>>> happen? My internal customer is waiting for that and I want to avoid
>>>>>>>>> backporting to 6.1.34.
>>>>>>>>>
>>>>>>>>
>>>>>>>> There is a brewing rebase to v6.1.42 pending tests here, no challenging
>>>>>>>> source conflict. I pushed the tree untagged to the v6.1.y-rebase branch
>>>>>>>> if you want to give it a try before Jan updates the stable branch.
>>>>>>>>
>>>>>>>
>>>>>>> We are testing against -rebase anyway (but that needs a trigger which I
>>>>>>> just provided). The merging branch is only updated once there is a
>>>>>>> release tagged.
>>>>>>>
>>>>>>
>>>>>> Passed with the Xenomai 3 tests:
>>>>>>
>>>>>> https://source.denx.de/Xenomai/xenomai-images/-/pipelines/17252
>>>>>>
>>>>>> But can we update to 6.1.44 directly? Florian mentioned that there are
>>>>>> Downfall-related fixes in that release.
>>>>>>
>>>>>> Jan
>>>>>
>>>>> yes, .44 is actually brewing here already.
>>>>>
>>>>
>>>> Now we are .45 even. Will this one be tagged? CI looks good so far.
>>>>
>>>
>>> Nope, .44 was broken due to [1]. .45 looks better with this fix in
>>> place. This issue triggered on kvm/arm64 w/ PROVE_LOCKING enabled.
>>>
>>> [1] https://source.denx.de/Xenomai/linux-dovetail/-/commit/60ae6e4ea6a074698be4d999e96e9c3697b18ea1
>>>
>>
>> Thanks for tagging v6.1.45-dovetail1 and v5.15.126-dovetail1, I've
>> updated the merging branches accordingly. How about 5.10?
>>
> 
> Not done with testing yet.
> 

If you push to -rebase, we could join that effort.

Jan

-- 
Siemens AG, Technology
Linux Expert Center

Re: v6.1.y-dovetail-rebase

[Philippe Gerum]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 21.08.23 08:41, Philippe Gerum wrote:
>> 
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>> 
>>> On 15.08.23 12:18, Philippe Gerum wrote:
>>>>
>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>
>>>>> On 09.08.23 15:11, Philippe Gerum wrote:
>>>>>>
>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>
>>>>>>> On 09.08.23 07:52, Jan Kiszka wrote:
>>>>>>>> On 01.08.23 15:26, Philippe Gerum wrote:
>>>>>>>>>
>>>>>>>>> Florian Bezdeka <florian.bezdeka@siemens.com> writes:
>>>>>>>>>
>>>>>>>>>> On Mon, 2023-07-10 at 08:59 +0200, Florian Bezdeka wrote:
>>>>>>>>>>> On Thu, 2023-07-06 at 21:00 +0200, Philippe Gerum wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Philippe,
>>>>>>>>>>>>>
>>>>>>>>>>>>> quick feedback on latest rebasing:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://source.denx.de/Xenomai/linux-dovetail/-/commit/8f155631c8b51731dfc2ae5145d4dcc68f2ed7ed
>>>>>>>>>>>>>
>>>>>>>>>>>>> This was likely accidentally folded, right?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It looks so. This conditional statement appeared upstream during the
>>>>>>>>>>>> v6.0 cycle it seems, and was unfortunately left unfixed in the dovetail
>>>>>>>>>>>> patch for this entire series.
>>>>>>>>>>>>
>>>>>>>>>>>>> Furthermore, I will factor this change out into a separate commit in 
>>>>>>>>>>>>> merging v6.1.y-dovetail, for better traceability:
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>>>>>>>>>>>>> index ce8bdd804bc7..c843bf352999 100644
>>>>>>>>>>>>> --- a/arch/x86/mm/fault.c
>>>>>>>>>>>>> +++ b/arch/x86/mm/fault.c
>>>>>>>>>>>>> @@ -1466,7 +1466,7 @@ void do_user_addr_fault(struct pt_regs *regs,
>>>>>>>>>>>>>  
>>>>>>>>>>>>>  	/* The fault is fully completed (including releasing mmap lock) */
>>>>>>>>>>>>>  	if (fault & VM_FAULT_COMPLETED)
>>>>>>>>>>>>> -		return;
>>>>>>>>>>>>> +		goto out;
>>>>>>>>>>>>>  
>>>>>>>>>>>>>  	/*
>>>>>>>>>>>>>  	 * If we need to retry the mmap_lock has already been released,
>>>>>>>>>>>>>
>>>>>>>>>>>>> To my understanding, this was a dovetail fix that applied to previous 
>>>>>>>>>>>>> versions as well.
>>>>>>>>>>>>
>>>>>>>>>>>> Only to v6.0, however this series is not maintained dovetail-wise
>>>>>>>>>>>> anymore, so this stayed under the radar.
>>>>>>>>>>>
>>>>>>>>>>> FYI: This change fixes a real issue here. The 6.1-rebase branch made it
>>>>>>>>>>> through a 24h stress test while the "merge" branch failed. Happily
>>>>>>>>>>> waiting for the next release...
>>>>>>>>>>
>>>>>>>>>> Do we have a idea / plan when the next 6.1 dovetail release will
>>>>>>>>>> happen? My internal customer is waiting for that and I want to avoid
>>>>>>>>>> backporting to 6.1.34.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> There is a brewing rebase to v6.1.42 pending tests here, no challenging
>>>>>>>>> source conflict. I pushed the tree untagged to the v6.1.y-rebase branch
>>>>>>>>> if you want to give it a try before Jan updates the stable branch.
>>>>>>>>>
>>>>>>>>
>>>>>>>> We are testing against -rebase anyway (but that needs a trigger which I
>>>>>>>> just provided). The merging branch is only updated once there is a
>>>>>>>> release tagged.
>>>>>>>>
>>>>>>>
>>>>>>> Passed with the Xenomai 3 tests:
>>>>>>>
>>>>>>> https://source.denx.de/Xenomai/xenomai-images/-/pipelines/17252
>>>>>>>
>>>>>>> But can we update to 6.1.44 directly? Florian mentioned that there are
>>>>>>> Downfall-related fixes in that release.
>>>>>>>
>>>>>>> Jan
>>>>>>
>>>>>> yes, .44 is actually brewing here already.
>>>>>>
>>>>>
>>>>> Now we are .45 even. Will this one be tagged? CI looks good so far.
>>>>>
>>>>
>>>> Nope, .44 was broken due to [1]. .45 looks better with this fix in
>>>> place. This issue triggered on kvm/arm64 w/ PROVE_LOCKING enabled.
>>>>
>>>> [1] https://source.denx.de/Xenomai/linux-dovetail/-/commit/60ae6e4ea6a074698be4d999e96e9c3697b18ea1
>>>>
>>>
>>> Thanks for tagging v6.1.45-dovetail1 and v5.15.126-dovetail1, I've
>>> updated the merging branches accordingly. How about 5.10?
>>>
>> 
>> Not done with testing yet.
>> 
>
> If you push to -rebase, we could join that effort.
>

This would help, thanks. Pushed now.

-- 
Philippe.

Re: v6.1.y-dovetail-rebase

[Jan Kiszka]

On 21.08.23 15:09, Philippe Gerum wrote:
> 
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
>> On 21.08.23 08:41, Philippe Gerum wrote:
>>>
>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>
>>>> On 15.08.23 12:18, Philippe Gerum wrote:
>>>>>
>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>
>>>>>> On 09.08.23 15:11, Philippe Gerum wrote:
>>>>>>>
>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>>
>>>>>>>> On 09.08.23 07:52, Jan Kiszka wrote:
>>>>>>>>> On 01.08.23 15:26, Philippe Gerum wrote:
>>>>>>>>>>
>>>>>>>>>> Florian Bezdeka <florian.bezdeka@siemens.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On Mon, 2023-07-10 at 08:59 +0200, Florian Bezdeka wrote:
>>>>>>>>>>>> On Thu, 2023-07-06 at 21:00 +0200, Philippe Gerum wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Philippe,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> quick feedback on latest rebasing:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://source.denx.de/Xenomai/linux-dovetail/-/commit/8f155631c8b51731dfc2ae5145d4dcc68f2ed7ed
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This was likely accidentally folded, right?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It looks so. This conditional statement appeared upstream during the
>>>>>>>>>>>>> v6.0 cycle it seems, and was unfortunately left unfixed in the dovetail
>>>>>>>>>>>>> patch for this entire series.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Furthermore, I will factor this change out into a separate commit in 
>>>>>>>>>>>>>> merging v6.1.y-dovetail, for better traceability:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>>>>>>>>>>>>>> index ce8bdd804bc7..c843bf352999 100644
>>>>>>>>>>>>>> --- a/arch/x86/mm/fault.c
>>>>>>>>>>>>>> +++ b/arch/x86/mm/fault.c
>>>>>>>>>>>>>> @@ -1466,7 +1466,7 @@ void do_user_addr_fault(struct pt_regs *regs,
>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>  	/* The fault is fully completed (including releasing mmap lock) */
>>>>>>>>>>>>>>  	if (fault & VM_FAULT_COMPLETED)
>>>>>>>>>>>>>> -		return;
>>>>>>>>>>>>>> +		goto out;
>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>  	/*
>>>>>>>>>>>>>>  	 * If we need to retry the mmap_lock has already been released,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To my understanding, this was a dovetail fix that applied to previous 
>>>>>>>>>>>>>> versions as well.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Only to v6.0, however this series is not maintained dovetail-wise
>>>>>>>>>>>>> anymore, so this stayed under the radar.
>>>>>>>>>>>>
>>>>>>>>>>>> FYI: This change fixes a real issue here. The 6.1-rebase branch made it
>>>>>>>>>>>> through a 24h stress test while the "merge" branch failed. Happily
>>>>>>>>>>>> waiting for the next release...
>>>>>>>>>>>
>>>>>>>>>>> Do we have a idea / plan when the next 6.1 dovetail release will
>>>>>>>>>>> happen? My internal customer is waiting for that and I want to avoid
>>>>>>>>>>> backporting to 6.1.34.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> There is a brewing rebase to v6.1.42 pending tests here, no challenging
>>>>>>>>>> source conflict. I pushed the tree untagged to the v6.1.y-rebase branch
>>>>>>>>>> if you want to give it a try before Jan updates the stable branch.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We are testing against -rebase anyway (but that needs a trigger which I
>>>>>>>>> just provided). The merging branch is only updated once there is a
>>>>>>>>> release tagged.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Passed with the Xenomai 3 tests:
>>>>>>>>
>>>>>>>> https://source.denx.de/Xenomai/xenomai-images/-/pipelines/17252
>>>>>>>>
>>>>>>>> But can we update to 6.1.44 directly? Florian mentioned that there are
>>>>>>>> Downfall-related fixes in that release.
>>>>>>>>
>>>>>>>> Jan
>>>>>>>
>>>>>>> yes, .44 is actually brewing here already.
>>>>>>>
>>>>>>
>>>>>> Now we are .45 even. Will this one be tagged? CI looks good so far.
>>>>>>
>>>>>
>>>>> Nope, .44 was broken due to [1]. .45 looks better with this fix in
>>>>> place. This issue triggered on kvm/arm64 w/ PROVE_LOCKING enabled.
>>>>>
>>>>> [1] https://source.denx.de/Xenomai/linux-dovetail/-/commit/60ae6e4ea6a074698be4d999e96e9c3697b18ea1
>>>>>
>>>>
>>>> Thanks for tagging v6.1.45-dovetail1 and v5.15.126-dovetail1, I've
>>>> updated the merging branches accordingly. How about 5.10?
>>>>
>>>
>>> Not done with testing yet.
>>>
>>
>> If you push to -rebase, we could join that effort.
>>
> 
> This would help, thanks. Pushed now.
> 

Tests went well:
https://source.denx.de/Xenomai/xenomai-images/-/jobs/681220
https://source.denx.de/Xenomai/xenomai-images/-/jobs/681219
https://source.denx.de/Xenomai/xenomai-images/-/jobs/681218

Jan

-- 
Siemens AG, Technology
Linux Expert Center