- Linux-stable-mirror - lists.linaro.org

FAILED: patch "[PATCH] btrfs: fix possible free space tree corruption with online" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2f96e40212d435b328459ba6b3956395eed8fa9f Mon Sep 17 00:00:00 2001 From: Josef Bacik <josef(a)toxicpanda.com> Date: Fri, 15 Jan 2021 16:26:17 -0500 Subject: [PATCH] btrfs: fix possible free space tree corruption with online conversion While running btrfs/011 in a loop I would often ASSERT() while trying to add a new free space entry that already existed, or get an EEXIST while adding a new block to the extent tree, which is another indication of double allocation. This occurs because when we do the free space tree population, we create the new root and then populate the tree and commit the transaction. The problem is when you create a new root, the root node and commit root node are the same. During this initial transaction commit we will run all of the delayed refs that were paused during the free space tree generation, and thus begin to cache block groups. While caching block groups the caching thread will be reading from the main root for the free space tree, so as we make allocations we'll be changing the free space tree, which can cause us to add the same range twice which results in either the ASSERT(ret != -EEXIST); in __btrfs_add_free_space, or in a variety of different errors when running delayed refs because of a double allocation. Fix this by marking the fs_info as unsafe to load the free space tree, and fall back on the old slow method. We could be smarter than this, for example caching the block group while we're populating the free space tree, but since this is a serious problem I've opted for the simplest solution. CC: stable(a)vger.kernel.org # 4.9+ Fixes: a5ed91828518 ("Btrfs: implement the free space B-tree") Reviewed-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: Josef Bacik <josef(a)toxicpanda.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c index 0886e81e5540..48ebc106a606 100644 --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -673,7 +673,15 @@ static noinline void caching_thread(struct btrfs_work *work) wake_up(&caching_ctl->wait); } - if (btrfs_fs_compat_ro(fs_info, FREE_SPACE_TREE)) + /* + * If we are in the transaction that populated the free space tree we + * can't actually cache from the free space tree as our commit root and + * real root are the same, so we could change the contents of the blocks + * while caching. Instead do the slow caching in this case, and after + * the transaction has committed we will be safe. + */ + if (btrfs_fs_compat_ro(fs_info, FREE_SPACE_TREE) && + !(test_bit(BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED, &fs_info->flags))) ret = load_free_space_tree(caching_ctl); else ret = load_extent_tree_free(caching_ctl); diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index 0225c5208f44..47ca8edafb5e 100644 --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree.h @@ -564,6 +564,9 @@ enum { /* Indicate that we need to cleanup space cache v1 */ BTRFS_FS_CLEANUP_SPACE_CACHE_V1, + + /* Indicate that we can't trust the free space tree for caching yet */ + BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED, }; /* diff --git a/fs/btrfs/free-space-tree.c b/fs/btrfs/free-space-tree.c index e33a65bd9a0c..a33bca94d133 100644 --- a/fs/btrfs/free-space-tree.c +++ b/fs/btrfs/free-space-tree.c @@ -1150,6 +1150,7 @@ int btrfs_create_free_space_tree(struct btrfs_fs_info *fs_info) return PTR_ERR(trans); set_bit(BTRFS_FS_CREATING_FREE_SPACE_TREE, &fs_info->flags); + set_bit(BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED, &fs_info->flags); free_space_root = btrfs_create_tree(trans, BTRFS_FREE_SPACE_TREE_OBJECTID); if (IS_ERR(free_space_root)) { @@ -1171,11 +1172,18 @@ int btrfs_create_free_space_tree(struct btrfs_fs_info *fs_info) btrfs_set_fs_compat_ro(fs_info, FREE_SPACE_TREE); btrfs_set_fs_compat_ro(fs_info, FREE_SPACE_TREE_VALID); clear_bit(BTRFS_FS_CREATING_FREE_SPACE_TREE, &fs_info->flags); + ret = btrfs_commit_transaction(trans); - return btrfs_commit_transaction(trans); + /* + * Now that we've committed the transaction any reading of our commit + * root will be safe, so we can cache from the free space tree now. + */ + clear_bit(BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED, &fs_info->flags); + return ret; abort: clear_bit(BTRFS_FS_CREATING_FREE_SPACE_TREE, &fs_info->flags); + clear_bit(BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED, &fs_info->flags); btrfs_abort_transaction(trans, ret); btrfs_end_transaction(trans); return ret;

