From: Johannes Berg <johannes@sipsolutions.net>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Richard Cochran <richardcochran@gmail.com>,
David Miller <davem@davemloft.net>,
netdev@vger.kernel.org
Subject: Re: [PATCH 0/3] net: time stamping fixes
Date: Wed, 19 Oct 2011 14:58:21 +0200 [thread overview]
Message-ID: <1319029101.4424.36.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <1319027881.3103.27.camel@edumazet-laptop> (sfid-20111019_143837_360206_014A6AA4)
On Wed, 2011-10-19 at 14:38 +0200, Eric Dumazet wrote:
> Le mercredi 19 octobre 2011 à 13:50 +0200, Richard Cochran a écrit :
> > On Wed, Oct 19, 2011 at 07:15:36AM +0200, Johannes Berg wrote:
> > > The only thing I'm not completely sure about is whether or not it is
> > > permissible to sock_hold() at that point. I'm probably just missing
> > > something, but: if sk_free() was called before hard_start_xmit() which
> > > will call skb_clone_tx_timestamp(), can we really call sock_hold()?
> > >
>
> This is not possible, or something is really broken. We specifically
> dont skb_orphan(skb) if we know tx timestamping is enabled for this skb.
Why can't sk_free() have been called? I'm not thinking of sock_wfree()
which can't have been called -- so the socket surely still exists
because skb->truesize is still accounted to it -- but what says
sk_refcnt hasn't reached 0 yet?
> /*
> * Try to orphan skb early, right before transmission by the device.
> * We cannot orphan skb if tx timestamp is requested or the sk-reference
> * is needed on driver level for other reasons, e.g. see net/can/raw.c
> */
> static inline void skb_orphan_try(struct sk_buff *skb)
> {
> struct sock *sk = skb->sk;
>
> if (sk && !skb_shinfo(skb)->tx_flags) {
> /* skb_tx_hash() wont be able to get sk.
> * We copy sk_hash into skb->rxhash
> */
> if (!skb->rxhash)
> skb->rxhash = sk->sk_hash;
> skb_orphan(skb);
> }
> }
Right.
> I dont really understand what's the concern, since sk_free() doesnt care
> at all about sk_refcnt, but sk_wmem_alloc.
Right.
> void sk_free(struct sock *sk)
[snip]
> If one skb is in flight, and still linked to a socket, then this socket
> cannot disappear, because this skb->truesize was accounted into
> sk->sk_wmem_alloc
This is undoubtedly true, I'm not disputing this.
> Of course, this point is valid as long as skb had not been orphaned.
>
> sk_refcnt can be 0, if user closed the socket, but socket wont disappear
> as long as sk_wmem_alloc is not 0.
Not disputing this either. But you said sk_refcnt can be 0, so why can't
the following happen:
/* skb; skb->sk = sk; skb->destructor = sock_wfree; */
/* skb is on qdisc, some time passes */
sk_free(sk); /* user closed socket,
sk->sk_refcnt reaches 0,
sk->sk_wmem_alloc == skb->truesize,
__sk_free not called, socket still lives,
but no more +1 in sk_wmem_alloc */
/* some more time passes */
/* ethernet hard_start_xmit calls skb_clone_tx_timestamp() */
skb2 = skb_clone(skb);
skb2->sk = skb->sk;
sock_hold(skb->sk);
/* ethernet TX completion calls skb_free(skb) */
skb_free(skb):
sock_wfree(skb); /* sk_wmem_alloc reaches 0,
__sk_free called DESPITE sk_refcnt > 0 */
/* later, in skb_complete_tx_timestamp() */
sock_put(sk); /* KABOOM */
I just want to understand why this can't happen :-)
johannes
next prev parent reply other threads:[~2011-10-19 12:58 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-07 17:11 [RFC] net: remove erroneous sk null assignment in timestamping Johannes Berg
2011-10-07 17:33 ` David Miller
2011-10-07 17:40 ` Johannes Berg
2011-10-07 17:47 ` Johannes Berg
2011-10-07 17:53 ` Johannes Berg
2011-10-07 18:42 ` Johannes Berg
2011-10-08 7:59 ` Richard Cochran
2011-10-08 7:57 ` Richard Cochran
2011-10-08 8:16 ` Johannes Berg
2011-10-08 8:57 ` Eric Dumazet
2011-10-08 10:32 ` Johannes Berg
2011-10-11 13:34 ` Richard Cochran
2011-10-08 10:35 ` Richard Cochran
2011-10-12 18:36 ` [PATCH 1/1] net: hold sock reference while processing tx timestamps Richard Cochran
2011-10-12 19:25 ` Eric Dumazet
2011-10-12 19:27 ` Johannes Berg
2011-10-12 19:52 ` Eric Dumazet
2011-10-13 8:54 ` Johannes Berg
2011-10-13 4:51 ` Richard Cochran
2011-10-13 9:46 ` [PATCH 0/3] net: time stamping fixes Richard Cochran
2011-10-19 4:16 ` David Miller
2011-10-19 5:15 ` Johannes Berg
2011-10-19 11:50 ` Richard Cochran
2011-10-19 12:33 ` Eric Dumazet
2011-10-19 12:38 ` Eric Dumazet
2011-10-19 12:58 ` Johannes Berg [this message]
2011-10-19 13:09 ` Johannes Berg
2011-10-19 13:25 ` Eric Dumazet
2011-10-19 13:35 ` Johannes Berg
2011-10-19 13:44 ` Eric Dumazet
2011-10-19 13:57 ` Johannes Berg
2011-10-19 14:08 ` Eric Dumazet
2011-10-19 14:24 ` Johannes Berg
2011-10-19 14:27 ` Richard Cochran
2011-10-19 14:33 ` Eric Dumazet
2011-10-19 13:21 ` Eric Dumazet
2011-10-19 13:25 ` Johannes Berg
2011-10-19 13:27 ` Eric Dumazet
2011-10-19 13:32 ` Johannes Berg
2011-10-19 14:25 ` Richard Cochran
2011-10-13 9:46 ` [PATCH 1/3] net: hold sock reference while processing tx timestamps Richard Cochran
2011-10-19 4:42 ` Eric Dumazet
2011-10-13 9:46 ` [PATCH 2/3] dp83640: use proper function to free transmit time stamping packets Richard Cochran
2011-10-19 4:47 ` Eric Dumazet
2011-10-13 9:46 ` [PATCH 3/3] dp83640: free packet queues on remove Richard Cochran
2011-10-19 4:48 ` Eric Dumazet
2011-10-21 10:49 ` [PATCH v2 0/3] net: time stamping fixes Richard Cochran
2011-10-21 10:49 ` [PATCH v2 1/3] net: hold sock reference while processing tx timestamps Richard Cochran
2011-10-21 11:31 ` Eric Dumazet
2011-10-24 6:55 ` David Miller
2011-10-21 11:44 ` Johannes Berg
2011-10-21 10:49 ` [PATCH v2 2/3] dp83640: use proper function to free transmit time stamping packets Richard Cochran
2011-10-24 6:55 ` David Miller
2011-10-24 17:47 ` Richard Cochran
2011-10-24 23:16 ` David Miller
2011-10-21 10:49 ` [PATCH v2 3/3] dp83640: free packet queues on remove Richard Cochran
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=1319029101.4424.36.camel@jlt3.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.com \
/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).