From: David Miller <davem@davemloft.net>
To: subashab@codeaurora.org
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org
Subject: Re: [PATCH] net: ipv4: Fix incorrect free in ICMP receive
Date: Fri, 16 Jan 2015 16:48:30 -0500 (EST) [thread overview]
Message-ID: <20150116.164830.172588830692811414.davem@davemloft.net> (raw)
In-Reply-To: <ff3aa93b48dfedd7721d7fcc8ee7624b.squirrel@www.codeaurora.org>
From: subashab@codeaurora.org
Date: Fri, 16 Jan 2015 20:59:14 -0000
>>skb_queue_purge() is also calling skb_orphan() on all skb
> From my reading, it looked like skb_queue_purge() is dequeuing and calling
> kfree_skb() which will release a reference. I did not see skb_orphan()
> being called directly. Am I missing something?
> I think that if it had really orphaned the skb, then this crash would not
> be seen in the first place.
The calls to skb->destructor(), done by skb_queue_purge() (via
kfree_skb()) do this.
But even if it didn't, the fact remains that we are operating on the
socket right here in the destructor. It still exists and has not been
freed yet.
And furthermore, exactly what skb_orphan() does is call skb->destructor(),
_JUST_LIKE_ skb_queue_purge() will via kfree_skb().
So either sock_rfree() is safe to call here, or it isn't. You are not
eliminating the calls to sock_rfree() which operate on this socket at
all. If you did, then the socket memory counters would end up being
corrupts and the warnings would trigger:
WARN_ON(atomic_read(&sk->sk_rmem_alloc));
WARN_ON(atomic_read(&sk->sk_wmem_alloc));
You're just moving the skb->destructor() call up a few lines in the
same function, it makes therefore no sense why this would fix a bug
or not.
next prev parent reply other threads:[~2015-01-16 21:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-16 7:48 [PATCH] net: ipv4: Fix incorrect free in ICMP receive subashab
2015-01-16 8:09 ` David Miller
2015-01-16 12:52 ` Eric Dumazet
2015-01-16 20:59 ` subashab
2015-01-16 21:48 ` Eric Dumazet
2015-01-16 21:48 ` David Miller [this message]
2015-01-20 2:34 ` subashab
2015-01-20 3:50 ` Eric Dumazet
2015-01-20 19:42 ` Cong Wang
2015-01-20 21:35 ` Eric Dumazet
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=20150116.164830.172588830692811414.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=subashab@codeaurora.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).