diff for duplicates of <20181111080945.GA78191@google.com> diff --git a/a/1.txt b/N1/1.txt index 8eaf198..34126f1 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -96,10 +96,10 @@ expected to fail. This is also evident from this code in mmap_region: ---8<----------------------- -From: "Joel Fernandes (Google)" <joel@joelfernandes.org> +From: "Joel Fernandes (Google)" <joel at joelfernandes.org> Subject: [PATCH] mm/memfd: implement future write seal using shmem ops -Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> +Signed-off-by: Joel Fernandes (Google) <joel at joelfernandes.org> --- fs/hugetlbfs/inode.c | 2 +- mm/memfd.c | 19 ------------------- diff --git a/a/content_digest b/N1/content_digest index 0c76c61..cf21367 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -8,32 +8,9 @@ "ref\0907D942E-E321-4BD7-BED7-ACD1D96A3643@amacapital.net\0" "ref\020181111023808.GA174670@google.com\0" "ref\0543A5181-3A16-438E-B372-97BEC48A74F8@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 00:09:45 -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 Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote:\n" @@ -134,10 +111,10 @@ "\n" "---8<-----------------------\n" "\n" - "From: \"Joel Fernandes (Google)\" <joel@joelfernandes.org>\n" + "From: \"Joel Fernandes (Google)\" <joel at joelfernandes.org>\n" "Subject: [PATCH] mm/memfd: implement future write seal using shmem ops\n" "\n" - "Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>\n" + "Signed-off-by: Joel Fernandes (Google) <joel at joelfernandes.org>\n" "---\n" " fs/hugetlbfs/inode.c | 2 +-\n" " mm/memfd.c | 19 -------------------\n" @@ -228,4 +205,4 @@ "-- \n" 2.19.1.930.g4563a0d9d0-goog -a3227b48d79ba0fd8d423faa8f2bf2275787c4fdc4c1392c712c09234dee5359 +db3f3f3218bb8614667f8afa7c24d5bd2f1fe93adbb4c2340b336d29d1aaf547
diff --git a/a/1.txt b/N2/1.txt index 8eaf198..3bb39a1 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,4 +1,4 @@ -On Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote: +On Sat, Nov 10, 2018@07:40:10PM -0800, Andy Lutomirski wrote: [...] > >>>>>>> I see two reasonable solutions: > >>>>>>> @@ -99,7 +99,7 @@ expected to fail. This is also evident from this code in mmap_region: From: "Joel Fernandes (Google)" <joel@joelfernandes.org> Subject: [PATCH] mm/memfd: implement future write seal using shmem ops -Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> +Signed-off-by: Joel Fernandes (Google) <joel at joelfernandes.org> --- fs/hugetlbfs/inode.c | 2 +- mm/memfd.c | 19 ------------------- diff --git a/a/content_digest b/N2/content_digest index 0c76c61..585b4aa 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -8,35 +8,12 @@ "ref\0907D942E-E321-4BD7-BED7-ACD1D96A3643@amacapital.net\0" "ref\020181111023808.GA174670@google.com\0" "ref\0543A5181-3A16-438E-B372-97BEC48A74F8@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 00:09:45 -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 Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote:\n" + "On Sat, Nov 10, 2018@07:40:10PM -0800, Andy Lutomirski wrote:\n" "[...]\n" "> >>>>>>> I see two reasonable solutions:\n" "> >>>>>>> \n" @@ -137,7 +114,7 @@ "From: \"Joel Fernandes (Google)\" <joel@joelfernandes.org>\n" "Subject: [PATCH] mm/memfd: implement future write seal using shmem ops\n" "\n" - "Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>\n" + "Signed-off-by: Joel Fernandes (Google) <joel at joelfernandes.org>\n" "---\n" " fs/hugetlbfs/inode.c | 2 +-\n" " mm/memfd.c | 19 -------------------\n" @@ -228,4 +205,4 @@ "-- \n" 2.19.1.930.g4563a0d9d0-goog -a3227b48d79ba0fd8d423faa8f2bf2275787c4fdc4c1392c712c09234dee5359 +03ce8a9e141654e6e7adee0ab2736715d02598866979ed0e89ac4d1debc7a9da
diff --git a/a/content_digest b/N3/content_digest index 0c76c61..6d960f0 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 Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote:\n" @@ -228,4 +230,4 @@ "-- \n" 2.19.1.930.g4563a0d9d0-goog -a3227b48d79ba0fd8d423faa8f2bf2275787c4fdc4c1392c712c09234dee5359 +55a82dbc28f3abaf0c5b7c4ef3f6b5ef631acbabd1a200f2f3ff9e4503f2e269
diff --git a/a/1.txt b/N4/1.txt index 8eaf198..ec3e081 100644 --- a/a/1.txt +++ b/N4/1.txt @@ -2,7 +2,7 @@ On Sat, Nov 10, 2018 at 07:40:10PM -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 Sat, Nov 10, 2018 at 07:40:10PM -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 @@ -67,16 +67,16 @@ On Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote: > If so, that sounds like it may already be a bug. > > > -> >> - 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. > diff --git a/a/content_digest b/N4/content_digest index 0c76c61..1aebd09 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 Sat, Nov 10, 2018 at 07:40:10PM -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" @@ -105,16 +107,16 @@ "> If so, that sounds like it may already be a bug.\n" "> \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" @@ -228,4 +230,4 @@ "-- \n" 2.19.1.930.g4563a0d9d0-goog -a3227b48d79ba0fd8d423faa8f2bf2275787c4fdc4c1392c712c09234dee5359 +4eb4a50606abed5d93a34f6733acdf42faf8ebf297c2db9430b75f09d62b26ea
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.