Re: v6.1.y-dovetail-rebase

[Philippe Gerum <rpm@xenomai.org>]

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.