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

[PATCH] DTS: ARM: gta04: remove legacy spi-cs-high to make display work again

by H. Nikolaus Schaller

This reverts commit f1f028ff89cb ("DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again") which had to be intruduced after commit 6953c57ab172 ("gpio: of: Handle SPI chipselect legacy bindings") broke the GTA04 display. This contradicted the data sheet but was the only way to get it as an spi client operational again. The panel data sheet defines the chip-select to be active low. Now, with the arrival of commit 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors") the logic of interaction between spi-cs-high and the gpio descriptor flags has been changed a second time, making the display broken again. So we have to remove the original fix which in retrospect was a workaround of a bug in the spi subsystem and not a feature of the panel or bug in the device tree. With this fix the device tree is back in sync with the data sheet and spi subsystem code. Fixes: 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors") CC: stable(a)vger.kernel.org Signed-off-by: H. Nikolaus Schaller <hns(a)goldelico.com> --- arch/arm/boot/dts/omap3-gta04.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi index c8745bc800f71..003202d129907 100644 --- a/arch/arm/boot/dts/omap3-gta04.dtsi +++ b/arch/arm/boot/dts/omap3-gta04.dtsi @@ -124,7 +124,6 @@ lcd: td028ttec1@0 { spi-max-frequency = <100000>; spi-cpol; spi-cpha; - spi-cs-high; backlight= <&backlight>; label = "lcd"; -- 2.26.2

4 years, 8 months

2
1
0 0

Re: Question for AMD patches

by Greg K-H

On Fri, Dec 18, 2020 at 05:18:16AM +0800, Young Hsieh wrote: > Hi Greg, > > Thanks. I am looking for the Essential, RAS & Perf patches for AMD Milan as follows: > I don't see anything here :( > I am not familiar the rules for stable kernel patches, can you help to elaborate ? Thanks for your assistance! :) Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for what stable kernels are all about. thanks, greg k-h

4 years, 8 months

1
0
0 0

+ kasan-fix-memory-leak-of-kasan-quarantine.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: kasan: fix memory leak of kasan quarantine has been added to the -mm tree. Its filename is kasan-fix-memory-leak-of-kasan-quarantine.patch This patch should soon appear at https://ozlabs.org/~akpm/mmots/broken-out/kasan-fix-memory-leak-of-kasan-qu… and later at https://ozlabs.org/~akpm/mmotm/broken-out/kasan-fix-memory-leak-of-kasan-qu… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Kuan-Ying Lee <Kuan-Ying.Lee(a)mediatek.com> Subject: kasan: fix memory leak of kasan quarantine When cpu is going offline, set q->offline as true and interrupt happened. The interrupt may call the quarantine_put. But quarantine_put do not free the the object. The object will cause memory leak. Add qlink_free() to free the object. Link: https://lkml.kernel.org/r/1608207487-30537-2-git-send-email-Kuan-Ying.Lee@m… Fixes: 6c82d45c7f03 (kasan: fix object remaining in offline per-cpu quarantine) Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee(a)mediatek.com> Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Cc: Alexander Potapenko <glider(a)google.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: Matthias Brugger <matthias.bgg(a)gmail.com> Cc: <stable(a)vger.kernel.org> [5.10-] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/kasan/quarantine.c | 1 + 1 file changed, 1 insertion(+) --- a/mm/kasan/quarantine.c~kasan-fix-memory-leak-of-kasan-quarantine +++ a/mm/kasan/quarantine.c @@ -191,6 +191,7 @@ void quarantine_put(struct kasan_free_me q = this_cpu_ptr(&cpu_quarantine); if (q->offline) { + qlink_free(&info->quarantine_link, cache); local_irq_restore(flags); return; } _ Patches currently in -mm which might be from Kuan-Ying.Lee(a)mediatek.com are kasan-fix-memory-leak-of-kasan-quarantine.patch

4 years, 8 months

1
0
0 0

Re: Question for AMD patches

by Sasha Levin

On Fri, Dec 18, 2020 at 07:34:07AM +0800, Young Hsieh wrote: >Hi Sasha, > >The other reason we are wondering if 5.4 has backporting is we are not very comfortable about using the bleeding edge. Do you think 5.10 is stable currently? Thanks for your help again. :) Hi Young, See https://www.kernel.org/releases.html for a list of the LTS branches. The 5.10 kernel is already designated as LTS and should be used by most stable tree users; this is the preferrable kernel to adopt right now. The AMD hardware enablement stuff won't be backported on top of 5.4. -- Thanks, Sasha

