August 2020 - Linux-stable-mirror

[PATCH] ARM: config: aspeed: Fix selection of media drivers

by Joel Stanley

In the 5.7 merge window the media kconfig was restructued. For most platforms these changes set CONFIG_MEDIA_SUPPORT_FILTER=y which keeps unwanted drivers disabled. The exception is if a config sets EMBEDDED or EXPERT (see b0cd4fb27665). In that case the filter is set to =n, causing a bunch of DVB tuner drivers (MEDIA_TUNER_*) to be accidentally enabled. This was noticed as it blew out the build time for the Aspeed defconfigs. Enabling the filter means the Aspeed config also needs to set CONFIG_MEDIA_PLATFORM_SUPPORT=y in order to have the CONFIG_VIDEO_ASPEED driver enabled. Fixes: 06b93644f4d1 ("media: Kconfig: add an option to filter in/out platform drivers") Fixes: b0cd4fb27665 ("media: Kconfig: on !EMBEDDED && !EXPERT, enable driver filtering") Cc: stable(a)vger.kernel.org CC: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> Signed-off-by: Joel Stanley <joel(a)jms.id.au> --- Another solution would be to revert b0cd4fb27665 ("media: Kconfig: on !EMBEDDED && !EXPERT, enable driver filtering"). I assume this was done to be helpful, but in practice it has enabled the TUNER drivers (and others) for the following configs that didn't have them before: $ git grep -lE "(CONFIG_EXPERT|CONFIG_EMBEDDED)" arch/*/configs/ | xargs grep -l MEDIA_SUPPORT arch/arm/configs/aspeed_g4_defconfig arch/arm/configs/aspeed_g5_defconfig arch/arm/configs/at91_dt_defconfig arch/arm/configs/bcm2835_defconfig arch/arm/configs/davinci_all_defconfig arch/arm/configs/ezx_defconfig arch/arm/configs/imote2_defconfig arch/arm/configs/imx_v4_v5_defconfig arch/arm/configs/imx_v6_v7_defconfig arch/arm/configs/milbeaut_m10v_defconfig arch/arm/configs/multi_v7_defconfig arch/arm/configs/omap2plus_defconfig arch/arm/configs/pxa_defconfig arch/arm/configs/qcom_defconfig arch/arm/configs/sama5_defconfig arch/arm/configs/tegra_defconfig arch/mips/configs/ci20_defconfig arch/mips/configs/lemote2f_defconfig arch/mips/configs/loongson3_defconfig arch/mips/configs/pistachio_defconfig I've cc'd the maintainers of these defconfigs so they are aware. --- arch/arm/configs/aspeed_g4_defconfig | 3 ++- arch/arm/configs/aspeed_g5_defconfig | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig index 303f75a3baec..58d293b63581 100644 --- a/arch/arm/configs/aspeed_g4_defconfig +++ b/arch/arm/configs/aspeed_g4_defconfig @@ -160,7 +160,8 @@ CONFIG_SENSORS_TMP421=y CONFIG_SENSORS_W83773G=y CONFIG_WATCHDOG_SYSFS=y CONFIG_MEDIA_SUPPORT=y -CONFIG_MEDIA_CAMERA_SUPPORT=y +CONFIG_MEDIA_SUPPORT_FILTER=y +CONFIG_MEDIA_PLATFORM_SUPPORT=y CONFIG_V4L_PLATFORM_DRIVERS=y CONFIG_VIDEO_ASPEED=y CONFIG_DRM=y diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig index b0d056d49abe..cc2449ed6e6d 100644 --- a/arch/arm/configs/aspeed_g5_defconfig +++ b/arch/arm/configs/aspeed_g5_defconfig @@ -175,7 +175,8 @@ CONFIG_SENSORS_TMP421=y CONFIG_SENSORS_W83773G=y CONFIG_WATCHDOG_SYSFS=y CONFIG_MEDIA_SUPPORT=y -CONFIG_MEDIA_CAMERA_SUPPORT=y +CONFIG_MEDIA_SUPPORT_FILTER=y +CONFIG_MEDIA_PLATFORM_SUPPORT=y CONFIG_V4L_PLATFORM_DRIVERS=y CONFIG_VIDEO_ASPEED=y CONFIG_DRM=y -- 2.28.0

