* [BUG] net: stmmac: Panic observed in stmmac_napi_poll_rx()
@ 2021-05-14 14:24 Jon Hunter
2021-05-14 21:49 ` Michał Mirosław
0 siblings, 1 reply; 4+ messages in thread
From: Jon Hunter @ 2021-05-14 14:24 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu
Cc: netdev, linux-tegra, Thierry Reding
Hello!
I have been looking into some random crashes that appear to stem from
the stmmac_napi_poll_rx() function. There are two different panics I
have observed which are ...
[ 19.591967] ------------[ cut here ]------------
[ 19.596701] kernel BUG at /home/jonathanh/kernel/include/linux/skbuff.h:2297!
[ 19.606273] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 19.611847] Modules linked in:
[ 19.615146] CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.10.0 #1
[ 19.621357] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
[ 19.628010] pstate: 00c00009 (nzcv daif +PAN +UAO -TCO BTYPE=--)
[ 19.634134] pc : eth_type_trans+0xf8/0x1a0
[ 19.638326] lr : stmmac_napi_poll_rx+0x340/0xbd0
[ 19.643123] sp : ffff800011f63ba0
[ 19.646544] x29: ffff800011f63ba0 x28: 00000000000005ea
[ 19.651995] x27: ffff0003d4fe48c0 x26: 00000000000000d3
[ 19.657532] x25: ffff0003d4fe48c0 x24: 0000000000000000
[ 19.662961] x23: ffff0000828d1a40 x22: ffff000083497f00
[ 19.668503] x21: ffff000084b4d6c0 x20: ffff800011b79000
[ 19.673934] x19: 0000000000000000 x18: 0000000000000000
[ 19.679472] x17: 0000000000000000 x16: ffff00008095e291
[ 19.684953] x15: 0000000000000001 x14: 4f77dff9f5ddb24a
[ 19.690425] x13: 3ecd4adcbed3184e x12: bca593c98536d7f5
[ 19.695860] x11: 62327b117d535683 x10: 69f6607bf62388d6
[ 19.701297] x9 : a65753eedd84defc x8 : ffff000084b4dcd0
[ 19.706836] x7 : ffff000084b4dcc0 x6 : 0000000000000000
[ 19.712271] x5 : 0000000000001000 x4 : 0000008000000000
[ 19.717810] x3 : 00000000ffffffea x2 : 00000000000005dc
[ 19.723241] x1 : ffff0003d4fe4000 x0 : ffff000083497f00
[ 19.728777] Call trace:
[ 19.731322] eth_type_trans+0xf8/0x1a0
[ 19.735163] stmmac_napi_poll_rx+0x340/0xbd0
[ 19.739540] net_rx_action+0x220/0x368
[ 19.743387] __do_softirq+0x10c/0x264
[ 19.747145] run_ksoftirqd+0x44/0x58
[ 19.750840] smpboot_thread_fn+0x1d0/0x298
[ 19.755025] kthread+0x120/0x150
[ 19.758484] ret_from_fork+0x10/0x1c
[ 19.762235] Code: 52800063 33000862 39020002 17ffffe0 (d4210000)
[ 19.768472] ---[ end trace 8e68a50b77108dd8 ]---
[ 19.773159] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt
[ 19.780636] SMP: stopping secondary CPUs
[ 19.785053] Kernel Offset: disabled
[ 19.788691] CPU features: 0x0240002,2300aa30
[ 19.793044] Memory Limit: none
[ 19.796183] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]---
... or ...
[ 14.914607] Unable to handle kernel write to read-only memory at virtual address ffff000087ab3000
[ 14.924064] Mem abort info:
[ 14.927201] ESR = 0x9600014f
[ 14.930578] EC = 0x25: DABT (current EL), IL = 32 bits
[ 14.936484] SET = 0, FnV = 0
[ 14.939890] EA = 0, S1PTW = 0
[ 14.943603] Data abort info:
[ 14.946781] ISV = 0, ISS = 0x0000014f
[ 14.950995] CM = 1, WnR = 1
[ 14.954334] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000004505ae000
[ 14.961377] [ffff000087ab3000] pgd=000000047fff8003, p4d=000000047fff8003, pud=000000047fc6b003, pmd=000000047fc2d003, pte=0060000107ab3787
[ 14.974932] Internal error: Oops: 9600014f [#1] PREEMPT SMP
[ 14.980660] Modules linked in: tegra210_adma snd_hda_codec_hdmi snd_hda_tegra snd_hda_codec host1x snd_hda_core crct10dif_ce tegra_aconnect pwm_fan lm90 pwm_tegra tegra_bpmp_thermal phy_tegra194_p2u pcie_tegra194 at24 ip_tables x_tables ipv6
[ 15.003003] CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.10.0 #1
[ 15.009381] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
[ 15.016058] pstate: 80c00009 (Nzcv daif +PAN +UAO -TCO BTYPE=--)
[ 15.022364] pc : __dma_inv_area+0x40/0x58
[ 15.026660] lr : arch_sync_dma_for_cpu+0x1c/0x28
[ 15.031368] sp : ffff800011f63ba0
[ 15.035035] x29: ffff800011f63ba0 x28: 0000000000000000
[ 15.040658] x27: ffff0003d4fb88c0 x26: 00000000000000be
[ 15.046253] x25: ffff0003d4fb88c0 x24: 00000000000005ea
[ 15.051960] x23: ffff0000828bd7a0 x22: 00000000ffffffa8
[ 15.057544] x21: 0000000000000002 x20: ffff000080929010
[ 15.063251] x19: 0000000107a3d000 x18: 0000000000000001
[ 15.068957] x17: 0000000000000000 x16: 0000000000000000
[ 15.074517] x15: 0000000000000068 x14: b17d6301a8460a08
[ 15.080185] x13: 010100003bd8701b x12: 1080e9f16ff0a040
[ 15.086033] x11: 3bb9990301080263 x10: a8c00163a8c0ccd5
[ 15.091856] x9 : 06400040fb17dc05 x8 : ffff000083e108c0
[ 15.097401] x7 : ffff000083e108c0 x6 : 00000000ffffffa8
[ 15.102924] x5 : ffff8000109ca6e0 x4 : 0000000000000000
[ 15.108612] x3 : 000000000000003f x2 : 0000000000000040
[ 15.114302] x1 : ffff000187a3cf80 x0 : ffff000087ab3000
[ 15.119952] Call trace:
[ 15.122543] __dma_inv_area+0x40/0x58
[ 15.126521] dma_sync_single_for_cpu+0xac/0x100
[ 15.131195] stmmac_napi_poll_rx+0x490/0xbd0
[ 15.135786] net_rx_action+0x220/0x368
[ 15.139663] __do_softirq+0x10c/0x264
[ 15.143609] run_ksoftirqd+0x44/0x58
[ 15.147452] smpboot_thread_fn+0x1d0/0x298
[ 15.151678] kthread+0x120/0x150
[ 15.155042] ret_from_fork+0x10/0x1c
[ 15.158772] Code: 8a230000 54000060 d50b7e20 14000002 (d5087620)
[ 15.165228] ---[ end trace 23cff873d17a8509 ]---
This is seen on our Tegra194 Jetson AGX Xavier and it seems that it
is more likely to occur when the CPU is operating at slower
frequencies. For instance if I set the CPU speed to the min of
115.2MHz it occurs more often but not 100%.
Please note that although the above panics logs are from 5.10, it
is also seen with the current mainline.
The bug being triggered in skbuff.h is the following ...
void *skb_pull(struct sk_buff *skb, unsigned int len);
static inline void *__skb_pull(struct sk_buff *skb, unsigned int len)
{
skb->len -= len;
BUG_ON(skb->len < skb->data_len);
return skb->data += len;
}
Looking into the above panic triggered in skbuff.h, when this occurs
I have noticed that the value of skb->data_len is unusually large ...
__skb_pull: len 1500 (14), data_len 4294967274
I then added some traces to stmmac_napi_poll_rx() and
stmmac_rx_buf2_len() to trace the values of various various variables
and when the problem occurs I see ...
stmmac_napi_poll_rx: stmmac_rx: count 0, len 1518, buf1 66, buf2 1452
stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 66, plen 1518
stmmac_napi_poll_rx: stmmac_rx: count 1, len 1518, buf1 66, buf2 1452
stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 66, plen 1536
stmmac_napi_poll_rx: stmmac_rx: count 2, len 1602, buf1 66, buf2 1536
stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 1602, plen 1518
stmmac_napi_poll_rx: stmmac_rx: count 2, len 1518, buf1 0, buf2 4294967212
stmmac_napi_poll_rx: stmmac_rx: dma_buf_sz 1536, buf1 0, buf2 4294967212
The above shows that occasionally the value of 'len' passed to
stmmac_rx_buf2_len() is greater than the value returned by
stmmac_get_rx_frame_len() and stored in 'plen', which then causes
stmmac_rx_buf2_len() to return a negative value but is then treated
as an unsigned value. So it is clear to me that there is overflow
happening occasionally, but I am not sure how to fix it. I tried the
following but this appears to be causing other issues ...
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4749bd0af160..26336de80fe8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3728,7 +3728,7 @@ static unsigned int stmmac_rx_buf2_len(struct stmmac_priv *priv,
/* Not last descriptor */
if (status & rx_not_ls)
- return priv->dma_buf_sz;
+ return priv->dma_buf_sz - len;
plen = stmmac_get_rx_frame_len(priv, p, coe);
@@ -3848,7 +3848,7 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
buf1_len = stmmac_rx_buf1_len(priv, p, status, len);
len += buf1_len;
- buf2_len = stmmac_rx_buf2_len(priv, p, status, len);
+ buf2_len = stmmac_rx_buf2_len(priv, p, status, buf1_len);
len += buf2_len;
The patch I added to trace the various variable is as follows ...
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4749bd0af160..975059bb3165 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3723,15 +3723,20 @@ static unsigned int stmmac_rx_buf2_len(struct stmmac_priv *priv,
unsigned int plen = 0;
/* Not split header, buffer is not available */
- if (!priv->sph)
+ if (!priv->sph) {
+ trace_printk("%s: len %u, plen %u\n", __func__, len, priv->dma_buf_sz);
return 0;
+ }
/* Not last descriptor */
- if (status & rx_not_ls)
+ if (status & rx_not_ls) {
+ trace_printk("%s: len %u, plen %u\n", __func__, len, priv->dma_buf_sz);
return priv->dma_buf_sz;
+ }
plen = stmmac_get_rx_frame_len(priv, p, coe);
+ trace_printk("%s: len %u, plen %u\n", __func__, len, plen);
/* Last descriptor */
return plen - len;
}
@@ -3850,7 +3855,13 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
len += buf1_len;
buf2_len = stmmac_rx_buf2_len(priv, p, status, len);
len += buf2_len;
-
+ trace_printk("%s: count %u, len %u, buf1 %u, buf2 %u\n", __func__,
+ count, len, buf1_len, buf2_len);
+ if (buf1_len > priv->dma_buf_sz || buf2_len > priv->dma_buf_sz) {
+ trace_printk("%s: dma_buf_sz %u, buf1 %u, buf2 %u\n",
+ __func__, priv->dma_buf_sz, buf1_len, buf2_len);
+ BUG_ON(1);
+ }
/* ACS is set; GMAC core strips PAD/FCS for IEEE 802.3
* Type frames (LLC/LLC-SNAP)
*
Note I added the above BUG_ON to trap unusually large buffers. Let
me know if you have any thoughts.
Thanks!
Jon
--
nvpublic
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [BUG] net: stmmac: Panic observed in stmmac_napi_poll_rx()
2021-05-14 14:24 [BUG] net: stmmac: Panic observed in stmmac_napi_poll_rx() Jon Hunter
@ 2021-05-14 21:49 ` Michał Mirosław
2021-05-17 10:39 ` Jon Hunter
0 siblings, 1 reply; 4+ messages in thread
From: Michał Mirosław @ 2021-05-14 21:49 UTC (permalink / raw)
To: Jon Hunter
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, netdev,
linux-tegra, Thierry Reding
On Fri, May 14, 2021 at 03:24:58PM +0100, Jon Hunter wrote:
> Hello!
>
> I have been looking into some random crashes that appear to stem from
> the stmmac_napi_poll_rx() function. There are two different panics I
> have observed which are ...
[...]
> The bug being triggered in skbuff.h is the following ...
>
> void *skb_pull(struct sk_buff *skb, unsigned int len);
> static inline void *__skb_pull(struct sk_buff *skb, unsigned int len)
> {
> skb->len -= len;
> BUG_ON(skb->len < skb->data_len);
> return skb->data += len;
> }
>
> Looking into the above panic triggered in skbuff.h, when this occurs
> I have noticed that the value of skb->data_len is unusually large ...
>
> __skb_pull: len 1500 (14), data_len 4294967274
[...]
The big value looks suspiciously similar to (unsigned)-EINVAL.
> I then added some traces to stmmac_napi_poll_rx() and
> stmmac_rx_buf2_len() to trace the values of various various variables
> and when the problem occurs I see ...
>
> stmmac_napi_poll_rx: stmmac_rx: count 0, len 1518, buf1 66, buf2 1452
> stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 66, plen 1518
> stmmac_napi_poll_rx: stmmac_rx: count 1, len 1518, buf1 66, buf2 1452
> stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 66, plen 1536
> stmmac_napi_poll_rx: stmmac_rx: count 2, len 1602, buf1 66, buf2 1536
> stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 1602, plen 1518
> stmmac_napi_poll_rx: stmmac_rx: count 2, len 1518, buf1 0, buf2 4294967212
> stmmac_napi_poll_rx: stmmac_rx: dma_buf_sz 1536, buf1 0, buf2 4294967212
And this one to (unsigned)-EILSEQ.
> Note I added the above BUG_ON to trap unusually large buffers. Let
> me know if you have any thoughts.
Do above ring any bell?
Best Regards
Michał Mirosław
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] net: stmmac: Panic observed in stmmac_napi_poll_rx()
2021-05-14 21:49 ` Michał Mirosław
@ 2021-05-17 10:39 ` Jon Hunter
2021-05-24 12:48 ` Mikko Perttunen
0 siblings, 1 reply; 4+ messages in thread
From: Jon Hunter @ 2021-05-17 10:39 UTC (permalink / raw)
To: Michał Mirosław
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, netdev,
linux-tegra, Thierry Reding
On 14/05/2021 22:49, Michał Mirosław wrote:
> On Fri, May 14, 2021 at 03:24:58PM +0100, Jon Hunter wrote:
>> Hello!
>>
>> I have been looking into some random crashes that appear to stem from
>> the stmmac_napi_poll_rx() function. There are two different panics I
>> have observed which are ...
> [...]
>> The bug being triggered in skbuff.h is the following ...
>>
>> void *skb_pull(struct sk_buff *skb, unsigned int len);
>> static inline void *__skb_pull(struct sk_buff *skb, unsigned int len)
>> {
>> skb->len -= len;
>> BUG_ON(skb->len < skb->data_len);
>> return skb->data += len;
>> }
>>
>> Looking into the above panic triggered in skbuff.h, when this occurs
>> I have noticed that the value of skb->data_len is unusually large ...
>>
>> __skb_pull: len 1500 (14), data_len 4294967274
> [...]
>
> The big value looks suspiciously similar to (unsigned)-EINVAL.
Yes it does and at first, I thought it was being set to -EINVAL.
However, from tracing the length variables I can see that this is not
the case.
>> I then added some traces to stmmac_napi_poll_rx() and
>> stmmac_rx_buf2_len() to trace the values of various various variables
>> and when the problem occurs I see ...
>>
>> stmmac_napi_poll_rx: stmmac_rx: count 0, len 1518, buf1 66, buf2 1452
>> stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 66, plen 1518
>> stmmac_napi_poll_rx: stmmac_rx: count 1, len 1518, buf1 66, buf2 1452
>> stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 66, plen 1536
>> stmmac_napi_poll_rx: stmmac_rx: count 2, len 1602, buf1 66, buf2 1536
>> stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 1602, plen 1518
>> stmmac_napi_poll_rx: stmmac_rx: count 2, len 1518, buf1 0, buf2 4294967212
>> stmmac_napi_poll_rx: stmmac_rx: dma_buf_sz 1536, buf1 0, buf2 4294967212
>
> And this one to (unsigned)-EILSEQ.
Yes but this simply comes from 1518-1602 = -84. So it is purely
coincidence.
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] net: stmmac: Panic observed in stmmac_napi_poll_rx()
2021-05-17 10:39 ` Jon Hunter
@ 2021-05-24 12:48 ` Mikko Perttunen
0 siblings, 0 replies; 4+ messages in thread
From: Mikko Perttunen @ 2021-05-24 12:48 UTC (permalink / raw)
To: Jon Hunter, Michał Mirosław
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, netdev,
linux-tegra, Thierry Reding
On 5/17/21 1:39 PM, Jon Hunter wrote:
>
> On 14/05/2021 22:49, Michał Mirosław wrote:
>> On Fri, May 14, 2021 at 03:24:58PM +0100, Jon Hunter wrote:
>>> Hello!
>>>
>>> I have been looking into some random crashes that appear to stem from
>>> the stmmac_napi_poll_rx() function. There are two different panics I
>>> have observed which are ...
>> [...]
>>> The bug being triggered in skbuff.h is the following ...
>>>
>>> void *skb_pull(struct sk_buff *skb, unsigned int len);
>>> static inline void *__skb_pull(struct sk_buff *skb, unsigned int len)
>>> {
>>> skb->len -= len;
>>> BUG_ON(skb->len < skb->data_len);
>>> return skb->data += len;
>>> }
>>>
>>> Looking into the above panic triggered in skbuff.h, when this occurs
>>> I have noticed that the value of skb->data_len is unusually large ...
>>>
>>> __skb_pull: len 1500 (14), data_len 4294967274
>> [...]
>>
>> The big value looks suspiciously similar to (unsigned)-EINVAL.
>
> Yes it does and at first, I thought it was being set to -EINVAL.
> However, from tracing the length variables I can see that this is not
> the case.
>
>>> I then added some traces to stmmac_napi_poll_rx() and
>>> stmmac_rx_buf2_len() to trace the values of various various variables
>>> and when the problem occurs I see ...
>>>
>>> stmmac_napi_poll_rx: stmmac_rx: count 0, len 1518, buf1 66, buf2 1452
>>> stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 66, plen 1518
>>> stmmac_napi_poll_rx: stmmac_rx: count 1, len 1518, buf1 66, buf2 1452
>>> stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 66, plen 1536
>>> stmmac_napi_poll_rx: stmmac_rx: count 2, len 1602, buf1 66, buf2 1536
>>> stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 1602, plen 1518
>>> stmmac_napi_poll_rx: stmmac_rx: count 2, len 1518, buf1 0, buf2 4294967212
>>> stmmac_napi_poll_rx: stmmac_rx: dma_buf_sz 1536, buf1 0, buf2 4294967212
>>
>> And this one to (unsigned)-EILSEQ.
>
> Yes but this simply comes from 1518-1602 = -84. So it is purely
> coincidence.
>
> Jon
>
I dug around this a little bit. It looks like the issue occurs when we
get (pardon my terminology, I haven't dealt with networking stuff much)
a split packet.
What happens is we first process the first frame, growing 'len'.
buf1_len, I think, hits the "First descriptor, get split header length"
case and the length is 66. buf2_len hits the rx_not_ls case and the
length is 1536. In total 1602.
Then the condition 'likely(status & rx_not_ls)' passes and we goto back
to 'read_again', and read the next frame. Here we eventually get to
buf2_len again. stmmac_get_rx_frame_len returns 1518 for this frame
which sounds reasonable, that's what we normally get for non-split
frames. So what we get is 1518 - 1602 which overflows.
I can dig around a bit more but it would be nice if someone with a bit
more knowledge of the hardware could comment on the above.
Thanks,
Mikko
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-05-24 12:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-14 14:24 [BUG] net: stmmac: Panic observed in stmmac_napi_poll_rx() Jon Hunter
2021-05-14 21:49 ` Michał Mirosław
2021-05-17 10:39 ` Jon Hunter
2021-05-24 12:48 ` Mikko Perttunen
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.