4 years, 8 months

1
0
0 0

Question for AMD patches

by Young Hsieh

Hello, This is Young Hsieh from Uber and currently I am in Uber infra team and in charge of server system design. Nice to e-meet you! :) We are working on AMD Milan platform with Debian, and notice there are some patches for performance and security improvements, which are not implemented in LTS kernels (4.14/4.19/5.4) yet. On our side, we prefer to use the general LTS kernel release instead of a customized kernel, in case we will not align on major fixes down the road. So would like to know if there is any plan to backport these patches and if so, what is the timeline? Thanks a lot again for any advice. Cheers, **************************************** Young Hsieh Uber Hardware Engineer ****************************************

4 years, 8 months

3
2
0 0

[PATCH 6/8] ext4: Fix deadlock with fs freezing and EA inodes

by Jan Kara

Xattr code using inodes with large xattr data can end up dropping last inode reference (and thus deleting the inode) from places like ext4_xattr_set_entry(). That function is called with transaction started and so ext4_evict_inode() can deadlock against fs freezing like: CPU1 CPU2 removexattr() freeze_super() vfs_removexattr() ext4_xattr_set() handle = ext4_journal_start() ... ext4_xattr_set_entry() iput(old_ea_inode) ext4_evict_inode(old_ea_inode) sb->s_writers.frozen = SB_FREEZE_FS; sb_wait_write(sb, SB_FREEZE_FS); ext4_freeze() jbd2_journal_lock_updates() -> blocks waiting for all handles to stop sb_start_intwrite() -> blocks as sb is already in SB_FREEZE_FS state Generally it is advisable to delete inodes from a separate transaction as it can consume quite some credits however in this case it would be quite clumsy and furthermore the credits for inode deletion are quite limited and already accounted for. So just tweak ext4_evict_inode() to avoid freeze protection if we have transaction already started and thus it is not really needed anyway. CC: stable(a)vger.kernel.org Fixes: dec214d00e0d ("ext4: xattr inode deduplication") CC: Tahsin Erdogan <tahsin(a)google.com> Signed-off-by: Jan Kara <jack(a)suse.cz> --- fs/ext4/inode.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 72534319fae5..777eb08b29cd 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -175,6 +175,7 @@ void ext4_evict_inode(struct inode *inode) */ int extra_credits = 6; struct ext4_xattr_inode_array *ea_inode_array = NULL; + bool freeze_protected = false; trace_ext4_evict_inode(inode); @@ -232,9 +233,14 @@ void ext4_evict_inode(struct inode *inode) /* * Protect us against freezing - iput() caller didn't have to have any - * protection against it + * protection against it. When we are in a running transaction though, + * we are already protected against freezing and we cannot grab further + * protection due to lock ordering constraints. */ - sb_start_intwrite(inode->i_sb); + if (!ext4_journal_current_handle()) { + sb_start_intwrite(inode->i_sb); + freeze_protected = true; + } if (!IS_NOQUOTA(inode)) extra_credits += EXT4_MAXQUOTAS_DEL_BLOCKS(inode->i_sb); @@ -253,7 +259,8 @@ void ext4_evict_inode(struct inode *inode) * cleaned up. */ ext4_orphan_del(NULL, inode); - sb_end_intwrite(inode->i_sb); + if (freeze_protected) + sb_end_intwrite(inode->i_sb); goto no_delete; } @@ -294,7 +301,8 @@ void ext4_evict_inode(struct inode *inode) stop_handle: ext4_journal_stop(handle); ext4_orphan_del(NULL, inode); - sb_end_intwrite(inode->i_sb); + if (freeze_protected) + sb_end_intwrite(inode->i_sb); ext4_xattr_inode_array_free(ea_inode_array); goto no_delete; } @@ -323,7 +331,8 @@ void ext4_evict_inode(struct inode *inode) else ext4_free_inode(handle, inode); ext4_journal_stop(handle); - sb_end_intwrite(inode->i_sb); + if (freeze_protected) + sb_end_intwrite(inode->i_sb); ext4_xattr_inode_array_free(ea_inode_array); return; no_delete: -- 2.16.4

4 years, 8 months

2
1
0 0

[PATCH 0/5] Backport of patch series for stable 4.4 branch

by SeongJae Park

