February 2021 - Linux-stable-mirror

[PATCH v4 0/2] mm: fix initialization of struct page for holes in memory layout

by Mike Rapoport

From: Mike Rapoport <rppt(a)linux.ibm.com> Hi, Commit 73a6e474cb37 ("mm: memmap_init: iterate over memblock regions rather that check each PFN") exposed several issues with the memory map initialization and these patches fix those issues. Initially there were crashes during compaction that Qian Cai reported back in April [1]. It seemed back then that the problem was fixed, but a few weeks ago Andrea Arcangeli hit the same bug [2] and there was an additional discussion at [3]. I didn't appreciate variety of ways BIOSes can report memory in the first megabyte, so v3 of this set caused boot failures on several x86 systems. Hopefully this time I covered all the bases. The first patch here complements commit bde9cfa3afe4 ("x86/setup: don't remove E820_TYPE_RAM for pfn 0") for the cases when BIOS reports the first page as absent or reserved. The second patch is a more robust version of d3921cb8be29 ("mm: fix initialization of struct page for holes in memory layout") that can now handle the above cases as well. v4: * make sure pages in the range 0 - start_pfn_of_lowest_zone are initialized even if an architecture hides them from the generic mm * finally make pfn 0 on x86 to be a part of memory visible to the generic mm as reserved memory. v3: https://lore.kernel.org/lkml/20210111194017.22696-1-rppt@kernel.org * use architectural zone constraints to set zone links for struct pages corresponding to the holes * drop implicit update of memblock.memory * add a patch that sets pfn 0 to E820_TYPE_RAM on x86 v2: https://lore.kernel.org/lkml/20201209214304.6812-1-rppt@kernel.org/): * added patch that adds all regions in memblock.reserved that do not overlap with memblock.memory to memblock.memory in the beginning of free_area_init() [1] https://lore.kernel.org/lkml/8C537EB7-85EE-4DCF-943E-3CC0ED0DF56D@lca.pw [2] https://lore.kernel.org/lkml/20201121194506.13464-1-aarcange@redhat.com [3] https://lore.kernel.org/mm-commits/20201206005401.qKuAVgOXr%akpm@linux-foun… Mike Rapoport (2): x86/setup: always add the beginning of RAM as memblock.memory mm: fix initialization of struct page for holes in memory layout arch/x86/kernel/setup.c | 8 ++++ mm/page_alloc.c | 85 ++++++++++++++++++++++++----------------- 2 files changed, 59 insertions(+), 34 deletions(-) -- 2.28.0

3 years, 11 months

4
13
0 0

Re: Patch "ASoC: qcom: Fix number of HDMI RDMA channels on sc7180" has been added to the 5.10-stable tree

by Stephen Boyd