3 years, 8 months

1
1
0 0

[PATCH] cxl: Rework error message for incompatible slots

by Frederic Barrat

Improve the error message shown if a capi adapter is plugged on a capi-incompatible slot directly under the PHB (no intermediate switch). Fixes: 5632874311db ("cxl: Add support for POWER9 DD2") Cc: stable(a)vger.kernel.org # 4.14+ Signed-off-by: Frederic Barrat <fbarrat(a)linux.ibm.com> --- drivers/misc/cxl/pci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c index 25a9dd9c0c1b..2ba899f5659f 100644 --- a/drivers/misc/cxl/pci.c +++ b/drivers/misc/cxl/pci.c @@ -393,8 +393,8 @@ int cxl_calc_capp_routing(struct pci_dev *dev, u64 *chipid, *capp_unit_id = get_capp_unit_id(np, *phb_index); of_node_put(np); if (!*capp_unit_id) { - pr_err("cxl: invalid capp unit id (phb_index: %d)\n", - *phb_index); + pr_err("cxl: No capp unit found for PHB[%lld,%d]. Make sure the adapter is on a capi-compatible slot\n", + *chipid, *phb_index); return -ENODEV; } -- 2.25.1

3 years, 8 months

3
3
0 0

[PATCH] ARM: aspeed: g5: Do not set sirq polarity

by Joel Stanley

A feature was added to the aspeed vuart driver to configure the vuart interrupt (sirq) polarity according to the LPC/eSPI strapping register. Systems that depend on a active low behaviour (sirq_polarity set to 0) such as OpenPower boxes also use LPC, so this relationship does not hold. The property was added for a Tyan S7106 system which is not supported in the kernel tree. Should this or other systems wish to use this feature of the driver they should add it to the machine specific device tree. Fixes: c791fc76bc72 ("arm: dts: aspeed: Add vuart aspeed,sirq-polarity-sense...") Cc: stable(a)vger.kernel.org Signed-off-by: Joel Stanley <joel(a)jms.id.au> --- arch/arm/boot/dts/aspeed-g5.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi index 27e5c5cf7712..664630a0e084 100644 --- a/arch/arm/boot/dts/aspeed-g5.dtsi +++ b/arch/arm/boot/dts/aspeed-g5.dtsi @@ -410,7 +410,6 @@ vuart: serial@1e787000 { interrupts = <8>; clocks = <&syscon ASPEED_CLK_APB>; no-loopback-test; - aspeed,sirq-polarity-sense = <&syscon 0x70 25>; status = "disabled"; }; -- 2.28.0

3 years, 8 months

2
2
0 0

[PATCH stable 4.19 v2 0/2] arm64: entry: Place an SB sequence following an ERET instruction

by Florian Fainelli

Changes in v2: - included missing preliminary patch to define the SB barrier instruction Will Deacon (2): arm64: Add support for SB barrier and patch in over DSB; ISB sequences arm64: entry: Place an SB sequence following an ERET instruction arch/arm64/include/asm/assembler.h | 13 +++++++++++++ arch/arm64/include/asm/barrier.h | 4 ++++ arch/arm64/include/asm/cpucaps.h | 3 ++- arch/arm64/include/asm/sysreg.h | 6 ++++++ arch/arm64/include/asm/uaccess.h | 3 +-- arch/arm64/include/uapi/asm/hwcap.h | 1 + arch/arm64/kernel/cpufeature.c | 12 ++++++++++++ arch/arm64/kernel/cpuinfo.c | 1 + arch/arm64/kernel/entry.S | 2 ++ arch/arm64/kvm/hyp/entry.S | 1 + arch/arm64/kvm/hyp/hyp-entry.S | 4 ++++ 11 files changed, 47 insertions(+), 3 deletions(-) -- 2.7.4

3 years, 8 months

1
3
0 0

[PATCH 1/2] drm/i915/gem: Replace reloc chain with terminator on error unwind

by Chris Wilson

