+++ /dev/null
-From 64815bc5ff54e339fff798c5947eeb54d509db99 Mon Sep 17 00:00:00 2001
-From: Kirill Smelkov <kirr@nexedi.com>
-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 <kirr@nexedi.com>
-Cc: Han-Wen Nienhuys <hanwen@google.com>
-Cc: Jakob Unterwurzacher <jakobunt@gmail.com>
-Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- 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
-
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
+++ /dev/null
-From ff654ec868b1d1933c45ddf69a513325d6a22137 Mon Sep 17 00:00:00 2001
-From: Kirill Smelkov <kirr@nexedi.com>
-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 <kirr@nexedi.com>
-Cc: Han-Wen Nienhuys <hanwen@google.com>
-Cc: Jakob Unterwurzacher <jakobunt@gmail.com>
-Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- 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
-
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
+++ /dev/null
-From cab2e5096300bcb12ce3b04f8e5e7c0538fde023 Mon Sep 17 00:00:00 2001
-From: Kirill Smelkov <kirr@nexedi.com>
-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 <kirr@nexedi.com>
-Cc: Han-Wen Nienhuys <hanwen@google.com>
-Cc: Jakob Unterwurzacher <jakobunt@gmail.com>
-Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- 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
-
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
+++ /dev/null
-From a021f455ad30040d0a816711b3586b51bdaae988 Mon Sep 17 00:00:00 2001
-From: Kirill Smelkov <kirr@nexedi.com>
-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 <kirr@nexedi.com>
-Cc: Han-Wen Nienhuys <hanwen@google.com>
-Cc: Jakob Unterwurzacher <jakobunt@gmail.com>
-Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- 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
-
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
+++ /dev/null
-From 7200a9baac58f2c13f744454b211c206bba108a7 Mon Sep 17 00:00:00 2001
-From: Kirill Smelkov <kirr@nexedi.com>
-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 <kirr@nexedi.com>
-Cc: Han-Wen Nienhuys <hanwen@google.com>
-Cc: Jakob Unterwurzacher <jakobunt@gmail.com>
-Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- 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
-
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