From: SeongJae Park <sjpark(a)amazon.de> SeongJae Park (5): xen/xenbus: Allow watches discard events before queueing xen/xenbus: Add 'will_handle' callback support in xenbus_watch_path() xen/xenbus/xen_bus_type: Support will_handle watch callback xen/xenbus: Count pending messages for each watch xenbus/xenbus_backend: Disallow pending watch messages drivers/block/xen-blkback/xenbus.c | 3 +- drivers/net/xen-netback/xenbus.c | 4 ++- drivers/xen/xen-pciback/xenbus.c | 2 +- drivers/xen/xenbus/xenbus_client.c | 8 ++++- drivers/xen/xenbus/xenbus_probe.c | 1 + drivers/xen/xenbus/xenbus_probe.h | 2 ++ drivers/xen/xenbus/xenbus_probe_backend.c | 7 +++++ drivers/xen/xenbus/xenbus_xs.c | 38 +++++++++++++++-------- include/xen/xenbus.h | 15 ++++++++- 9 files changed, 62 insertions(+), 18 deletions(-) -- 2.17.1

4 years, 8 months

2
7
0 0

FAILED: patch "[PATCH] KVM: mmu: Fix SPTE encoding of MMIO generation upper half" failed to apply to 5.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.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 34c0f6f2695a2db81e09a3ab7bdb2853f45d4d3d Mon Sep 17 00:00:00 2001 From: "Maciej S. Szmigiero" <maciej.szmigiero(a)oracle.com> Date: Sat, 5 Dec 2020 01:48:08 +0100 Subject: [PATCH] KVM: mmu: Fix SPTE encoding of MMIO generation upper half Commit cae7ed3c2cb0 ("KVM: x86: Refactor the MMIO SPTE generation handling") cleaned up the computation of MMIO generation SPTE masks, however it introduced a bug how the upper part was encoded: SPTE bits 52-61 were supposed to contain bits 10-19 of the current generation number, however a missing shift encoded bits 1-10 there instead (mostly duplicating the lower part of the encoded generation number that then consisted of bits 1-9). In the meantime, the upper part was shrunk by one bit and moved by subsequent commits to become an upper half of the encoded generation number (bits 9-17 of bits 0-17 encoded in a SPTE). In addition to the above, commit 56871d444bc4 ("KVM: x86: fix overlap between SPTE_MMIO_MASK and generation") has changed the SPTE bit range assigned to encode the generation number and the total number of bits encoded but did not update them in the comment attached to their defines, nor in the KVM MMU doc. Let's do it here, too, since it is too trivial thing to warrant a separate commit. Fixes: cae7ed3c2cb0 ("KVM: x86: Refactor the MMIO SPTE generation handling") Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero(a)oracle.com> Message-Id: <156700708db2a5296c5ed7a8b9ac71f1e9765c85.1607129096.git.maciej.szmigiero(a)oracle.com> Cc: stable(a)vger.kernel.org [Reorganize macros so that everything is computed from the bit ranges. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/Documentation/virt/kvm/mmu.rst b/Documentation/virt/kvm/mmu.rst index 1c030dbac7c4..5bfe28b0728e 100644 --- a/Documentation/virt/kvm/mmu.rst +++ b/Documentation/virt/kvm/mmu.rst @@ -455,7 +455,7 @@ If the generation number of the spte does not equal the global generation number, it will ignore the cached MMIO information and handle the page fault through the slow path. -Since only 19 bits are used to store generation-number on mmio spte, all +Since only 18 bits are used to store generation-number on mmio spte, all pages are zapped when there is an overflow. Unfortunately, a single memory access might access kvm_memslots(kvm) multiple diff --git a/arch/x86/kvm/mmu/spte.c b/arch/x86/kvm/mmu/spte.c index fcac2cac78fe..c51ad544f25b 100644 --- a/arch/x86/kvm/mmu/spte.c +++ b/arch/x86/kvm/mmu/spte.c @@ -40,8 +40,8 @@ static u64 generation_mmio_spte_mask(u64 gen) WARN_ON(gen & ~MMIO_SPTE_GEN_MASK); BUILD_BUG_ON((MMIO_SPTE_GEN_HIGH_MASK | MMIO_SPTE_GEN_LOW_MASK) & SPTE_SPECIAL_MASK); - mask = (gen << MMIO_SPTE_GEN_LOW_START) & MMIO_SPTE_GEN_LOW_MASK; - mask |= (gen << MMIO_SPTE_GEN_HIGH_START) & MMIO_SPTE_GEN_HIGH_MASK; + mask = (gen << MMIO_SPTE_GEN_LOW_SHIFT) & MMIO_SPTE_GEN_LOW_MASK; + mask |= (gen << MMIO_SPTE_GEN_HIGH_SHIFT) & MMIO_SPTE_GEN_HIGH_MASK; return mask; } diff --git a/arch/x86/kvm/mmu/spte.h b/arch/x86/kvm/mmu/spte.h index 5c75a451c000..2b3a30bd38b0 100644 --- a/arch/x86/kvm/mmu/spte.h +++ b/arch/x86/kvm/mmu/spte.h @@ -56,11 +56,11 @@ #define SPTE_MMU_WRITEABLE (1ULL << (PT_FIRST_AVAIL_BITS_SHIFT + 1)) /* - * Due to limited space in PTEs, the MMIO generation is a 19 bit subset of + * Due to limited space in PTEs, the MMIO generation is a 18 bit subset of * the memslots generation and is derived as follows: * * Bits 0-8 of the MMIO generation are propagated to spte bits 3-11 - * Bits 9-18 of the MMIO generation are propagated to spte bits 52-61 + * Bits 9-17 of the MMIO generation are propagated to spte bits 54-62 * * The KVM_MEMSLOT_GEN_UPDATE_IN_PROGRESS flag is intentionally not included in * the MMIO generation number, as doing so would require stealing a bit from @@ -69,18 +69,29 @@ * requires a full MMU zap). The flag is instead explicitly queried when * checking for MMIO spte cache hits. */ -#define MMIO_SPTE_GEN_MASK GENMASK_ULL(17, 0) #define MMIO_SPTE_GEN_LOW_START 3 #define MMIO_SPTE_GEN_LOW_END 11 -#define MMIO_SPTE_GEN_LOW_MASK GENMASK_ULL(MMIO_SPTE_GEN_LOW_END, \ - MMIO_SPTE_GEN_LOW_START) #define MMIO_SPTE_GEN_HIGH_START PT64_SECOND_AVAIL_BITS_SHIFT #define MMIO_SPTE_GEN_HIGH_END 62 + +#define MMIO_SPTE_GEN_LOW_MASK GENMASK_ULL(MMIO_SPTE_GEN_LOW_END, \ + MMIO_SPTE_GEN_LOW_START) #define MMIO_SPTE_GEN_HIGH_MASK GENMASK_ULL(MMIO_SPTE_GEN_HIGH_END, \ MMIO_SPTE_GEN_HIGH_START) +#define MMIO_SPTE_GEN_LOW_BITS (MMIO_SPTE_GEN_LOW_END - MMIO_SPTE_GEN_LOW_START + 1) +#define MMIO_SPTE_GEN_HIGH_BITS (MMIO_SPTE_GEN_HIGH_END - MMIO_SPTE_GEN_HIGH_START + 1) + +/* remember to adjust the comment above as well if you change these */ +static_assert(MMIO_SPTE_GEN_LOW_BITS == 9 && MMIO_SPTE_GEN_HIGH_BITS == 9); + +#define MMIO_SPTE_GEN_LOW_SHIFT (MMIO_SPTE_GEN_LOW_START - 0) +#define MMIO_SPTE_GEN_HIGH_SHIFT (MMIO_SPTE_GEN_HIGH_START - MMIO_SPTE_GEN_LOW_BITS) + +#define MMIO_SPTE_GEN_MASK GENMASK_ULL(MMIO_SPTE_GEN_LOW_BITS + MMIO_SPTE_GEN_HIGH_BITS - 1, 0) + extern u64 __read_mostly shadow_nx_mask; extern u64 __read_mostly shadow_x_mask; /* mutual exclusive with nx_mask */ extern u64 __read_mostly shadow_user_mask; @@ -228,8 +239,8 @@ static inline u64 get_mmio_spte_generation(u64 spte) { u64 gen; - gen = (spte & MMIO_SPTE_GEN_LOW_MASK) >> MMIO_SPTE_GEN_LOW_START; - gen |= (spte & MMIO_SPTE_GEN_HIGH_MASK) >> MMIO_SPTE_GEN_HIGH_START; + gen = (spte & MMIO_SPTE_GEN_LOW_MASK) >> MMIO_SPTE_GEN_LOW_SHIFT; + gen |= (spte & MMIO_SPTE_GEN_HIGH_MASK) >> MMIO_SPTE_GEN_HIGH_SHIFT; return gen; }

