From: Eric Dumazet <eric.dumazet@gmail.com>
To: Johannes Berg <johannes@sipsolutions.net>
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 15:21:43 +0200 [thread overview]
Message-ID: <1319030503.8416.11.camel@edumazet-laptop> (raw)
In-Reply-To: <1319029101.4424.36.camel@jlt3.sipsolutions.net>
Le mercredi 19 octobre 2011 à 14:58 +0200, Johannes Berg a écrit :
> 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 :-)
Since you answer your own question :)
Hmm, oh well, sk_refcnt is/should not be changed if a xmit packet is
duped, but sk_wmem_alloc should be, exactly paired with skb->truesize
next prev parent reply other threads:[~2011-10-19 13:21 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-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-19 4:16 ` [PATCH 0/3] net: time stamping fixes 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
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 [this message]
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-21 10:49 ` [PATCH v2 " 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=1319030503.8416.11.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=johannes@sipsolutions.net \
--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