November 2021 - Linux-stable-mirror

[PATCH 5.10 0/1] fix null-ptr-deref in rds_ib_add_one()

by Yang Yingliang

I got this null-ptr-deref report while doing fuzz test: [ 158.820284][T12735] BUG: KASAN: null-ptr-deref in dma_pool_create+0xf7/0x440 [ 158.821192][T12735] Read of size 4 at addr 0000000000000298 by task syz-executor.7/12735 [ 158.822239][T12735] [ 158.822539][T12735] CPU: 0 PID: 12735 Comm: syz-executor.7 Not tainted 5.10.78 #691 [ 158.823494][T12735] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 158.824720][T12735] Call Trace: [ 158.825889][T12735] dump_stack+0x111/0x151 [ 158.826458][T12735] ? dma_pool_create+0xf7/0x440 [ 158.827067][T12735] ? dma_pool_create+0xf7/0x440 [ 158.827672][T12735] kasan_report.cold.11+0x5/0x37 [ 158.828289][T12735] ? dma_pool_create+0xf7/0x440 [ 158.828894][T12735] dma_pool_create+0xf7/0x440 [ 158.829480][T12735] rds_ib_add_one+0x448/0x570 [ 158.830062][T12735] ? rds_ib_remove_one+0x150/0x150 [ 158.830702][T12735] add_client_context+0x2ef/0x440 [ 158.831329][T12735] ? ib_unregister_driver+0x1a0/0x1a0 [ 158.832005][T12735] ? strchr+0x28/0x50 [ 158.832527][T12735] enable_device_and_get+0x199/0x320 [ 158.833194][T12735] ? add_one_compat_dev.part.20+0x3d0/0x3d0 [ 158.833924][T12735] ? rxe_ib_alloc_hw_stats+0x84/0x90 [ 158.834590][T12735] ? setup_hw_stats+0x40/0x520 [ 158.835184][T12735] ? uevent_show+0x1e0/0x1e0 [ 158.835758][T12735] ? rxe_ib_get_hw_stats+0xa0/0xa0 [ 158.836398][T12735] ib_register_device+0x8ef/0x9d0 [ 158.837026][T12735] ? netlink_unicast+0x3e1/0x510 [ 158.837644][T12735] ? alloc_port_data.part.17+0x1f0/0x1f0 [ 158.838358][T12735] ? __alloc_pages_nodemask+0x229/0x450 [ 158.839051][T12735] ? kasan_unpoison_shadow+0x30/0x40 [ 158.839710][T12735] ? __kasan_kmalloc.constprop.12+0xbe/0xd0 [ 158.840443][T12735] ? kmem_cache_alloc_node_trace+0xa3/0x870 [ 158.841178][T12735] ? __crypto_alg_lookup+0x26d/0x2d0 [ 158.841841][T12735] ? __kasan_kmalloc.constprop.12+0xbe/0xd0 [ 158.842573][T12735] ? crypto_shash_init_tfm+0x10d/0x160 [ 158.843255][T12735] ? crc32_pclmul_cra_init+0x12/0x20 [ 158.843916][T12735] ? crypto_create_tfm_node+0xb7/0x1a0 [ 158.844594][T12735] ? crypto_alloc_tfm_node+0x12e/0x260 [ 158.845273][T12735] rxe_register_device+0x21f/0x250 [ 158.845904][T12735] rxe_add+0x9f9/0xa80 [ 158.846412][T12735] rxe_net_add+0x56/0xa0 [ 158.846917][T12735] rxe_newlink+0x8c/0xb0 [ 158.847427][T12735] nldev_newlink+0x23d/0x360 [ 158.847973][T12735] ? nldev_set_doit+0x2b0/0x2b0 [ 158.848562][T12735] ? apparmor_capable+0x2e9/0x4e0 [ 158.849159][T12735] ? apparmor_cred_prepare+0x3f0/0x3f0 [ 158.849811][T12735] ? apparmor_cred_prepare+0x3f0/0x3f0 [ 158.850469][T12735] ? ____sys_sendmsg+0x4db/0x500 [ 158.851064][T12735] ? ___sys_sendmsg+0xf8/0x160 [ 158.851648][T12735] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 158.852400][T12735] ? cap_capable+0x125/0x140 [ 158.854398][T12735] ? ns_capable_common+0x88/0xa0 [ 158.855012][T12735] ? nldev_set_doit+0x2b0/0x2b0 [ 158.855611][T12735] rdma_nl_rcv+0x41f/0x630 [ 158.856162][T12735] ? rdma_nl_multicast+0xa0/0xa0 [ 158.856772][T12735] ? netlink_lookup+0x273/0x3a0 [ 158.857374][T12735] ? netlink_broadcast+0x40/0x40 [ 158.857984][T12735] ? __kasan_kmalloc.constprop.12+0xbe/0xd0 [ 158.858724][T12735] ? __rcu_read_unlock+0x34/0x260 [ 158.859349][T12735] ? netlink_deliver_tap+0x65/0x450 [ 158.859991][T12735] netlink_unicast+0x3e1/0x510 [ 158.860586][T12735] ? netlink_attachskb+0x540/0x540 [ 158.861218][T12735] ? _copy_from_iter_full+0x1b9/0x5e0 [ 158.861905][T12735] ? __check_object_size+0x27c/0x300 [ 158.862561][T12735] netlink_sendmsg+0x4aa/0x870 [ 158.863131][T12735] ? netlink_unicast+0x510/0x510 [ 158.863728][T12735] ? netlink_unicast+0x510/0x510 [ 158.864326][T12735] sock_sendmsg+0x83/0xa0 [ 158.864849][T12735] ____sys_sendmsg+0x4db/0x500 [ 158.865429][T12735] ? __copy_msghdr_from_user+0x310/0x310 [ 158.866112][T12735] ? kernel_sendmsg+0x50/0x50 [ 158.866700][T12735] ? do_syscall_64+0x2d/0x70 [ 158.867256][T12735] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 158.867996][T12735] ___sys_sendmsg+0xf8/0x160 [ 158.868552][T12735] ? sendmsg_copy_msghdr+0x70/0x70 [ 158.869175][T12735] ? kasan_unpoison_shadow+0x30/0x40 [ 158.869824][T12735] ? futex_exit_release+0x80/0x80 [ 158.870442][T12735] ? apparmor_task_setrlimit+0x500/0x500 [ 158.871122][T12735] ? kmem_cache_alloc+0x143/0x810 [ 158.871733][T12735] ? __rcu_read_unlock+0x34/0x260 [ 158.872351][T12735] ? __fget_files+0x14a/0x1b0 [ 158.872920][T12735] ? __fget_light+0xeb/0x140 [ 158.873474][T12735] __sys_sendmsg+0xfe/0x1c0 [ 158.874017][T12735] ? __sys_sendmsg_sock+0x80/0x80 [ 158.874625][T12735] ? _copy_to_user+0x97/0xb0 [ 158.875177][T12735] ? put_timespec64+0xab/0xe0 [ 158.875740][T12735] ? nsecs_to_jiffies+0x30/0x30 [ 158.876325][T12735] ? fpregs_assert_state_consistent+0x8f/0xa0 [ 158.877054][T12735] do_syscall_64+0x2d/0x70 [ 158.877585][T12735] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 158.878297][T12735] RIP: 0033:0x45ecc9 [ 158.878769][T12735] Code: 1d b1 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 eb b0 fb ff c3 66 2e 0f 1f 84 00 00 00 00 [ 158.881085][T12735] RSP: 002b:00007f2c7a09fc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 158.882086][T12735] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 000000000045ecc9 [ 158.883038][T12735] RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 000000000000000a [ 158.883983][T12735] RBP: 000000000119bfe0 R08: 0000000000000000 R09: 0000000000000000 [ 158.884929][T12735] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000119bfac [ 158.885877][T12735] R13: 00007fff86afff9f R14: 00007f2c7a0a09c0 R15: 000000000119bfac In rxe_register_device(), it passes a null pointer to ib_register_device() the 'device->dma_device' will be set to null, when it used in rds_ib_add_one(), it leads a null-ptr-deref. Christoph Hellwig (1): rds: stop using dmapool net/rds/ib.c | 10 ---- net/rds/ib.h | 6 --- net/rds/ib_cm.c | 128 ++++++++++++++++++++++++++++------------------ net/rds/ib_recv.c | 18 +++++-- net/rds/ib_send.c | 8 +++ 5 files changed, 101 insertions(+), 69 deletions(-) -- 2.25.1