Quoting Sasha Levin (2021-02-01 08:52:31) > This is a note to let you know that I've just added the patch titled > > ASoC: qcom: Fix number of HDMI RDMA channels on sc7180 > > to the 5.10-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > asoc-qcom-fix-number-of-hdmi-rdma-channels-on-sc7180.patch > and it can be found in the queue-5.10 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > Please drop this from stable queue. It will be reverted shortly and replaced with a proper patch. See [2] for more info. Quote: > In my opinion, It 's better not to apply this patch. > > I will post patch with changing size in sc7180.dtsi file. After further discussion with Srinivasa it turns out the dtsi file is correct, but the regmap size is wrong in a different way and the valid registers functions are also wrong. We'll be sending a proper fix this week. Thanks, Stephen [2] https://lore.kernel.org/alsa-devel/89cc3dfb-35da-3498-b126-b440c91f9a45@cod… > > > commit f3d3274aa72af6366a4cfef1a5a51154aca8cd69 > Author: Stephen Boyd <swboyd(a)chromium.org> > Date: Fri Jan 15 12:33:29 2021 -0800 > > ASoC: qcom: Fix number of HDMI RDMA channels on sc7180 > > [ Upstream commit 7dfe20ee92f681ab1342015254ddb77a18f40cdb ] > > Suspending/resuming with an HDMI dongle attached leads to crashes from > an audio regmap. > > Unable to handle kernel paging request at virtual address ffffffc018068000 > Mem abort info: > ESR = 0x96000047 > EC = 0x25: DABT (current EL), IL = 32 bits > SET = 0, FnV = 0 > EA = 0, S1PTW = 0 > Data abort info: > ISV = 0, ISS = 0x00000047 > CM = 0, WnR = 1 > swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081b12000 > [ffffffc018068000] pgd=0000000275d14003, pud=0000000275d14003, pmd=000000026365d003, pte=0000000000000000 > Internal error: Oops: 96000047 [#1] PREEMPT SMP > Call trace: > regmap_mmio_write32le+0x2c/0x40 > regmap_mmio_write+0x48/0x6c > _regmap_bus_reg_write+0x34/0x44 > _regmap_write+0x100/0x150 > regcache_default_sync+0xc0/0x138 > regcache_sync+0x188/0x26c > lpass_platform_pcmops_resume+0x48/0x54 [snd_soc_lpass_platform] > snd_soc_component_resume+0x28/0x40 > soc_resume_deferred+0x6c/0x178 > process_one_work+0x208/0x3c8 > worker_thread+0x23c/0x3e8 > kthread+0x144/0x178 > ret_from_fork+0x10/0x18 > Code: d503201f d50332bf f94002a8 8b344108 (b9000113) > > I can reliably reproduce this problem by running 'tail' on the registers > file in debugfs for the hdmi regmap. > > # tail /sys/kernel/debug/regmap/62d87000.lpass-lpass_hdmi/registers > [ 84.658733] Unable to handle kernel paging request at virtual address ffffffd0128e800c > > This crash happens because we're trying to read registers from the > regmap beyond the length of the mapping created by ioremap(). > > The number of hdmi_rdma_channels determines the size of the regmap via > this code in sound/soc/qcom/lpass-cpu.c: > > lpass_hdmi_regmap_config.max_register = LPAIF_HDMI_RDMAPER_REG(variant, variant->hdmi_rdma_channels); > > According to debugfs the size of the regmap is 0x68010 but according to > the DTS file posted in [1] the size is only 0x68000 (see the first reg > property of the lpass_cpu node). Let's change the number of channels to > be 3 instead of 4 so the math works out to have a max register of > 0x67010, nicely fitting inside of the region size of 0x68000. > > Note: I tried to bump up the size of the register region to the next > page to include the 0x68010 register but then the tail command caused > SErrors with an async abort, implying that the register region doesn't > exist or it isn't clocked because the bus is telling us that the > register read failed. I reduce the number of channels and played audio > through the HDMI channel and it kept working so I think this is correct. > > Fixes: 2ad63dc8df6b ("ASoC: qcom: sc7180: Add support for audio over DP") > Link: https://lore.kernel.org/r/1601448168-18396-2-git-send-email-srivasam@codeau… [1] > Cc: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> > Cc: Srinivasa Rao <srivasam(a)codeaurora.org> > Cc: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> > Cc: Cheng-Yi Chiang <cychiang(a)chromium.org> > Signed-off-by: Stephen Boyd <swboyd(a)chromium.org> > Link: https://lore.kernel.org/r/20210115203329.846824-1-swboyd@chromium.org > Signed-off-by: Mark Brown <broonie(a)kernel.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/sound/soc/qcom/lpass-sc7180.c b/sound/soc/qcom/lpass-sc7180.c > index c647e627897a2..c33da7faaf913 100644 > --- a/sound/soc/qcom/lpass-sc7180.c > +++ b/sound/soc/qcom/lpass-sc7180.c > @@ -170,7 +170,7 @@ static struct lpass_variant sc7180_data = { > .rdma_channels = 5, > .hdmi_rdma_reg_base = 0x64000, > .hdmi_rdma_reg_stride = 0x1000, > - .hdmi_rdma_channels = 4, > + .hdmi_rdma_channels = 3, > .dmactl_audif_start = 1, > .wrdma_reg_base = 0x18000, > .wrdma_reg_stride = 0x1000,