4 years, 6 months

1
0
0 0

[PATCH 2/3] drm/panfrost: Don't try to map pages that are already mapped

by Boris Brezillon

We allocate 2MB chunks at a time, so it might appear that a page fault has already been handled by a previous page fault when we reach panfrost_mmu_map_fault_addr(). Bail out in that case to avoid mapping the same area twice. Cc: <stable(a)vger.kernel.org> Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations") Signed-off-by: Boris Brezillon <boris.brezillon(a)collabora.com> --- drivers/gpu/drm/panfrost/panfrost_mmu.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c b/drivers/gpu/drm/panfrost/panfrost_mmu.c index 904d63450862..21e552d1ac71 100644 --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c @@ -488,8 +488,14 @@ static int panfrost_mmu_map_fault_addr(struct panfrost_device *pfdev, int as, } bo->base.pages = pages; bo->base.pages_use_count = 1; - } else + } else { pages = bo->base.pages; + if (pages[page_offset]) { + /* Pages are already mapped, bail out. */ + mutex_unlock(&bo->base.pages_lock); + goto out; + } + } mapping = bo->base.base.filp->f_mapping; mapping_set_unevictable(mapping); @@ -522,6 +528,7 @@ static int panfrost_mmu_map_fault_addr(struct panfrost_device *pfdev, int as, dev_dbg(pfdev->dev, "mapped page fault @ AS%d %llx", as, addr); +out: panfrost_gem_mapping_put(bomapping); return 0; -- 2.26.2

4 years, 6 months

2
1
0 0

[PATCH 1/3] drm/panfrost: Clear MMU irqs before handling the fault

by Boris Brezillon

When a fault is handled it will unblock the GPU which will continue executing its shader and might fault almost immediately on a different page. If we clear interrupts after handling the fault we might miss new faults, so clear them before. Cc: <stable(a)vger.kernel.org> Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations") Signed-off-by: Boris Brezillon <boris.brezillon(a)collabora.com> --- drivers/gpu/drm/panfrost/panfrost_mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c b/drivers/gpu/drm/panfrost/panfrost_mmu.c index 7c1b3481b785..904d63450862 100644 --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c @@ -593,6 +593,8 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int irq, void *data) access_type = (fault_status >> 8) & 0x3; source_id = (fault_status >> 16); + mmu_write(pfdev, MMU_INT_CLEAR, mask); + /* Page fault only */ ret = -1; if ((status & mask) == BIT(i) && (exception_type & 0xF8) == 0xC0) @@ -616,8 +618,6 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int irq, void *data) access_type, access_type_name(pfdev, fault_status), source_id); - mmu_write(pfdev, MMU_INT_CLEAR, mask); - status &= ~mask; } -- 2.26.2

4 years, 6 months

2
1
0 0

[PATCH 4.9 00/12] Futex back-port from v4.14

by Lee Jones

Ref: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tre… This set required 1 additional patch from v4.14 to avoid build errors. Arnd Bergmann (1): y2038: futex: Move compat implementation into futex.c Thomas Gleixner (11): futex: Move futex exit handling into futex code futex: Replace PF_EXITPIDONE with a state exit/exec: Seperate mm_release() futex: Split futex_mm_release() for exit/exec futex: Set task::futex_state to DEAD right after handling futex exit futex: Mark the begin of futex exit explicitly futex: Sanitize exit state handling futex: Provide state handling for exec() as well futex: Add mutex around futex exit futex: Provide distinct return value when owner is exiting futex: Prevent exit livelock fs/exec.c | 2 +- include/linux/compat.h | 2 - include/linux/futex.h | 44 ++-- include/linux/sched.h | 9 +- kernel/Makefile | 3 - kernel/exit.c | 29 +-- kernel/fork.c | 40 ++-- kernel/futex.c | 446 ++++++++++++++++++++++++++++++++++++++--- kernel/futex_compat.c | 201 ------------------- 9 files changed, 466 insertions(+), 310 deletions(-) delete mode 100644 kernel/futex_compat.c Cc: Stable Team <stable(a)vger.kernel.org> -- 2.25.1