If we hit an error during construction of the reloc chain, we need to replace the chain into the next batch with the terminator so that upon flushing the relocations so far, we do not execute a hanging batch. Reported-by: Pavel Machek <pavel(a)ucw.cz> Fixes: 964a9b0f611e ("drm/i915/gem: Use chained reloc batches") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Pavel Machek <pavel(a)ucw.cz> Cc: <stable(a)vger.kernel.org> # v5.8+ --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 31 ++++++++++--------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 24a1486d2dc5..a09f04eee417 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -972,21 +972,6 @@ static int reloc_gpu_chain(struct reloc_cache *cache) if (err) goto out_pool; - GEM_BUG_ON(cache->rq_size + RELOC_TAIL > PAGE_SIZE / sizeof(u32)); - cmd = cache->rq_cmd + cache->rq_size; - *cmd++ = MI_ARB_CHECK; - if (cache->gen >= 8) - *cmd++ = MI_BATCH_BUFFER_START_GEN8; - else if (cache->gen >= 6) - *cmd++ = MI_BATCH_BUFFER_START; - else - *cmd++ = MI_BATCH_BUFFER_START | MI_BATCH_GTT; - *cmd++ = lower_32_bits(batch->node.start); - *cmd++ = upper_32_bits(batch->node.start); /* Always 0 for gen<8 */ - i915_gem_object_flush_map(cache->rq_vma->obj); - i915_gem_object_unpin_map(cache->rq_vma->obj); - cache->rq_vma = NULL; - err = intel_gt_buffer_pool_mark_active(pool, rq); if (err == 0) { i915_vma_lock(batch); @@ -999,15 +984,31 @@ static int reloc_gpu_chain(struct reloc_cache *cache) if (err) goto out_pool; + GEM_BUG_ON(cache->rq_size + RELOC_TAIL > PAGE_SIZE / sizeof(u32)); + cmd = cache->rq_cmd + cache->rq_size; + *cmd++ = MI_ARB_CHECK; + if (cache->gen >= 8) + *cmd++ = MI_BATCH_BUFFER_START_GEN8; + else if (cache->gen >= 6) + *cmd++ = MI_BATCH_BUFFER_START; + else + *cmd++ = MI_BATCH_BUFFER_START | MI_BATCH_GTT; + *cmd++ = lower_32_bits(batch->node.start); + *cmd++ = upper_32_bits(batch->node.start); /* Always 0 for gen<8 */ + cmd = i915_gem_object_pin_map(batch->obj, cache->has_llc ? I915_MAP_FORCE_WB : I915_MAP_FORCE_WC); if (IS_ERR(cmd)) { + /* We will replace the BBS with BBE upon flushing the rq */ err = PTR_ERR(cmd); goto out_pool; } + i915_gem_object_flush_map(cache->rq_vma->obj); + i915_gem_object_unpin_map(cache->rq_vma->obj); + /* Return with batch mapping (cmd) still pinned */ cache->rq_cmd = cmd; cache->rq_size = 0; -- 2.20.1

3 years, 8 months

2
9
0 0

[PATCH v2 1/2] media: uvcvideo: Fix uvc_ctrl_fixup_xu_info() not having any effect

by Hans de Goede