3 years, 11 months

2
1
0 0

[PATCH 01/11] x86/fault: Fix AMD erratum #91 errata fixup for user code

by Andy Lutomirski

The recent rework of probe_kernel_read() and its conversion to get_kernel_nofault() inadvertently broke is_prefetch(). We were using probe_kernel_read() as a sloppy "read user or kernel memory" helper, but it doens't do that any more. The new get_kernel_nofault() reads *kernel* memory only, which completely broke is_prefetch() for user access. Adjust the code to the the correct accessor based on access mode. The manual address bounds check is no longer necessary, since the accessor helpers (get_user() / get_kernel_nofault()) do the right thing all by themselves. As a bonus, by using the correct accessor, we don't need the open-coded address bounds check. While we're at it, disable the workaround on all CPUs except AMD Family 0xF. By my reading of the Revision Guide for AMD Athlon™ 64 and AMD Opteron™ Processors, only family 0xF is affected. Fixes: eab0c6089b68 ("maccess: unify the probe kernel arch hooks") Cc: stable(a)vger.kernel.org Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Alexei Starovoitov <ast(a)kernel.org> Cc: Daniel Borkmann <daniel(a)iogearbox.net> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Signed-off-by: Andy Lutomirski <luto(a)kernel.org> --- arch/x86/mm/fault.c | 31 +++++++++++++++++++++---------- 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index 106b22d1d189..50dfdc71761e 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -54,7 +54,7 @@ kmmio_fault(struct pt_regs *regs, unsigned long addr) * 32-bit mode: * * Sometimes AMD Athlon/Opteron CPUs report invalid exceptions on prefetch. - * Check that here and ignore it. + * Check that here and ignore it. This is AMD erratum #91. * * 64-bit mode: * @@ -83,11 +83,7 @@ check_prefetch_opcode(struct pt_regs *regs, unsigned char *instr, #ifdef CONFIG_X86_64 case 0x40: /* - * In AMD64 long mode 0x40..0x4F are valid REX prefixes - * Need to figure out under what instruction mode the - * instruction was issued. Could check the LDT for lm, - * but for now it's good enough to assume that long - * mode only uses well known segments or kernel. + * In 64-bit mode 0x40..0x4F are valid REX prefixes */ return (!user_mode(regs) || user_64bit_mode(regs)); #endif @@ -124,23 +120,38 @@ is_prefetch(struct pt_regs *regs, unsigned long error_code, unsigned long addr) if (error_code & X86_PF_INSTR) return 0; + if (likely(boot_cpu_data.x86_vendor != X86_VENDOR_AMD + || boot_cpu_data.x86 != 0xf)) + return 0; + instr = (void *)convert_ip_to_linear(current, regs); max_instr = instr + 15; - if (user_mode(regs) && instr >= (unsigned char *)TASK_SIZE_MAX) - return 0; + /* + * This code has historically always bailed out if IP points to a + * not-present page (e.g. due to a race). No one has ever + * complained about this. + */ + pagefault_disable(); while (instr < max_instr) { unsigned char opcode; - if (get_kernel_nofault(opcode, instr)) - break; + if (user_mode(regs)) { + if (get_user(opcode, instr)) + break; + } else { + if (get_kernel_nofault(opcode, instr)) + break; + } instr++; if (!check_prefetch_opcode(regs, instr, opcode, &prefetch)) break; } + + pagefault_enable(); return prefetch; } -- 2.29.2

3 years, 11 months

3
2
0 0

