December 2021 - Linux-stable-mirror

[PATCH 5.4] KVM: x86: Ignore sparse banks size for an "all CPUs", non-sparse IPI req

by Vitaly Kuznetsov

From: Sean Christopherson <seanjc(a)google.com> commit 3244867af8c065e51969f1bffe732d3ebfd9a7d2 upstream. Do not bail early if there are no bits set in the sparse banks for a non-sparse, a.k.a. "all CPUs", IPI request. Per the Hyper-V spec, it is legal to have a variable length of '0', e.g. VP_SET's BankContents in this case, if the request can be serviced without the extra info. It is possible that for a given invocation of a hypercall that does accept variable sized input headers that all the header input fits entirely within the fixed size header. In such cases the variable sized input header is zero-sized and the corresponding bits in the hypercall input should be set to zero. Bailing early results in KVM failing to send IPIs to all CPUs as expected by the guest. Fixes: 214ff83d4473 ("KVM: x86: hyperv: implement PV IPI send hypercalls") Cc: stable(a)vger.kernel.org Signed-off-by: Sean Christopherson <seanjc(a)google.com> Reviewed-by: Vitaly Kuznetsov <vkuznets(a)redhat.com> Message-Id: <20211207220926.718794-2-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets(a)redhat.com> --- arch/x86/kvm/hyperv.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c index 26408434b9bc..be92e8dccda3 100644 --- a/arch/x86/kvm/hyperv.c +++ b/arch/x86/kvm/hyperv.c @@ -1501,11 +1501,13 @@ static u64 kvm_hv_send_ipi(struct kvm_vcpu *current_vcpu, u64 ingpa, u64 outgpa, all_cpus = send_ipi_ex.vp_set.format == HV_GENERIC_SET_ALL; + if (all_cpus) + goto check_and_send_ipi; + if (!sparse_banks_len) goto ret_success; - if (!all_cpus && - kvm_read_guest(kvm, + if (kvm_read_guest(kvm, ingpa + offsetof(struct hv_send_ipi_ex, vp_set.bank_contents), sparse_banks, @@ -1513,6 +1515,7 @@ static u64 kvm_hv_send_ipi(struct kvm_vcpu *current_vcpu, u64 ingpa, u64 outgpa, return HV_STATUS_INVALID_HYPERCALL_INPUT; } +check_and_send_ipi: if ((vector < HV_IPI_LOW_VECTOR) || (vector > HV_IPI_HIGH_VECTOR)) return HV_STATUS_INVALID_HYPERCALL_INPUT; -- 2.33.1

3 years

1
0
0 0

[PATCH 5.10 0/5] memblock, arm: fixes for freeing of the memory map

by Mark-PK Tsai

When linux memory is not aligned with page block size and have hole in zone, the 5.4-lts arm kernel might crash in move_freepages() as Kefen Wang reported in [1]. Backport the upstream fix commits by Mike Rapoport [2] to 5.4 can fix this issue. And free_unused_memmap() of arm and arm64 are moved to generic mm/memblock in the below upstream commit, so I applied the first two patches to free_unused_memmap() in arch/arm/mm/init.c. (4f5b0c178996 arm, arm64: move free_unused_memmap() to generic mm) [1] https://lore.kernel.org/lkml/2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.co… [2] https://lore.kernel.org/lkml/20210630071211.21011-1-rppt@kernel.org/#t Mike Rapoport (5): memblock: free_unused_memmap: use pageblock units instead of MAX_ORDER memblock: align freed memory map on pageblock boundaries with SPARSEMEM memblock: ensure there is no overflow in memblock_overlaps_region() arm: extend pfn_valid to take into account freed memory map alignment arm: ioremap: don't abuse pfn_valid() to check if pfn is in RAM arch/arm/mm/init.c | 37 +++++++++++++++++++++++++------------ arch/arm/mm/ioremap.c | 4 +++- mm/memblock.c | 3 ++- 3 files changed, 30 insertions(+), 14 deletions(-) -- 2.18.0

3 years

1
5
0 0

[PATCH v2] x86/setup: call early_reserve_memory() earlier

by Juergen Gross

