Re: A native armv7 panic during kyua runs: sys/netinet6/exthdr:exthdr -> Fatal kernel mode data abort: 'Alignment Fault' on read

Mark Millard <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
On Aug 5, 2023, at 14:04, Mark Millard <[email protected]> wrote:

> On Aug 5, 2023, at 11:27, Michal Meloun <[email protected]> wrote:
> 
>> Hi Mark,
>> can you please try a this patch?
>> https://github.com/strejda/tegra/commit/bd4390c5f6a8b66b2fc83966d4fadb945a19dc23
> 
> I'll take a stab at testing it.
> 
> But I'll note that description of the patch is somewhat odd:
> 
> QUOTE
> Pack IP structures directly used for access packet data.
> All structures used to access data in byte buffers shall be marked
> as packed. Otherwise, this is undefined behavior - formally on
> every platform.
> END QUOTE
> 
> __packed (and whatever it might be a macro for) is not part of
> any vintage of the C standard, not even as explicitly
> implementation defined nor as explicitly undefined. (C23's
> "attribute specifier sequence" notation use would give an
> implementation defined status as an understand, but not via
> explicit identification of the concept of packed in the standard.)
> As far as the language is concerned, there is no guarantee that
> a code generator will ensure to break things up into aligned
> accesses with assembly of the overall value if the members are
> not aligned in the first place, __packed or not. Nor does the
> language guarantee pack of padding in the layout for __packed.
> 
> Past that, it is toolchain specific if __packed would avoid
> unaligned accesses for simple member access notation bytes
> yet also avoid having pad bytes. We will see for this context.
> (My history suggests a lack of overall uniformity in the
> interpretations given to declaring struct's as packed --or
> analogous wording for other languages that are not explicit
> about it.)
> 
>> I'm sorry, but I don't have the time or energy to fully test it... I only hope the actual patch is much easier than the one listed in PR271759.
> 

[Older history deleted.]

No notable change in behavior, I'm afraid . . .

sys/netinet6/exthdr:exthdr  ->  
Fatal kernel mode data abort: 'Alignment Fault' on read
trapframe: 0xc51fbaa0
FSR=00000001, FAR=daed4476, spsr=60000013
r0 =daf787c0, r1 =c51fbb34, r2 =00000000, r3 =00000000
r4 =00000000, r5 =00000000, r6 =daed4476, r7 =daed4466
r8 =c0965c3c, r9 =00000000, r10=db0e4400, r11=c51fbb60
r12=00000000, ssp=c51fbb30, slr=c0b524c0, pc =c04e8e78

panic: Fatal abort
cpuid = 1
time = 1691270886
KDB: stack backtrace:
db_trace_self() at db_trace_self
         pc = 0xc0661824  lr = 0xc007db80 (db_trace_self_wrapper+0x30)
         sp = 0xc51fb858  fp = 0xc51fb970
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
         pc = 0xc007db80  lr = 0xc031a834 (vpanic+0x140)
         sp = 0xc51fb978  fp = 0xc51fb998
         r4 = 0x00000100  r5 = 0x00000000
         r6 = 0xc07c5a9a  r7 = 0xc0b36e58
vpanic() at vpanic+0x140
         pc = 0xc031a834  lr = 0xc031a6f4 (vpanic)
         sp = 0xc51fb9a0  fp = 0xc51fb9a4
         r4 = 0xc51fbaa0  r5 = 0x00000013
         r6 = 0xdaed4476  r7 = 0x00000001
         r8 = 0x00000001  r9 = 0xdaf787c0
        r10 = 0xdaed4476
vpanic() at vpanic
         pc = 0xc031a6f4  lr = 0xc0686ddc (abort_align)
         sp = 0xc51fb9ac  fp = 0xc51fb9d8
         r4 = 0x00000001  r5 = 0x00000001
         r6 = 0xdaf787c0  r7 = 0xdaed4476
         r8 = 0xc51fb9a4  r9 = 0xc031a6f4
        r10 = 0xc51fb9ac
abort_align() at abort_align
         pc = 0xc0686ddc  lr = 0xc0686e50 (abort_align+0x74)
         sp = 0xc51fb9e0  fp = 0xc51fb9f8
         r4 = 0x00000013 r10 = 0xdaed4476
abort_align() at abort_align+0x74
         pc = 0xc0686e50  lr = 0xc0686aa8 (abort_handler+0x45c)
         sp = 0xc51fba00  fp = 0xc51fba98
         r4 = 0x00000000 r10 = 0xdaed4476
abort_handler() at abort_handler+0x45c
         pc = 0xc0686aa8  lr = 0xc06640d8 (exception_exit)
         sp = 0xc51fbaa0  fp = 0xc51fbb60
         r4 = 0x00000000  r5 = 0x00000000
         r6 = 0xdaed4476  r7 = 0xdaed4466
         r8 = 0xc0965c3c  r9 = 0x00000000
        r10 = 0xdb0e4400
exception_exit() at exception_exit
         pc = 0xc06640d8  lr = 0xc0b524c0 (__pcpu+0x200)
         sp = 0xc51fbb30  fp = 0xc51fbb60
         r0 = 0xdaf787c0  r1 = 0xc51fbb34
         r2 = 0x00000000  r3 = 0x00000000
         r4 = 0x00000000  r5 = 0x00000000
         r6 = 0xdaed4476  r7 = 0xdaed4466
         r8 = 0xc0965c3c  r9 = 0x00000000
        r10 = 0xdb0e4400 r12 = 0x00000000
