Re: UNALIGNED_MEMCPY

[enh via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: enh <enh () google com>
>
> Date: Wed, 10 Jun 2026 11:28:53 -0400
>
> On Wed, Jun 10, 2026 at 10:56 AM Denis Ovsienko <denis () ovsienko info> wrote:
> > On Wed, 13 May 2026 15:58:51 -0700
> > Guy Harris <gharris () sonic net> wrote:
> >
> > > I'm not sure about 32-bit Arm, though. It may be that the 32-bit Arm
> > > platforms that matter do handle unaligned loads.
> >
> > On Raspberry Pi 0 (armv6l):
> >
> > # echo 1 >/proc/cpu/alignment
> >
> > kernel: alignment: ignoring faults is unsafe on this CPU. Defaulting to
> > fixup mode.
> >
> > # cat /proc/cpu/alignment
> > User:           0
> > System:         0 (0x0)
> > Skipped:        0
> > Half:           0
> > Word:           0
> > DWord:          0
> > Multi:          0
> > User faults:    3 (fixup+warn)
> >
> > Yet setting this to 4 (signal) and running a test program that triggers
> > a signal on SPARC neither triggers the signal nor increments the fault
> > counter on armv6l.  The same holds for armv7l, if I remember correctly.
>
> (i wonder whether this functionality broke at some point because
> no-one was actually using it?)
>
> > Maybe I am not testing it right, or maybe the problem no longer exists.
>
> given that tcpdump _already_ says "arm handles unaligned loads", i'd
> say that the absence of bug reports is another useful signal of how
> useful this is for tcpdump in practice :-)
>
> > The next step to clarify this could be to performance-test aligned and
> > unaligned loads on a few architectures, and to see if there is a
> > meaningful difference in that sense.
>
> that's certainly possible [in cases where you actually take the fault
> and have the kernel fix it up], but that's (a) not a regression, (b)
> would be a regression for cases where you _don't_ take the fault, (c)
> loses _FORTIFY_SOURCE protection for these call sites, and (d) sounds
> to me like an argument for what i said earlier that -- if we do keep
> the unaligned load support -- we should flip the sense of the list to
> explicitly call out those architectures (if any) that do need to be on
> the slow path [to avoid the pathologically slow kernel fixup path],
> rather than attempting (but failing) to have an exhaustive list of all
> the architectures in the world.
>
> but as long as no-one's noticed in all this time ... i still argue "YAGNI".
>
> given that this hasn't turned out to be the trivial "yeah, let's move
> forward" i'd hoped for, should i send out the patch to add `||
> defined(__riscv)` anyway?
>
> > --
> >     Denis Ovsienko
> > _______________________________________________
> > tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
> > To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s