[PATCH 1/2] arm64: Do not pass tagged addresses to __is_lm_address()

by Catalin Marinas

Commit 519ea6f1c82f ("arm64: Fix kernel address detection of __is_lm_address()") fixed the incorrect validation of addresses below PAGE_OFFSET. However, it no longer allowed tagged addresses to be passed to virt_addr_valid(). Fix this by explicitly resetting the pointer tag prior to invoking __is_lm_address(). This is consistent with the __lm_to_phys() macro. Fixes: 519ea6f1c82f ("arm64: Fix kernel address detection of __is_lm_address()") Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> Cc: <stable(a)vger.kernel.org> # 5.4.x Cc: Will Deacon <will(a)kernel.org> Cc: Vincenzo Frascino <vincenzo.frascino(a)arm.com> Cc: Ard Biesheuvel <ardb(a)kernel.org> Cc: Mark Rutland <mark.rutland(a)arm.com> --- arch/arm64/include/asm/memory.h | 2 +- arch/arm64/mm/physaddr.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h index 99d7e1494aaa..3c1aaa522cbd 100644 --- a/arch/arm64/include/asm/memory.h +++ b/arch/arm64/include/asm/memory.h @@ -332,7 +332,7 @@ static inline void *phys_to_virt(phys_addr_t x) #endif /* !CONFIG_SPARSEMEM_VMEMMAP || CONFIG_DEBUG_VIRTUAL */ #define virt_addr_valid(addr) ({ \ - __typeof__(addr) __addr = addr; \ + __typeof__(addr) __addr = __tag_reset(addr); \ __is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr)); \ }) diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c index 67a9ba9eaa96..cde44c13dda1 100644 --- a/arch/arm64/mm/physaddr.c +++ b/arch/arm64/mm/physaddr.c @@ -9,7 +9,7 @@ phys_addr_t __virt_to_phys(unsigned long x) { - WARN(!__is_lm_address(x), + WARN(!__is_lm_address(__tag_reset(x)), "virt_to_phys used for non-linear address: %pK (%pS)\n", (void *)x, (void *)x);

3 years, 11 months

1
0
0 0

[PATCH 1/6] io_uring: fix inconsistent lock state

by Pavel Begunkov

