Patchwork [46/49] net/netfilter: Use vzalloc

login
register
mail settings
Submitter Joe Perches
Date Nov. 5, 2010, 3:08 a.m.
Message ID <7d6da34b7e84955795717b0241000a0701cd5b34.1288925425.git.joe@perches.com>
Download mbox | patch
Permalink /patch/70210/
State Deferred
Delegated to: David Miller
Headers show

Comments

Joe Perches - Nov. 5, 2010, 3:08 a.m.
Signed-off-by: Joe Perches <joe@perches.com>
---
 net/netfilter/x_tables.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)
Eric Dumazet - Nov. 5, 2010, 6:30 a.m.
Le jeudi 04 novembre 2010 à 20:08 -0700, Joe Perches a écrit :
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
>  net/netfilter/x_tables.c |    5 ++---
>  1 files changed, 2 insertions(+), 3 deletions(-)

So many 'vzalloc' patches for net tree... 

I had _one_ patch, waiting that David actually had vzalloc() in its tree
before sending it.

Given Jesper Juhl was doing this work, could you please take another
one, please ?

For example, explaining him how to use other tools than "bash+egrep
+manual inspection" as he mentioned in a previous mail.

Really Joe, your behavior should be smarter than that.

Thanks


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Joe Perches - Nov. 5, 2010, 6:55 a.m.
On Fri, 2010-11-05 at 07:30 +0100, Eric Dumazet wrote:
> I had _one_ patch, waiting that David actually had vzalloc() in its tree
> before sending it.

Fine by me, use yours.

> Given Jesper Juhl was doing this work, could you please take another
> one, please ?
> For example, explaining him how to use other tools than "bash+egrep
> +manual inspection" as he mentioned in a previous mail.

Jesper Juhl was both pointed at the cocci docs and
given a cocci script.  He said he'd investigate it
when he could.  I trust he will get to it.

I think that for this sort of patchset, grep and
manual inspection works just as well as spatch
and likely better because a simple cocci script
doesn't transform code like:

	if (size > PAGE_SIZE)
		ptr = vmalloc(size);
	else
		ptr = kmalloc(size, GFP);
	if (ptr)
		memset(ptr, 0, size);

I did say in the 00 cover that this was broken up
just to cc the maintainers of each block.

I also think a single rolled-up single patch is good.

I believe Jiri Kosina can easily apply all these
individual patches as a single patch if he chooses.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Eric Dumazet - Nov. 5, 2010, 7:16 a.m.
Le jeudi 04 novembre 2010 à 23:55 -0700, Joe Perches a écrit :
> On Fri, 2010-11-05 at 07:30 +0100, Eric Dumazet wrote:
> > I had _one_ patch, waiting that David actually had vzalloc() in its tree
> > before sending it.
> 
> Fine by me, use yours.

I dont care at all, only to say that David tree was not ready yet.


> 
> > Given Jesper Juhl was doing this work, could you please take another
> > one, please ?
> > For example, explaining him how to use other tools than "bash+egrep
> > +manual inspection" as he mentioned in a previous mail.
> 
> Jesper Juhl was both pointed at the cocci docs and
> given a cocci script.  He said he'd investigate it
> when he could.  I trust he will get to it.
> 

Yes, yet you posted patches, knowing he was working on the _same_
subject.

I remember other occurrences of such behavior.

I find this behavior very unfriendly, time consuming, and not useful.

We try to work together, to increase our common knowledge, not to throw
a bunch of patches "just because I know better than you"



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jiri Kosina - Nov. 5, 2010, 3:10 p.m.
On Thu, 4 Nov 2010, Joe Perches wrote:

> I also think a single rolled-up single patch is good.
> 
> I believe Jiri Kosina can easily apply all these individual patches as a 
> single patch if he chooses.

I will, after this settles a little bit (the same for the WARN series). 
I prefer waiting a bit before applying your patches usually. 

First to see what lands in linux-next through maintainer's trees, second 
to gather Acks.
Joe Perches - Nov. 5, 2010, 3:25 p.m.
On Fri, 2010-11-05 at 11:10 -0400, Jiri Kosina wrote:
> On Thu, 4 Nov 2010, Joe Perches wrote:
> > I also think a single rolled-up single patch is good.
> > I believe Jiri Kosina can easily apply all these individual patches as a 
> > single patch if he chooses.
> I will, after this settles a little bit (the same for the WARN series). 
> I prefer waiting a bit before applying your patches usually. 
> First to see what lands in linux-next through maintainer's trees, second 
> to gather Acks.

I think that's the right way to do these
sorts of trivial changes too.

Individual patches cc'd to maintainers for
feedback, improvement, acks or to be directly
applied to their trees, followed by a longish
delay before any unapplied patches are taken
up as a single patch by your trivial queue.

Thanks for doing that work Jiri.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jesper Juhl - Nov. 5, 2010, 5:01 p.m.
On Fri, 5 Nov 2010, Eric Dumazet wrote:

> Le jeudi 04 novembre 2010 à 23:55 -0700, Joe Perches a écrit :
> > On Fri, 2010-11-05 at 07:30 +0100, Eric Dumazet wrote:
> > > I had _one_ patch, waiting that David actually had vzalloc() in its tree
> > > before sending it.
> > 
> > Fine by me, use yours.
> 
> I dont care at all, only to say that David tree was not ready yet.
> 
> 
> > 
> > > Given Jesper Juhl was doing this work, could you please take another
> > > one, please ?
> > > For example, explaining him how to use other tools than "bash+egrep
> > > +manual inspection" as he mentioned in a previous mail.
> > 
> > Jesper Juhl was both pointed at the cocci docs and
> > given a cocci script.  He said he'd investigate it
> > when he could.  I trust he will get to it.
> > 
> 
> Yes, yet you posted patches, knowing he was working on the _same_
> subject.
> 
And I will get to look at cocci and spatch, they are definately tools that 
I want in my arsenal.

> I remember other occurrences of such behavior.
> 
> I find this behavior very unfriendly, time consuming, and not useful.
> 
> We try to work together, to increase our common knowledge, not to throw
> a bunch of patches "just because I know better than you"
> 

To be completely honest, I did get the feeling that the task I'd set for 
myself and was having fun doing in the little spare time I have got 
hijacked and I did waste about an hour and a half doing a few more 
cleanups before I saw the patchset on lkml.

But on the other hand, the most important thing is that it gets done, not 
who ends up doing it - especially since it's such a trivial cleanup, so I 
choose to see it as my initial patches just getting the ball rolling.

It would have been nice with at least an email along the lines of "I 
know how we can do all those patches in a jiffy, mind if I just go along 
and do that?", but I'll live. There's plenty of other stuff to do :-)

Patch

diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
index 8046350..89e8895 100644
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -753,12 +753,11 @@  static int xt_jumpstack_alloc(struct xt_table_info *i)
 
 	size = sizeof(void **) * nr_cpu_ids;
 	if (size > PAGE_SIZE)
-		i->jumpstack = vmalloc(size);
+		i->jumpstack = vzalloc(size);
 	else
-		i->jumpstack = kmalloc(size, GFP_KERNEL);
+		i->jumpstack = kzalloc(size, GFP_KERNEL);
 	if (i->jumpstack == NULL)
 		return -ENOMEM;
-	memset(i->jumpstack, 0, size);
 
 	i->stacksize *= xt_jumpstack_multiplier;
 	size = sizeof(void *) * i->stacksize;