Re: [PATCH net 1/1] r8169: fix sleepable allocation during netdevice stats retrieval.

[Corinna Vinschen <vinschen@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3427 bytes --]

On Sep  9 20:34, poma wrote:
> On 09/09/2015 05:55 PM, Corinna Vinschen wrote:
> > On Sep  9 17:54, Corinna Vinschen wrote:
> >> On Sep  9 17:24, poma wrote:
> >>> [PATCH net] r8169: Fix sleeping function called during get_stats64
> >>> http://marc.info/?l=linux-netdev&m=144180123410135&q=raw
> >>> - the noise is still present
> >>
> >> Are you really sure?  The entire dma_alloc/dma_free stuff has been moved
> >> away.  There's no locking or sleeping involved different from what was
> >> there before my original patch when calling .ndo_get_stats64.
> >>
> 
> 
> It is literally the kernel ring buffer output,
> so I really can not understand your question.

I'm asking because I'm wondering if you're actually testing the
right r8169.ko module, the one with the patch applied.  See below.

> >> How would I be able to reproduce this on the command line?
> 
> This I have already written, here's once more for you,
> <quote>
>  This noise is induced via userspace, xfce4-netload-plugin,
>  http://goodies.xfce.org/projects/panel-plugins/xfce4-netload-plugin
> 
>  $ grep -i device .config/xfce4/panel/netload-16.rc
>  Network_Device=enp3s0
> 
>  $ ethtool -i enp3s0 | grep driver
>  driver: r8169
> </quote>
> 
> Therefore, to try to reproduce this issue, 'xfce4-netload-plugin' must run within 'xfce4-panel',
> moreover 'xfce4-netload-plugin' must be configured to monitor affected network interface.

I'lll see if I can try this tomorrow.

> No command line this time, hombre.

If it has to be spanish, I'd prefer mujer, but whatever.

> > It would also be interesting to see the "noise" as it looks after
> > applying the above patch...
> 
> The "noise" after applying "r8169: Fix sleeping function called during get_stats64":
> [...]
> [  215.049067] Call Trace:
> [  215.049078]  [<ffffffff8184b6c1>] dump_stack+0x4b/0x63
> [  215.049090]  [<ffffffff81100d77>] lockdep_rcu_suspicious+0xd7/0x110
> [  215.049099]  [<ffffffff810d5377>] ___might_sleep+0xa7/0x230
> [  215.049107]  [<ffffffff810d5549>] __might_sleep+0x49/0x80
> [  215.049121]  [<ffffffff811e575e>] __alloc_pages_nodemask+0x2fe/0xb90
> [  215.049130]  [<ffffffff81121b0d>] ? debug_lockdep_rcu_enabled+0x1d/0x20
> [  215.049141]  [<ffffffff81024b29>] ? sched_clock+0x9/0x10
> [  215.049149]  [<ffffffff810e258c>] ? local_clock+0x1c/0x20
> [  215.049157]  [<ffffffff81121b0d>] ? debug_lockdep_rcu_enabled+0x1d/0x20
> [  215.049168]  [<ffffffff810218e6>] dma_generic_alloc_coherent+0x96/0x130
> [  215.049178]  [<ffffffff81069865>] x86_swiotlb_alloc_coherent+0x25/0x50
> [  215.049193]  [<ffffffff810215fd>] dma_alloc_attrs+0x6d/0xe0
> [  215.049208]  [<ffffffffa002e25e>] rtl8169_map_counters+0x3e/0x70 [r8169]

This is very certainly not the r8169.ko driver with my patch applied.
There is no rtl8169_map_counters function anymore, just as with
Francois' patch.  I'm not sure what you're doing wrong there, but this
stack dump definitely cannot be produced with either Francois or my
patch, so you're apparently testing the unpatched upstream driver all
the time.

> ...
> etc.
>   etc.
>     etc.
> 
> This looks the same as at the beginning, as if you were dealing with
> an entirely different problem, hombre.

No, sorry, it's you running the wrong kernel module, and a single
occurence of the stack dump would have been sufficient, but thanks
all the same.


Corinna

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]