3 years, 1 month

1
1
0 0

Параметры учетной записи для A Senior Dating Site That Actually Works https://www.google.com/url?q=https%3A%2F%2Fyourladiefun.life%2F%3Fu%3Dxu2kte0%26o%3Db01p800%26m%3D1&sa=D&sntz=1&usg=AFQjCNFxUrIeaK4crq0AcEiPXw3WiBbpPA&c=atu на сайте Челябинский психоневрологический интернат № 2

by Название сайта

Здравствуйте, A Senior Dating Site That Actually Works https://www.google.com/url?q=https%3A%2F%2Fyourladiefun.life%2F%3Fu%3Dxu2kt…, Благодарим вас за регистрацию на сайте «Челябинский психоневрологический интернат № 2». Ваша учётная запись создана, но должна быть активирована прежде, чем вы сможете ею воспользоваться. Чтобы активировать учётную запись, перейдите по ссылке ниже, или скопируйте её в адресную строку браузера: http://xn--2-otboh3b.xn--p1ai/index.php?option=com_users&task=registration.… После активации вы сможете входить на сайт «http://xn--2-otboh3b.xn--p1ai/» с помощью указанных ниже логина и пароля: Логин: A Senior Dating Site That Actually Works https://www.google.com/url?q=https3A2F2Fyourladiefun.life2F3Fu3Dxu2kte026o3… Пароль: Ich_mag_audi.com