4 years, 6 months

2
13
0 0

Re: linux-5.10.11 build failure

by Chris Clayton

Hi Greg, On 29/01/2021 15:14, Josh Poimboeuf wrote: > On Fri, Jan 29, 2021 at 12:09:53PM +0100, Greg Kroah-Hartman wrote: >> On Fri, Jan 29, 2021 at 11:03:26AM +0000, Chris Clayton wrote: >>> >>> >>> On 29/01/2021 10:11, Greg Kroah-Hartman wrote: >>>> On Thu, Jan 28, 2021 at 10:00:15AM -0600, Josh Poimboeuf wrote: ... >>>> >>>> It is in Linus's tree now :) >>>> >>>> Now grabbed. >>>> >>> >>> Are you sure, Greg? I don't see the patch in Linus' tree at >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git. Nor do is see it in your stable queue at >>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/. For clarity, I've attached the patch which >>> fixes problem I reported and is currently sat in https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git As I >>> understand it, the patch is scheduled to be included in a pull request to Linus this weekend in time for -rc6. >>> >>> In fact, I did a pull from Linus' tree a few minutes ago and the build failed in the way I reported in this thread. I >>> added the patch and the build now succeeds. >> >> Ok, sorry, no, I grabbed 1d489151e9f9 ("objtool: Don't fail on missing >> symbol table") which is what Josh asked me to take. I got that confused >> here. > > I'm probably responsible for that confusion, I got mixed up myself. > It'll be a good idea to take both anyway. > The patch is now in Linus' tree at 5e6dca82bcaa49348f9e5fcb48df4881f6d6c4ae Thanks. Chris

4 years, 6 months

2
1
0 0

[git:media_tree/master] media: Revert "media: videobuf2: Fix length check for single plane dmabuf queueing"

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: Revert "media: videobuf2: Fix length check for single plane dmabuf queueing" Author: Naushir Patuck <naush(a)raspberrypi.com> Date: Wed Jan 6 16:16:57 2021 +0100 The updated length check for dmabuf types broke existing usage in v4l2 userland clients. Fixes: 961d3b27 ("media: videobuf2: Fix length check for single plane dmabuf queueing") Cc: stable(a)vger.kernel.org Signed-off-by: Naushir Patuck <naush(a)raspberrypi.com> Tested-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> drivers/media/common/videobuf2/videobuf2-v4l2.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c b/drivers/media/common/videobuf2/videobuf2-v4l2.c index 96d3b2b2aa31..3f61f5863bf7 100644 --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c @@ -118,8 +118,7 @@ static int __verify_length(struct vb2_buffer *vb, const struct v4l2_buffer *b) return -EINVAL; } } else { - length = (b->memory == VB2_MEMORY_USERPTR || - b->memory == VB2_MEMORY_DMABUF) + length = (b->memory == VB2_MEMORY_USERPTR) ? b->length : vb->planes[0].length; if (b->bytesused > length)

4 years, 6 months

1
0
0 0

[git:media_tree/master] media: rc: ensure that uevent can be read directly after rc device register

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: rc: ensure that uevent can be read directly after rc device register Author: Sean Young <sean(a)mess.org> Date: Sun Dec 20 13:29:54 2020 +0100 There is a race condition where if the /sys/class/rc0/uevent file is read before rc_dev->registered is set to true, -ENODEV will be returned. Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1901089 Cc: stable(a)vger.kernel.org Fixes: a2e2d73fa281 ("media: rc: do not access device via sysfs after rc_unregister_device()") Signed-off-by: Sean Young <sean(a)mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> drivers/media/rc/rc-main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index 1d811e5ffb55..29d4d01896ff 100644 --- a/drivers/media/rc/rc-main.c +++ b/drivers/media/rc/rc-main.c @@ -1928,6 +1928,8 @@ int rc_register_device(struct rc_dev *dev) goto out_raw; } + dev->registered = true; + rc = device_add(&dev->dev); if (rc) goto out_rx_free; @@ -1937,8 +1939,6 @@ int rc_register_device(struct rc_dev *dev) dev->device_name ?: "Unspecified device", path ?: "N/A"); kfree(path); - dev->registered = true; - /* * once the the input device is registered in rc_setup_rx_device, * userspace can open the input device and rc_open() will be called

4 years, 6 months

1
0
0 0

[git:media_tree/master] media: rc: ite-cir: fix min_timeout calculation

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: rc: ite-cir: fix min_timeout calculation Author: Matthias Reichl <hias(a)horus.com> Date: Sat Jan 9 21:10:55 2021 +0100 Commit 528222d853f92 ("media: rc: harmonize infrared durations to microseconds") missed to switch the min_timeout calculation from ns to us. This resulted in a minimum timeout of 1.2 seconds instead of 1.2ms, leading to large delays and long key repeats. Fix this by applying proper ns->us conversion. Cc: stable(a)vger.kernel.org Fixes: 528222d853f92 ("media: rc: harmonize infrared durations to microseconds") Signed-off-by: Matthias Reichl <hias(a)horus.com> Signed-off-by: Sean Young <sean(a)mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> drivers/media/rc/ite-cir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c index a905113fef6e..0c6229592e13 100644 --- a/drivers/media/rc/ite-cir.c +++ b/drivers/media/rc/ite-cir.c @@ -1551,7 +1551,7 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id rdev->s_rx_carrier_range = ite_set_rx_carrier_range; /* FIFO threshold is 17 bytes, so 17 * 8 samples minimum */ rdev->min_timeout = 17 * 8 * ITE_BAUDRATE_DIVISOR * - itdev->params.sample_period; + itdev->params.sample_period / 1000; rdev->timeout = IR_DEFAULT_TIMEOUT; rdev->max_timeout = 10 * IR_DEFAULT_TIMEOUT; rdev->rx_resolution = ITE_BAUDRATE_DIVISOR *