uvc_ctrl_add_info() calls uvc_ctrl_get_flags() which will override the fixed-up flags set by uvc_ctrl_fixup_xu_info(). uvc_ctrl_init_xu_ctrl() already calls uvc_ctrl_get_flags() before calling uvc_ctrl_add_info(), so the uvc_ctrl_get_flags() call in uvc_ctrl_add_info() is not necessary for xu ctrls. This commit moves the uvc_ctrl_get_flags() call for normal controls from uvc_ctrl_add_info() to uvc_ctrl_init_ctrl(), so that we no longer call uvc_ctrl_get_flags() twice for xu controls and so that we no longer override the fixed-up flags set by uvc_ctrl_fixup_xu_info(). This fixes the xu motor controls not working properly on a Logitech 046d:08cc, and presumably also on the other Logitech models which have a quirk for this in the uvc_ctrl_fixup_xu_info() function. Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- Changes in v2: - Move the uvc_ctrl_get_flags() call for normal controls to uvc_ctrl_init_ctrl() --- drivers/media/usb/uvc/uvc_ctrl.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c index e399b9fad757..b78aba991212 100644 --- a/drivers/media/usb/uvc/uvc_ctrl.c +++ b/drivers/media/usb/uvc/uvc_ctrl.c @@ -2024,13 +2024,6 @@ static int uvc_ctrl_add_info(struct uvc_device *dev, struct uvc_control *ctrl, goto done; } - /* - * Retrieve control flags from the device. Ignore errors and work with - * default flag values from the uvc_ctrl array when the device doesn't - * properly implement GET_INFO on standard controls. - */ - uvc_ctrl_get_flags(dev, ctrl, &ctrl->info); - ctrl->initialized = 1; uvc_trace(UVC_TRACE_CONTROL, "Added control %pUl/%u to device %s " @@ -2253,6 +2246,13 @@ static void uvc_ctrl_init_ctrl(struct uvc_device *dev, struct uvc_control *ctrl) if (uvc_entity_match_guid(ctrl->entity, info->entity) && ctrl->index == info->index) { uvc_ctrl_add_info(dev, ctrl, info); + /* + * Retrieve control flags from the device. Ignore errors + * and work with default flag values from the uvc_ctrl + * array when the device doesn't properly implement + * GET_INFO on standard controls. + */ + uvc_ctrl_get_flags(dev, ctrl, &ctrl->info); break; } } -- 2.26.2

3 years, 8 months

2
3
0 0

[PATCH] nvme: Revert: Fix controller creation races with teardown flow

by James Smart

The indicated patch introduced a barrier in the sysfs_delete attribute for the controller that rejects the request if the controller isn't created. "Created" is defined as at least 1 call to nvme_start_ctrl(). This is problematic in error-injection testing. If an error occurs on the initial attempt to create an association and the controller enters reconnect(s) attempts, the admin cannot delete the controller until either there is a successful association created or ctrl_loss_tmo times out. Where this issue is particularly hurtful is when the "admin" is the nvme-cli, it is performing a connection to a discovery controller, and it is initiated via auto-connect scripts. With the FC transport, if the first connection attempt fails, the controller enters a normal reconnect state but returns control to the cli thread that created the controller. In this scenario, the cli attempts to read the discovery log via ioctl, which fails, causing the cli to see it as an empty log and then proceeds to delete the discovery controller. The delete is rejected and the controller is left live. If the discovery controller reconnect then succeeds, there is no action to delete it, and it sits live doing nothing. Cc: <stable(a)vger.kernel.org> # v5.7+ Fixes: ce1518139e69 ("nvme: Fix controller creation races with teardown flow") Signed-off-by: James Smart <james.smart(a)broadcom.com> CC: Israel Rukshin <israelr(a)mellanox.com> CC: Max Gurtovoy <maxg(a)mellanox.com> CC: Christoph Hellwig <hch(a)lst.de> CC: Keith Busch <kbusch(a)kernel.org> CC: Sagi Grimberg <sagi(a)grimberg.me> --- drivers/nvme/host/core.c | 5 ----- drivers/nvme/host/nvme.h | 1 - 2 files changed, 6 deletions(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 05aa568a60af..86abce864aa9 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -3481,10 +3481,6 @@ static ssize_t nvme_sysfs_delete(struct device *dev, { struct nvme_ctrl *ctrl = dev_get_drvdata(dev); - /* Can't delete non-created controllers */ - if (!ctrl->created) - return -EBUSY; - if (device_remove_file_self(dev, attr)) nvme_delete_ctrl_sync(ctrl); return count; @@ -4355,7 +4351,6 @@ void nvme_start_ctrl(struct nvme_ctrl *ctrl) nvme_queue_scan(ctrl); nvme_start_queues(ctrl); } - ctrl->created = true; } EXPORT_SYMBOL_GPL(nvme_start_ctrl); diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h index c5c1bac797aa..45cf360fefbc 100644 --- a/drivers/nvme/host/nvme.h +++ b/drivers/nvme/host/nvme.h @@ -300,7 +300,6 @@ struct nvme_ctrl { struct nvme_command ka_cmd; struct work_struct fw_act_work; unsigned long events; - bool created; #ifdef CONFIG_NVME_MULTIPATH /* asymmetric namespace access: */ -- 2.26.2

3 years, 8 months

3
10
0 0

[PATCH AUTOSEL 4.14 01/33] iommu/arm-smmu: Free context bitmap in the err path of arm_smmu_init_domain_context

by Sasha Levin

From: Liu Xiang <liuxiang_1999(a)126.com> [ Upstream commit 6db7bfb431220d78e34d2d0afdb7c12683323588 ] When alloc_io_pgtable_ops is failed, context bitmap which is just allocated by __arm_smmu_alloc_bitmap should be freed to release the resource. Signed-off-by: Liu Xiang <liuxiang_1999(a)126.com> Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/iommu/arm-smmu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index c38cf03c099ed..f97c26c90c41f 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -922,6 +922,7 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain, return 0; out_clear_smmu: + __arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx); smmu_domain->smmu = NULL; out_unlock: mutex_unlock(&smmu_domain->init_mutex); -- 2.20.1