WARNING: inconsistent lock state inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. syz-executor217/8450 [HC1[1]:SC0[0]:HE0:SE1] takes: ffff888023d6e620 (&fs->lock){?.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:354 [inline] ffff888023d6e620 (&fs->lock){?.+.}-{2:2}, at: io_req_clean_work fs/io_uring.c:1398 [inline] ffff888023d6e620 (&fs->lock){?.+.}-{2:2}, at: io_dismantle_req+0x66f/0xf60 fs/io_uring.c:2029 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&fs->lock); <Interrupt> lock(&fs->lock); *** DEADLOCK *** 1 lock held by syz-executor217/8450: #0: ffff88802417c3e8 (&ctx->uring_lock){+.+.}-{3:3}, at: __do_sys_io_uring_enter+0x1071/0x1f30 fs/io_uring.c:9442 stack backtrace: CPU: 1 PID: 8450 Comm: syz-executor217 Not tainted 5.11.0-rc5-next-20210129-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> [...] _raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:151 spin_lock include/linux/spinlock.h:354 [inline] io_req_clean_work fs/io_uring.c:1398 [inline] io_dismantle_req+0x66f/0xf60 fs/io_uring.c:2029 __io_free_req+0x3d/0x2e0 fs/io_uring.c:2046 io_free_req fs/io_uring.c:2269 [inline] io_double_put_req fs/io_uring.c:2392 [inline] io_put_req+0xf9/0x570 fs/io_uring.c:2388 io_link_timeout_fn+0x30c/0x480 fs/io_uring.c:6497 __run_hrtimer kernel/time/hrtimer.c:1519 [inline] __hrtimer_run_queues+0x609/0xe40 kernel/time/hrtimer.c:1583 hrtimer_interrupt+0x334/0x940 kernel/time/hrtimer.c:1645 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1085 [inline] __sysvec_apic_timer_interrupt+0x146/0x540 arch/x86/kernel/apic/apic.c:1102 asm_call_irq_on_stack+0xf/0x20 </IRQ> __run_sysvec_on_irqstack arch/x86/include/asm/irq_stack.h:37 [inline] run_sysvec_on_irqstack_cond arch/x86/include/asm/irq_stack.h:89 [inline] sysvec_apic_timer_interrupt+0xbd/0x100 arch/x86/kernel/apic/apic.c:1096 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:629 RIP: 0010:__raw_spin_unlock_irq include/linux/spinlock_api_smp.h:169 [inline] RIP: 0010:_raw_spin_unlock_irq+0x25/0x40 kernel/locking/spinlock.c:199 spin_unlock_irq include/linux/spinlock.h:404 [inline] io_queue_linked_timeout+0x194/0x1f0 fs/io_uring.c:6525 __io_queue_sqe+0x328/0x1290 fs/io_uring.c:6594 io_queue_sqe+0x631/0x10d0 fs/io_uring.c:6639 io_queue_link_head fs/io_uring.c:6650 [inline] io_submit_sqe fs/io_uring.c:6697 [inline] io_submit_sqes+0x19b5/0x2720 fs/io_uring.c:6960 __do_sys_io_uring_enter+0x107d/0x1f30 fs/io_uring.c:9443 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Don't free requests from under hrtimer context (softirq) as it may sleep or take spinlocks improperly (e.g. non-irq versions). Cc: stable(a)vger.kernel.org # 5.6+ Reported-by: syzbot+81d17233a2b02eafba33(a)syzkaller.appspotmail.com Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> --- fs/io_uring.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/fs/io_uring.c b/fs/io_uring.c index a8bf867b6cf2..f3252ff6542b 100644 --- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -1886,8 +1886,8 @@ static void io_cqring_fill_event(struct io_kiocb *req, long res) __io_cqring_fill_event(req, res, 0); } -static void io_req_complete_nostate(struct io_kiocb *req, long res, - unsigned int cflags) +static void io_req_complete_post(struct io_kiocb *req, long res, + unsigned int cflags) { struct io_ring_ctx *ctx = req->ctx; unsigned long flags; @@ -1898,6 +1898,12 @@ static void io_req_complete_nostate(struct io_kiocb *req, long res, spin_unlock_irqrestore(&ctx->completion_lock, flags); io_cqring_ev_posted(ctx); +} + +static inline void io_req_complete_nostate(struct io_kiocb *req, long res, + unsigned int cflags) +{ + io_req_complete_post(req, res, cflags); io_put_req(req); } @@ -6489,9 +6495,10 @@ static enum hrtimer_restart io_link_timeout_fn(struct hrtimer *timer) if (prev) { req_set_fail_links(prev); io_async_find_and_cancel(ctx, req, prev->user_data, -ETIME); - io_put_req(prev); + io_put_req_deferred(prev, 1); } else { - io_req_complete(req, -ETIME); + io_req_complete_post(req, -ETIME, 0); + io_put_req_deferred(req, 1); } return HRTIMER_NORESTART; } -- 2.24.0

3 years, 11 months

1
0
0 0

[PATCH 1/9] crypto: michael_mic - fix broken misalignment handling

by Ard Biesheuvel