Commit a799c2bd29d19c565 ("x86/setup: Consolidate early memory reservations") introduced early_reserve_memory() to do all needed initial memblock_reserve() calls in one function. Unfortunately the call of early_reserve_memory() is done too late for Xen dom0, as in some cases a Xen hook called by e820__memory_setup() will need those memory reservations to have happened already. Move the call of early_reserve_memory() before the call of e820__memory_setup() in order to avoid such problems. Cc: stable(a)vger.kernel.org Fixes: a799c2bd29d19c565 ("x86/setup: Consolidate early memory reservations") Reported-by: Marek Marczykowski-Górecki <marmarek(a)invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross(a)suse.com> --- V2: - update comment (Jan Beulich, Boris Petkov) - move call down in setup_arch() (Mike Galbraith) --- arch/x86/kernel/setup.c | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 79f164141116..40ed44ead063 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -830,6 +830,20 @@ void __init setup_arch(char **cmdline_p) x86_init.oem.arch_setup(); + /* + * Do some memory reservations *before* memory is added to memblock, so + * memblock allocations won't overwrite it. + * + * After this point, everything still needed from the boot loader or + * firmware or kernel text should be early reserved or marked not RAM in + * e820. All other memory is free game. + * + * This call needs to happen before e820__memory_setup() which calls the + * xen_memory_setup() on Xen dom0 which relies on the fact that those + * early reservations have happened already. + */ + early_reserve_memory(); + iomem_resource.end = (1ULL << boot_cpu_data.x86_phys_bits) - 1; e820__memory_setup(); parse_setup_data(); @@ -876,18 +890,6 @@ void __init setup_arch(char **cmdline_p) parse_early_param(); - /* - * Do some memory reservations *before* memory is added to - * memblock, so memblock allocations won't overwrite it. - * Do it after early param, so we could get (unlikely) panic from - * serial. - * - * After this point everything still needed from the boot loader or - * firmware or kernel text should be early reserved or marked not - * RAM in e820. All other memory is free game. - */ - early_reserve_memory(); - #ifdef CONFIG_MEMORY_HOTPLUG /* * Memory used by the kernel cannot be hot-removed because Linux -- 2.26.2

3 years

12
24
0 0

