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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 9 Sep 2015 21:08:05 +0200
From:	Corinna Vinschen <vinschen@...hat.com>
To:	poma <pomidorabelisima@...il.com>
Cc:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>,
	Francois Romieu <romieu@...zoreil.com>,
	Mike Massonnet <m8t@...di.net>,
	Benedikt Meurer <benedikt.meurer@...x-ag.uni-siegen.de>,
	Bernhard Walle <bernhard.walle@....de>,
	Hendrik Scholz <hscholz@...sdorf.net>,
	Florian Rivoal <frivoal@...e.org>
Subject: Re: [PATCH net 1/1] r8169: fix sleepable allocation during netdevice
 stats retrieval.

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

Content of type "application/pgp-signature" skipped