All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp>
To: arend.vanspriel@broadcom.com
Cc: aspriel@gmail.com, linux-rpi-kernel@lists.infradead.org,
	linux-wireless@vger.kernel.org,
	brcm80211-dev-list.pdl@broadcom.com,
	SHA-cyfmac-dev-list@infineon.com, franky.lin@broadcom.com,
	hante.meuleman@broadcom.com, chi-hsien.lin@infineon.com,
	wright.feng@infineon.com, chung-hsien.hsu@infineon.com,
	netdev@vger.kernel.org, davem@davemloft.net
Subject: Re: 5.10.58 UBSAN from brcmf_sdio_dpc+0xa50/0x128c [brcmfmac]
Date: Wed, 18 Aug 2021 18:41:09 +0900 (JST)	[thread overview]
Message-ID: <20210818.184109.580170563027962616.ryutaroh@ict.e.titech.ac.jp> (raw)
In-Reply-To: <56ea3e65-62f4-2496-edd4-e454126abc66@broadcom.com>

Hi Arend, sorry for my late response, partly because compilation takes 10 hours
on RPi4B...
I did the same thing with version 5.10.59 and CLang 11 and got the same
UBSAN. 

>> 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.

Summary: I confirm that the stack trace indeed points to
brcmf_sdio_sendfromq(). The detail follows (you don't have to read it if
you believe in me :-)
If kernel version 5.10.x or 5.13.x is compiled with gcc 10, I have never seen
UBSAN. I wonder if CLang 11/12 tends to generate falsely positive UBSAN.

(gdb) add-symbol-file  drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko 0x0
add symbol table from file "drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko" at
	.text_addr = 0x0
(y or n) y

(gdb)  l *brcmf_sdio_dpc+0xa50
warning: Could not find DWO CU drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.dwo(0x79060145b4b45807) referenced by CU at offset 0x394 [in module /usr/lib/debug/lib/modules/5.10.59-clang11debug/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko]
0x277a4 is at ./include/linux/skbuff.h:2016.
2011	./include/linux/skbuff.h: No such file or directory.

Line 2016 of skbuff.h is __skb_insert in the next inline function:
static inline void __skb_queue_before(struct sk_buff_head *list,
                                      struct sk_buff *next,
                                      struct sk_buff *newsk)
{
        __skb_insert(newsk, next->prev, next, list);
}

Then:
(gdb) l *brcmf_sdio_dpc+0xa43
0x27797 is at drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2346.
2341	drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: No such file or directory.

The line 2346 is in the function brcmf_sdio_sendfromq().

Best regards, Ryutaroh

  reply	other threads:[~2021-08-18  9:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-15 23:42 5.10.58 UBSAN from brcmf_sdio_dpc+0xa50/0x128c [brcmfmac] Ryutaroh Matsumoto
2021-08-16  9:54 ` Arend van Spriel
2021-08-17  0:36   ` Ryutaroh Matsumoto
2021-08-17  1:57     ` Ryutaroh Matsumoto
2021-08-17  5:42     ` Arend van Spriel
2021-08-17  8:17       ` Arend van Spriel
2021-08-18  9:41         ` Ryutaroh Matsumoto [this message]
2021-08-19 16:40           ` Arend Van Spriel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210818.184109.580170563027962616.ryutaroh@ict.e.titech.ac.jp \
    --to=ryutaroh@ict.e.titech.ac.jp \
    --cc=SHA-cyfmac-dev-list@infineon.com \
    --cc=arend.vanspriel@broadcom.com \
    --cc=aspriel@gmail.com \
    --cc=brcm80211-dev-list.pdl@broadcom.com \
    --cc=chi-hsien.lin@infineon.com \
    --cc=chung-hsien.hsu@infineon.com \
    --cc=davem@davemloft.net \
    --cc=franky.lin@broadcom.com \
    --cc=hante.meuleman@broadcom.com \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=wright.feng@infineon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.