| Message ID | 7d6da34b7e84955795717b0241000a0701cd5b34.1288925425.git.joe@perches.com |
|---|---|
| State | Deferred, archived |
| Delegated to: | David Miller |
| Headers | show |
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
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
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
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.
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
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 :-)
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;
Signed-off-by: Joe Perches <joe@perches.com> --- net/netfilter/x_tables.c | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-)