Re: [PATCH 0/3] ARM: fix hash_name() and branch predictor issues

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Mon, Dec 08, 2025 at 03:59:49PM +0000, Russell King (Oracle) wrote:
> On Mon, Dec 08, 2025 at 11:08:40PM +0800, Xie Yuanbin wrote:
> > On Mon, 8 Dec 2025 12:34:27 +0000, Russell King wrote:
> > > The first patch adds an additional check in __do_kernel_fault() to
> > > detect this condition. This patch is a non-obvious dependency for the
> > > next patch.
> > >
> > > The second patch handles faults above the top of userspace entirely
> > > separately, meaning we have a simpler and more obvious fault path,
> > > which avoids any possibility of taking any MM mutexes, which is the
> > > cause of the hash_name() problem.
> > >
> > > The third patch moves harden_branch_predictor() out of
> > > __do_user_fault() and to appropriate places in the parent functions.
> > > The reason this has been avoided thus far is because do_page_fault()
> > > can be a hot path (since it's used for page aging as well) but with
> > > kernel address faults being handled by an entirely separate path,
> > > this avoids adding to that overhead.
> > 
> > I don't have any objections to the first and second patches. However,
> > for the third patch, I feel it complicates some things. It removes
> > harden_branch_predictor() from __do_user_fault() and adds it to various
> > previous calling points.
> > 
> > This seems to be solely for adapting to the scenario of do_alignment() &&
> > user_mode(regs) && addr >= TASK_SIZE. Does this scenario really exist?
> 
> As explained in the other thread, alignment faults are the first thing
> that are checked when enabled, before permission fauls, so we can end
> up entering do_alignment() from userspace with an address in the
> kernel address space.
> 
> However, there is a user accessible page above TASK_SIZE, that is the
> vectors page which can have userspace helpers in. Userspace can read
> from this page, and thus can perform unaligned loads to this page.
> 
> The system behaviour of unaligned loads has been configurable, ARMv4,
> for example, had the ability to check for alignment faults and raise
> this exception. If that was disabled, then unaligned loads would
> load the equivalent 32-bit aligned address and rotate the data in
> the register. Compilers knew about this, and would code for it,
> which made it ABI. Later compilers stopped using that which cut down
> on the unaligned loads that userspace issued. Modern CPUs (ARMv7)
> tend to behave "sanely" in that unaligned loads are generally
> supported in hardware.

Also, would you mind giving ASAP some tested-by/reviewed-by for these
patches so they can be pushed out to linux-next for a bit of testing
there pelase? I'm on vacation from Thursday, so time is very short
to get these out - if we're not ready by Wednesday, then it'll be the
new year, possibly after the 11th January, before I can do anything
further (medical stuff.)

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!