diff for duplicates of <CAHmME9pZKUMnnSZ0670rUH4H61g0x88c-B-DZYw_X-8+xgH-=g@mail.gmail.com>
diff --git a/a/1.txt b/N1/1.txt
index 10c99d0..bfb14c2 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,7 +1,7 @@
On Wed, Sep 26, 2018 at 6:21 PM Andy Lutomirski <luto@amacapital.net> wrote:
-> Are, is what you’re saying that the Zinc chacha20 functions should call simd_relax() every n bytes automatically for some reasonable value of n? If so, seems sensible, except that some care might be needed to make sure they interact with preemption correctly.
+> Are, is what you?re saying that the Zinc chacha20 functions should call simd_relax() every n bytes automatically for some reasonable value of n? If so, seems sensible, except that some care might be needed to make sure they interact with preemption correctly.
>
-> What I mean is: the public Zinc entry points should either be callable in an atomic context or they should not be. I think this should be checked at runtime in an appropriate place with an __might_sleep or similar. Or simd_relax should learn to *not* schedule if the result of preempt_enable() leaves it atomic. (And the latter needs to be done in a way that works even on non-preempt kernels, and I don’t remember whether that’s possible.). And this should happen regardless of how many bytes are processed. IOW, calling into Zinc should be equally not atomic-safe for 100 bytes and for 10 MB.
+> What I mean is: the public Zinc entry points should either be callable in an atomic context or they should not be. I think this should be checked at runtime in an appropriate place with an __might_sleep or similar. Or simd_relax should learn to *not* schedule if the result of preempt_enable() leaves it atomic. (And the latter needs to be done in a way that works even on non-preempt kernels, and I don?t remember whether that?s possible.). And this should happen regardless of how many bytes are processed. IOW, calling into Zinc should be equally not atomic-safe for 100 bytes and for 10 MB.
I'm not sure this is actually a problem. Namely:
diff --git a/a/content_digest b/N1/content_digest
index fdd8d31..c2d6391 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -17,31 +17,16 @@
"ref\0D93C2C15-DC70-4A95-9350-AD4036C9556A\@amacapital.net\0"
]
[
- "From\0Jason A. Donenfeld <Jason\@zx2c4.com>\0"
+ "From\0Jason\@zx2c4.com (Jason A. Donenfeld)\0"
]
[
- "Subject\0Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations\0"
+ "Subject\0[PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations\0"
]
[
"Date\0Wed, 26 Sep 2018 19:03:34 +0200\0"
]
[
- "To\0Andy Lutomirski <luto\@amacapital.net>\0"
-]
-[
- "Cc\0Ard Biesheuvel <ard.biesheuvel\@linaro.org>",
- " Herbert Xu <herbert\@gondor.apana.org.au>",
- " Thomas Gleixner <tglx\@linutronix.de>",
- " LKML <linux-kernel\@vger.kernel.org>",
- " Netdev <netdev\@vger.kernel.org>",
- " Linux Crypto Mailing List <linux-crypto\@vger.kernel.org>",
- " David Miller <davem\@davemloft.net>",
- " Greg Kroah-Hartman <gregkh\@linuxfoundation.org>",
- " Samuel Neves <sneves\@dei.uc.pt>",
- " Andrew Lutomirski <luto\@kernel.org>",
- " Jean-Philippe Aumasson <jeanphilippe.aumasson\@gmail.com>",
- " Russell King - ARM Linux <linux\@armlinux.org.uk>",
- " linux-arm-kernel\@lists.infradead.org\0"
+ "To\0linux-arm-kernel\@lists.infradead.org\0"
]
[
"\0000:1\0"
@@ -51,9 +36,9 @@
]
[
"On Wed, Sep 26, 2018 at 6:21 PM Andy Lutomirski <luto\@amacapital.net> wrote:\n",
- "> Are, is what you\342\200\231re saying that the Zinc chacha20 functions should call simd_relax() every n bytes automatically for some reasonable value of n? If so, seems sensible, except that some care might be needed to make sure they interact with preemption correctly.\n",
+ "> Are, is what you?re saying that the Zinc chacha20 functions should call simd_relax() every n bytes automatically for some reasonable value of n? If so, seems sensible, except that some care might be needed to make sure they interact with preemption correctly.\n",
">\n",
- "> What I mean is: the public Zinc entry points should either be callable in an atomic context or they should not be. I think this should be checked at runtime in an appropriate place with an __might_sleep or similar. Or simd_relax should learn to *not* schedule if the result of preempt_enable() leaves it atomic. (And the latter needs to be done in a way that works even on non-preempt kernels, and I don\342\200\231t remember whether that\342\200\231s possible.). And this should happen regardless of how many bytes are processed. IOW, calling into Zinc should be equally not atomic-safe for 100 bytes and for 10 MB.\n",
+ "> What I mean is: the public Zinc entry points should either be callable in an atomic context or they should not be. I think this should be checked at runtime in an appropriate place with an __might_sleep or similar. Or simd_relax should learn to *not* schedule if the result of preempt_enable() leaves it atomic. (And the latter needs to be done in a way that works even on non-preempt kernels, and I don?t remember whether that?s possible.). And this should happen regardless of how many bytes are processed. IOW, calling into Zinc should be equally not atomic-safe for 100 bytes and for 10 MB.\n",
"\n",
"I'm not sure this is actually a problem. Namely:\n",
"\n",
@@ -78,4 +63,4 @@
"Jason"
]
-b25a42a95c2f056b16e7a67311c449fc35802992f646bbd1d9487ab15e28190a
+cf7a80b75b780b962b6aab5d638db93b6d6be94f62c59a917880b9a8ecbd1ebf
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.