netdev - Re: + ppp_generic-fix-lockdep-warning.patch added to -mm tree

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]

Message-ID: <20070418064011.GA1680@ff.dom.local>
Date:	Wed, 18 Apr 2007 08:40:11 +0200
From:	Jarek Poplawski <jarkao2@...pl>
To:	Michal Ostrowski <mostrows@...thlink.net>
Cc:	"Yuriy N\. Shkandybin" <jura@...ams.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Paul Mackerras <paulus@...ba.org>, netdev@...r.kernel.org,
	Michal Ostrowski <mostrows@...akeasy.net>
Subject: Re: + ppp_generic-fix-lockdep-warning.patch added to -mm tree

On Tue, Apr 17, 2007 at 08:26:32AM -0500, Michal Ostrowski wrote:
> The "xmit" function of a PPP channel is a synchronous operation.  If the 
> transmission fails, we must notify the caller and let them re-submit the 
> skb later.  The return status of dev_queue_xmit is needed to determine 
> the return code passed back to the caller and thus the call is made 
> synchronously and not in a tasklet.

Sure! But on the other hand:

- the return code from dev_queue_xmit doesn't guarantee
the transmission won't fail,

- similar code in ppp_async: ppp_async_send isn't so
truthful and doesn't even check the return from
ppp_async_push; BTW - probably other layers should
care for transmission errors and re-submiting,

- maybe I'm wrong here, but I think every "layer" should
look (work) similarly here: dev_queue_xmit (or qdisc_run)
thinks it's talking to some independent network device,
which after dev_hard_start_xmit (and dev->hard_start_xmit)
does some transmission; if, instead of this, next
dev_queue_xmits are called with xmit locks held from
previous "devs", then it looks like logical recursion and
locking is really hard to follow (even if it's OK).

> Looking at the stack traces earlier in this thread, it seems to me that 
> even if the PPPoE call was made in a tasklet, this same warning could be 
> generated.

Of course a tasklet by itself isn't a cure, but if
dev_queue_xmit is done from tasklet - only locks got
within this tasklet should be counted.

Thanks for response & best regards,
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html