From: Sasha Levin Date: Tue, 11 Jun 2019 21:28:58 +0000 (-0400) Subject: Drop fuse patch X-Git-Tag: v5.1.10~16^2 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=92b9533991497aa165ae88cee0ac8f684ec54d7d;p=thirdparty%2Fkernel%2Fstable-queue.git Drop fuse patch Signed-off-by: Sasha Levin --- diff --git a/queue-4.14/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch b/queue-4.14/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch deleted file mode 100644 index 8fb0ad391d3..00000000000 --- a/queue-4.14/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch +++ /dev/null @@ -1,82 +0,0 @@ -From 64815bc5ff54e339fff798c5947eeb54d509db99 Mon Sep 17 00:00:00 2001 -From: Kirill Smelkov -Date: Wed, 27 Mar 2019 10:15:15 +0000 -Subject: fuse: require /dev/fuse reads to have enough buffer capacity - -[ Upstream commit d4b13963f217dd947da5c0cabd1569e914d21699 ] - -A FUSE filesystem server queues /dev/fuse sys_read calls to get -filesystem requests to handle. It does not know in advance what would be -that request as it can be anything that client issues - LOOKUP, READ, -WRITE, ... Many requests are short and retrieve data from the -filesystem. However WRITE and NOTIFY_REPLY write data into filesystem. - -Before getting into operation phase, FUSE filesystem server and kernel -client negotiate what should be the maximum write size the client will -ever issue. After negotiation the contract in between server/client is -that the filesystem server then should queue /dev/fuse sys_read calls with -enough buffer capacity to receive any client request - WRITE in -particular, while FUSE client should not, in particular, send WRITE -requests with > negotiated max_write payload. FUSE client in kernel and -libfuse historically reserve 4K for request header. This way the -contract is that filesystem server should queue sys_reads with -4K+max_write buffer. - -If the filesystem server does not follow this contract, what can happen -is that fuse_dev_do_read will see that request size is > buffer size, -and then it will return EIO to client who issued the request but won't -indicate in any way that there is a problem to filesystem server. -This can be hard to diagnose because for some requests, e.g. for -NOTIFY_REPLY which mimics WRITE, there is no client thread that is -waiting for request completion and that EIO goes nowhere, while on -filesystem server side things look like the kernel is not replying back -after successful NOTIFY_RETRIEVE request made by the server. - -We can make the problem easy to diagnose if we indicate via error return to -filesystem server when it is violating the contract. This should not -practically cause problems because if a filesystem server is using shorter -buffer, writes to it were already very likely to cause EIO, and if the -filesystem is read-only it should be too following FUSE_MIN_READ_BUFFER -minimum buffer size. - -Please see [1] for context where the problem of stuck filesystem was hit -for real (because kernel client was incorrectly sending more than -max_write data with NOTIFY_REPLY; see also previous patch), how the -situation was traced and for more involving patch that did not make it -into the tree. - -[1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2 - -Signed-off-by: Kirill Smelkov -Cc: Han-Wen Nienhuys -Cc: Jakob Unterwurzacher -Signed-off-by: Miklos Szeredi -Signed-off-by: Sasha Levin ---- - fs/fuse/dev.c | 10 ++++++++++ - 1 file changed, 10 insertions(+) - -diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c -index c934fab44452..4c78b90bc83e 100644 ---- a/fs/fuse/dev.c -+++ b/fs/fuse/dev.c -@@ -1243,6 +1243,16 @@ static ssize_t fuse_dev_do_read(struct fuse_dev *fud, struct file *file, - struct fuse_in *in; - unsigned reqsize; - -+ /* -+ * Require sane minimum read buffer - that has capacity for fixed part -+ * of any request header + negotated max_write room for data. If the -+ * requirement is not satisfied return EINVAL to the filesystem server -+ * to indicate that it is not following FUSE server/client contract. -+ * Don't dequeue / abort any request. -+ */ -+ if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER, 4096 + fc->max_write)) -+ return -EINVAL; -+ - restart: - spin_lock(&fiq->waitq.lock); - err = -EAGAIN; --- -2.20.1 - diff --git a/queue-4.14/series b/queue-4.14/series index 2bf1b36b305..ad6f1b8bad5 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -40,7 +40,6 @@ misc-pci_endpoint_test-fix-test_reg_bar-to-be-update.patch nvme-pci-unquiesce-admin-queue-on-shutdown.patch alsa-hda-register-irq-handler-after-the-chip-initial.patch nvmem-core-fix-read-buffer-in-place.patch -fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch fuse-retrieve-cap-requested-size-to-negotiated-max_w.patch nfsd-allow-fh_want_write-to-be-called-twice.patch vfio-fix-warning-do-not-call-blocking-ops-when-task_.patch diff --git a/queue-4.19/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch b/queue-4.19/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch deleted file mode 100644 index 44bc43b2824..00000000000 --- a/queue-4.19/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch +++ /dev/null @@ -1,82 +0,0 @@ -From ff654ec868b1d1933c45ddf69a513325d6a22137 Mon Sep 17 00:00:00 2001 -From: Kirill Smelkov -Date: Wed, 27 Mar 2019 10:15:15 +0000 -Subject: fuse: require /dev/fuse reads to have enough buffer capacity - -[ Upstream commit d4b13963f217dd947da5c0cabd1569e914d21699 ] - -A FUSE filesystem server queues /dev/fuse sys_read calls to get -filesystem requests to handle. It does not know in advance what would be -that request as it can be anything that client issues - LOOKUP, READ, -WRITE, ... Many requests are short and retrieve data from the -filesystem. However WRITE and NOTIFY_REPLY write data into filesystem. - -Before getting into operation phase, FUSE filesystem server and kernel -client negotiate what should be the maximum write size the client will -ever issue. After negotiation the contract in between server/client is -that the filesystem server then should queue /dev/fuse sys_read calls with -enough buffer capacity to receive any client request - WRITE in -particular, while FUSE client should not, in particular, send WRITE -requests with > negotiated max_write payload. FUSE client in kernel and -libfuse historically reserve 4K for request header. This way the -contract is that filesystem server should queue sys_reads with -4K+max_write buffer. - -If the filesystem server does not follow this contract, what can happen -is that fuse_dev_do_read will see that request size is > buffer size, -and then it will return EIO to client who issued the request but won't -indicate in any way that there is a problem to filesystem server. -This can be hard to diagnose because for some requests, e.g. for -NOTIFY_REPLY which mimics WRITE, there is no client thread that is -waiting for request completion and that EIO goes nowhere, while on -filesystem server side things look like the kernel is not replying back -after successful NOTIFY_RETRIEVE request made by the server. - -We can make the problem easy to diagnose if we indicate via error return to -filesystem server when it is violating the contract. This should not -practically cause problems because if a filesystem server is using shorter -buffer, writes to it were already very likely to cause EIO, and if the -filesystem is read-only it should be too following FUSE_MIN_READ_BUFFER -minimum buffer size. - -Please see [1] for context where the problem of stuck filesystem was hit -for real (because kernel client was incorrectly sending more than -max_write data with NOTIFY_REPLY; see also previous patch), how the -situation was traced and for more involving patch that did not make it -into the tree. - -[1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2 - -Signed-off-by: Kirill Smelkov -Cc: Han-Wen Nienhuys -Cc: Jakob Unterwurzacher -Signed-off-by: Miklos Szeredi -Signed-off-by: Sasha Levin ---- - fs/fuse/dev.c | 10 ++++++++++ - 1 file changed, 10 insertions(+) - -diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c -index 249de20f752a..0ee64efc1980 100644 ---- a/fs/fuse/dev.c -+++ b/fs/fuse/dev.c -@@ -1250,6 +1250,16 @@ static ssize_t fuse_dev_do_read(struct fuse_dev *fud, struct file *file, - struct fuse_in *in; - unsigned reqsize; - -+ /* -+ * Require sane minimum read buffer - that has capacity for fixed part -+ * of any request header + negotated max_write room for data. If the -+ * requirement is not satisfied return EINVAL to the filesystem server -+ * to indicate that it is not following FUSE server/client contract. -+ * Don't dequeue / abort any request. -+ */ -+ if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER, 4096 + fc->max_write)) -+ return -EINVAL; -+ - restart: - spin_lock(&fiq->waitq.lock); - err = -EAGAIN; --- -2.20.1 - diff --git a/queue-4.19/series b/queue-4.19/series index e66b824e02f..29ec850c253 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -63,7 +63,6 @@ netfilter-nf_flow_table-fix-netdev-refcnt-leak.patch alsa-hda-register-irq-handler-after-the-chip-initial.patch nvmem-core-fix-read-buffer-in-place.patch nvmem-sunxi_sid-support-sid-on-a83t-and-h5.patch -fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch fuse-retrieve-cap-requested-size-to-negotiated-max_w.patch nfsd-allow-fh_want_write-to-be-called-twice.patch nfsd-avoid-uninitialized-variable-warning.patch diff --git a/queue-4.4/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch b/queue-4.4/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch deleted file mode 100644 index b3439702eba..00000000000 --- a/queue-4.4/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch +++ /dev/null @@ -1,82 +0,0 @@ -From cab2e5096300bcb12ce3b04f8e5e7c0538fde023 Mon Sep 17 00:00:00 2001 -From: Kirill Smelkov -Date: Wed, 27 Mar 2019 10:15:15 +0000 -Subject: fuse: require /dev/fuse reads to have enough buffer capacity - -[ Upstream commit d4b13963f217dd947da5c0cabd1569e914d21699 ] - -A FUSE filesystem server queues /dev/fuse sys_read calls to get -filesystem requests to handle. It does not know in advance what would be -that request as it can be anything that client issues - LOOKUP, READ, -WRITE, ... Many requests are short and retrieve data from the -filesystem. However WRITE and NOTIFY_REPLY write data into filesystem. - -Before getting into operation phase, FUSE filesystem server and kernel -client negotiate what should be the maximum write size the client will -ever issue. After negotiation the contract in between server/client is -that the filesystem server then should queue /dev/fuse sys_read calls with -enough buffer capacity to receive any client request - WRITE in -particular, while FUSE client should not, in particular, send WRITE -requests with > negotiated max_write payload. FUSE client in kernel and -libfuse historically reserve 4K for request header. This way the -contract is that filesystem server should queue sys_reads with -4K+max_write buffer. - -If the filesystem server does not follow this contract, what can happen -is that fuse_dev_do_read will see that request size is > buffer size, -and then it will return EIO to client who issued the request but won't -indicate in any way that there is a problem to filesystem server. -This can be hard to diagnose because for some requests, e.g. for -NOTIFY_REPLY which mimics WRITE, there is no client thread that is -waiting for request completion and that EIO goes nowhere, while on -filesystem server side things look like the kernel is not replying back -after successful NOTIFY_RETRIEVE request made by the server. - -We can make the problem easy to diagnose if we indicate via error return to -filesystem server when it is violating the contract. This should not -practically cause problems because if a filesystem server is using shorter -buffer, writes to it were already very likely to cause EIO, and if the -filesystem is read-only it should be too following FUSE_MIN_READ_BUFFER -minimum buffer size. - -Please see [1] for context where the problem of stuck filesystem was hit -for real (because kernel client was incorrectly sending more than -max_write data with NOTIFY_REPLY; see also previous patch), how the -situation was traced and for more involving patch that did not make it -into the tree. - -[1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2 - -Signed-off-by: Kirill Smelkov -Cc: Han-Wen Nienhuys -Cc: Jakob Unterwurzacher -Signed-off-by: Miklos Szeredi -Signed-off-by: Sasha Levin ---- - fs/fuse/dev.c | 10 ++++++++++ - 1 file changed, 10 insertions(+) - -diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c -index 341196338e48..fbb978e75c6b 100644 ---- a/fs/fuse/dev.c -+++ b/fs/fuse/dev.c -@@ -1265,6 +1265,16 @@ static ssize_t fuse_dev_do_read(struct fuse_dev *fud, struct file *file, - struct fuse_in *in; - unsigned reqsize; - -+ /* -+ * Require sane minimum read buffer - that has capacity for fixed part -+ * of any request header + negotated max_write room for data. If the -+ * requirement is not satisfied return EINVAL to the filesystem server -+ * to indicate that it is not following FUSE server/client contract. -+ * Don't dequeue / abort any request. -+ */ -+ if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER, 4096 + fc->max_write)) -+ return -EINVAL; -+ - restart: - spin_lock(&fiq->waitq.lock); - err = -EAGAIN; --- -2.20.1 - diff --git a/queue-4.4/series b/queue-4.4/series index 5ba3dd8d01a..1048b2c0b8e 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -17,7 +17,6 @@ mips-make-sure-dt-memory-regions-are-valid.patch iommu-vt-d-set-intel_iommu_gfx_mapped-correctly.patch alsa-hda-register-irq-handler-after-the-chip-initial.patch nvmem-core-fix-read-buffer-in-place.patch -fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch fuse-retrieve-cap-requested-size-to-negotiated-max_w.patch nfsd-allow-fh_want_write-to-be-called-twice.patch x86-pci-fix-pci-irq-routing-table-memory-leak.patch diff --git a/queue-4.9/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch b/queue-4.9/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch deleted file mode 100644 index f6c4add7e59..00000000000 --- a/queue-4.9/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch +++ /dev/null @@ -1,82 +0,0 @@ -From a021f455ad30040d0a816711b3586b51bdaae988 Mon Sep 17 00:00:00 2001 -From: Kirill Smelkov -Date: Wed, 27 Mar 2019 10:15:15 +0000 -Subject: fuse: require /dev/fuse reads to have enough buffer capacity - -[ Upstream commit d4b13963f217dd947da5c0cabd1569e914d21699 ] - -A FUSE filesystem server queues /dev/fuse sys_read calls to get -filesystem requests to handle. It does not know in advance what would be -that request as it can be anything that client issues - LOOKUP, READ, -WRITE, ... Many requests are short and retrieve data from the -filesystem. However WRITE and NOTIFY_REPLY write data into filesystem. - -Before getting into operation phase, FUSE filesystem server and kernel -client negotiate what should be the maximum write size the client will -ever issue. After negotiation the contract in between server/client is -that the filesystem server then should queue /dev/fuse sys_read calls with -enough buffer capacity to receive any client request - WRITE in -particular, while FUSE client should not, in particular, send WRITE -requests with > negotiated max_write payload. FUSE client in kernel and -libfuse historically reserve 4K for request header. This way the -contract is that filesystem server should queue sys_reads with -4K+max_write buffer. - -If the filesystem server does not follow this contract, what can happen -is that fuse_dev_do_read will see that request size is > buffer size, -and then it will return EIO to client who issued the request but won't -indicate in any way that there is a problem to filesystem server. -This can be hard to diagnose because for some requests, e.g. for -NOTIFY_REPLY which mimics WRITE, there is no client thread that is -waiting for request completion and that EIO goes nowhere, while on -filesystem server side things look like the kernel is not replying back -after successful NOTIFY_RETRIEVE request made by the server. - -We can make the problem easy to diagnose if we indicate via error return to -filesystem server when it is violating the contract. This should not -practically cause problems because if a filesystem server is using shorter -buffer, writes to it were already very likely to cause EIO, and if the -filesystem is read-only it should be too following FUSE_MIN_READ_BUFFER -minimum buffer size. - -Please see [1] for context where the problem of stuck filesystem was hit -for real (because kernel client was incorrectly sending more than -max_write data with NOTIFY_REPLY; see also previous patch), how the -situation was traced and for more involving patch that did not make it -into the tree. - -[1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2 - -Signed-off-by: Kirill Smelkov -Cc: Han-Wen Nienhuys -Cc: Jakob Unterwurzacher -Signed-off-by: Miklos Szeredi -Signed-off-by: Sasha Levin ---- - fs/fuse/dev.c | 10 ++++++++++ - 1 file changed, 10 insertions(+) - -diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c -index eaedbc1a3e95..bc2d4832f02b 100644 ---- a/fs/fuse/dev.c -+++ b/fs/fuse/dev.c -@@ -1240,6 +1240,16 @@ static ssize_t fuse_dev_do_read(struct fuse_dev *fud, struct file *file, - struct fuse_in *in; - unsigned reqsize; - -+ /* -+ * Require sane minimum read buffer - that has capacity for fixed part -+ * of any request header + negotated max_write room for data. If the -+ * requirement is not satisfied return EINVAL to the filesystem server -+ * to indicate that it is not following FUSE server/client contract. -+ * Don't dequeue / abort any request. -+ */ -+ if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER, 4096 + fc->max_write)) -+ return -EINVAL; -+ - restart: - spin_lock(&fiq->waitq.lock); - err = -EAGAIN; --- -2.20.1 - diff --git a/queue-4.9/series b/queue-4.9/series index 181f1a8d2c3..d3b8ff75ec3 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -29,7 +29,6 @@ watchdog-fix-compile-time-error-of-pretimeout-govern.patch iommu-vt-d-set-intel_iommu_gfx_mapped-correctly.patch alsa-hda-register-irq-handler-after-the-chip-initial.patch nvmem-core-fix-read-buffer-in-place.patch -fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch fuse-retrieve-cap-requested-size-to-negotiated-max_w.patch nfsd-allow-fh_want_write-to-be-called-twice.patch x86-pci-fix-pci-irq-routing-table-memory-leak.patch diff --git a/queue-5.1/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch b/queue-5.1/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch deleted file mode 100644 index 8208079df08..00000000000 --- a/queue-5.1/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch +++ /dev/null @@ -1,82 +0,0 @@ -From 7200a9baac58f2c13f744454b211c206bba108a7 Mon Sep 17 00:00:00 2001 -From: Kirill Smelkov -Date: Wed, 27 Mar 2019 10:15:15 +0000 -Subject: fuse: require /dev/fuse reads to have enough buffer capacity - -[ Upstream commit d4b13963f217dd947da5c0cabd1569e914d21699 ] - -A FUSE filesystem server queues /dev/fuse sys_read calls to get -filesystem requests to handle. It does not know in advance what would be -that request as it can be anything that client issues - LOOKUP, READ, -WRITE, ... Many requests are short and retrieve data from the -filesystem. However WRITE and NOTIFY_REPLY write data into filesystem. - -Before getting into operation phase, FUSE filesystem server and kernel -client negotiate what should be the maximum write size the client will -ever issue. After negotiation the contract in between server/client is -that the filesystem server then should queue /dev/fuse sys_read calls with -enough buffer capacity to receive any client request - WRITE in -particular, while FUSE client should not, in particular, send WRITE -requests with > negotiated max_write payload. FUSE client in kernel and -libfuse historically reserve 4K for request header. This way the -contract is that filesystem server should queue sys_reads with -4K+max_write buffer. - -If the filesystem server does not follow this contract, what can happen -is that fuse_dev_do_read will see that request size is > buffer size, -and then it will return EIO to client who issued the request but won't -indicate in any way that there is a problem to filesystem server. -This can be hard to diagnose because for some requests, e.g. for -NOTIFY_REPLY which mimics WRITE, there is no client thread that is -waiting for request completion and that EIO goes nowhere, while on -filesystem server side things look like the kernel is not replying back -after successful NOTIFY_RETRIEVE request made by the server. - -We can make the problem easy to diagnose if we indicate via error return to -filesystem server when it is violating the contract. This should not -practically cause problems because if a filesystem server is using shorter -buffer, writes to it were already very likely to cause EIO, and if the -filesystem is read-only it should be too following FUSE_MIN_READ_BUFFER -minimum buffer size. - -Please see [1] for context where the problem of stuck filesystem was hit -for real (because kernel client was incorrectly sending more than -max_write data with NOTIFY_REPLY; see also previous patch), how the -situation was traced and for more involving patch that did not make it -into the tree. - -[1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2 - -Signed-off-by: Kirill Smelkov -Cc: Han-Wen Nienhuys -Cc: Jakob Unterwurzacher -Signed-off-by: Miklos Szeredi -Signed-off-by: Sasha Levin ---- - fs/fuse/dev.c | 10 ++++++++++ - 1 file changed, 10 insertions(+) - -diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c -index 9971a35cf1ef..7d86629b803d 100644 ---- a/fs/fuse/dev.c -+++ b/fs/fuse/dev.c -@@ -1317,6 +1317,16 @@ static ssize_t fuse_dev_do_read(struct fuse_dev *fud, struct file *file, - unsigned reqsize; - unsigned int hash; - -+ /* -+ * Require sane minimum read buffer - that has capacity for fixed part -+ * of any request header + negotated max_write room for data. If the -+ * requirement is not satisfied return EINVAL to the filesystem server -+ * to indicate that it is not following FUSE server/client contract. -+ * Don't dequeue / abort any request. -+ */ -+ if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER, 4096 + fc->max_write)) -+ return -EINVAL; -+ - restart: - spin_lock(&fiq->waitq.lock); - err = -EAGAIN; --- -2.20.1 - diff --git a/queue-5.1/series b/queue-5.1/series index afc129a4102..cc45b89f461 100644 --- a/queue-5.1/series +++ b/queue-5.1/series @@ -82,7 +82,6 @@ arm64-defconfig-update-ufshcd-for-hi3660-soc.patch iommu-vt-d-don-t-request-page-request-irq-under-dmar.patch nvmem-core-fix-read-buffer-in-place.patch nvmem-sunxi_sid-support-sid-on-a83t-and-h5.patch -fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch fuse-retrieve-cap-requested-size-to-negotiated-max_w.patch nfsd-allow-fh_want_write-to-be-called-twice.patch nfsd-avoid-uninitialized-variable-warning.patch