All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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-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 [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-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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.