4 years, 6 months

1
0
0 0

[git:media_tree/master] media: rc: fix timeout handling after switch to microsecond durations

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: rc: fix timeout handling after switch to microsecond durations Author: Matthias Reichl <hias(a)horus.com> Date: Tue Jan 5 10:30:23 2021 +0100 Commit 528222d853f92 ("media: rc: harmonize infrared durations to microseconds") missed to switch some timeout calculations from nanoseconds to microseconds. This resulted in spurious key_up+key_down events at the last scancode if the rc device uses a long timeout (eg 100ms on nuvoton-cir) as the device timeout wasn't properly accounted for in the keyup timeout calculation. Fix this by applying the proper conversion functions. Cc: stable(a)vger.kernel.org Fixes: 528222d853f92 ("media: rc: harmonize infrared durations to microseconds") Signed-off-by: Matthias Reichl <hias(a)horus.com> Signed-off-by: Sean Young <sean(a)mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> drivers/media/rc/ir-mce_kbd-decoder.c | 2 +- drivers/media/rc/rc-main.c | 4 ++-- drivers/media/rc/serial_ir.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) --- diff --git a/drivers/media/rc/ir-mce_kbd-decoder.c b/drivers/media/rc/ir-mce_kbd-decoder.c index be8f2756a444..1524dc0fc566 100644 --- a/drivers/media/rc/ir-mce_kbd-decoder.c +++ b/drivers/media/rc/ir-mce_kbd-decoder.c @@ -320,7 +320,7 @@ again: data->body); spin_lock(&data->keylock); if (scancode) { - delay = nsecs_to_jiffies(dev->timeout) + + delay = usecs_to_jiffies(dev->timeout) + msecs_to_jiffies(100); mod_timer(&data->rx_timeout, jiffies + delay); } else { diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index 29d4d01896ff..1fd62c1dac76 100644 --- a/drivers/media/rc/rc-main.c +++ b/drivers/media/rc/rc-main.c @@ -737,7 +737,7 @@ static unsigned int repeat_period(int protocol) void rc_repeat(struct rc_dev *dev) { unsigned long flags; - unsigned int timeout = nsecs_to_jiffies(dev->timeout) + + unsigned int timeout = usecs_to_jiffies(dev->timeout) + msecs_to_jiffies(repeat_period(dev->last_protocol)); struct lirc_scancode sc = { .scancode = dev->last_scancode, .rc_proto = dev->last_protocol, @@ -855,7 +855,7 @@ void rc_keydown(struct rc_dev *dev, enum rc_proto protocol, u64 scancode, ir_do_keydown(dev, protocol, scancode, keycode, toggle); if (dev->keypressed) { - dev->keyup_jiffies = jiffies + nsecs_to_jiffies(dev->timeout) + + dev->keyup_jiffies = jiffies + usecs_to_jiffies(dev->timeout) + msecs_to_jiffies(repeat_period(protocol)); mod_timer(&dev->timer_keyup, dev->keyup_jiffies); } diff --git a/drivers/media/rc/serial_ir.c b/drivers/media/rc/serial_ir.c index 8cc28c92d05d..96ae0294ac10 100644 --- a/drivers/media/rc/serial_ir.c +++ b/drivers/media/rc/serial_ir.c @@ -385,7 +385,7 @@ static irqreturn_t serial_ir_irq_handler(int i, void *blah) } while (!(sinp(UART_IIR) & UART_IIR_NO_INT)); /* still pending ? */ mod_timer(&serial_ir.timeout_timer, - jiffies + nsecs_to_jiffies(serial_ir.rcdev->timeout)); + jiffies + usecs_to_jiffies(serial_ir.rcdev->timeout)); ir_raw_event_handle(serial_ir.rcdev);