3 years, 8 months

3
36
0 0

[PATCH v2] Revert "ALSA: hda: Add support for Loongson 7A1000 controller"

by Tiezhu Yang

This reverts commit 61eee4a7fc40 ("ALSA: hda: Add support for Loongson 7A1000 controller") to fix the following error on the Loongson LS7A platform: rcu: INFO: rcu_preempt self-detected stall on CPU <SNIP> NMI backtrace for cpu 0 CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted 5.8.0+ #3 Hardware name: , BIOS Workqueue: events azx_probe_work [snd_hda_intel] <SNIP> Call Trace: [<ffffffff80211a64>] show_stack+0x9c/0x130 [<ffffffff8065a740>] dump_stack+0xb0/0xf0 [<ffffffff80665774>] nmi_cpu_backtrace+0x134/0x140 [<ffffffff80665910>] nmi_trigger_cpumask_backtrace+0x190/0x200 [<ffffffff802b1abc>] rcu_dump_cpu_stacks+0x12c/0x190 [<ffffffff802b08cc>] rcu_sched_clock_irq+0xa2c/0xfc8 [<ffffffff802b91d4>] update_process_times+0x2c/0xb8 [<ffffffff802cad80>] tick_sched_timer+0x40/0xb8 [<ffffffff802ba5f0>] __hrtimer_run_queues+0x118/0x1d0 [<ffffffff802bab74>] hrtimer_interrupt+0x12c/0x2d8 [<ffffffff8021547c>] c0_compare_interrupt+0x74/0xa0 [<ffffffff80296bd0>] __handle_irq_event_percpu+0xa8/0x198 [<ffffffff80296cf0>] handle_irq_event_percpu+0x30/0x90 [<ffffffff8029d958>] handle_percpu_irq+0x88/0xb8 [<ffffffff80296124>] generic_handle_irq+0x44/0x60 [<ffffffff80b3cfd0>] do_IRQ+0x18/0x28 [<ffffffff8067ace4>] plat_irq_dispatch+0x64/0x100 [<ffffffff80209a20>] handle_int+0x140/0x14c [<ffffffff802402e8>] irq_exit+0xf8/0x100 Because AZX_DRIVER_GENERIC can not work well for Loongson LS7A HDA controller, it needs some workarounds which are not merged into the upstream kernel at this time, so it should revert this patch now. Fixes: 61eee4a7fc40 ("ALSA: hda: Add support for Loongson 7A1000 controller") Cc: <stable(a)vger.kernel.org> # 5.9-rc1+ Signed-off-by: Tiezhu Yang <yangtiezhu(a)loongson.cn> --- v2: update commit message sound/pci/hda/hda_intel.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index e34a4d5..0f86e37 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2745,8 +2745,6 @@ static const struct pci_device_id azx_ids[] = { .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_HDMI }, /* Zhaoxin */ { PCI_DEVICE(0x1d17, 0x3288), .driver_data = AZX_DRIVER_ZHAOXIN }, - /* Loongson */ - { PCI_DEVICE(0x0014, 0x7a07), .driver_data = AZX_DRIVER_GENERIC }, { 0, } }; MODULE_DEVICE_TABLE(pci, azx_ids); -- 2.1.0

3 years, 8 months

4
4
0 0

[PATCH] mm: madvise: fix vma user-after-free

by Yang Shi