The Michael MIC driver uses the cra_alignmask to ensure that pointers presented to its update and finup/final methods are 32-bit aligned. However, due to the way the shash API works, this is no guarantee that the 32-bit reads occurring in the update method are also aligned, as the size of the buffer presented to update may be of uneven length. For instance, an update() of 3 bytes followed by a misaligned update() of 4 or more bytes will result in a misaligned access using an accessor that is not suitable for this. On most architectures, this does not matter, and so setting the cra_alignmask is pointless. On architectures where this does matter, setting the cra_alignmask does not actually solve the problem. So let's get rid of the cra_alignmask, and use unaligned accessors instead, where appropriate. Cc: <stable(a)vger.kernel.org> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> --- crypto/michael_mic.c | 31 ++++++++------------ 1 file changed, 12 insertions(+), 19 deletions(-) diff --git a/crypto/michael_mic.c b/crypto/michael_mic.c index 63350c4ad461..f4c31049601c 100644 --- a/crypto/michael_mic.c +++ b/crypto/michael_mic.c @@ -7,7 +7,7 @@ * Copyright (c) 2004 Jouni Malinen <j(a)w1.fi> */ #include <crypto/internal/hash.h> -#include <asm/byteorder.h> +#include <asm/unaligned.h> #include <linux/init.h> #include <linux/module.h> #include <linux/string.h> @@ -19,7 +19,7 @@ struct michael_mic_ctx { }; struct michael_mic_desc_ctx { - u8 pending[4]; + __le32 pending; size_t pending_len; u32 l, r; @@ -60,13 +60,12 @@ static int michael_update(struct shash_desc *desc, const u8 *data, unsigned int len) { struct michael_mic_desc_ctx *mctx = shash_desc_ctx(desc); - const __le32 *src; if (mctx->pending_len) { int flen = 4 - mctx->pending_len; if (flen > len) flen = len; - memcpy(&mctx->pending[mctx->pending_len], data, flen); + memcpy((u8 *)&mctx->pending + mctx->pending_len, data, flen); mctx->pending_len += flen; data += flen; len -= flen; @@ -74,23 +73,21 @@ static int michael_update(struct shash_desc *desc, const u8 *data, if (mctx->pending_len < 4) return 0; - src = (const __le32 *)mctx->pending; - mctx->l ^= le32_to_cpup(src); + mctx->l ^= le32_to_cpu(mctx->pending); michael_block(mctx->l, mctx->r); mctx->pending_len = 0; } - src = (const __le32 *)data; - while (len >= 4) { - mctx->l ^= le32_to_cpup(src++); + mctx->l ^= get_unaligned_le32(data); michael_block(mctx->l, mctx->r); + data += 4; len -= 4; } if (len > 0) { mctx->pending_len = len; - memcpy(mctx->pending, src, len); + memcpy(&mctx->pending, data, len); } return 0; @@ -100,8 +97,7 @@ static int michael_update(struct shash_desc *desc, const u8 *data, static int michael_final(struct shash_desc *desc, u8 *out) { struct michael_mic_desc_ctx *mctx = shash_desc_ctx(desc); - u8 *data = mctx->pending; - __le32 *dst = (__le32 *)out; + u8 *data = (u8 *)&mctx->pending; /* Last block and padding (0x5a, 4..7 x 0) */ switch (mctx->pending_len) { @@ -123,8 +119,8 @@ static int michael_final(struct shash_desc *desc, u8 *out) /* l ^= 0; */ michael_block(mctx->l, mctx->r); - dst[0] = cpu_to_le32(mctx->l); - dst[1] = cpu_to_le32(mctx->r); + put_unaligned_le32(mctx->l, out); + put_unaligned_le32(mctx->r, out + 4); return 0; } @@ -135,13 +131,11 @@ static int michael_setkey(struct crypto_shash *tfm, const u8 *key, { struct michael_mic_ctx *mctx = crypto_shash_ctx(tfm); - const __le32 *data = (const __le32 *)key; - if (keylen != 8) return -EINVAL; - mctx->l = le32_to_cpu(data[0]); - mctx->r = le32_to_cpu(data[1]); + mctx->l = get_unaligned_le32(key); + mctx->r = get_unaligned_le32(key + 4); return 0; } @@ -156,7 +150,6 @@ static struct shash_alg alg = { .cra_name = "michael_mic", .cra_driver_name = "michael_mic-generic", .cra_blocksize = 8, - .cra_alignmask = 3, .cra_ctxsize = sizeof(struct michael_mic_ctx), .cra_module = THIS_MODULE, } -- 2.20.1