4 years, 6 months

1
0
0 0

Re: [PATCH] watchdog: qcom: Remove incorrect usage of QCOM_WDT_ENABLE_IRQ

by Sai Prakash Ranjan

On 2021-01-31 22:33, Jorge Ramirez-Ortiz, Foundries wrote: > On 28/01/21, Sai Prakash Ranjan wrote: >> On 2021-01-28 13:49, Jorge Ramirez-Ortiz, Foundries wrote: >> > On 26/01/21, Sai Prakash Ranjan wrote: >> > > As per register documentation, QCOM_WDT_ENABLE_IRQ which is BIT(1) >> > > of watchdog control register is wakeup interrupt enable bit and >> > > not related to bark interrupt at all, BIT(0) is used for that. >> > > So remove incorrect usage of this bit when supporting bark irq for >> > > pre-timeout notification. Currently with this bit set and bark >> > > interrupt specified, pre-timeout notification and/or watchdog >> > > reset/bite does not occur. >> > > >> > > Fixes: 36375491a439 ("watchdog: qcom: support pre-timeout when the >> > > bark irq is available") >> > > Cc: stable(a)vger.kernel.org >> > > Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan(a)codeaurora.org> >> > > --- >> > > >> > > Reading the conversations from when qcom pre-timeout support was >> > > added [1], Bjorn already had mentioned it was not right to touch this >> > > bit, not sure which SoC the pre-timeout was tested on at that time, >> > > but I have tested this on SDM845, SM8150, SC7180 and watchdog bark >> > > and bite does not occur with enabling this bit with the bark irq >> > > specified in DT. >> > >> > this was tested on QCS404. have you validated there? unfortunately I >> > no longer have access to that hardware or the documentation >> > >> >> I didn't validate on qcs404 yet since I didn't have access to it. >> But now that you mention it, let me arrange for a setup and test it >> there as well. Note: I did not see bark irq entry in upstream qcs404 >> dtsi, so you must have had some local change when you tested? > > TBH I dont quite remember. I suppose that if those with access to the > documents and hardware are OK with this change then it shouldnt cause > regressions (I just cant check from my end) > No worries, I got the documentation access now and it is the same as other SoCs which I have tested above, meaning the BIT(1) is not related to bark irq. I am arranging a setup as well now, it took some time as I don't work on QCS* chipsets but I can confirm by this week. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

4 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror