diff for duplicates of <20181111173650.GA256781@google.com> diff --git a/a/1.txt b/N1/1.txt index 58ab57b..daa7957 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -126,10 +126,10 @@ The updated patch now looks like the following: ---8<----------------------- -From: "Joel Fernandes" <joel@joelfernandes.org> +From: "Joel Fernandes" <joel at joelfernandes.org> Subject: [PATCH] mm/memfd: implement future write seal using shmem ops -Signed-off-by: Joel Fernandes <joel@joelfernandes.org> +Signed-off-by: Joel Fernandes <joel at joelfernandes.org> --- fs/hugetlbfs/inode.c | 2 +- mm/memfd.c | 19 ------------------- diff --git a/a/content_digest b/N1/content_digest index c58f51d..1cb968b 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -8,32 +8,9 @@ "ref\020181111080945.GA78191@google.com\0" "ref\0CAKOZuethQ3eaV4uoEXiffVMc_S0hyk1FGPB3iQHHnv4NadW1UQ@mail.gmail.com\0" "ref\091E8E1AA-859A-457A-8978-3EA39CBBF075@amacapital.net\0" - "From\0Joel Fernandes <joel@joelfernandes.org>\0" - "Subject\0Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd\0" + "From\0joel at joelfernandes.org (Joel Fernandes)\0" + "Subject\0[PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd\0" "Date\0Sun, 11 Nov 2018 09:36:50 -0800\0" - "To\0Andy Lutomirski <luto@amacapital.net>\0" - "Cc\0Daniel Colascione <dancol@google.com>" - Jann Horn <jannh@google.com> - kernel list <linux-kernel@vger.kernel.org> - John Reck <jreck@google.com> - John Stultz <john.stultz@linaro.org> - Todd Kjos <tkjos@google.com> - Greg Kroah-Hartman <gregkh@linuxfoundation.org> - Christoph Hellwig <hch@infradead.org> - Al Viro <viro@zeniv.linux.org.uk> - Andrew Morton <akpm@linux-foundation.org> - Bruce Fields <bfields@fieldses.org> - Jeff Layton <jlayton@kernel.org> - Khalid Aziz <khalid.aziz@oracle.com> - Lei.Yang@windriver.com - linux-fsdevel@vger.kernel.org - linux-kselftest@vger.kernel.org - Linux-MM <linux-mm@kvack.org> - marcandre.lureau@redhat.com - Mike Kravetz <mike.kravetz@oracle.com> - Minchan Kim <minchan@kernel.org> - Shuah Khan <shuah@kernel.org> - " Valdis\0" "\00:1\0" "b\0" "On Sun, Nov 11, 2018 at 07:14:33AM -0800, Andy Lutomirski wrote:\n" @@ -164,10 +141,10 @@ "\n" "---8<-----------------------\n" "\n" - "From: \"Joel Fernandes\" <joel@joelfernandes.org>\n" + "From: \"Joel Fernandes\" <joel at joelfernandes.org>\n" "Subject: [PATCH] mm/memfd: implement future write seal using shmem ops\n" "\n" - "Signed-off-by: Joel Fernandes <joel@joelfernandes.org>\n" + "Signed-off-by: Joel Fernandes <joel at joelfernandes.org>\n" "---\n" " fs/hugetlbfs/inode.c | 2 +-\n" " mm/memfd.c | 19 -------------------\n" @@ -269,4 +246,4 @@ "-- \n" 2.19.1.930.g4563a0d9d0-goog -b3f09a2f634608a86befb293c1c890dc65fc6e81eefad4e4bfd0ef9c1f14807e +4ab8cd4e51a76422903ca1e7520cd7bc05db3639b1c9defe1078e447c9d4b862
diff --git a/a/1.txt b/N2/1.txt index 58ab57b..9731b99 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,4 +1,4 @@ -On Sun, Nov 11, 2018 at 07:14:33AM -0800, Andy Lutomirski wrote: +On Sun, Nov 11, 2018@07:14:33AM -0800, Andy Lutomirski wrote: [...] > >>>>>>>>>> I see two reasonable solutions: > >>>>>>>>>> @@ -129,7 +129,7 @@ The updated patch now looks like the following: From: "Joel Fernandes" <joel@joelfernandes.org> Subject: [PATCH] mm/memfd: implement future write seal using shmem ops -Signed-off-by: Joel Fernandes <joel@joelfernandes.org> +Signed-off-by: Joel Fernandes <joel at joelfernandes.org> --- fs/hugetlbfs/inode.c | 2 +- mm/memfd.c | 19 ------------------- diff --git a/a/content_digest b/N2/content_digest index c58f51d..7d0248f 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -8,35 +8,12 @@ "ref\020181111080945.GA78191@google.com\0" "ref\0CAKOZuethQ3eaV4uoEXiffVMc_S0hyk1FGPB3iQHHnv4NadW1UQ@mail.gmail.com\0" "ref\091E8E1AA-859A-457A-8978-3EA39CBBF075@amacapital.net\0" - "From\0Joel Fernandes <joel@joelfernandes.org>\0" - "Subject\0Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd\0" + "From\0joel@joelfernandes.org (Joel Fernandes)\0" + "Subject\0[PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd\0" "Date\0Sun, 11 Nov 2018 09:36:50 -0800\0" - "To\0Andy Lutomirski <luto@amacapital.net>\0" - "Cc\0Daniel Colascione <dancol@google.com>" - Jann Horn <jannh@google.com> - kernel list <linux-kernel@vger.kernel.org> - John Reck <jreck@google.com> - John Stultz <john.stultz@linaro.org> - Todd Kjos <tkjos@google.com> - Greg Kroah-Hartman <gregkh@linuxfoundation.org> - Christoph Hellwig <hch@infradead.org> - Al Viro <viro@zeniv.linux.org.uk> - Andrew Morton <akpm@linux-foundation.org> - Bruce Fields <bfields@fieldses.org> - Jeff Layton <jlayton@kernel.org> - Khalid Aziz <khalid.aziz@oracle.com> - Lei.Yang@windriver.com - linux-fsdevel@vger.kernel.org - linux-kselftest@vger.kernel.org - Linux-MM <linux-mm@kvack.org> - marcandre.lureau@redhat.com - Mike Kravetz <mike.kravetz@oracle.com> - Minchan Kim <minchan@kernel.org> - Shuah Khan <shuah@kernel.org> - " Valdis\0" "\00:1\0" "b\0" - "On Sun, Nov 11, 2018 at 07:14:33AM -0800, Andy Lutomirski wrote:\n" + "On Sun, Nov 11, 2018@07:14:33AM -0800, Andy Lutomirski wrote:\n" "[...]\n" "> >>>>>>>>>> I see two reasonable solutions:\n" "> >>>>>>>>>> \n" @@ -167,7 +144,7 @@ "From: \"Joel Fernandes\" <joel@joelfernandes.org>\n" "Subject: [PATCH] mm/memfd: implement future write seal using shmem ops\n" "\n" - "Signed-off-by: Joel Fernandes <joel@joelfernandes.org>\n" + "Signed-off-by: Joel Fernandes <joel at joelfernandes.org>\n" "---\n" " fs/hugetlbfs/inode.c | 2 +-\n" " mm/memfd.c | 19 -------------------\n" @@ -269,4 +246,4 @@ "-- \n" 2.19.1.930.g4563a0d9d0-goog -b3f09a2f634608a86befb293c1c890dc65fc6e81eefad4e4bfd0ef9c1f14807e +892b55168fcb48d5b2a6039bf96a255976c0f738f82413bfa15203cc8d4120f2
diff --git a/a/content_digest b/N3/content_digest index c58f51d..ce9bb5c 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -33,7 +33,9 @@ Mike Kravetz <mike.kravetz@oracle.com> Minchan Kim <minchan@kernel.org> Shuah Khan <shuah@kernel.org> - " Valdis\0" + Valdis Kletnieks <valdis.kletnieks@vt.edu> + Hugh Dickins <hughd@google.com> + " Linux API <linux-api@vger.kernel.org>\0" "\00:1\0" "b\0" "On Sun, Nov 11, 2018 at 07:14:33AM -0800, Andy Lutomirski wrote:\n" @@ -269,4 +271,4 @@ "-- \n" 2.19.1.930.g4563a0d9d0-goog -b3f09a2f634608a86befb293c1c890dc65fc6e81eefad4e4bfd0ef9c1f14807e +36b8d7dd2598076617ab91af064425f68085217236ff88a45f29c332454eb5d3
diff --git a/a/1.txt b/N4/1.txt index 58ab57b..b158022 100644 --- a/a/1.txt +++ b/N4/1.txt @@ -2,7 +2,7 @@ On Sun, Nov 11, 2018 at 07:14:33AM -0800, Andy Lutomirski wrote: [...] > >>>>>>>>>> I see two reasonable solutions: > >>>>>>>>>> -> >>>>>>>>>> 1. Don’t fiddle with the struct file at all. Instead make the inode flag +> >>>>>>>>>> 1. Dona??t fiddle with the struct file at all. Instead make the inode flag > >>>>>>>>>> work by itself. > >>>>>>>>> > >>>>>>>>> Currently, the various VFS paths check only the struct file's f_mode to deny @@ -57,7 +57,7 @@ On Sun, Nov 11, 2018 at 07:14:33AM -0800, Andy Lutomirski wrote: > >>>> that in all those handlers, to check for the seal (and hope we didn't miss a > >>>> file_operations handler). Is that what you are proposing? > >>> -> >>> The existing code already does this. That’s why I suggested grepping :) +> >>> The existing code already does this. Thata??s why I suggested grepping :) > >>> > >>>> > >>>> Also, it means we have to keep CONFIG_TMPFS enabled so that the @@ -70,16 +70,16 @@ On Sun, Nov 11, 2018 at 07:14:33AM -0800, Andy Lutomirski wrote: > > write(2) on tmpfs FDs shouldn't work differently. If it does, that's a > > kernel implementation detail leaking out into userspace. > > -> >>>>> - add_seals won’t need the wait_for_pins and mapping_deny_write logic. +> >>>>> - add_seals wona??t need the wait_for_pins and mapping_deny_write logic. > >>>>> -> >>>>> That really should be all that’s needed. +> >>>>> That really should be all thata??s needed. > >>>> > >>>> It seems a fair idea what you're saying. But I don't see how its less > >>>> complex.. IMO its far more simple to have VFS do the denial of the operations > >>>> based on the flags of its datastructures.. and if it works (which I will test > >>>> to be sure it will), then we should be good. > >>> -> >>> I agree it’s complicated, but the code is already written. You should just +> >>> I agree ita??s complicated, but the code is already written. You should just > >>> need to adjust some masks. > >>> > >> @@ -104,7 +104,7 @@ On Sun, Nov 11, 2018 at 07:14:33AM -0800, Andy Lutomirski wrote: > > memfd seals for ashmem, since ashmem currently allows MAP_SHARED > > mappings after changing prot_mask. > -> Hmm. I’m guessing the intent is that the mmap count should track writable +> Hmm. Ia??m guessing the intent is that the mmap count should track writable > mappings in addition to mappings that could be made writable using > mprotect. I think you could address this for SEAL_FUTURE in two ways: > @@ -115,7 +115,7 @@ On Sun, Nov 11, 2018 at 07:14:33AM -0800, Andy Lutomirski wrote: > for shmem. > > (1) probably gives the semantics you want for SEAL_FUTURE: old maps can be -> mprotected, but new maps can’t. +> mprotected, but new maps cana??t. Thanks Andy and Daniel! This occured to me too and I like the solution in (1). I tested that now PROT_READ + MAP_SHARED works and the mrprotect is not able diff --git a/a/content_digest b/N4/content_digest index c58f51d..5c5e84f 100644 --- a/a/content_digest +++ b/N4/content_digest @@ -33,14 +33,16 @@ Mike Kravetz <mike.kravetz@oracle.com> Minchan Kim <minchan@kernel.org> Shuah Khan <shuah@kernel.org> - " Valdis\0" + Valdis Kletnieks <valdis.kletnieks@vt.edu> + Hugh Dickins <hughd@google.com> + " Linux API <linux-api@vger.kernel.org>\0" "\00:1\0" "b\0" "On Sun, Nov 11, 2018 at 07:14:33AM -0800, Andy Lutomirski wrote:\n" "[...]\n" "> >>>>>>>>>> I see two reasonable solutions:\n" "> >>>>>>>>>> \n" - "> >>>>>>>>>> 1. Don\342\200\231t fiddle with the struct file at all. Instead make the inode flag\n" + "> >>>>>>>>>> 1. Dona??t fiddle with the struct file at all. Instead make the inode flag\n" "> >>>>>>>>>> work by itself.\n" "> >>>>>>>>> \n" "> >>>>>>>>> Currently, the various VFS paths check only the struct file's f_mode to deny\n" @@ -95,7 +97,7 @@ "> >>>> that in all those handlers, to check for the seal (and hope we didn't miss a\n" "> >>>> file_operations handler). Is that what you are proposing?\n" "> >>> \n" - "> >>> The existing code already does this. That\342\200\231s why I suggested grepping :)\n" + "> >>> The existing code already does this. Thata??s why I suggested grepping :)\n" "> >>> \n" "> >>>> \n" "> >>>> Also, it means we have to keep CONFIG_TMPFS enabled so that the\n" @@ -108,16 +110,16 @@ "> > write(2) on tmpfs FDs shouldn't work differently. If it does, that's a\n" "> > kernel implementation detail leaking out into userspace.\n" "> > \n" - "> >>>>> - add_seals won\342\200\231t need the wait_for_pins and mapping_deny_write logic.\n" + "> >>>>> - add_seals wona??t need the wait_for_pins and mapping_deny_write logic.\n" "> >>>>> \n" - "> >>>>> That really should be all that\342\200\231s needed.\n" + "> >>>>> That really should be all thata??s needed.\n" "> >>>> \n" "> >>>> It seems a fair idea what you're saying. But I don't see how its less\n" "> >>>> complex.. IMO its far more simple to have VFS do the denial of the operations\n" "> >>>> based on the flags of its datastructures.. and if it works (which I will test\n" "> >>>> to be sure it will), then we should be good.\n" "> >>> \n" - "> >>> I agree it\342\200\231s complicated, but the code is already written. You should just\n" + "> >>> I agree ita??s complicated, but the code is already written. You should just\n" "> >>> need to adjust some masks.\n" "> >>> \n" "> >> \n" @@ -142,7 +144,7 @@ "> > memfd seals for ashmem, since ashmem currently allows MAP_SHARED\n" "> > mappings after changing prot_mask.\n" "> \n" - "> Hmm. I\342\200\231m guessing the intent is that the mmap count should track writable\n" + "> Hmm. Ia??m guessing the intent is that the mmap count should track writable\n" "> mappings in addition to mappings that could be made writable using\n" "> mprotect. I think you could address this for SEAL_FUTURE in two ways:\n" "> \n" @@ -153,7 +155,7 @@ "> for shmem.\n" "> \n" "> (1) probably gives the semantics you want for SEAL_FUTURE: old maps can be\n" - "> mprotected, but new maps can\342\200\231t.\n" + "> mprotected, but new maps cana??t.\n" "\n" "Thanks Andy and Daniel! This occured to me too and I like the solution in (1).\n" "I tested that now PROT_READ + MAP_SHARED works and the mrprotect is not able\n" @@ -269,4 +271,4 @@ "-- \n" 2.19.1.930.g4563a0d9d0-goog -b3f09a2f634608a86befb293c1c890dc65fc6e81eefad4e4bfd0ef9c1f14807e +46d7123cf5f3635b3945c76285f3dc5a78546375616df16121d3908b9341bd0c
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.