in6ifa_ifwithaddr() at in6ifa_ifwithaddr+0x30
         pc = 0xc04e8e78  lr = 0xc04fb338 (ip6_input+0xd38)
         sp = 0xc51fbb68  fp = 0xc51fbc28
         r4 = 0xdaed4476  r5 = 0xdaed445e
         r6 = 0x00000000  r7 = 0xdaed4466
ip6_input() at ip6_input+0xd38
         pc = 0xc04fb338  lr = 0xc046d66c (netisr_dispatch_src+0xf8)
         sp = 0xc51fbc30  fp = 0xc51fbc58
         r4 = 0xdaed4400  r5 = 0x00000006
         r6 = 0x00000001  r7 = 0xc0b4dd50
         r8 = 0xdaf9d900  r9 = 0xdaed4400
        r10 = 0x00000086
netisr_dispatch_src() at netisr_dispatch_src+0xf8
         pc = 0xc046d66c  lr = 0xc04641b0 (ether_demux+0x18c)
         sp = 0xc51fbc60  fp = 0xc51fbc78
         r4 = 0x00000006  r5 = 0x00001201
         r6 = 0xdb0e4400  r7 = 0x000000ff
         r8 = 0xdaf9d900  r9 = 0xdaed4400
        r10 = 0x00000086
ether_demux() at ether_demux+0x18c
         pc = 0xc04641b0  lr = 0xc0465880 (ether_nh_input+0x490)
         sp = 0xc51fbc80  fp = 0xc51fbce0
         r4 = 0xdb0e4400  r5 = 0xdaed4400
         r6 = 0xdaed4450 r10 = 0x00000086
ether_nh_input() at ether_nh_input+0x490
         pc = 0xc0465880  lr = 0xc046d66c (netisr_dispatch_src+0xf8)
         sp = 0xc51fbce8  fp = 0xc51fbd10
         r4 = 0xdaed4400  r5 = 0x00000005
         r6 = 0x00000003  r7 = 0xc0b4dd30
         r8 = 0xdaf9d900  r9 = 0xdaed4400
        r10 = 0xc098f58f
netisr_dispatch_src() at netisr_dispatch_src+0xf8
         pc = 0xc046d66c  lr = 0xc04645c4 (ether_input+0x50)
         sp = 0xc51fbd18  fp = 0xc51fbd48
         r4 = 0xdaed4400  r5 = 0x00000000
         r6 = 0x00008803  r7 = 0x00000000
         r8 = 0xdaf9d900  r9 = 0xdaed4400
        r10 = 0xc098f58f
ether_input() at ether_input+0x50
         pc = 0xc04645c4  lr = 0xdffb3f08 ($a.10+0x108)
         sp = 0xc51fbd50  fp = 0xc51fbd78
         r4 = 0xdb0e4400  r5 = 0xdaff4000
         r6 = 0xdaff4010  r7 = 0x00000000
         r8 = 0x00000000 r10 = 0xc098f58f
$a.10() at $a.10+0x108
         pc = 0xdffb3f08  lr = 0xc038cb2c (taskqueue_run_locked+0x1c4)
         sp = 0xc51fbd80  fp = 0xc51fbdd8
         r4 = 0xdaff2100  r5 = 0xdaff402c
         r6 = 0xdaff2150  r7 = 0x00000001
         r8 = 0x00000000  r9 = 0xc51fbd90
        r10 = 0x00000001
taskqueue_run_locked() at taskqueue_run_locked+0x1c4
         pc = 0xc038cb2c  lr = 0xc038e4e4 (taskqueue_thread_loop+0x1b0)
         sp = 0xc51fbde0  fp = 0xc51fbe10
         r4 = 0xdaff2100  r5 = 0xdaff2140
         r6 = 0xc07b18c4  r7 = 0x00000000
         r8 = 0xc098f58f  r9 = 0x00000100
        r10 = 0xc0b268a0
taskqueue_thread_loop() at taskqueue_thread_loop+0x1b0
         pc = 0xc038e4e4  lr = 0xc02cdf0c (fork_exit+0xc0)
         sp = 0xc51fbe18  fp = 0xc51fbe38
         r4 = 0xdaf787c0  r5 = 0xc0b264e0
         r6 = 0xc038e334  r7 = 0xdffc4f54
         r8 = 0xc51fbe40  r9 = 0xc098f591
fork_exit() at fork_exit+0xc0
         pc = 0xc02cdf0c  lr = 0xc066406c (swi_exit)
         sp = 0xc51fbe40  fp = 0x00000000
         r4 = 0xc038e334  r5 = 0xdffc4f54
         r6 = 0xc0b48d84  r7 = 0xd73bd3e0
         r8 = 0x00000001 r10 = 0xc0b268a0
swi_exit() at swi_exit
         pc = 0xc066406c  lr = 0xc066406c (swi_exit)
         sp = 0xc51fbe40  fp = 0x00000000
KDB: enter: panic
[ thread pid 0 tid 100226 ]


I've just restored the sources involved but still have
the .diff I that got via github.




===
Mark Millard
marklmi at yahoo.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.