fix up binfmt patch

diff --git a/queue-4.19/binfmt_misc-cleanup-on-filesystem-umount.patch b/queue-4.19/binfmt_misc-cleanup-on-filesystem-umount.patch
index 4efb838ad052da9a5d8c144354bbbee942946ca5..c249b6ecb86bf899259006d64ca72fd1c06ee45f 100644 (file)
--- a/queue-4.19/binfmt_misc-cleanup-on-filesystem-umount.patch
+++ b/queue-4.19/binfmt_misc-cleanup-on-filesystem-umount.patch
@@ -85,27 +85,6 @@ Acked-by: Serge Hallyn <serge@hallyn.com>
 Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
 Signed-off-by: Christian Brauner <brauner@kernel.org>
 Signed-off-by: Kees Cook <keescook@chromium.org>
----
-/* v2 */
-- Christian Brauner <christian.brauner@ubuntu.com>:
-  - Add more comments that explain what's going on.
-  - Rename functions while changing them to better reflect what they are
-    doing to make the code easier to understand.
-  - In the first version when a specific binary type handler was removed
-    either through a write to the entry's file or all binary type
-    handlers were removed by a write to the binfmt_misc mount's status
-    file all cleanup work happened during inode eviction.
-    That includes removal of the relevant entries from entry list. While
-    that works fine I disliked that model after thinking about it for a
-    bit. Because it means that there was a window were someone has
-    already removed a or all binary handlers but they could still be
-    safely reached from load_misc_binary() when it has managed to take
-    the read_lock() on the entries list while inode eviction was already
-    happening. Again, that perfectly benign but it's cleaner to remove
-    the binary handler from the list immediately meaning that ones the
-    write to then entry's file or the binfmt_misc status file returns
-    the binary type cannot be executed anymore. That gives stronger
-    guarantees to the user.
 Signed-off-by: Sasha Levin <sashal@kernel.org>
 ---
  fs/binfmt_misc.c | 216 ++++++++++++++++++++++++++++++++++++-----------

diff --git a/queue-5.10/binfmt_misc-cleanup-on-filesystem-umount.patch b/queue-5.10/binfmt_misc-cleanup-on-filesystem-umount.patch
index 57e21ce10a39d389775470b6219a65c47e47ed9b..1858e7270c80ad12d09acadcee6b6ef3e55b58c6 100644 (file)
--- a/queue-5.10/binfmt_misc-cleanup-on-filesystem-umount.patch
+++ b/queue-5.10/binfmt_misc-cleanup-on-filesystem-umount.patch
@@ -85,27 +85,6 @@ Acked-by: Serge Hallyn <serge@hallyn.com>
 Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
 Signed-off-by: Christian Brauner <brauner@kernel.org>
 Signed-off-by: Kees Cook <keescook@chromium.org>
----
-/* v2 */
-- Christian Brauner <christian.brauner@ubuntu.com>:
-  - Add more comments that explain what's going on.
-  - Rename functions while changing them to better reflect what they are
-    doing to make the code easier to understand.
-  - In the first version when a specific binary type handler was removed
-    either through a write to the entry's file or all binary type
-    handlers were removed by a write to the binfmt_misc mount's status
-    file all cleanup work happened during inode eviction.
-    That includes removal of the relevant entries from entry list. While
-    that works fine I disliked that model after thinking about it for a
-    bit. Because it means that there was a window were someone has
-    already removed a or all binary handlers but they could still be
-    safely reached from load_misc_binary() when it has managed to take
-    the read_lock() on the entries list while inode eviction was already
-    happening. Again, that perfectly benign but it's cleaner to remove
-    the binary handler from the list immediately meaning that ones the
-    write to then entry's file or the binfmt_misc status file returns
-    the binary type cannot be executed anymore. That gives stronger
-    guarantees to the user.
 Signed-off-by: Sasha Levin <sashal@kernel.org>
 ---
  fs/binfmt_misc.c | 216 ++++++++++++++++++++++++++++++++++++-----------

