From: Greg Kroah-Hartman Date: Mon, 15 Apr 2019 12:14:05 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v4.9.169~19 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=da425238e5f9c7435a6fde784ee099a0fe71f9c8;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: block-do-not-leak-memory-in-bio_copy_user_iov.patch btrfs-do-not-allow-trimming-when-a-fs-is-mounted-with-the-nologreplay-option.patch genirq-respect-irqchip_skip_set_wake-in-irq_chip_set_wake_parent.patch virtio-honour-may_reduce_num-in-vring_create_virtqueue.patch --- diff --git a/queue-4.9/block-do-not-leak-memory-in-bio_copy_user_iov.patch b/queue-4.9/block-do-not-leak-memory-in-bio_copy_user_iov.patch new file mode 100644 index 00000000000..ba6fb04026f --- /dev/null +++ b/queue-4.9/block-do-not-leak-memory-in-bio_copy_user_iov.patch @@ -0,0 +1,42 @@ +From a3761c3c91209b58b6f33bf69dd8bb8ec0c9d925 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= +Date: Wed, 10 Apr 2019 16:27:51 -0400 +Subject: block: do not leak memory in bio_copy_user_iov() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jérôme Glisse + +commit a3761c3c91209b58b6f33bf69dd8bb8ec0c9d925 upstream. + +When bio_add_pc_page() fails in bio_copy_user_iov() we should free +the page we just allocated otherwise we are leaking it. + +Cc: linux-block@vger.kernel.org +Cc: Linus Torvalds +Cc: stable@vger.kernel.org +Reviewed-by: Chaitanya Kulkarni +Signed-off-by: Jérôme Glisse +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + block/bio.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/block/bio.c ++++ b/block/bio.c +@@ -1214,8 +1214,11 @@ struct bio *bio_copy_user_iov(struct req + } + } + +- if (bio_add_pc_page(q, bio, page, bytes, offset) < bytes) ++ if (bio_add_pc_page(q, bio, page, bytes, offset) < bytes) { ++ if (!map_data) ++ __free_page(page); + break; ++ } + + len -= bytes; + offset = 0; diff --git a/queue-4.9/btrfs-do-not-allow-trimming-when-a-fs-is-mounted-with-the-nologreplay-option.patch b/queue-4.9/btrfs-do-not-allow-trimming-when-a-fs-is-mounted-with-the-nologreplay-option.patch new file mode 100644 index 00000000000..e0f9588e864 --- /dev/null +++ b/queue-4.9/btrfs-do-not-allow-trimming-when-a-fs-is-mounted-with-the-nologreplay-option.patch @@ -0,0 +1,53 @@ +From f35f06c35560a86e841631f0243b83a984dc11a9 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Tue, 26 Mar 2019 10:49:56 +0000 +Subject: Btrfs: do not allow trimming when a fs is mounted with the nologreplay option + +From: Filipe Manana + +commit f35f06c35560a86e841631f0243b83a984dc11a9 upstream. + +Whan a filesystem is mounted with the nologreplay mount option, which +requires it to be mounted in RO mode as well, we can not allow discard on +free space inside block groups, because log trees refer to extents that +are not pinned in a block group's free space cache (pinning the extents is +precisely the first phase of replaying a log tree). + +So do not allow the fitrim ioctl to do anything when the filesystem is +mounted with the nologreplay option, because later it can be mounted RW +without that option, which causes log replay to happen and result in +either a failure to replay the log trees (leading to a mount failure), a +crash or some silent corruption. + +Reported-by: Darrick J. Wong +Fixes: 96da09192cda ("btrfs: Introduce new mount option to disable tree log replay") +CC: stable@vger.kernel.org # 4.9+ +Reviewed-by: Nikolay Borisov +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/ioctl.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/fs/btrfs/ioctl.c ++++ b/fs/btrfs/ioctl.c +@@ -385,6 +385,16 @@ static noinline int btrfs_ioctl_fitrim(s + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + ++ /* ++ * If the fs is mounted with nologreplay, which requires it to be ++ * mounted in RO mode as well, we can not allow discard on free space ++ * inside block groups, because log trees refer to extents that are not ++ * pinned in a block group's free space cache (pinning the extents is ++ * precisely the first phase of replaying a log tree). ++ */ ++ if (btrfs_test_opt(fs_info, NOLOGREPLAY)) ++ return -EROFS; ++ + rcu_read_lock(); + list_for_each_entry_rcu(device, &fs_info->fs_devices->devices, + dev_list) { diff --git a/queue-4.9/genirq-respect-irqchip_skip_set_wake-in-irq_chip_set_wake_parent.patch b/queue-4.9/genirq-respect-irqchip_skip_set_wake-in-irq_chip_set_wake_parent.patch new file mode 100644 index 00000000000..325abc7f5d2 --- /dev/null +++ b/queue-4.9/genirq-respect-irqchip_skip_set_wake-in-irq_chip_set_wake_parent.patch @@ -0,0 +1,69 @@ +From 325aa19598e410672175ed50982f902d4e3f31c5 Mon Sep 17 00:00:00 2001 +From: Stephen Boyd +Date: Mon, 25 Mar 2019 11:10:26 -0700 +Subject: genirq: Respect IRQCHIP_SKIP_SET_WAKE in irq_chip_set_wake_parent() + +From: Stephen Boyd + +commit 325aa19598e410672175ed50982f902d4e3f31c5 upstream. + +If a child irqchip calls irq_chip_set_wake_parent() but its parent irqchip +has the IRQCHIP_SKIP_SET_WAKE flag set an error is returned. + +This is inconsistent behaviour vs. set_irq_wake_real() which returns 0 when +the irqchip has the IRQCHIP_SKIP_SET_WAKE flag set. It doesn't attempt to +walk the chain of parents and set irq wake on any chips that don't have the +flag set either. If the intent is to call the .irq_set_wake() callback of +the parent irqchip, then we expect irqchip implementations to omit the +IRQCHIP_SKIP_SET_WAKE flag and implement an .irq_set_wake() function that +calls irq_chip_set_wake_parent(). + +The problem has been observed on a Qualcomm sdm845 device where set wake +fails on any GPIO interrupts after applying work in progress wakeup irq +patches to the GPIO driver. The chain of chips looks like this: + + QCOM GPIO -> QCOM PDC (SKIP) -> ARM GIC (SKIP) + +The GPIO controllers parent is the QCOM PDC irqchip which in turn has ARM +GIC as parent. The QCOM PDC irqchip has the IRQCHIP_SKIP_SET_WAKE flag +set, and so does the grandparent ARM GIC. + +The GPIO driver doesn't know if the parent needs to set wake or not, so it +unconditionally calls irq_chip_set_wake_parent() causing this function to +return a failure because the parent irqchip (PDC) doesn't have the +.irq_set_wake() callback set. Returning 0 instead makes everything work and +irqs from the GPIO controller can be configured for wakeup. + +Make it consistent by returning 0 (success) from irq_chip_set_wake_parent() +when a parent chip has IRQCHIP_SKIP_SET_WAKE set. + +[ tglx: Massaged changelog ] + +Fixes: 08b55e2a9208e ("genirq: Add irqchip_set_wake_parent") +Signed-off-by: Stephen Boyd +Signed-off-by: Thomas Gleixner +Acked-by: Marc Zyngier +Cc: linux-arm-kernel@lists.infradead.org +Cc: linux-gpio@vger.kernel.org +Cc: Lina Iyer +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20190325181026.247796-1-swboyd@chromium.org +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/irq/chip.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/kernel/irq/chip.c ++++ b/kernel/irq/chip.c +@@ -1142,6 +1142,10 @@ int irq_chip_set_vcpu_affinity_parent(st + int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on) + { + data = data->parent_data; ++ ++ if (data->chip->flags & IRQCHIP_SKIP_SET_WAKE) ++ return 0; ++ + if (data->chip->irq_set_wake) + return data->chip->irq_set_wake(data, on); + diff --git a/queue-4.9/series b/queue-4.9/series index ef9337d0b60..8adfc606469 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -64,3 +64,7 @@ alsa-seq-fix-oob-reads-from-strlcpy.patch parisc-detect-qemu-earlier-in-boot-process.patch include-linux-bitrev.h-fix-constant-bitrev.patch asoc-fsl_esai-fix-channel-swap-issue-when-stream-starts.patch +btrfs-do-not-allow-trimming-when-a-fs-is-mounted-with-the-nologreplay-option.patch +block-do-not-leak-memory-in-bio_copy_user_iov.patch +genirq-respect-irqchip_skip_set_wake-in-irq_chip_set_wake_parent.patch +virtio-honour-may_reduce_num-in-vring_create_virtqueue.patch diff --git a/queue-4.9/virtio-honour-may_reduce_num-in-vring_create_virtqueue.patch b/queue-4.9/virtio-honour-may_reduce_num-in-vring_create_virtqueue.patch new file mode 100644 index 00000000000..d863b21d336 --- /dev/null +++ b/queue-4.9/virtio-honour-may_reduce_num-in-vring_create_virtqueue.patch @@ -0,0 +1,60 @@ +From cf94db21905333e610e479688add629397a4b384 Mon Sep 17 00:00:00 2001 +From: Cornelia Huck +Date: Mon, 8 Apr 2019 14:33:22 +0200 +Subject: virtio: Honour 'may_reduce_num' in vring_create_virtqueue + +From: Cornelia Huck + +commit cf94db21905333e610e479688add629397a4b384 upstream. + +vring_create_virtqueue() allows the caller to specify via the +may_reduce_num parameter whether the vring code is allowed to +allocate a smaller ring than specified. + +However, the split ring allocation code tries to allocate a +smaller ring on allocation failure regardless of what the +caller specified. This may cause trouble for e.g. virtio-pci +in legacy mode, which does not support ring resizing. (The +packed ring code does not resize in any case.) + +Let's fix this by bailing out immediately in the split ring code +if the requested size cannot be allocated and may_reduce_num has +not been specified. + +While at it, fix a typo in the usage instructions. + +Fixes: 2a2d1382fe9d ("virtio: Add improved queue allocation API") +Cc: stable@vger.kernel.org # v4.6+ +Signed-off-by: Cornelia Huck +Signed-off-by: Michael S. Tsirkin +Reviewed-by: Halil Pasic +Reviewed-by: Jens Freimann +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/virtio/virtio_ring.c | 2 ++ + include/linux/virtio_ring.h | 2 +- + 2 files changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/virtio/virtio_ring.c ++++ b/drivers/virtio/virtio_ring.c +@@ -1040,6 +1040,8 @@ struct virtqueue *vring_create_virtqueue + GFP_KERNEL|__GFP_NOWARN|__GFP_ZERO); + if (queue) + break; ++ if (!may_reduce_num) ++ return NULL; + } + + if (!num) +--- a/include/linux/virtio_ring.h ++++ b/include/linux/virtio_ring.h +@@ -62,7 +62,7 @@ struct virtqueue; + /* + * Creates a virtqueue and allocates the descriptor ring. If + * may_reduce_num is set, then this may allocate a smaller ring than +- * expected. The caller should query virtqueue_get_ring_size to learn ++ * expected. The caller should query virtqueue_get_vring_size to learn + * the actual size of the ring. + */ + struct virtqueue *vring_create_virtqueue(unsigned int index,