3 years, 1 month

1
0
0 0

[PATCH] cxl/pmem: Fix module reload vs workqueue state

by Dan Williams

A test of the form: while true; do modprobe -r cxl_pmem; modprobe cxl_pmem; done May lead to a crash signature of the form: BUG: unable to handle page fault for address: ffffffffc0660030 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page [..] Workqueue: cxl_pmem 0xffffffffc0660030 RIP: 0010:0xffffffffc0660030 Code: Unable to access opcode bytes at RIP 0xffffffffc0660006. [..] Call Trace: ? process_one_work+0x4ec/0x9c0 ? pwq_dec_nr_in_flight+0x100/0x100 ? rwlock_bug.part.0+0x60/0x60 ? worker_thread+0x2eb/0x700 In that report the 0xffffffffc0660030 address corresponds to the former function address of cxl_nvb_update_state() from a previous load of the module, not the current address. Fix that by arranging for ->state_work in the 'struct cxl_nvdimm_bridge' object to be reinitialized on cxl_pmem module reload. Details: Recall that CXL subsystem wants to link a CXL memory expander device to an NVDIMM sub-hierarchy when both a persistent memory range has been registered by the CXL platform driver (cxl_acpi) *and* when that CXL memory expander has published persistent memory capacity (Get Partition Info). To this end the cxl_nvdimm_bridge driver arranges to rescan the CXL bus when either of those conditions change. The helper bus_rescan_devices() can not be called underneath the device_lock() for any device on that bus, so the cxl_nvdimm_bridge driver uses a workqueue for the rescan. Typically a driver allocates driver data to hold a 'struct work_struct' for a driven device, but for a workqueue that may run after ->remove() returns, driver data will have been freed. The 'struct cxl_nvdimm_bridge' object holds the state and work_struct directly. Unfortunately it was only arranging for that infrastructure to be initialized once per device creation rather than the necessary once per workqueue (cxl_pmem_wq) creation. Introduce is_cxl_nvdimm_bridge() and cxl_nvdimm_bridge_reset() in support of invalidating stale references to a recently destroyed cxl_pmem_wq. Cc: <stable(a)vger.kernel.org> Fixes: 8fdcb1704f61 ("cxl/pmem: Add initial infrastructure for pmem support") Reported-by: Vishal Verma <vishal.l.verma(a)intel.com> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> --- drivers/cxl/core/pmem.c | 8 +++++++- drivers/cxl/cxl.h | 8 ++++++++ drivers/cxl/pmem.c | 29 +++++++++++++++++++++++++++-- 3 files changed, 42 insertions(+), 3 deletions(-) diff --git a/drivers/cxl/core/pmem.c b/drivers/cxl/core/pmem.c index 76a4fa39834c..cc402cb7a905 100644 --- a/drivers/cxl/core/pmem.c +++ b/drivers/cxl/core/pmem.c @@ -51,10 +51,16 @@ struct cxl_nvdimm_bridge *to_cxl_nvdimm_bridge(struct device *dev) } EXPORT_SYMBOL_NS_GPL(to_cxl_nvdimm_bridge, CXL); -__mock int match_nvdimm_bridge(struct device *dev, const void *data) +bool is_cxl_nvdimm_bridge(struct device *dev) { return dev->type == &cxl_nvdimm_bridge_type; } +EXPORT_SYMBOL_NS_GPL(is_cxl_nvdimm_bridge, CXL); + +__mock int match_nvdimm_bridge(struct device *dev, const void *data) +{ + return is_cxl_nvdimm_bridge(dev); +} struct cxl_nvdimm_bridge *cxl_find_nvdimm_bridge(struct cxl_nvdimm *cxl_nvd) { diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h index 5e2e93451928..ca979ee11017 100644 --- a/drivers/cxl/cxl.h +++ b/drivers/cxl/cxl.h @@ -221,6 +221,13 @@ struct cxl_decoder { }; +/** + * enum cxl_nvdimm_brige_state - state machine for managing bus rescans + * @CXL_NVB_NEW: Set at bridge create and after cxl_pmem_wq is destroyed + * @CXL_NVB_DEAD: Set at brige unregistration to preclude async probing + * @CXL_NVB_ONLINE: Target state after successful ->probe() + * @CXL_NVB_OFFLINE: Target state after ->remove() or failed ->probe() + */ enum cxl_nvdimm_brige_state { CXL_NVB_NEW, CXL_NVB_DEAD, @@ -333,6 +340,7 @@ struct cxl_nvdimm_bridge *devm_cxl_add_nvdimm_bridge(struct device *host, struct cxl_port *port); struct cxl_nvdimm *to_cxl_nvdimm(struct device *dev); bool is_cxl_nvdimm(struct device *dev); +bool is_cxl_nvdimm_bridge(struct device *dev); int devm_cxl_add_nvdimm(struct device *host, struct cxl_memdev *cxlmd); struct cxl_nvdimm_bridge *cxl_find_nvdimm_bridge(struct cxl_nvdimm *cxl_nvd); diff --git a/drivers/cxl/pmem.c b/drivers/cxl/pmem.c index 17e82ae90456..b65a272a2d6d 100644 --- a/drivers/cxl/pmem.c +++ b/drivers/cxl/pmem.c @@ -315,6 +315,31 @@ static struct cxl_driver cxl_nvdimm_bridge_driver = { .id = CXL_DEVICE_NVDIMM_BRIDGE, }; +/* + * Return all bridges to the CXL_NVB_NEW state to invalidate any + * ->state_work referring to the now destroyed cxl_pmem_wq. + */ +static int cxl_nvdimm_bridge_reset(struct device *dev, void *data) +{ + struct cxl_nvdimm_bridge *cxl_nvb; + + if (!is_cxl_nvdimm_bridge(dev)) + return 0; + + cxl_nvb = to_cxl_nvdimm_bridge(dev); + device_lock(dev); + cxl_nvb->state = CXL_NVB_NEW; + device_unlock(dev); + + return 0; +} + +static void destroy_cxl_pmem_wq(void) +{ + destroy_workqueue(cxl_pmem_wq); + bus_for_each_dev(&cxl_bus_type, NULL, NULL, cxl_nvdimm_bridge_reset); +} + static __init int cxl_pmem_init(void) { int rc; @@ -340,7 +365,7 @@ static __init int cxl_pmem_init(void) err_nvdimm: cxl_driver_unregister(&cxl_nvdimm_bridge_driver); err_bridge: - destroy_workqueue(cxl_pmem_wq); + destroy_cxl_pmem_wq(); return rc; } @@ -348,7 +373,7 @@ static __exit void cxl_pmem_exit(void) { cxl_driver_unregister(&cxl_nvdimm_driver); cxl_driver_unregister(&cxl_nvdimm_bridge_driver); - destroy_workqueue(cxl_pmem_wq); + destroy_cxl_pmem_wq(); } MODULE_LICENSE("GPL v2");

3 years, 1 month

2
1
0 0

[PATCH 1/4] KVM: arm64: Extract ESR_ELx.EC only

by Marc Zyngier

From: Mark Rutland <mark.rutland(a)arm.com> Since ARMv8.0 the upper 32 bits of ESR_ELx have been RES0, and recently some of the upper bits gained a meaning and can be non-zero. For example, when FEAT_LS64 is implemented, ESR_ELx[36:32] contain ISS2, which for an ST64BV or ST64BV0 can be non-zero. This can be seen in ARM DDI 0487G.b, page D13-3145, section D13.2.37. Generally, we must not rely on RES0 bit remaining zero in future, and when extracting ESR_ELx.EC we must mask out all other bits. All C code uses the ESR_ELx_EC() macro, which masks out the irrelevant bits, and therefore no alterations are required to C code to avoid consuming irrelevant bits. In a couple of places the KVM assembly extracts ESR_ELx.EC using LSR on an X register, and so could in theory consume previously RES0 bits. In both cases this is for comparison with EC values ESR_ELx_EC_HVC32 and ESR_ELx_EC_HVC64, for which the upper bits of ESR_ELx must currently be zero, but this could change in future. This patch adjusts the KVM vectors to use UBFX rather than LSR to extract ESR_ELx.EC, ensuring these are robust to future additions to ESR_ELx. Cc: stable(a)vger.kernel.org Signed-off-by: Mark Rutland <mark.rutland(a)arm.com> Cc: Alexandru Elisei <alexandru.elisei(a)arm.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: James Morse <james.morse(a)arm.com> Cc: Marc Zyngier <maz(a)kernel.org> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Will Deacon <will(a)kernel.org> Acked-by: Will Deacon <will(a)kernel.org> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Link: https://lore.kernel.org/r/20211103110545.4613-1-mark.rutland@arm.com --- arch/arm64/include/asm/esr.h | 1 + arch/arm64/kvm/hyp/hyp-entry.S | 2 +- arch/arm64/kvm/hyp/nvhe/host.S | 2 +- 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h index 29f97eb3dad4..8f59bbeba7a7 100644 --- a/arch/arm64/include/asm/esr.h +++ b/arch/arm64/include/asm/esr.h @@ -68,6 +68,7 @@ #define ESR_ELx_EC_MAX (0x3F) #define ESR_ELx_EC_SHIFT (26) +#define ESR_ELx_EC_WIDTH (6) #define ESR_ELx_EC_MASK (UL(0x3F) << ESR_ELx_EC_SHIFT) #define ESR_ELx_EC(esr) (((esr) & ESR_ELx_EC_MASK) >> ESR_ELx_EC_SHIFT) diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S index 9aa9b73475c9..b6b6801d96d5 100644 --- a/arch/arm64/kvm/hyp/hyp-entry.S +++ b/arch/arm64/kvm/hyp/hyp-entry.S @@ -44,7 +44,7 @@ el1_sync: // Guest trapped into EL2 mrs x0, esr_el2 - lsr x0, x0, #ESR_ELx_EC_SHIFT + ubfx x0, x0, #ESR_ELx_EC_SHIFT, #ESR_ELx_EC_WIDTH cmp x0, #ESR_ELx_EC_HVC64 ccmp x0, #ESR_ELx_EC_HVC32, #4, ne b.ne el1_trap diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S index 0c6116d34e18..3d613e721a75 100644 --- a/arch/arm64/kvm/hyp/nvhe/host.S +++ b/arch/arm64/kvm/hyp/nvhe/host.S @@ -141,7 +141,7 @@ SYM_FUNC_END(__host_hvc) .L__vect_start\@: stp x0, x1, [sp, #-16]! mrs x0, esr_el2 - lsr x0, x0, #ESR_ELx_EC_SHIFT + ubfx x0, x0, #ESR_ELx_EC_SHIFT, #ESR_ELx_EC_WIDTH cmp x0, #ESR_ELx_EC_HVC64 b.eq __host_hvc b __host_exit -- 2.30.2

3 years, 1 month

1
0
0 0

[RFC 01/19] KVM: x86/mmu: Fix TLB flush range when handling disconnected pt

by Ben Gardon

When recursively clearing out disconnected pts, the range based TLB flush in handle_removed_tdp_mmu_page uses the wrong starting GFN, resulting in the flush mostly missing the affected range. Fix this by using base_gfn for the flush. Fixes: a066e61f13cf ("KVM: x86/mmu: Factor out handling of removed page tables") CC: stable(a)vger.kernel.org Signed-off-by: Ben Gardon <bgardon(a)google.com> --- arch/x86/kvm/mmu/tdp_mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c index 7c5dd83e52de..866c2b191e1e 100644 --- a/arch/x86/kvm/mmu/tdp_mmu.c +++ b/arch/x86/kvm/mmu/tdp_mmu.c @@ -374,7 +374,7 @@ static void handle_removed_tdp_mmu_page(struct kvm *kvm, tdp_ptep_t pt, shared); } - kvm_flush_remote_tlbs_with_address(kvm, gfn, + kvm_flush_remote_tlbs_with_address(kvm, base_gfn, KVM_PAGES_PER_HPAGE(level + 1)); call_rcu(&sp->rcu_head, tdp_mmu_free_sp_rcu_callback); -- 2.34.0.rc0.344.g81b53c2807-goog

3 years, 1 month

2
1
0 0

[5.15 REGRESSION] iomap: Fix inline extent handling in iomap_readpage

by Andreas Gruenbacher

When reporting IOMAP_INLINE extents, filesystems set iomap->length to the length of iomap->inline_data. For reading that into the page cache, function iomap_read_inline_data copies the inline data, zeroes out the rest of the page, and marks the entire page up-to-date. Before commit 740499c78408 ("iomap: fix the iomap_readpage_actor return value for inline data"), when hitting an IOMAP_INLINE extent, iomap_readpage_actor would report having read the entire page. Since then, it only reports having read the inline data (iomap->length). This will force iomap_readpage into another iteration, and the filesystem will report an unaligned hole after the IOMAP_INLINE extent. But iomap_readpage_actor (now iomap_readpage_iter) isn't prepared to deal with unaligned extents, it will get things wrong on filesystems with a block size smaller than the page size, and we'll eventually run into the following warning in iomap_iter_advance: WARN_ON_ONCE(iter->processed > iomap_length(iter)); Fix that by changing iomap_readpage_iter back to report that we've read the entire page, which avoids having to deal with unaligned extents. To prevent iomap from complaining about running past the end of the extent, fix up the extent size as well. Fixes: 740499c78408 ("iomap: fix the iomap_readpage_actor return value for inline data") Cc: stable(a)vger.kernel.org # v5.15+ Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com> --- fs/iomap/buffered-io.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index 1753c26c8e76..de3fcd2522a2 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -244,10 +244,10 @@ static inline bool iomap_block_needs_zeroing(const struct iomap_iter *iter, pos >= i_size_read(iter->inode); } -static loff_t iomap_readpage_iter(const struct iomap_iter *iter, +static loff_t iomap_readpage_iter(struct iomap_iter *iter, struct iomap_readpage_ctx *ctx, loff_t offset) { - const struct iomap *iomap = &iter->iomap; + struct iomap *iomap = &iter->iomap; loff_t pos = iter->pos + offset; loff_t length = iomap_length(iter) - offset; struct page *page = ctx->cur_page; @@ -256,8 +256,15 @@ static loff_t iomap_readpage_iter(const struct iomap_iter *iter, unsigned poff, plen; sector_t sector; - if (iomap->type == IOMAP_INLINE) - return min(iomap_read_inline_data(iter, page), length); + if (iomap->type == IOMAP_INLINE) { + /* + * The filesystem sets iomap->length to the size of the inline + * data. We're at the end of the file, so we know that the + * rest of the page needs to be zeroed out. + */ + iomap->length = iomap_read_inline_data(iter, page); + return iomap->length; + } /* zero post-eof blocks as the page may be mapped */ iop = iomap_page_create(iter->inode, page); @@ -352,7 +359,7 @@ iomap_readpage(struct page *page, const struct iomap_ops *ops) } EXPORT_SYMBOL_GPL(iomap_readpage); -static loff_t iomap_readahead_iter(const struct iomap_iter *iter, +static loff_t iomap_readahead_iter(struct iomap_iter *iter, struct iomap_readpage_ctx *ctx) { loff_t length = iomap_length(iter); -- 2.31.1

3 years, 1 month

3
4
0 0

regression with mainline kernel

by Sudip Mukherjee

Hi Linus, My testing has been failing for the last few days. Last good test was with 6f2b76a4a384 and I started seeing the failure with ce840177930f5 where boot timeout. Last good test - https://openqa.qa.codethink.co.uk/tests/323 Failing test - https://openqa.qa.codethink.co.uk/tests/335 Saw a similar issue with 5.10.79-rc1 today and bisect showed the problem with 8615ff6dd1ac but that was already in the last good test I had. I will do a bisect tonight and let you know the result. -- Regards Sudip

3 years, 2 months

1
0
0 0

[PATCH] spi: fix use-after-free of the add_lock mutex

by Michael Walle

Commit 6098475d4cb4 ("spi: Fix deadlock when adding SPI controllers on SPI buses") introduced a per-controller mutex. But mutex_unlock() of said lock is called after the controller is already freed: spi_unregister_controller(ctlr) -> put_device(&ctlr->dev) -> spi_controller_release(dev) -> mutex_unlock(&ctrl->add_lock) Move the put_device() after the mutex_unlock(). Fixes: 6098475d4cb4 ("spi: Fix deadlock when adding SPI controllers on SPI buses") Signed-off-by: Michael Walle <michael(a)walle.cc> Reviewed-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Reviewed-by: Lukas Wunner <lukas(a)wunner.de> Cc: stable(a)vger.kernel.org # v5.15 --- changes since RFC: - fix call graph indendation in commit message drivers/spi/spi.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index b23e675953e1..fdd530b150a7 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -3099,12 +3099,6 @@ void spi_unregister_controller(struct spi_controller *ctlr) device_del(&ctlr->dev); - /* Release the last reference on the controller if its driver - * has not yet been converted to devm_spi_alloc_master/slave(). - */ - if (!ctlr->devm_allocated) - put_device(&ctlr->dev); - /* free bus id */ mutex_lock(&board_lock); if (found == ctlr) @@ -3113,6 +3107,12 @@ void spi_unregister_controller(struct spi_controller *ctlr) if (IS_ENABLED(CONFIG_SPI_DYNAMIC)) mutex_unlock(&ctlr->add_lock); + + /* Release the last reference on the controller if its driver + * has not yet been converted to devm_spi_alloc_master/slave(). + */ + if (!ctlr->devm_allocated) + put_device(&ctlr->dev); } EXPORT_SYMBOL_GPL(spi_unregister_controller); -- 2.30.2

3 years, 2 months

2
3
0 0

Re: [PATCH] hostfs: Fix writeback of dirty pages

by Christopher Obbard

Hi Sjoerd, On 05/11/2021 08:10, Sjoerd Simons wrote: > Hostfs was not setting up the backing device information, which means it > uses the noop bdi. The noop bdi does not have the writeback capability > enabled, which in turns means dirty pages never got written back to > storage. > > In other words programs using mmap to write to files on hostfs never > actually got their data written out... > > Fix this by simply setting up the bdi with default settings as all the > required code for writeback is already in place. > > Signed-off-by: Sjoerd Simons <sjoerd(a)collabora.com> Cc: stable(a)vger.kernel.org Reviewed-by: Christopher Obbard <chris.obbard(a)collabora.com> ...replying mainly as I wonder if adding the stable tag in a reply will make the patch appear in stable (obviously once it is in mainline) ? :-) > > --- > > fs/hostfs/hostfs_kern.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/hostfs/hostfs_kern.c b/fs/hostfs/hostfs_kern.c > index d5c9d886cd9f..ef481c3d9019 100644 > --- a/fs/hostfs/hostfs_kern.c > +++ b/fs/hostfs/hostfs_kern.c > @@ -924,6 +924,9 @@ static int hostfs_fill_sb_common(struct super_block *sb, void *d, int silent) > sb->s_op = &hostfs_sbops; > sb->s_d_op = &simple_dentry_operations; > sb->s_maxbytes = MAX_LFS_FILESIZE; > + err = super_setup_bdi(sb); > + if (err) > + goto out; > > /* NULL is printed as '(null)' by printf(): avoid that. */ > if (req_root == NULL) >

3 years, 2 months

1
0
0 0

[PATCH v3] fbdev: Prevent probing generic drivers if a FB is already registered

by Javier Martinez Canillas

The efifb and simplefb drivers just render to a pre-allocated frame buffer and rely on the display hardware being initialized before the kernel boots. But if another driver already probed correctly and registered a fbdev, the generic drivers shouldn't be probed since an actual driver for the display hardware is already present. This is more likely to occur after commit d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers support") since the "efi-framebuffer" and "simple-framebuffer" platform devices are registered at a later time. Link: https://lore.kernel.org/r/20211110200253.rfudkt3edbd3nsyj@lahvuun/ Fixes: d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers support") Reported-by: Ilya Trukhanov <lahvuun(a)gmail.com> Cc: <stable(a)vger.kernel.org> # 5.15.x Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- Changes in v3: - Cc <stable(a)vger.kernel.org> since a Fixes: tag is not enough (gregkh). Changes in v2: - Add a Link: tag with a reference to the bug report (Thorsten Leemhuis). - Add a comment explaining why the probe fails earlier (Daniel Vetter). - Add a Fixes: tag for stable to pick the fix (Daniel Vetter). - Add Daniel Vetter's Reviewed-by: tag. - Improve the commit message and mention the culprit commit drivers/video/fbdev/efifb.c | 11 +++++++++++ drivers/video/fbdev/simplefb.c | 11 +++++++++++ 2 files changed, 22 insertions(+) diff --git drivers/video/fbdev/efifb.c drivers/video/fbdev/efifb.c index edca3703b964..ea42ba6445b2 100644 --- drivers/video/fbdev/efifb.c +++ drivers/video/fbdev/efifb.c @@ -351,6 +351,17 @@ static int efifb_probe(struct platform_device *dev) char *option = NULL; efi_memory_desc_t md; + /* + * Generic drivers must not be registered if a framebuffer exists. + * If a native driver was probed, the display hardware was already + * taken and attempting to use the system framebuffer is dangerous. + */ + if (num_registered_fb > 0) { + dev_err(&dev->dev, + "efifb: a framebuffer is already registered\n"); + return -EINVAL; + } + if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled) return -ENODEV; diff --git drivers/video/fbdev/simplefb.c drivers/video/fbdev/simplefb.c index 62f0ded70681..b63074fd892e 100644 --- drivers/video/fbdev/simplefb.c +++ drivers/video/fbdev/simplefb.c @@ -407,6 +407,17 @@ static int simplefb_probe(struct platform_device *pdev) struct simplefb_par *par; struct resource *mem; + /* + * Generic drivers must not be registered if a framebuffer exists. + * If a native driver was probed, the display hardware was already + * taken and attempting to use the system framebuffer is dangerous. + */ + if (num_registered_fb > 0) { + dev_err(&pdev->dev, + "simplefb: a framebuffer is already registered\n"); + return -EINVAL; + } + if (fb_get_options("simplefb", NULL)) return -ENODEV; -- 2.33.1

3 years, 2 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2021