diff --git a/queue-5.15/binfmt_misc-cleanup-on-filesystem-umount.patch b/queue-5.15/binfmt_misc-cleanup-on-filesystem-umount.patch
index e78f3687e5b0786af015de68d031191e9385eddf..65f5ae46a1edfbe32a545d781df3585941919593 100644 (file)
--- a/queue-5.15/binfmt_misc-cleanup-on-filesystem-umount.patch
+++ b/queue-5.15/binfmt_misc-cleanup-on-filesystem-umount.patch
@@ -85,27 +85,6 @@ Acked-by: Serge Hallyn <serge@hallyn.com>
 Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
 Signed-off-by: Christian Brauner <brauner@kernel.org>
 Signed-off-by: Kees Cook <keescook@chromium.org>
----
-/* v2 */
-- Christian Brauner <christian.brauner@ubuntu.com>:
-  - Add more comments that explain what's going on.
-  - Rename functions while changing them to better reflect what they are
-    doing to make the code easier to understand.
-  - In the first version when a specific binary type handler was removed
-    either through a write to the entry's file or all binary type
-    handlers were removed by a write to the binfmt_misc mount's status
-    file all cleanup work happened during inode eviction.
-    That includes removal of the relevant entries from entry list. While
-    that works fine I disliked that model after thinking about it for a
-    bit. Because it means that there was a window were someone has
-    already removed a or all binary handlers but they could still be
-    safely reached from load_misc_binary() when it has managed to take
-    the read_lock() on the entries list while inode eviction was already
-    happening. Again, that perfectly benign but it's cleaner to remove
-    the binary handler from the list immediately meaning that ones the
-    write to then entry's file or the binfmt_misc status file returns
-    the binary type cannot be executed anymore. That gives stronger
-    guarantees to the user.
 Signed-off-by: Sasha Levin <sashal@kernel.org>
 ---
  fs/binfmt_misc.c | 216 ++++++++++++++++++++++++++++++++++++-----------

diff --git a/queue-5.4/binfmt_misc-cleanup-on-filesystem-umount.patch b/queue-5.4/binfmt_misc-cleanup-on-filesystem-umount.patch
index 26e1a410c86be40419a44a388f3064812a35d080..4c5e2c1dd03d210a4dc0165d83481158ea8dba13 100644 (file)
--- a/queue-5.4/binfmt_misc-cleanup-on-filesystem-umount.patch
+++ b/queue-5.4/binfmt_misc-cleanup-on-filesystem-umount.patch
@@ -85,27 +85,6 @@ Acked-by: Serge Hallyn <serge@hallyn.com>
 Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
 Signed-off-by: Christian Brauner <brauner@kernel.org>
 Signed-off-by: Kees Cook <keescook@chromium.org>
----
-/* v2 */
-- Christian Brauner <christian.brauner@ubuntu.com>:
-  - Add more comments that explain what's going on.
-  - Rename functions while changing them to better reflect what they are
-    doing to make the code easier to understand.
-  - In the first version when a specific binary type handler was removed
-    either through a write to the entry's file or all binary type
-    handlers were removed by a write to the binfmt_misc mount's status
-    file all cleanup work happened during inode eviction.
-    That includes removal of the relevant entries from entry list. While
-    that works fine I disliked that model after thinking about it for a
-    bit. Because it means that there was a window were someone has
-    already removed a or all binary handlers but they could still be
-    safely reached from load_misc_binary() when it has managed to take
-    the read_lock() on the entries list while inode eviction was already
-    happening. Again, that perfectly benign but it's cleaner to remove
-    the binary handler from the list immediately meaning that ones the
-    write to then entry's file or the binfmt_misc status file returns
-    the binary type cannot be executed anymore. That gives stronger
-    guarantees to the user.
 Signed-off-by: Sasha Levin <sashal@kernel.org>
 ---
  fs/binfmt_misc.c | 216 ++++++++++++++++++++++++++++++++++++-----------

