diff for duplicates of <CALCETrWaewXsdJsf3SocgZ0ggnvZk86L+5-LWPRbjdnG2mB7jw@mail.gmail.com>
diff --git a/a/content_digest b/N1/content_digest
index 224ad6b..4ed148b 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -45,7 +45,11 @@
" Kees Cook <keescook\@chromium.org>",
" Martin K. Petersen <martin.petersen\@oracle.com>",
" Greg KH <gregkh\@linuxfoundation.org>",
- " Andrew Mort\0"
+ " Andrew Morton <akpm\@linux-foundation.org>",
+ " Richard Weinberger <richard\@nod.at>",
+ " Linux Crypto Mailing List <linux-crypto\@vger.kernel.org>",
+ " linux-arm-kernel <linux-arm-kernel\@lists.infradead.org>",
+ " linuxppc-dev <linuxppc-dev\@lists.ozlabs.org>\0"
]
[
"\0000:1\0"
@@ -189,4 +193,4 @@
"--Andy"
]
-1716d7dcf82ed39f5220fc8b4b2a0a4f3e58af770c1355ffa7b49f2d85cf554e
+daf271db7baea18012e360c9bec9373bc44448e9b6ec8f259664c7c942557f31
diff --git a/a/content_digest b/N2/content_digest
index 224ad6b..40e8ee7 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -26,26 +26,28 @@
"To\0Ard Biesheuvel <ard.biesheuvel\@linaro.org>\0"
]
[
- "Cc\0Peter Zijlstra <peterz\@infradead.org>",
- " LKML <linux-kernel\@vger.kernel.org>",
- " Jason A. Donenfeld <Jason\@zx2c4.com>",
- " Eric Biggers <ebiggers\@kernel.org>",
- " Samuel Neves <sneves\@dei.uc.pt>",
- " Andrew Lutomirski <luto\@kernel.org>",
- " Arnd Bergmann <arnd\@arndb.de>",
- " Herbert Xu <herbert\@gondor.apana.org.au>",
- " David S. Miller <davem\@davemloft.net>",
+ "Cc\0Jason A. Donenfeld <Jason\@zx2c4.com>",
+ " Peter Zijlstra <peterz\@infradead.org>",
" Catalin Marinas <catalin.marinas\@arm.com>",
" Will Deacon <will.deacon\@arm.com>",
- " Benjamin Herrenschmidt <benh\@kernel.crashing.org>",
+ " Samuel Neves <sneves\@dei.uc.pt>",
" Paul Mackerras <paulus\@samba.org>",
- " Michael Ellerman <mpe\@ellerman.id.au>",
- " Thomas Gleixner <tglx\@linutronix.de>",
+ " Herbert Xu <herbert\@gondor.apana.org.au>",
+ " Richard Weinberger <richard\@nod.at>",
+ " Eric Biggers <ebiggers\@kernel.org>",
" Ingo Molnar <mingo\@redhat.com>",
" Kees Cook <keescook\@chromium.org>",
+ " Arnd Bergmann <arnd\@arndb.de>",
+ " Andrew Lutomirski <luto\@kernel.org>",
+ " Thomas Gleixner <tglx\@linutronix.de>",
+ " linux-arm-kernel <linux-arm-kernel\@lists.infradead.org>",
" Martin K. Petersen <martin.petersen\@oracle.com>",
" Greg KH <gregkh\@linuxfoundation.org>",
- " Andrew Mort\0"
+ " LKML <linux-kernel\@vger.kernel.org>",
+ " Linux Crypto Mailing List <linux-crypto\@vger.kernel.org>",
+ " Andrew Morton <akpm\@linux-foundation.org>",
+ " linuxppc-dev <linuxppc-dev\@lists.ozlabs.org>",
+ " David S. Miller <davem\@davemloft.net>\0"
]
[
"\0000:1\0"
@@ -189,4 +191,4 @@
"--Andy"
]
-1716d7dcf82ed39f5220fc8b4b2a0a4f3e58af770c1355ffa7b49f2d85cf554e
+dbef6216682fedf6917d4972622ddf3332b12c3af0b311b3a6241d4754120f0d
diff --git a/a/1.txt b/N3/1.txt
index 18ed7a1..296e896 100644
--- a/a/1.txt
+++ b/N3/1.txt
@@ -60,15 +60,15 @@ On Fri, Oct 5, 2018 at 8:24 AM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >> site, so how are we going to patch all call-sites when you update the
> >> target?
> >
-> > I’m also confused.
+> > I?m also confused.
> >
-> > Anyway, we have patchable functions on x86. They’re called PVOPs, and they’re way overcomplicated.
+> > Anyway, we have patchable functions on x86. They?re called PVOPs, and they?re way overcomplicated.
> >
-> > I’ve proposed a better way that should generate better code, be more portable, and be more maintainable. It goes like this.
+> > I?ve proposed a better way that should generate better code, be more portable, and be more maintainable. It goes like this.
> >
-> > To call the function, you literally just call the default implementation. It *might* be necessary to call a nonexistent wrapper to avoid annoying optimizations. At build time, the kernel is built with relocations, so the object files contain relocation entries for the call. We collect these entries into a table. If we’re using the “nonexistent wrapper” approach, we can link in a .S or linker script to alias them to the default implementation.
+> > To call the function, you literally just call the default implementation. It *might* be necessary to call a nonexistent wrapper to avoid annoying optimizations. At build time, the kernel is built with relocations, so the object files contain relocation entries for the call. We collect these entries into a table. If we?re using the ?nonexistent wrapper? approach, we can link in a .S or linker script to alias them to the default implementation.
> >
-> > To patch them, we just patch them. It can’t necessarily be done concurrently because nothing forces the right alignment. But we can do it at boot time and module load time. (Maybe we can patch at runtime on architectures with appropriate instruction alignment. Or we ask gcc for an extension to align calls to a function.)
+> > To patch them, we just patch them. It can?t necessarily be done concurrently because nothing forces the right alignment. But we can do it at boot time and module load time. (Maybe we can patch at runtime on architectures with appropriate instruction alignment. Or we ask gcc for an extension to align calls to a function.)
> >
> > Most of the machinery already exists: this is roughly how the module loader resolves calls outside of a module.
>
diff --git a/a/content_digest b/N3/content_digest
index 224ad6b..eede1b2 100644
--- a/a/content_digest
+++ b/N3/content_digest
@@ -14,38 +14,16 @@
"ref\0CAKv+Gu9z503ZJXcsG+9Ys240BZiB-+GB=kNY4VGWpjvdzN4JtA\@mail.gmail.com\0"
]
[
- "From\0Andy Lutomirski <luto\@kernel.org>\0"
+ "From\0luto\@kernel.org (Andy Lutomirski)\0"
]
[
- "Subject\0Re: [RFC PATCH 1/9] kernel: add support for patchable function pointers\0"
+ "Subject\0[RFC PATCH 1/9] kernel: add support for patchable function pointers\0"
]
[
"Date\0Fri, 5 Oct 2018 09:58:23 -0700\0"
]
[
- "To\0Ard Biesheuvel <ard.biesheuvel\@linaro.org>\0"
-]
-[
- "Cc\0Peter Zijlstra <peterz\@infradead.org>",
- " LKML <linux-kernel\@vger.kernel.org>",
- " Jason A. Donenfeld <Jason\@zx2c4.com>",
- " Eric Biggers <ebiggers\@kernel.org>",
- " Samuel Neves <sneves\@dei.uc.pt>",
- " Andrew Lutomirski <luto\@kernel.org>",
- " Arnd Bergmann <arnd\@arndb.de>",
- " Herbert Xu <herbert\@gondor.apana.org.au>",
- " David S. Miller <davem\@davemloft.net>",
- " Catalin Marinas <catalin.marinas\@arm.com>",
- " Will Deacon <will.deacon\@arm.com>",
- " Benjamin Herrenschmidt <benh\@kernel.crashing.org>",
- " Paul Mackerras <paulus\@samba.org>",
- " Michael Ellerman <mpe\@ellerman.id.au>",
- " Thomas Gleixner <tglx\@linutronix.de>",
- " Ingo Molnar <mingo\@redhat.com>",
- " Kees Cook <keescook\@chromium.org>",
- " Martin K. Petersen <martin.petersen\@oracle.com>",
- " Greg KH <gregkh\@linuxfoundation.org>",
- " Andrew Mort\0"
+ "To\0linux-arm-kernel\@lists.infradead.org\0"
]
[
"\0000:1\0"
@@ -116,15 +94,15 @@
"> >> site, so how are we going to patch all call-sites when you update the\n",
"> >> target?\n",
"> >\n",
- "> > I\342\200\231m also confused.\n",
+ "> > I?m also confused.\n",
"> >\n",
- "> > Anyway, we have patchable functions on x86. They\342\200\231re called PVOPs, and they\342\200\231re way overcomplicated.\n",
+ "> > Anyway, we have patchable functions on x86. They?re called PVOPs, and they?re way overcomplicated.\n",
"> >\n",
- "> > I\342\200\231ve proposed a better way that should generate better code, be more portable, and be more maintainable. It goes like this.\n",
+ "> > I?ve proposed a better way that should generate better code, be more portable, and be more maintainable. It goes like this.\n",
"> >\n",
- "> > To call the function, you literally just call the default implementation. It *might* be necessary to call a nonexistent wrapper to avoid annoying optimizations. At build time, the kernel is built with relocations, so the object files contain relocation entries for the call. We collect these entries into a table. If we\342\200\231re using the \342\200\234nonexistent wrapper\342\200\235 approach, we can link in a .S or linker script to alias them to the default implementation.\n",
+ "> > To call the function, you literally just call the default implementation. It *might* be necessary to call a nonexistent wrapper to avoid annoying optimizations. At build time, the kernel is built with relocations, so the object files contain relocation entries for the call. We collect these entries into a table. If we?re using the ?nonexistent wrapper? approach, we can link in a .S or linker script to alias them to the default implementation.\n",
"> >\n",
- "> > To patch them, we just patch them. It can\342\200\231t necessarily be done concurrently because nothing forces the right alignment. But we can do it at boot time and module load time. (Maybe we can patch at runtime on architectures with appropriate instruction alignment. Or we ask gcc for an extension to align calls to a function.)\n",
+ "> > To patch them, we just patch them. It can?t necessarily be done concurrently because nothing forces the right alignment. But we can do it at boot time and module load time. (Maybe we can patch at runtime on architectures with appropriate instruction alignment. Or we ask gcc for an extension to align calls to a function.)\n",
"> >\n",
"> > Most of the machinery already exists: this is roughly how the module loader resolves calls outside of a module.\n",
">\n",
@@ -189,4 +167,4 @@
"--Andy"
]
-1716d7dcf82ed39f5220fc8b4b2a0a4f3e58af770c1355ffa7b49f2d85cf554e
+199270981e4db619d5b593625fd6f4732af160e6298207db1276744bbd61b1b8
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.