4 years, 8 months

3
2
0 0

[PATCH v2 0/5] Backport of patch series for stable 4.4 branch

by SeongJae Park

From: SeongJae Park <sjpark(a)amazon.de> Changes from v1 (https://lore.kernel.org/stable/20201217081727.8253-1-sjpark@amazon.com/) - Remove wrong 'Signed-off-by' lines for 'Author Redacted' SeongJae Park (5): xen/xenbus: Allow watches discard events before queueing xen/xenbus: Add 'will_handle' callback support in xenbus_watch_path() xen/xenbus/xen_bus_type: Support will_handle watch callback xen/xenbus: Count pending messages for each watch xenbus/xenbus_backend: Disallow pending watch messages drivers/block/xen-blkback/xenbus.c | 3 +- drivers/net/xen-netback/xenbus.c | 4 ++- drivers/xen/xen-pciback/xenbus.c | 2 +- drivers/xen/xenbus/xenbus_client.c | 8 ++++- drivers/xen/xenbus/xenbus_probe.c | 1 + drivers/xen/xenbus/xenbus_probe.h | 2 ++ drivers/xen/xenbus/xenbus_probe_backend.c | 7 +++++ drivers/xen/xenbus/xenbus_xs.c | 38 +++++++++++++++-------- include/xen/xenbus.h | 15 ++++++++- 9 files changed, 62 insertions(+), 18 deletions(-) -- 2.17.1

4 years, 8 months

1
4
0 0

[PATCH net v3] net: mvpp2: Fix GoP port 3 Networking Complex Control configurations

by stefanc＠marvell.com

From: Stefan Chulski <stefanc(a)marvell.com> During GoP port 2 Networking Complex Control mode of operation configurations, also GoP port 3 mode of operation was wrongly set. Patch removes these configurations. GENCONF_CTRL0_PORTX naming also fixed. Cc: stable(a)vger.kernel.org Fixes: f84bf386f395 ("net: mvpp2: initialize the GoP") Signed-off-by: Stefan Chulski <stefanc(a)marvell.com> --- Changes in v3: - Added cc stable(a)vger.kernel.org Changes in v2: - Added Fixes tag. drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 6 +++--- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 8 ++++---- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h index 6bd7e40..39c4e5c 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h @@ -651,9 +651,9 @@ #define GENCONF_PORT_CTRL1_EN(p) BIT(p) #define GENCONF_PORT_CTRL1_RESET(p) (BIT(p) << 28) #define GENCONF_CTRL0 0x1120 -#define GENCONF_CTRL0_PORT0_RGMII BIT(0) -#define GENCONF_CTRL0_PORT1_RGMII_MII BIT(1) -#define GENCONF_CTRL0_PORT1_RGMII BIT(2) +#define GENCONF_CTRL0_PORT2_RGMII BIT(0) +#define GENCONF_CTRL0_PORT3_RGMII_MII BIT(1) +#define GENCONF_CTRL0_PORT3_RGMII BIT(2) /* Various constants */ diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c index d64dc12..d2b0506 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c @@ -1231,9 +1231,9 @@ static void mvpp22_gop_init_rgmii(struct mvpp2_port *port) regmap_read(priv->sysctrl_base, GENCONF_CTRL0, &val); if (port->gop_id == 2) - val |= GENCONF_CTRL0_PORT0_RGMII | GENCONF_CTRL0_PORT1_RGMII; + val |= GENCONF_CTRL0_PORT2_RGMII; else if (port->gop_id == 3) - val |= GENCONF_CTRL0_PORT1_RGMII_MII; + val |= GENCONF_CTRL0_PORT3_RGMII_MII; regmap_write(priv->sysctrl_base, GENCONF_CTRL0, val); } @@ -1250,9 +1250,9 @@ static void mvpp22_gop_init_sgmii(struct mvpp2_port *port) if (port->gop_id > 1) { regmap_read(priv->sysctrl_base, GENCONF_CTRL0, &val); if (port->gop_id == 2) - val &= ~GENCONF_CTRL0_PORT0_RGMII; + val &= ~GENCONF_CTRL0_PORT2_RGMII; else if (port->gop_id == 3) - val &= ~GENCONF_CTRL0_PORT1_RGMII_MII; + val &= ~GENCONF_CTRL0_PORT3_RGMII_MII; regmap_write(priv->sysctrl_base, GENCONF_CTRL0, val); } } -- 1.9.1

4 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror