Re: [RFC PATCH v2 1/2] ARM/mm/fault: always goto bad_area when handling with page faults of kernel address

Sebastian Andrzej Siewior
2025-11-30T11:20:12Z

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