diff --git a/queue-6.1/binfmt_misc-cleanup-on-filesystem-umount.patch b/queue-6.1/binfmt_misc-cleanup-on-filesystem-umount.patch
index ad75623b54b9a1c2f45c5a9a3b45d6eedf15a689..35c0625b9d8d359d0c0b9e7ef12b85d9eb89f4f9 100644 (file)
--- a/queue-6.1/binfmt_misc-cleanup-on-filesystem-umount.patch
+++ b/queue-6.1/binfmt_misc-cleanup-on-filesystem-umount.patch
@@ -85,27 +85,6 @@ Acked-by: Serge Hallyn <serge@hallyn.com>
 Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
 Signed-off-by: Christian Brauner <brauner@kernel.org>
 Signed-off-by: Kees Cook <keescook@chromium.org>
----
-/* v2 */
-- Christian Brauner <christian.brauner@ubuntu.com>:
-  - Add more comments that explain what's going on.
-  - Rename functions while changing them to better reflect what they are
-    doing to make the code easier to understand.
-  - In the first version when a specific binary type handler was removed
-    either through a write to the entry's file or all binary type
-    handlers were removed by a write to the binfmt_misc mount's status
-    file all cleanup work happened during inode eviction.
-    That includes removal of the relevant entries from entry list. While
-    that works fine I disliked that model after thinking about it for a
-    bit. Because it means that there was a window were someone has
-    already removed a or all binary handlers but they could still be
-    safely reached from load_misc_binary() when it has managed to take
-    the read_lock() on the entries list while inode eviction was already
-    happening. Again, that perfectly benign but it's cleaner to remove
-    the binary handler from the list immediately meaning that ones the
-    write to then entry's file or the binfmt_misc status file returns
-    the binary type cannot be executed anymore. That gives stronger
-    guarantees to the user.
 Signed-off-by: Sasha Levin <sashal@kernel.org>
 ---
  fs/binfmt_misc.c | 216 ++++++++++++++++++++++++++++++++++++-----------

diff --git a/queue-6.6/binfmt_misc-cleanup-on-filesystem-umount.patch b/queue-6.6/binfmt_misc-cleanup-on-filesystem-umount.patch
index d455f98d47dd82d79e531e5e94e1c55a6f737019..a89f85bfa0cbb46aad300c593e386658d53fbdb0 100644 (file)
--- a/queue-6.6/binfmt_misc-cleanup-on-filesystem-umount.patch
+++ b/queue-6.6/binfmt_misc-cleanup-on-filesystem-umount.patch
@@ -85,27 +85,6 @@ Acked-by: Serge Hallyn <serge@hallyn.com>
 Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
 Signed-off-by: Christian Brauner <brauner@kernel.org>
 Signed-off-by: Kees Cook <keescook@chromium.org>
----
-/* v2 */
-- Christian Brauner <christian.brauner@ubuntu.com>:
-  - Add more comments that explain what's going on.
-  - Rename functions while changing them to better reflect what they are
-    doing to make the code easier to understand.
-  - In the first version when a specific binary type handler was removed
-    either through a write to the entry's file or all binary type
-    handlers were removed by a write to the binfmt_misc mount's status
-    file all cleanup work happened during inode eviction.
-    That includes removal of the relevant entries from entry list. While
-    that works fine I disliked that model after thinking about it for a
-    bit. Because it means that there was a window were someone has
-    already removed a or all binary handlers but they could still be
-    safely reached from load_misc_binary() when it has managed to take
-    the read_lock() on the entries list while inode eviction was already
-    happening. Again, that perfectly benign but it's cleaner to remove
-    the binary handler from the list immediately meaning that ones the
-    write to then entry's file or the binfmt_misc status file returns
-    the binary type cannot be executed anymore. That gives stronger
-    guarantees to the user.
 Signed-off-by: Sasha Levin <sashal@kernel.org>
 ---
  fs/binfmt_misc.c | 216 ++++++++++++++++++++++++++++++++++++-----------