From: Eric Dumazet <eric.dumazet@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: shemminger@vyatta.com, netdev@vger.kernel.org
Subject: Re: OOP in ip_cmsg_recv (net-next)
Date: Tue, 04 May 2010 06:43:45 +0200 [thread overview]
Message-ID: <1272948225.2407.170.camel@edumazet-laptop> (raw)
In-Reply-To: <20100503.152351.181464355.davem@davemloft.net>
Le lundi 03 mai 2010 à 15:23 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 03 May 2010 19:21:09 +0200
>
> >
> > - /* skb is now orphaned, might be freed outside of locked section */
> > - consume_skb(skb);
> > + /* skb is now orphaned, can be freed outside of locked section */
> > + __kfree_skb(skb);
> > }
> > EXPORT_SYMBOL(skb_free_datagram_locked);
>
> Eric, if you do this you undo the utility of the SKB packet drop tracing
> that Neil wrote.
>
> consome_skb() says that the application actually took in the packet and
> we didn't drop it due to some error or similar.
>
> Whereas __kfree_skb() is going to be tagged as a packet drop and the
> data didn't reach the application.
>
> So if you need to use __kfree_skb() to fix this you'll need to somehow
> add some appropriate annotations for the tracer. Perhaps add a
> __consume_skb() that is marked for the tracing stuff and does what
> you need.
> --
David, if I am not mistaken (not thea yet for me this early morning) the
tracer you mention is included in kfree_skb(), not in __kfree_skb() :
void kfree_skb(struct sk_buff *skb)
{
if (unlikely(!skb))
return;
if (likely(atomic_read(&skb->users) == 1))
smp_rmb();
else if (likely(!atomic_dec_and_test(&skb->users)))
return;
trace_kfree_skb(skb, __builtin_return_address(0));
__kfree_skb(skb);
}
EXPORT_SYMBOL(kfree_skb);
I only copied part of consume_skb() which doesnt call
trace_kfree_skb() :
void consume_skb(struct sk_buff *skb)
{
if (unlikely(!skb))
return;
if (likely(atomic_read(&skb->users) == 1))
smp_rmb();
else if (likely(!atomic_dec_and_test(&skb->users)))
return;
__kfree_skb(skb);
}
EXPORT_SYMBOL(consume_skb);
So I believe my second patch is a bit better : We dont even lock the
socket in the (rare) case we should not orphan the skb ;)
We keep the two slab calls outside of sock lock, so we keep sock locked
for a very very short time period (remember we now use lock_sock_bh() :
producers now might spin on the lock instead of queueing packet in
backlog)
Thanks !
[PATCH net-next-2.6] net: skb_free_datagram_locked() fix
Commit 4b0b72f7dd617b ( net: speedup udp receive path )
introduced a bug in skb_free_datagram_locked().
We should not skb_orphan() skb if we dont have the guarantee we are the
last skb user, this might happen with MSG_PEEK concurrent users.
To keep socket locked for the smallest period of time, we split
consume_skb() logic, inlined in skb_free_datagram_locked()
Reported-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/datagram.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/core/datagram.c b/net/core/datagram.c
index 95b851f..e009753 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -229,13 +229,18 @@ EXPORT_SYMBOL(skb_free_datagram);
void skb_free_datagram_locked(struct sock *sk, struct sk_buff *skb)
{
+ if (likely(atomic_read(&skb->users) == 1))
+ smp_rmb();
+ else if (likely(!atomic_dec_and_test(&skb->users)))
+ return;
+
lock_sock_bh(sk);
skb_orphan(skb);
sk_mem_reclaim_partial(sk);
unlock_sock_bh(sk);
- /* skb is now orphaned, might be freed outside of locked section */
- consume_skb(skb);
+ /* skb is now orphaned, can be freed outside of locked section */
+ __kfree_skb(skb);
}
EXPORT_SYMBOL(skb_free_datagram_locked);
next prev parent reply other threads:[~2010-05-04 4:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-03 16:47 OOP in ip_cmsg_recv (net-next) Stephen Hemminger
2010-05-03 17:04 ` Eric Dumazet
2010-05-03 17:21 ` Eric Dumazet
2010-05-03 22:23 ` David Miller
2010-05-04 4:43 ` Eric Dumazet [this message]
2010-05-04 6:17 ` David Miller
2010-05-03 21:00 ` Stephen Hemminger
2010-05-03 22:30 ` David Miller
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=1272948225.2407.170.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.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