+netdev, +Dave
On 8/17/2021 7:42 AM, Arend van Spriel wrote:
Using different email to avoid disclaimers...
On August 17, 2021 2:39:56 AM Ryutaroh Matsumoto
<ryutaroh@xxxxxxxxxxxxxxxxxx> wrote:
Hi Arend, thank you for paying attention to this.
Line 2016 in skbuff.h is inline function __skb_queue_before() and as
far as I can tell brcmfmac is not using that direct or indirect. Maybe
I am reading the line info incorrectly?
I am unsure of it. On the other hand, I have also seen somewhat similar
UBSAN from a header file "include/net/flow.h" as reported at
https://lore.kernel.org/netdev/20210813.081908.1574714532738245424.ryutaroh@xxxxxxxxxxxxxxxxxx/
All UBSANs that I have seen come from *.h compiled with clang...
Would you be able to provide information as to what line
brcmf_sdio_dpc+0xa50 refers to.
I'd like to do, but I do not know how to let kernel UBSAN include a
line number,
though I know it with user-space applications...
If you enable CONFIG_DEBUG_INFO in your kernel .config and recompile
brcmfmac you can load the module in gdb:
gdb> add-symbol-file brcmfmac.ko [address]
gdb> l *brcmf_sdio_dpc+0xa50
The [address] is not very important so just fill in a nice value. The
'l' command should provide the line number.
Hi Ryutaroh,
Meanwhile I did some digging in the brcmfmac driver and I think I found
the location in brcmf_sdio_sendfromq() where we do a __skb_queue_tail().
So I looked at that and it does following:
static inline void __skb_queue_tail(struct sk_buff_head *list,
struct sk_buff *newsk)
{
__skb_queue_before(list, (struct sk_buff *)list, newsk);
}
Your report seems to be coming from the cast that is done here, which is
fine as long as sk_buff and sk_buff_head have the same members 'next'
and 'prev' at the start, which is true today and hopefully forever ;-) I
am inclined to say this is a false report.
Can you please confirm the stack trace indeed points to
brcmf_sdio_sendfromq() in your report.
Regards,
Arend