3 years, 11 months

1
0
0 0

Re: [PATCH v2] KVM: x86: Allow guests to see MSR_IA32_TSX_CTRL even if tsx=off

by Sean Christopherson

On Fri, Jan 29, 2021, Paolo Bonzini wrote: > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 76bce832cade..15733013b266 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -1401,7 +1401,7 @@ static u64 kvm_get_arch_capabilities(void) > * This lets the guest use VERW to clear CPU buffers. This comment be updated to call out the new TSX_CTRL behavior. /* * On TAA affected systems: * - nothing to do if TSX is disabled on the host. * - we emulate TSX_CTRL if present on the host. * This lets the guest use VERW to clear CPU buffers. */ > */ > if (!boot_cpu_has(X86_FEATURE_RTM)) > - data &= ~(ARCH_CAP_TAA_NO | ARCH_CAP_TSX_CTRL_MSR); > + data &= ~ARCH_CAP_TAA_NO; Hmm, simply clearing TSX_CTRL will only preserve the host value. Since ARCH_CAPABILITIES is unconditionally emulated by KVM, wouldn't it make sense to unconditionally expose TSX_CTRL as well, as opposed to exposing it only if it's supported in the host? I.e. allow migrating a TSX-disabled guest to a host without TSX. Or am I misunderstanding how TSX_CTRL is checked/used? > else if (!boot_cpu_has_bug(X86_BUG_TAA)) > data |= ARCH_CAP_TAA_NO; > > -- > 2.26.2 >

3 years, 11 months

2
6
0 0

[PATCH] spi: fsl: invert spisel_boot signal on MPC8309

by Rasmus Villemoes

Commit 7a2da5d7960a ("spi: fsl: Fix driver breakage when SPI_CS_HIGH is not set in spi->mode") broke our MPC8309 board by effectively inverting the boolean value passed to fsl_spi_cs_control. The SPISEL_BOOT signal is used as chipselect, but it's not a gpio, so we cannot rely on gpiolib handling the polarity. Adapt to the new world order by inverting the logic here. This does assume that the slave sitting at the SPISEL_BOOT is active low, but should that ever turn out not to be the case, one can create a stub gpiochip driver controlling a single gpio (or rather, a single "spo", special-purpose output). Fixes: 7a2da5d7960a ("spi: fsl: Fix driver breakage when SPI_CS_HIGH is not set in spi->mode") Cc: stable(a)vger.kernel.org Signed-off-by: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk> --- drivers/spi/spi-fsl-spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-fsl-spi.c b/drivers/spi/spi-fsl-spi.c index 6d8e0a05a535..e4a8d203f940 100644 --- a/drivers/spi/spi-fsl-spi.c +++ b/drivers/spi/spi-fsl-spi.c @@ -695,7 +695,7 @@ static void fsl_spi_cs_control(struct spi_device *spi, bool on) if (WARN_ON_ONCE(!pinfo->immr_spi_cs)) return; - iowrite32be(on ? SPI_BOOT_SEL_BIT : 0, pinfo->immr_spi_cs); + iowrite32be(on ? 0 : SPI_BOOT_SEL_BIT, pinfo->immr_spi_cs); } } -- 2.23.0

3 years, 11 months

2
1
0 0

