Re: [PATCH 03/24] alpha: select ARCH_HAS_UBSAN

[Magnus Lindholm]

Hi Michael,

On Fri, Sep 4, 2026 at 10:31 PM Michael Cree <mcree@xxxxxxxxxxxx> wrote:
>
> On Wed, Sep 02, 2026 at 12:34:50AM +0200, Magnus Lindholm wrote:
> > On Tue, Sep 1, 2026 at 5:50 PM Matt Turner <mattst88@xxxxxxxxx> wrote:
> > >
> > > GCC's undefined behavior sanitizer has no architecture-specific runtime
> > > requirements. Enable it for Alpha to allow UBSAN instrumentation of the
> > > kernel.
> > >
> > I tested this patch on top of my rebased Alpha GENERIC_ENTRY patch on an
> > AlphaServer ES40. The kernel built and booted successfully with
> > CONFIG_UBSAN=y, and the UBSAN instrumentation is active.
>
> So have I, on an XP1000 and ES45.
>
> > CONFIG_UBSAN_ALIGNMENT did expose a misaligned struct bucket_table
> > allocation in lib/rhashtable.c. This appears to be a generic rhashtable
> > allocation-alignment issue rather than an Alpha UBSAN problem.
>
> But in my case the kernel vomited copious misaligned access reports,
> so many that it took quite a few minutes to boot and I lost much of
> the kernel log before disks were mounted.  A few examples that
> were recorded later in the boot on the ES45:
>
> Sep 03 21:12:36 electro kernel: UBSAN: misaligned-access in net/core/dev.c:1401:2
> Sep 03 21:12:36 electro kernel: member access within misaligned address (____ptrval____) for type 'struct net_device'
> Sep 03 21:12:36 electro kernel: which requires 64 byte alignment
>
> Sep 03 21:12:36 electro kernel: UBSAN: misaligned-access in kernel/signal.c:4362:4
> Sep 03 21:12:36 electro kernel: member access within misaligned address 0000000058e1e939 for type 'struct task_struct'
> Sep 03 21:12:36 electro kernel: which requires 64 byte alignment
>
> Sep 03 21:13:04 electro kernel: UBSAN: misaligned-access in drivers/net/ethernet/intel/e100.c:1941:36
> Sep 03 21:13:04 electro kernel: member access within misaligned address 000000001c866fa6 for type 'struct rfd'
> Sep 03 21:13:04 electro kernel: which requires 4 byte alignment
>
> Interestingly "kernel unaligned acc" in /proc/cpuinfo remained at
> zero, which really makes me wonder whether these reports are all
> false-positives.
>
Good question, had to dig deeper here,

Not false positives - real UB, but harmless, and I tracked down why.
for_each_thread() and for_each_netdev_rcu() are list_for_each_entry
macros: their loop computes container_of() once extra per traversal,
unconditionally, to test for end-of-list. That test compares against
the list head (&signal->thread_head, &net->dev_base_head), which lives
in a different struct entirely (signal_struct, net) - not
task_struct/net_device. At the real end of the list, container_of()
still subtracts offsetof(task_struct, thread_node) from that head's
address anyway, producing a pointer that looks nothing like a real
task_struct. It's used only for a pointer-value comparison, never
dereferenced - confirmed with a printk inside find_alive_thread()'s
loop body that never fired even when UBSAN caught the same line. Zero
unaligned-access count follows directly: nothing ever loads or stores
through it.

If it's worth fixing rather than living with: the sentinel comparison
in list_entry_rcu()/list_for_each_entry_rcu() only needs the raw
pointer value, not a type-checked container_of(). Splitting that one
use into an unchecked pointer subtraction for the loop-termination
test, keeping checked container_of() for the real element on every
other iteration, would remove the false trigger without losing any
real coverage. Not alpha-specific, so probably wants a wider list than
this one if someone wants to pick it up.

e100.c's struct rfd is unrelated: casts skb->data (not guaranteed
4-byte aligned) to struct rfd *, writes via put_unaligned_le32() - UB
in the cast, safe access after.
Not alpha-specific either - list_for_each_entry is everywhere.
CONFIG_UBSAN_ALIGNMENT just defaults on for us
(!HAVE_EFFICIENT_UNALIGNED_ACCESS) and off elsewhere.
Confirmed on the UP2000+ rather than assumed: 7 reports,
"kernel unaligned acc: 0" never moved.

Magnus