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 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.

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