FAILED: patch "[PATCH] Revert "dm raid: fix discard limits for raid1 and raid10"" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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 0941e3b0653fef1ea68287f6a948c6c68a45c9ba Mon Sep 17 00:00:00 2001 From: Mike Snitzer <snitzer(a)redhat.com> Date: Mon, 14 Dec 2020 12:12:08 -0500 Subject: [PATCH] Revert "dm raid: fix discard limits for raid1 and raid10" This reverts commit e0910c8e4f87bb9f767e61a778b0d9271c4dc512. Reverting 6ffeb1c3f822 ("md: change mddev 'chunk_sectors' from int to unsigned") exposes dm-raid.c compiler warnings detailed that commit's header. Clearly this more conservative fix, of simply reverting e0910c8e4f8, would've been more prudent given how late we were in the v5.10 release. Lessons have been learned. Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c index dc8568ab96f2..56b723d012ac 100644 --- a/drivers/md/dm-raid.c +++ b/drivers/md/dm-raid.c @@ -3730,14 +3730,12 @@ static void raid_io_hints(struct dm_target *ti, struct queue_limits *limits) blk_limits_io_opt(limits, chunk_size_bytes * mddev_data_stripes(rs)); /* - * RAID10 personality requires bio splitting, - * RAID0/1/4/5/6 don't and process large discard bios properly. + * RAID1 and RAID10 personalities require bio splitting, + * RAID0/4/5/6 don't and process large discard bios properly. */ - if (rs_is_raid10(rs)) { - limits->discard_granularity = max(chunk_size_bytes, - limits->discard_granularity); - limits->max_discard_sectors = min_not_zero(rs->md.chunk_sectors, - limits->max_discard_sectors); + if (rs_is_raid1(rs) || rs_is_raid10(rs)) { + limits->discard_granularity = chunk_size_bytes; + limits->max_discard_sectors = rs->md.chunk_sectors; } }

3 years, 11 months

1
0
0 0

FAILED: patch "[PATCH] dm raid: fix discard limits for raid1 and raid10" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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 e0910c8e4f87bb9f767e61a778b0d9271c4dc512 Mon Sep 17 00:00:00 2001 From: Mike Snitzer <snitzer(a)redhat.com> Date: Thu, 24 Sep 2020 13:14:52 -0400 Subject: [PATCH] dm raid: fix discard limits for raid1 and raid10 Block core warned that discard_granularity was 0 for dm-raid with personality of raid1. Reason is that raid_io_hints() was incorrectly special-casing raid1 rather than raid0. But since commit 29efc390b9462 ("md/md0: optimize raid0 discard handling") even raid0 properly handles large discards. Fix raid_io_hints() by removing discard limits settings for raid1. Also, fix limits for raid10 by properly stacking underlying limits as done in blk_stack_limits(). Depends-on: 29efc390b9462 ("md/md0: optimize raid0 discard handling") Fixes: 61697a6abd24a ("dm: eliminate 'split_discard_bios' flag from DM target interface") Cc: stable(a)vger.kernel.org Reported-by: Zdenek Kabelac <zkabelac(a)redhat.com> Reported-by: Mikulas Patocka <mpatocka(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c index 56b723d012ac..dc8568ab96f2 100644 --- a/drivers/md/dm-raid.c +++ b/drivers/md/dm-raid.c @@ -3730,12 +3730,14 @@ static void raid_io_hints(struct dm_target *ti, struct queue_limits *limits) blk_limits_io_opt(limits, chunk_size_bytes * mddev_data_stripes(rs)); /* - * RAID1 and RAID10 personalities require bio splitting, - * RAID0/4/5/6 don't and process large discard bios properly. + * RAID10 personality requires bio splitting, + * RAID0/1/4/5/6 don't and process large discard bios properly. */ - if (rs_is_raid1(rs) || rs_is_raid10(rs)) { - limits->discard_granularity = chunk_size_bytes; - limits->max_discard_sectors = rs->md.chunk_sectors; + if (rs_is_raid10(rs)) { + limits->discard_granularity = max(chunk_size_bytes, + limits->discard_granularity); + limits->max_discard_sectors = min_not_zero(rs->md.chunk_sectors, + limits->max_discard_sectors); } }

3 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2021