The syzbot reported the below use-after-free: BUG: KASAN: use-after-free in madvise_willneed mm/madvise.c:293 [inline] BUG: KASAN: use-after-free in madvise_vma mm/madvise.c:942 [inline] BUG: KASAN: use-after-free in do_madvise.part.0+0x1c8b/0x1cf0 mm/madvise.c:1145 Read of size 8 at addr ffff8880a6163eb0 by task syz-executor.0/9996 CPU: 0 PID: 9996 Comm: syz-executor.0 Not tainted 5.9.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xae/0x497 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 madvise_willneed mm/madvise.c:293 [inline] madvise_vma mm/madvise.c:942 [inline] do_madvise.part.0+0x1c8b/0x1cf0 mm/madvise.c:1145 do_madvise mm/madvise.c:1169 [inline] __do_sys_madvise mm/madvise.c:1171 [inline] __se_sys_madvise mm/madvise.c:1169 [inline] __x64_sys_madvise+0xd9/0x110 mm/madvise.c:1169 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45d4d9 Code: 5d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f04f7464c78 EFLAGS: 00000246 ORIG_RAX: 000000000000001c RAX: ffffffffffffffda RBX: 0000000000020800 RCX: 000000000045d4d9 RDX: 0000000000000003 RSI: 0000000000600003 RDI: 0000000020000000 RBP: 000000000118d020 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000118cfec R13: 00007ffc579cce7f R14: 00007f04f74659c0 R15: 000000000118cfec Allocated by task 9992: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461 slab_post_alloc_hook mm/slab.h:518 [inline] slab_alloc mm/slab.c:3312 [inline] kmem_cache_alloc+0x138/0x3a0 mm/slab.c:3482 vm_area_alloc+0x1c/0x110 kernel/fork.c:347 mmap_region+0x8e5/0x1780 mm/mmap.c:1743 do_mmap+0xcf9/0x11d0 mm/mmap.c:1545 vm_mmap_pgoff+0x195/0x200 mm/util.c:506 ksys_mmap_pgoff+0x43a/0x560 mm/mmap.c:1596 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 9992: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 kasan_set_track+0x1c/0x30 mm/kasan/common.c:56 kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:355 __kasan_slab_free+0xd8/0x120 mm/kasan/common.c:422 __cache_free mm/slab.c:3418 [inline] kmem_cache_free.part.0+0x67/0x1f0 mm/slab.c:3693 remove_vma+0x132/0x170 mm/mmap.c:184 remove_vma_list mm/mmap.c:2613 [inline] __do_munmap+0x743/0x1170 mm/mmap.c:2869 do_munmap mm/mmap.c:2877 [inline] mmap_region+0x257/0x1780 mm/mmap.c:1716 do_mmap+0xcf9/0x11d0 mm/mmap.c:1545 vm_mmap_pgoff+0x195/0x200 mm/util.c:506 ksys_mmap_pgoff+0x43a/0x560 mm/mmap.c:1596 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 It is because vma is accessed after releasing mmap_sem, but someone else acquired the mmap_sem and the vma is gone. Releasing mmap_sem after accessing vma should fix the problem. Fixes: 692fe62433d4c ("mm: Handle MADV_WILLNEED through vfs_fadvise()") Reported-by: syzbot+b90df26038d1d5d85c97(a)syzkaller.appspotmail.com Cc: Jan Kara <jack(a)suse.cz> Cc: <stable(a)vger.kernel.org> v5.4+ Signed-off-by: Yang Shi <shy828301(a)gmail.com> --- mm/madvise.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/madvise.c b/mm/madvise.c index dd1d43cf026d..d4aa5f776543 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -289,9 +289,9 @@ static long madvise_willneed(struct vm_area_struct *vma, */ *prev = NULL; /* tell sys_madvise we drop mmap_lock */ get_file(file); - mmap_read_unlock(current->mm); offset = (loff_t)(start - vma->vm_start) + ((loff_t)vma->vm_pgoff << PAGE_SHIFT); + mmap_read_unlock(current->mm); vfs_fadvise(file, offset, end - start, POSIX_FADV_WILLNEED); fput(file); mmap_read_lock(current->mm); -- 2.26.2

3 years, 8 months

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2020