From: Jarek Poplawski <jarkao2@o2.pl>
To: Michal Ostrowski <mostrows@earthlink.net>
Cc: "Yuriy N\. Shkandybin" <jura@netams.com>,
Andrew Morton <akpm@linux-foundation.org>,
Paul Mackerras <paulus@samba.org>,
netdev@vger.kernel.org, Michal Ostrowski <mostrows@speakeasy.net>
Subject: Re: + ppp_generic-fix-lockdep-warning.patch added to -mm tree
Date: Wed, 18 Apr 2007 08:40:11 +0200 [thread overview]
Message-ID: <20070418064011.GA1680@ff.dom.local> (raw)
In-Reply-To: <4624CB08.2070005@earthlink.net>
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.
next prev parent reply other threads:[~2007-04-18 6:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200703282353.l2SNr2iL023119@shell0.pdx.osdl.net>
[not found] ` <01ef01c77bfe$4cdfe640$0202fea9@Jura>
2007-04-11 7:09 ` + ppp_generic-fix-lockdep-warning.patch added to -mm tree Andrew Morton
2007-04-11 8:52 ` Yuriy N. Shkandybin
2007-04-11 8:58 ` Andrew Morton
2007-04-17 7:37 ` Jarek Poplawski
2007-04-17 13:26 ` Michal Ostrowski
2007-04-18 6:40 ` Jarek Poplawski [this message]
2007-04-19 5:30 ` Jarek Poplawski
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=20070418064011.GA1680@ff.dom.local \
--to=jarkao2@o2.pl \
--cc=akpm@linux-foundation.org \
--cc=jura@netams.com \
--cc=mostrows@earthlink.net \
--cc=mostrows@speakeasy.net \
--cc=netdev@vger.kernel.org \
--cc=paulus@samba.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).