All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: kernel-janitors@vger.kernel.org
Subject: Re: [KJ] [PATCH] net/ipv4/netfilter/ipt_recent.c 2.6.17-rc2-git5
Date: Mon, 24 Apr 2006 23:24:33 +0000	[thread overview]
Message-ID: <20060424232433.GC32505@parisc-linux.org> (raw)
In-Reply-To: <444C4F8E.4050001@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]

On Mon, Apr 24, 2006 at 04:39:10PM -0400, Anne Thrax wrote:
> >
> >But this skbuff wasn't allocated with alloc_skb().  Is this kosher?
> >Is it also a bug that this skb was kmalloced?
> >
> >It looks to me like this is a fake skb and it should be kfree'd,
> >but I'd welcome more eyes on this one.
> 
> Maybe we should then have it alloc_skb() rather than just kmalloc()
> The function isn't there for nothing, and it does do some checking
> that would not be done through kmalloc() and kfree().

But then, alloc_skb() does a lot of work that kmalloc doesn't do.
If the author knows that work is irrelevant, then this is a good
optimisation, and perhaps even necessary given that this code path is
potentially called for every packet.

I don't know; you may be right.  Let's see if the author can explain why
he's kmallocing instead of skb_allocing

> --- /usr/src/linux-2.6.17-rc2-git5-orig/net/ipv4/netfilter/ipt_recent.c 
> 2006-04-23 16:47:53.000000000 -0500
> +++ /usr/src/linux-2.6.17-rc2-git5/net/ipv4/netfilter/ipt_recent.c 
> 2006-04-23 23:50:50.000000000 -0500
> @@ -304,7 +304,7 @@
>        strncpy(info->name,curr_table->name,IPT_RECENT_NAME_LEN);
>        info->name[IPT_RECENT_NAME_LEN-1] = '\0';
> 
> -       skb = kmalloc(sizeof(struct sk_buff),GFP_KERNEL);
> +       skb = alloc_skb(sizeof(struct sk_buff),GFP_KERNEL);
>        if (!skb) {
>                used = -ENOMEM;
>                goto out_free_info;
> @@ -323,7 +323,7 @@
> 
>        kfree(skb->nh.iph);
> out_free_skb:
> -       kfree(skb);
> +       kfree_skb(skb);
> out_free_info:
>        kfree(info);
> 
> 
> While reading the function alloc_skb(), you can request it to be
> a certain size. But why would anyone want to allocate a different
> size than sizeof(sk_buff)? Unless there is something I'm missing
> here, why don't we just remove the size parameter altogether?
> _______________________________________________
> Kernel-janitors mailing list
> Kernel-janitors@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/kernel-janitors

[-- Attachment #2: Type: text/plain, Size: 168 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

  parent reply	other threads:[~2006-04-24 23:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-24  4:09 [KJ] [PATCH] net/ipv4/netfilter/ipt_recent.c 2.6.17-rc2-git5 Anne Thrax
2006-04-24  4:41 ` Matthew Wilcox
2006-04-24 20:39 ` Anne Thrax
2006-04-24 23:24 ` Matthew Wilcox [this message]
2006-04-25  0:31 ` Stephen Frost
2006-04-25  1:04 ` Anne Thrax

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=20060424232433.GC32505@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=kernel-janitors@vger.kernel.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 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.