[Bug 241728] linuxkpi: panics after loading radeonkms kernel module (data storage interrupt trap)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241728

--- Comment #24 from Mark Millard <marklmi26-fbsd at yahoo.com> ---
(In reply to Piotr Kubaj from comment #0)

[This note reports 5 or so more pcpu_entry_'s that are
LOCAL -- and notes that there are around 300 vnet_entry_'s
that are LOCAL (around 98 GLOBAL). I start with
pcpu_entry_'s.]

For my context, beyond linuxkpi.kld there is also . . .

ipfw.kld having:

   469: 0000000000000000     8 OBJECT  LOCAL  DEFAULT   20 pcpu_entry_dyn_hp

siftr.kld having:

    91: 0000000000000000    56 OBJECT  LOCAL  DEFAULT   18 pcpu_entry_ss

which would seem likely to have the same type of problem as linuxkpi.kld
ended up with because of the "LOCAL" final results in the .kld files.

ipfw, linuxkpi, and siftr were mentioned in bug 232387 (but possibly not
all completely fixed). This prompted for me to check my clang 8.0.1 ELFv1
based build tree targeting powerpc64 to see teh above.

I have not tested loading ipfw.ko or siftr.ko . I just looked for
the pcpu_entry_<?> information via readelf on the .kld files.

Going the other way, looking for .kld files with pcpu_entry_ text in
that build that I've been looking at: It has 3 more LOCAL's beyond the
3 noted so far:

pcpu_entry_epair_dpcpu ( /usr/src/sys/net/if_epair.c )
pcpu_entry_tasklet_worker ( sys/compat/linuxkpi/common/src/linux_tasklet.c )
pcpu_entry_linux_epoch_record ( sys/compat/linuxkpi/common/src/linux_rcu.c )

The first uses DPCPU_DEFINE and the other two use DPCPU_DEFINE_STATIC, but
LOCAL can be forced other ways than the macro definitions ( as in the earlier
linuxkld.kld notes ).

For reference:

# find /usr/obj/powerpc64vtsc_clang_altbinutils/ -name '*.kld' -exec readelf -a
{} \; | grep pcpu_entry_
000000000020 017800000026 R_PPC64_ADDR64      0000000000000000
pcpu_entry_pmc_sampled + 0
000000000168 017800000026 R_PPC64_ADDR64      0000000000000000
pcpu_entry_pmc_sampled + 0
   376: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND
pcpu_entry_pmc_sampled
000000000010 005000000026 R_PPC64_ADDR64      0000000000000000
pcpu_entry_epair_dpcpu + 0
00000000017d 005000000026 R_PPC64_ADDR64      0000000000000000
pcpu_entry_epair_dpcpu + 0
    80: 0000000000000000    56 OBJECT  LOCAL  DEFAULT   19
pcpu_entry_epair_dpcpu
0000000001f8 01d500000026 R_PPC64_ADDR64      0000000000000000
pcpu_entry_dyn_hp + 0
000000015f9b 01d500000026 R_PPC64_ADDR64      0000000000000000
pcpu_entry_dyn_hp + 0
   469: 0000000000000000     8 OBJECT  LOCAL  DEFAULT   20 pcpu_entry_dyn_hp
0000000000f8 018400000026 R_PPC64_ADDR64      0000000000000000
pcpu_entry_linux_idr_cache + 0
0000000001e0 020b00000026 R_PPC64_ADDR64      0000000000000080
pcpu_entry_linux_epoch_record + 0
000000000290 01c000000026 R_PPC64_ADDR64      0000000000000200
pcpu_entry_tasklet_worker + 0
00000001f60b 018400000026 R_PPC64_ADDR64      0000000000000000
pcpu_entry_linux_idr_cache + 0
00000004e25d 020b00000026 R_PPC64_ADDR64      0000000000000080
pcpu_entry_linux_epoch_record + 0
0000000647e9 01c000000026 R_PPC64_ADDR64      0000000000000200
pcpu_entry_tasklet_worker + 0
   388: 0000000000000000    48 OBJECT  LOCAL  DEFAULT   19
pcpu_entry_linux_idr_cache
   448: 0000000000000200   256 OBJECT  LOCAL  DEFAULT   19
pcpu_entry_tasklet_worker
   523: 0000000000000080   384 OBJECT  LOCAL  DEFAULT   19
pcpu_entry_linux_epoch_record
000000000020 005b00000026 R_PPC64_ADDR64      0000000000000000 pcpu_entry_ss +
0
0000000030e5 005b00000026 R_PPC64_ADDR64      0000000000000000 pcpu_entry_ss +
0
    91: 0000000000000000    56 OBJECT  LOCAL  DEFAULT   18 pcpu_entry_ss


The list for vnet_entry_'s that are LOCAL in my build is very long,
around 300 of them.

I've not done anything to certify that they all lead to failure. On
what I've done it just suggests that they need consideration.

There are around 98 vnet_entry_'s that are GLOBAL.

If there are more than just pcpu_entry_'s and vnet_entry_'s that
would have the issue, than I'm unaware and have not covered them
at all.

-- 
You are receiving this mail because:
You are the assignee for the bug.