FAILED: patch "[PATCH] btrfs: zoned: clear data relocation bg on zone finish" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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 5911f5382022aff2b817cb88f276756af229664d Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> Date: Thu, 2 Dec 2021 00:47:14 -0800 Subject: [PATCH] btrfs: zoned: clear data relocation bg on zone finish When finishing a zone that is used by a dedicated data relocation block group, also remove its reference from fs_info, so we're not trying to use a full block group for allocations during data relocation, which will always fail. The result is we're not making any forward progress and end up in a deadlock situation. Fixes: c2707a255623 ("btrfs: zoned: add a dedicated data relocation block group") Reviewed-by: Naohiro Aota <naohiro.aota(a)wdc.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c index 67d932d70798..678a29469511 100644 --- a/fs/btrfs/zoned.c +++ b/fs/btrfs/zoned.c @@ -1860,6 +1860,7 @@ int btrfs_zone_finish(struct btrfs_block_group *block_group) block_group->alloc_offset = block_group->zone_capacity; block_group->free_space_ctl->free_space = 0; btrfs_clear_treelog_bg(block_group); + btrfs_clear_data_reloc_bg(block_group); spin_unlock(&block_group->lock); ret = blkdev_zone_mgmt(device->bdev, REQ_OP_ZONE_FINISH, @@ -1942,6 +1943,7 @@ void btrfs_zone_finish_endio(struct btrfs_fs_info *fs_info, u64 logical, u64 len ASSERT(block_group->alloc_offset == block_group->zone_capacity); ASSERT(block_group->free_space_ctl->free_space == 0); btrfs_clear_treelog_bg(block_group); + btrfs_clear_data_reloc_bg(block_group); spin_unlock(&block_group->lock); map = block_group->physical_map;

3 years

2
3
0 0

[PATCH 5.10 0/5] aio poll fixes for 5.10

by Eric Biggers

Backport the aio poll fixes to 5.10. This resolves a conflict in aio_poll_wake() in patch 4. It's a "trivial" conflict, but I'm sending this to make sure it doesn't get dropped. Eric Biggers (5): wait: add wake_up_pollfree() binder: use wake_up_pollfree() signalfd: use wake_up_pollfree() aio: keep poll requests on waitqueue until completed aio: fix use-after-free due to missing POLLFREE handling drivers/android/binder.c | 21 ++-- fs/aio.c | 184 ++++++++++++++++++++++++++------ fs/signalfd.c | 12 +-- include/linux/wait.h | 26 +++++ include/uapi/asm-generic/poll.h | 2 +- kernel/sched/wait.c | 7 ++ 6 files changed, 195 insertions(+), 57 deletions(-) -- 2.34.1

3 years

2
8
0 0

FAILED: patch "[PATCH] iio: adc: stm32: fix a current leak by resetting pcsel before" 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 f711f28e71e965c0d1141c830fa7131b41abbe75 Mon Sep 17 00:00:00 2001 From: Fabrice Gasnier <fabrice.gasnier(a)foss.st.com> Date: Fri, 22 Oct 2021 14:19:29 +0200 Subject: [PATCH] iio: adc: stm32: fix a current leak by resetting pcsel before disabling vdda Some I/Os are connected to ADC input channels, when the corresponding bit in PCSEL register are set on STM32H7 and STM32MP15. This is done in the prepare routine of stm32-adc driver. There are constraints here, as PCSEL shouldn't be set when VDDA supply is disabled. Enabling/disabling of VDDA supply in done via stm32-adc-core runtime PM routines (before/after ADC is enabled/disabled). Currently, PCSEL remains set when disabling ADC. Later on, PM runtime can disable the VDDA supply. This creates some conditions on I/Os that can start to leak current. So PCSEL needs to be cleared when disabling the ADC. Fixes: 95e339b6e85d ("iio: adc: stm32: add support for STM32H7") Signed-off-by: Fabrice Gasnier <fabrice.gasnier(a)foss.st.com> Reviewed-by: Olivier Moysan <olivier.moysan(a)foss.st.com> Link: https://lore.kernel.org/r/1634905169-23762-1-git-send-email-fabrice.gasnier… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c index 6245434f8377..60f2ccf7e342 100644 --- a/drivers/iio/adc/stm32-adc.c +++ b/drivers/iio/adc/stm32-adc.c @@ -1117,6 +1117,7 @@ static void stm32h7_adc_unprepare(struct iio_dev *indio_dev) { struct stm32_adc *adc = iio_priv(indio_dev); + stm32_adc_writel(adc, STM32H7_ADC_PCSEL, 0); stm32h7_adc_disable(indio_dev); stm32_adc_int_ch_disable(adc); stm32h7_adc_enter_pwr_down(adc);

3 years

1
0
0 0

FAILED: patch "[PATCH] iio: adc: stm32: fix a current leak by resetting pcsel before" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-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 f711f28e71e965c0d1141c830fa7131b41abbe75 Mon Sep 17 00:00:00 2001 From: Fabrice Gasnier <fabrice.gasnier(a)foss.st.com> Date: Fri, 22 Oct 2021 14:19:29 +0200 Subject: [PATCH] iio: adc: stm32: fix a current leak by resetting pcsel before disabling vdda Some I/Os are connected to ADC input channels, when the corresponding bit in PCSEL register are set on STM32H7 and STM32MP15. This is done in the prepare routine of stm32-adc driver. There are constraints here, as PCSEL shouldn't be set when VDDA supply is disabled. Enabling/disabling of VDDA supply in done via stm32-adc-core runtime PM routines (before/after ADC is enabled/disabled). Currently, PCSEL remains set when disabling ADC. Later on, PM runtime can disable the VDDA supply. This creates some conditions on I/Os that can start to leak current. So PCSEL needs to be cleared when disabling the ADC. Fixes: 95e339b6e85d ("iio: adc: stm32: add support for STM32H7") Signed-off-by: Fabrice Gasnier <fabrice.gasnier(a)foss.st.com> Reviewed-by: Olivier Moysan <olivier.moysan(a)foss.st.com> Link: https://lore.kernel.org/r/1634905169-23762-1-git-send-email-fabrice.gasnier… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c index 6245434f8377..60f2ccf7e342 100644 --- a/drivers/iio/adc/stm32-adc.c +++ b/drivers/iio/adc/stm32-adc.c @@ -1117,6 +1117,7 @@ static void stm32h7_adc_unprepare(struct iio_dev *indio_dev) { struct stm32_adc *adc = iio_priv(indio_dev); + stm32_adc_writel(adc, STM32H7_ADC_PCSEL, 0); stm32h7_adc_disable(indio_dev); stm32_adc_int_ch_disable(adc); stm32h7_adc_enter_pwr_down(adc);

3 years

1
0
0 0

FAILED: patch "[PATCH] iio: adc: stm32: fix a current leak by resetting pcsel before" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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 f711f28e71e965c0d1141c830fa7131b41abbe75 Mon Sep 17 00:00:00 2001 From: Fabrice Gasnier <fabrice.gasnier(a)foss.st.com> Date: Fri, 22 Oct 2021 14:19:29 +0200 Subject: [PATCH] iio: adc: stm32: fix a current leak by resetting pcsel before disabling vdda Some I/Os are connected to ADC input channels, when the corresponding bit in PCSEL register are set on STM32H7 and STM32MP15. This is done in the prepare routine of stm32-adc driver. There are constraints here, as PCSEL shouldn't be set when VDDA supply is disabled. Enabling/disabling of VDDA supply in done via stm32-adc-core runtime PM routines (before/after ADC is enabled/disabled). Currently, PCSEL remains set when disabling ADC. Later on, PM runtime can disable the VDDA supply. This creates some conditions on I/Os that can start to leak current. So PCSEL needs to be cleared when disabling the ADC. Fixes: 95e339b6e85d ("iio: adc: stm32: add support for STM32H7") Signed-off-by: Fabrice Gasnier <fabrice.gasnier(a)foss.st.com> Reviewed-by: Olivier Moysan <olivier.moysan(a)foss.st.com> Link: https://lore.kernel.org/r/1634905169-23762-1-git-send-email-fabrice.gasnier… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c index 6245434f8377..60f2ccf7e342 100644 --- a/drivers/iio/adc/stm32-adc.c +++ b/drivers/iio/adc/stm32-adc.c @@ -1117,6 +1117,7 @@ static void stm32h7_adc_unprepare(struct iio_dev *indio_dev) { struct stm32_adc *adc = iio_priv(indio_dev); + stm32_adc_writel(adc, STM32H7_ADC_PCSEL, 0); stm32h7_adc_disable(indio_dev); stm32_adc_int_ch_disable(adc); stm32h7_adc_enter_pwr_down(adc);

3 years

1
0
0 0

FAILED: patch "[PATCH] iio: trigger: Fix reference counting" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-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 a827a4984664308f13599a0b26c77018176d0c7c Mon Sep 17 00:00:00 2001 From: Lars-Peter Clausen <lars(a)metafoo.de> Date: Sun, 24 Oct 2021 11:27:00 +0200 Subject: [PATCH] iio: trigger: Fix reference counting MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In viio_trigger_alloc() device_initialize() is used to set the initial reference count of the trigger to 1. Then another get_device() is called on trigger. This sets the reference count to 2 before the trigger is returned. iio_trigger_free(), which is the matching API to viio_trigger_alloc(), calls put_device() which decreases the reference count by 1. But the second reference count acquired in viio_trigger_alloc() is never dropped. As a result the iio_trigger_release() function is never called and the memory associated with the trigger is never freed. Since there is no reason for the trigger to start its lifetime with two reference counts just remove the extra get_device() in viio_trigger_alloc(). Fixes: 5f9c035cae18 ("staging:iio:triggers. Add a reference get to the core for triggers.") Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> Acked-by: Nuno Sá <nuno.sa(a)analog.com> Link: https://lore.kernel.org/r/20211024092700.6844-2-lars@metafoo.de Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c index b23caa2f2aa1..93990ff1dfe3 100644 --- a/drivers/iio/industrialio-trigger.c +++ b/drivers/iio/industrialio-trigger.c @@ -556,7 +556,6 @@ struct iio_trigger *viio_trigger_alloc(struct device *parent, irq_modify_status(trig->subirq_base + i, IRQ_NOREQUEST | IRQ_NOAUTOEN, IRQ_NOPROBE); } - get_device(&trig->dev); return trig;

3 years

1
0
0 0

FAILED: patch "[PATCH] iio: trigger: Fix reference counting" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-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 a827a4984664308f13599a0b26c77018176d0c7c Mon Sep 17 00:00:00 2001 From: Lars-Peter Clausen <lars(a)metafoo.de> Date: Sun, 24 Oct 2021 11:27:00 +0200 Subject: [PATCH] iio: trigger: Fix reference counting MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In viio_trigger_alloc() device_initialize() is used to set the initial reference count of the trigger to 1. Then another get_device() is called on trigger. This sets the reference count to 2 before the trigger is returned. iio_trigger_free(), which is the matching API to viio_trigger_alloc(), calls put_device() which decreases the reference count by 1. But the second reference count acquired in viio_trigger_alloc() is never dropped. As a result the iio_trigger_release() function is never called and the memory associated with the trigger is never freed. Since there is no reason for the trigger to start its lifetime with two reference counts just remove the extra get_device() in viio_trigger_alloc(). Fixes: 5f9c035cae18 ("staging:iio:triggers. Add a reference get to the core for triggers.") Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> Acked-by: Nuno Sá <nuno.sa(a)analog.com> Link: https://lore.kernel.org/r/20211024092700.6844-2-lars@metafoo.de Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c index b23caa2f2aa1..93990ff1dfe3 100644 --- a/drivers/iio/industrialio-trigger.c +++ b/drivers/iio/industrialio-trigger.c @@ -556,7 +556,6 @@ struct iio_trigger *viio_trigger_alloc(struct device *parent, irq_modify_status(trig->subirq_base + i, IRQ_NOREQUEST | IRQ_NOAUTOEN, IRQ_NOPROBE); } - get_device(&trig->dev); return trig;

3 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2021