linux-kernel - Re: [PATCH 0/6] percpu: Implement Preemption checks for __this

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 14 Oct 2013 22:24:30 +0000
From:	Christoph Lameter <cl@...ux.com>
To:	Ingo Molnar <mingo@...nel.org>
cc:	David Miller <davem@...emloft.net>, tj@...nel.org,
	akpm@...uxfoundation.org, srostedt@...hat.com,
	linux-kernel@...r.kernel.org, peterz@...radead.org,
	tglx@...utronix.de
Subject: Re: [PATCH 0/6] percpu: Implement Preemption checks for __this_cpu
 operations V4

On Sat, 12 Oct 2013, Ingo Molnar wrote:

> Another problem is that the patch emails are not properly threaded to the
> 0/6 patch and thus appear out of order and mixed up:
>
> 66216 N C Oct 11 Christoph Lamet (  36) [PATCH 0/6] percpu: Implement Preemption checks for __this_cpu operations V4
> 66217 N C Oct 11 David Miller    (  13) О©╫О©╫>
> 66218 N C Oct 11 Christoph Lamet (  43) О©╫О©╫>[PATCH 1/6] net: ip4_datagram_connect: Use correct form of statistics update
> 66219 N C Oct 11 Eric Dumazet    (  17) О©╫ О©╫О©╫>
> 66220 N C Oct 11 Christoph Lamet ( 121) О©╫О©╫>[PATCH 2/6] percpu: Add raw_cpu_ops
> 66221 N C Oct 11 Christoph Lamet ( 189) О©╫О©╫>[PATCH 6/6] percpu: Add preemption checks to __this_cpu ops
> 66222 N C Oct 11 Christoph Lamet (  64) О©╫О©╫>[PATCH 5/6] net: __this_cpu_inc in route.c
> 66223 N C Oct 11 Christoph Lamet ( 103) О©╫О©╫>[PATCH 3/6] mm: Use raw_cpu ops for determining current NUMA node
> 66224 N C Oct 11 Christoph Lamet (  43) О©╫О©╫>[PATCH 4/6] Use raw_cpu_write for initialization of per cpu refcount.
>
> Note how the order is 1,2,6,5,3,4 with no threading instead of 1,2,3,4,5,6
> with proper threading.

Threading is done by quilt and it has been doing that for a pretty long time.

> That won't cause email servers to reject the mails, it just makes the
> patches a bit harder to review.

I do not have any control over how my ISP sorts these emails. You
repeatedly asked me to use quilt 0.60 because I guess you believed that it
could do some magic. I upgraded specially for you. I really do not know
what else to do to appease you. I could chance ISPs hoping that another
will deliver them in sequence but that is not easy to do. Maybe Amazon in
some way borks the headers.

> Most kernel developers tend to use 'git send-email' to send patches to
> lkml, and that method is working pretty reliably.

People are not allowed to use quilt for patches submitted to you?

I just checked and git send-mail does the threading in the same way as
quilt. There would be no change.