[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251130112008.DZYHlSPm@linutronix.de>
Date: Sun, 30 Nov 2025 12:20:08 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Xie Yuanbin <xieyuanbin1@...wei.com>, akpm@...ux-foundation.org,
arnd@...db.de, brauner@...nel.org, david.laight@...box.com,
hch@....de, jack@...e.com, kuninori.morimoto.gx@...esas.com,
liaohua4@...wei.com, lilinjie8@...wei.com,
linux-arm-kernel@...ts.infradead.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
lorenzo.stoakes@...cle.com, marc.zyngier@....com, nico@...xnic.net,
pangliyuan1@...wei.com, pfalcato@...e.de, punitagrawal@...il.com,
rjw@...ysocki.net, rppt@...nel.org, tony@...mide.com,
vbabka@...e.cz, viro@...iv.linux.org.uk, wangkefeng.wang@...wei.com,
will@...nel.org, wozizhi@...weicloud.com
Subject: Re: [RFC PATCH v2 1/2] ARM/mm/fault: always goto bad_area when
handling with page faults of kernel address
On 2025-11-28 17:34:31 [+0000], Russell King (Oracle) wrote:
> On Fri, Nov 28, 2025 at 06:22:42PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2025-11-28 17:01:18 [+0000], Russell King (Oracle) wrote:
> > > > I hope Russell will add them once he gets to it. They got reviewed, I
> > > > added them to the patch system.
> > >
> > > I'm not sure which patches you're talking about, but discussion is
> > > still ongoing, so it would be greatly premature to merge anything.
> >
> > This thread
> > https://lore.kernel.org/all/20251110145555.2555055-1-bigeasy@linutronix.de/
> >
> > and the patches are 9459/1 to 9463/1 in your patch system. They address
> > other issues, not this one.
>
> Oh, the branch predictor issue. Yea, I'm not keen on changing that
> because I'm not sure if it's correct (the knowledge for this has
> long since evaporated.) There have been multiple attempts at fixing
> this in the past, and I've previously pointed out problems with
> them when I _did_ have the knowledge. Have you looked back in the
> archives to see whether any of that feedback I've given in the past
> is relevant?
I dug up the emails from 2021, 2019 and you complained that I open the
interrupts too early. Now I moved the invocation of hardening the branch
predictor to happen before the interrupts are enabled. Based on that it
should not raise to any complains.
> > So Will suggested to let change the handler and handle this case. The
> > other patch is avoiding handling addr > TASK_SIZE.
> > Any preferences from your side?
>
> ... and now we have a new proposal from Linus. I'm not intending to
> do anything on this new problem until the discussion calms down and
> we stop getting new solutions.
Okay. If we could please sort out the first part then it might be easier
to move on here once the dust settled.
Sebastian
Powered by blists - more mailing lists