From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>,
Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Alexander Duyck <alexander.h.duyck@intel.com>,
Florian Westphal <fw@strlen.de>,
netdev@vger.kernel.org, mkl@pengutronix.de,
"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
Subject: Re: [PATCH] can: use sock_efree instead of own destructor
Date: Tue, 10 Mar 2015 08:19:33 -0700 [thread overview]
Message-ID: <54FF0B85.7040601@redhat.com> (raw)
In-Reply-To: <1425998185.8261.51.camel@edumazet-glaptop2.roam.corp.google.com>
On 03/10/2015 07:36 AM, Eric Dumazet wrote:
> On Tue, 2015-03-10 at 14:36 +0100, Oliver Hartkopp wrote:
>> Yes - in connection with sock_rfree() for the read buffer destructur and
>> sock_wfree() for the write buffer it can make sense to name a function
>> sock_efree() as an unassigned destructor - which does not fiddle with rmem nor
>> wmen.
>>
>> But both sock_efree() and sock_edemux() lack some comment - especially when it
>> makes sense to use them from non-INET contexts which Florian suggested.
>>
>> Maybe Alexander can send a patch which adds a comment, as I don't know if I
>> would find the best words for it.
> Please do not top post on netdev.
>
> If you cannot find best words for it, maybe a comment would not be
> useful : Very often, best comments are added by people that had problems
> to understand the code ;)
>
> I do not trust comments, I prefer using "git grep" or tools like that to
> check call sites.
>
> In this particular case this becomes clear, while being concise.
>
> # git grep -n sock_efree
> include/net/sock.h:1526:void sock_efree(struct sk_buff *skb);
> include/net/sock.h:1530:#define sock_edemux(skb) sock_efree(skb)
> net/core/skbuff.c:3625: clone->destructor = sock_efree;
> net/core/sock.c:1658:void sock_efree(struct sk_buff *skb)
> net/core/sock.c:1662:EXPORT_SYMBOL(sock_efree);
> net/ipv4/udp.c:1992: skb->destructor = sock_efree;
As I recall one of the reasons for leaving it as sock_efree was because
sock_put just calls sk_free if it has decremented the reference count to
0. Also as Eric pointed out the name is actually pretty close to the
existing destructors sock_edemux and sock_rfree. The sock_efree name
was based on the fact that the main consumer is usually either the UDP
early receive path or the error handler/Timestamp path.
As far as the comments about it not freeing anything take a look at
sock_rfree and tell me what it is actually freeing? Last I knew it is
simply dropping references to memory so that the socket can go ahead and
either make use of them or close itself once all references have been
freed. That is the same thing this does, but it is holding references
to a single byte of sk_wmem_alloc.
Patches are always welcome if you believe we need additional
documentation, I had assumed this was pretty straight forward since the
function was essentially just a wrapper for sock_put so I could use it
as a destructor.
- Alex
prev parent reply other threads:[~2015-03-10 15:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1425959300-27132-1-git-send-email-fw@strlen.de>
2015-03-10 6:14 ` [PATCH] can: use sock_efree instead of own destructor Oliver Hartkopp
2015-03-10 12:22 ` Eric Dumazet
2015-03-10 13:36 ` Oliver Hartkopp
2015-03-10 14:36 ` Eric Dumazet
2015-03-10 14:55 ` Oliver Hartkopp
2015-03-10 15:19 ` Alexander Duyck [this message]
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=54FF0B85.7040601@redhat.com \
--to=alexander.h.duyck@redhat.com \
--cc=alexander.h.duyck@intel.com \
--cc=eric.dumazet@gmail.com \
--cc=fw@strlen.de \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=socketcan@hartkopp.net \
/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).