- Jun 27, 2023
-
-
Robert Nelson authored
Signed-off-by:Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by:
-
- Mar 29, 2021
-
-
LCPD Auto Merger authored
TI-Feature: connectivity TI-Branch: connectivity-ti-linux-5.4.y * 'connectivity-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity : net: ethernet: ti: am65-cpsw-qos: fix dma per-queue rate checks Signed-off-by:
LCPD Auto Merger <lcpd_integration@list.ti.com>
-
- Mar 28, 2021
-
-
There is a HW limitation that dma per-queue rate limiting has to be enabled sequentially from hi->lo channels. The driver performs checks for above, but does it incorrectly, as result it's not possible to disable rate limiting for the channel: echo 100 > /sys/class/net/eth0/queues/tx-7/tx_maxrate echo 0 > /sys/class/net/eth0/queues/tx-7/tx_maxrate ^ will fail. This patch fixes above issue. Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
- Mar 26, 2021
-
-
Aparna Balasubramanian authored
Merge tag 'v5.4.106' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-5.4.y This is the 5.4.106 stable release. * tag 'v5.4.106' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (925 commits) Linux 5.4.106 xen/events: avoid handling the same event on two cpus at the same time xen/events: don't unmask an event channel when an eoi is pending xen/events: reset affinity of 2-level event when tearing it down KVM: arm64: Reject VM creation when the default IPA size is unsupported KVM: arm64: Ensure I-cache isolation between vcpus of a same VM nvme: release namespace head reference on error nvme: unlink head after removing last namespace KVM: arm64: Fix exclusive limit for IPA size x86/unwind/orc: Disable KASAN checking in the ORC unwinder, part 2 binfmt_misc: fix possible deadlock in bm_register_write powerpc/64s: Fix instruction encoding for lis in ppc_function_entry() sched/membarrier: fix missing local execution of ipi_sync_rq_state() zram: fix return value on writeback_store include/linux/sched/mm.h: use rcu_dereference in in_vfork() stop_machine: mark helpers __always_inline hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() arm64: mm: use a 48-bit ID map when possible on 52-bit VA builds configfs: fix a use-after-free in __configfs_open_file block: rsxx: fix error return code of rsxx_pci_probe() ... Commit 40af962e ("usb: host: xhci: mvebu: make USB 3.0 PHY optional for Armada 3720") was reverted and squashed to fix a build issue. Signed-off-by:
Aparna Balasubramanian <aparnab@ti.com>
-
LCPD Auto Merger authored
TI-Feature: connectivity TI-Branch: connectivity-ti-linux-5.4.y * 'connectivity-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity : net: ethernet: ti: am65-cpsw: fix cut-thru link speed cfg Signed-off-by:
-
For cut-thru to be enabled the link speed has to be configured in CPSW_PN_SPEED_REG which supports two modes: - link speed auto detection which is implemented by driver by default - link speed manual configuration The driver checks CPSW_PN_SPEED_REG after link up event is detected by PHY and CPSW_PN_MAC_CONTROL_REG is configured. It was identified that depending on setup and runtime conditions the speed auto-detection can happen with different delays, so when driver reads CPSW_PN_SPEED_REG it sees that link speed has not been detected yet and disables cut-thru. Its recommended to use following delays after Link up is detected and MAC_SL configured - 15us in 10/100 mode and 3us in 1G mode. Hence, fix cut-thru link speed configuration be adding 40us delay before reading CPSW_PN_SPEED_REG and implement fall back to manual configuration if link speed auto detection fails. Signed-off-by:
-
- Mar 23, 2021
-
-
LCPD Auto Merger authored
TI-Feature: connectivity TI-Branch: connectivity-ti-linux-5.4.y * 'connectivity-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity : net: ethernet: ti: prueth: fix handling packets with timestamp Signed-off-by:
-
- Mar 19, 2021
-
-
The packets with timestamp (TS) got the TS placed in the data block following the packet data and TS data block has corresponding Buffer descriptor allocated. Now ICSS prueth driver reads packet data and TS properly, but releases only Buffer descriptors allocated for Packet data and misses Buffer descriptor allocated for TS. As result, the queue rd_ptr points on Buffer descriptor allocated for TS when driver switches to next packet processing which is all 0. This situation is detected by driver as critical error and driver tries to recover by discarding all existing packets in the RX queue (rd_ptr = wr_ptr). Hence, fix packets with timestamp processing by properly account Buffer descriptor allocated for TS. Fixes: 813f7dc8 ("net: ti: prueth: Add support for reading timestamps from rx packets") Signed-off-by:
-
- Mar 18, 2021
-
-
LCPD Auto Merger authored
TI-Feature: connectivity TI-Branch: connectivity-ti-linux-5.4.y * 'connectivity-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity : PCI: endpoint: Initialize "epf->node" in pci_epf_create() phy: cadence-torrent: Add delay for PIPE clock to be stable Signed-off-by:
-
Modify pci_epf_create() to take "struct device_node" as an argument and initialize epf->node. There is a race condition wherein probe of pci-epf-ntb.c gets invoked before epf->node is initialized in pci_epf_of_create(). Fix it here. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
- Mar 17, 2021
-
-
The Torrent spec specifies delay of 660.5us after phy_reset is asserted by the controller. So provide a delay of 2ms in ->phy_on() callback where the SERDES is already configured in bootloader. Signed-off-by:
-
Greg Kroah-Hartman authored
Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Jason Self <jason@bluehome.net> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Hulk Robot <hulkrobot@huawei.com> Tested-by:
Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20210315135550.333963635@linuxfoundation.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Juergen Gross authored
commit b6622798 upstream. When changing the cpu affinity of an event it can happen today that (with some unlucky timing) the same event will be handled on the old and the new cpu at the same time. Avoid that by adding an "event active" flag to the per-event data and call the handler only if this flag isn't set. Cc: stable@vger.kernel.org Reported-by:
Julien Grall <julien@xen.org> Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Julien Grall <jgrall@amazon.com> Link: https://lore.kernel.org/r/20210306161833.4552-4-jgross@suse.com Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
-
Juergen Gross authored
commit 25da4618 upstream. An event channel should be kept masked when an eoi is pending for it. When being migrated to another cpu it might be unmasked, though. In order to avoid this keep three different flags for each event channel to be able to distinguish "normal" masking/unmasking from eoi related masking/unmasking and temporary masking. The event channel should only be able to generate an interrupt if all flags are cleared. Cc: stable@vger.kernel.org Fixes: 54c9de89 ("xen/events: add a new "late EOI" evtchn framework") Reported-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Link: https://lore.kernel.org/r/20210306161833.4552-3-jgross@suse.com [boris -- corrected Fixed tag format] Signed-off-by:
-
Juergen Gross authored
commit 9e77d96b upstream. When creating a new event channel with 2-level events the affinity needs to be reset initially in order to avoid using an old affinity from earlier usage of the event channel port. So when tearing an event channel down reset all affinity bits. The same applies to the affinity when onlining a vcpu: all old affinity settings for this vcpu must be reset. As percpu events get initialized before the percpu event channel hook is called, resetting of the affinities happens after offlining a vcpu (this is working, as initial percpu memory is zeroed out). Cc: stable@vger.kernel.org Reported-by:
-
Marc Zyngier authored
Commit 7d717558 upstream. KVM/arm64 has forever used a 40bit default IPA space, partially due to its 32bit heritage (where the only choice is 40bit). However, there are implementations in the wild that have a *cough* much smaller *cough* IPA space, which leads to a misprogramming of VTCR_EL2, and a guest that is stuck on its first memory access if userspace dares to ask for the default IPA setting (which most VMMs do). Instead, blundly reject the creation of such VM, as we can't satisfy the requirements from userspace (with a one-off warning). Also clarify the boot warning, and document that the VM creation will fail when an unsupported IPA size is provided. Although this is an ABI change, it doesn't really change much for userspace: - the guest couldn't run before this change, but no error was returned. At least userspace knows what is happening. - a memory slot that was accepted because it did fit the default IPA space now doesn't even get a chance to be registered. The other thing that is left doing is to convince userspace to actually use the IPA space setting instead of relying on the antiquated default. Fixes: 233a7cb2 ("kvm: arm64: Allow tuning the physical address size for VM") Signed-off-by:
Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Reviewed-by:
Andrew Jones <drjones@redhat.com> Reviewed-by:
Eric Auger <eric.auger@redhat.com> Link: https://lore.kernel.org/r/20210311100016.3830038-2-maz@kernel.org Signed-off-by:
-
Marc Zyngier authored
Commit 01dc9262 upstream. It recently became apparent that the ARMv8 architecture has interesting rules regarding attributes being used when fetching instructions if the MMU is off at Stage-1. In this situation, the CPU is allowed to fetch from the PoC and allocate into the I-cache (unless the memory is mapped with the XN attribute at Stage-2). If we transpose this to vcpus sharing a single physical CPU, it is possible for a vcpu running with its MMU off to influence another vcpu running with its MMU on, as the latter is expected to fetch from the PoU (and self-patching code doesn't flush below that level). In order to solve this, reuse the vcpu-private TLB invalidation code to apply the same policy to the I-cache, nuking it every time the vcpu runs on a physical CPU that ran another vcpu of the same VM in the past. This involve renaming __kvm_tlb_flush_local_vmid() to __kvm_flush_cpu_context(), and inserting a local i-cache invalidation there. Cc: stable@vger.kernel.org Signed-off-by:
Will Deacon <will@kernel.org> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20210303164505.68492-1-maz@kernel.org [maz: added 32bit ARM support] Signed-off-by:
-
Keith Busch authored
commit ac262508 upstream. If a namespace identification does not match the subsystem's head for that NSID, release the reference that was taken when the matching head was initially found. Signed-off-by:
Keith Busch <kbusch@kernel.org> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Keith Busch authored
commit d5675729 upstream. The driver had been unlinking the namespace head from the subsystem's list only after the last reference was released, and outside of the list's subsys->lock protection. There is no reason to track an empty head, so unlink the entry from the subsystem's list when the last namespace using that head is removed and with the mutex lock protecting the list update. The next namespace to attach reusing the previous NSID will allocate a new head rather than find the old head with mismatched identifiers. Signed-off-by:
-
Marc Zyngier authored
commit 262b003d upstream. When registering a memslot, we check the size and location of that memslot against the IPA size to ensure that we can provide guest access to the whole of the memory. Unfortunately, this check rejects memslot that end-up at the exact limit of the addressing capability for a given IPA size. For example, it refuses the creation of a 2GB memslot at 0x8000000 with a 32bit IPA space. Fix it by relaxing the check to accept a memslot reaching the limit of the IPA space. Fixes: c3058d5d ("arm/arm64: KVM: Ensure memslots are within KVM_PHYS_SIZE") Reviewed-by:
-
Josh Poimboeuf authored
commit e504e74c upstream. KASAN reserves "redzone" areas between stack frames in order to detect stack overruns. A read or write to such an area triggers a KASAN "stack-out-of-bounds" BUG. Normally, the ORC unwinder stays in-bounds and doesn't access the redzone. But sometimes it can't find ORC metadata for a given instruction. This can happen for code which is missing ORC metadata, or for generated code. In such cases, the unwinder attempts to fall back to frame pointers, as a best-effort type thing. This fallback often works, but when it doesn't, the unwinder can get confused and go off into the weeds into the KASAN redzone, triggering the aforementioned KASAN BUG. But in this case, the unwinder's confusion is actually harmless and working as designed. It already has checks in place to prevent off-stack accesses, but those checks get short-circuited by the KASAN BUG. And a BUG is a lot more disruptive than a harmless unwinder warning. Disable the KASAN checks by using READ_ONCE_NOCHECK() for all stack accesses. This finishes the job started by commit 881125bf ("x86/unwind: Disable KASAN checking in the ORC unwinder"), which only partially fixed the issue. Fixes: ee9f8fce ("x86/unwind: Add the ORC unwinder") Reported-by:
Ivan Babrou <ivan@cloudflare.com> Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Tested-by:
-
Lior Ribak authored
commit e7850f4d upstream. There is a deadlock in bm_register_write: First, in the begining of the function, a lock is taken on the binfmt_misc root inode with inode_lock(d_inode(root)). Then, if the user used the MISC_FMT_OPEN_FILE flag, the function will call open_exec on the user-provided interpreter. open_exec will call a path lookup, and if the path lookup process includes the root of binfmt_misc, it will try to take a shared lock on its inode again, but it is already locked, and the code will get stuck in a deadlock To reproduce the bug: $ echo ":iiiii:E::ii::/proc/sys/fs/binfmt_misc/bla:F" > /proc/sys/fs/binfmt_misc/register backtrace of where the lock occurs (#5): 0 schedule () at ./arch/x86/include/asm/current.h:15 1 0xffffffff81b51237 in rwsem_down_read_slowpath (sem=0xffff888003b202e0, count=<optimized out>, state=state@entry=2) at kernel/locking/rwsem.c:992 2 0xffffffff81b5150a in __down_read_common (state=2, sem=<optimized out>) at kernel/locking/rwsem.c:1213 3 __down_read (sem=<optimized out>) at kernel/locking/rwsem.c:1222 4 down_read (sem=<optimized out>) at kernel/locking/rwsem.c:1355 5 0xffffffff811ee22a in inode_lock_shared (inode=<optimized out>) at ./include/linux/fs.h:783 6 open_last_lookups (op=0xffffc9000022fe34, file=0xffff888004098600, nd=0xffffc9000022fd10) at fs/namei.c:3177 7 path_openat (nd=nd@entry=0xffffc9000022fd10, op=op@entry=0xffffc9000022fe34, flags=flags@entry=65) at fs/namei.c:3366 8 0xffffffff811efe1c in do_filp_open (dfd=<optimized out>, pathname=pathname@entry=0xffff8880031b9000, op=op@entry=0xffffc9000022fe34) at fs/namei.c:3396 9 0xffffffff811e493f in do_open_execat (fd=fd@entry=-100, name=name@entry=0xffff8880031b9000, flags=<optimized out>, flags@entry=0) at fs/exec.c:913 10 0xffffffff811e4a92 in open_exec (name=<optimized out>) at fs/exec.c:948 11 0xffffffff8124aa84 in bm_register_write (file=<optimized out>, buffer=<optimized out>, count=19, ppos=<optimized out>) at fs/binfmt_misc.c:682 12 0xffffffff811decd2 in vfs_write (file=file@entry=0xffff888004098500, buf=buf@entry=0xa758d0 ":iiiii:E::ii::i:CF ", count=count@entry=19, pos=pos@entry=0xffffc9000022ff10) at fs/read_write.c:603 13 0xffffffff811defda in ksys_write (fd=<optimized out>, buf=0xa758d0 ":iiiii:E::ii::i:CF ", count=19) at fs/read_write.c:658 14 0xffffffff81b49813 in do_syscall_64 (nr=<optimized out>, regs=0xffffc9000022ff58) at arch/x86/entry/common.c:46 15 0xffffffff81c0007c in entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:120 To solve the issue, the open_exec call is moved to before the write lock is taken by bm_register_write Link: https://lkml.kernel.org/r/20210228224414.95962-1-liorribak@gmail.com Fixes: 948b701a ("binfmt_misc: add persistent opened binary handler for containers") Signed-off-by:
Lior Ribak <liorribak@gmail.com> Acked-by:
Helge Deller <deller@gmx.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Naveen N. Rao authored
commit cea15316 upstream. 'lis r2,N' is 'addis r2,0,N' and the instruction encoding in the macro LIS_R2 is incorrect (it currently maps to 'addis r0,r2,N'). Fix the same. Fixes: c71b7eff ("powerpc: Add ABIv2 support to ppc_function_entry") Cc: stable@vger.kernel.org # v3.16+ Reported-by:
Jiri Olsa <jolsa@redhat.com> Signed-off-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Acked-by:
Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210304020411.16796-1-naveen.n.rao@linux.vnet.ibm.com Signed-off-by:
-
Mathieu Desnoyers authored
commit ce29ddc4 upstream. The function sync_runqueues_membarrier_state() should copy the membarrier state from the @mm received as parameter to each runqueue currently running tasks using that mm. However, the use of smp_call_function_many() skips the current runqueue, which is unintended. Replace by a call to on_each_cpu_mask(). Fixes: 227a4aad ("sched/membarrier: Fix p->mm->membarrier_state racy load") Reported-by:
Nadav Amit <nadav.amit@gmail.com> Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org # 5.4.x+ Link: https://lore.kernel.org/r/74F1E842-4A84-47BF-B6C2-5407DFDD4A4A@gmail.com Signed-off-by:
-
Minchan Kim authored
commit 57e0076e upstream. writeback_store's return value is overwritten by submit_bio_wait's return value. Thus, writeback_store will return zero since there was no IO error. In the end, write syscall from userspace will see the zero as return value, which could make the process stall to keep trying the write until it will succeed. Link: https://lkml.kernel.org/r/20210312173949.2197662-1-minchan@kernel.org Fixes: 3b82a051 ("drivers/block/zram/zram_drv.c: fix error return codes not being returned in writeback_store") Signed-off-by:
Minchan Kim <minchan@kernel.org> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Colin Ian King <colin.king@canonical.com> Cc: John Dias <joaodias@google.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Matthew Wilcox (Oracle) authored
[ Upstream commit 149fc787 ] Fix a sparse warning by using rcu_dereference(). Technically this is a bug and a sufficiently aggressive compiler could reload the `real_parent' pointer outside the protection of the rcu lock (and access freed memory), but I think it's pretty unlikely to happen. Link: https://lkml.kernel.org/r/20210221194207.1351703-1-willy@infradead.org Fixes: b18dc5f2 ("mm, oom: skip vforked tasks from being selected") Signed-off-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Reviewed-by:
Miaohe Lin <linmiaohe@huawei.com> Acked-by:
Michal Hocko <mhocko@suse.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Arnd Bergmann authored
[ Upstream commit cbf78d85 ] With clang-13, some functions only get partially inlined, with a specialized version referring to a global variable. This triggers a harmless build-time check for the intel-rng driver: WARNING: modpost: drivers/char/hw_random/intel-rng.o(.text+0xe): Section mismatch in reference from the function stop_machine() to the function .init.text:intel_rng_hw_init() The function stop_machine() references the function __init intel_rng_hw_init(). This is often because stop_machine lacks a __init annotation or the annotation of intel_rng_hw_init is wrong. In this instance, an easy workaround is to force the stop_machine() function to be inline, along with related interfaces that did not show the same behavior at the moment, but theoretically could. The combination of the two patches listed below triggers the behavior in clang-13, but individually these commits are correct. Link: https://lkml.kernel.org/r/20210225130153.1956990-1-arnd@kernel.org Fixes: fe5595c0 ("stop_machine: Provide stop_machine_cpuslocked()") Fixes: ee527cd3 ("Use stop_machine_run in the Intel RNG driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: "Paul E. McKenney" <paulmck@kernel.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Daniel Bristot de Oliveira <bristot@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by:
-
Anna-Maria Behnsen authored
[ Upstream commit 46eb1701 ] hrtimer_force_reprogram() and hrtimer_interrupt() invokes __hrtimer_get_next_event() to find the earliest expiry time of hrtimer bases. __hrtimer_get_next_event() does not update cpu_base::[softirq_]_expires_next to preserve reprogramming logic. That needs to be done at the callsites. hrtimer_force_reprogram() updates cpu_base::softirq_expires_next only when the first expiring timer is a softirq timer and the soft interrupt is not activated. That's wrong because cpu_base::softirq_expires_next is left stale when the first expiring timer of all bases is a timer which expires in hard interrupt context. hrtimer_interrupt() does never update cpu_base::softirq_expires_next which is wrong too. That becomes a problem when clock_settime() sets CLOCK_REALTIME forward and the first soft expiring timer is in the CLOCK_REALTIME_SOFT base. Setting CLOCK_REALTIME forward moves the clock MONOTONIC based expiry time of that timer before the stale cpu_base::softirq_expires_next. cpu_base::softirq_expires_next is cached to make the check for raising the soft interrupt fast. In the above case the soft interrupt won't be raised until clock monotonic reaches the stale cpu_base::softirq_expires_next value. That's incorrect, but what's worse it that if the softirq timer becomes the first expiring timer of all clock bases after the hard expiry timer has been handled the reprogramming of the clockevent from hrtimer_interrupt() will result in an interrupt storm. That happens because the reprogramming does not use cpu_base::softirq_expires_next, it uses __hrtimer_get_next_event() which returns the actual expiry time. Once clock MONOTONIC reaches cpu_base::softirq_expires_next the soft interrupt is raised and the storm subsides. Change the logic in hrtimer_force_reprogram() to evaluate the soft and hard bases seperately, update softirq_expires_next and handle the case when a soft expiring timer is the first of all bases by comparing the expiry times and updating the required cpu base fields. Split this functionality into a separate function to be able to use it in hrtimer_interrupt() as well without copy paste. Fixes: 5da70160 ("hrtimer: Implement support for softirq based hrtimers") Reported-by:
Mikael Beckius <mikael.beckius@windriver.com> Suggested-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by:
-
Ard Biesheuvel authored
[ Upstream commit 7ba8f2b2 ] 52-bit VA kernels can run on hardware that is only 48-bit capable, but configure the ID map as 52-bit by default. This was not a problem until recently, because the special T0SZ value for a 52-bit VA space was never programmed into the TCR register anwyay, and because a 52-bit ID map happens to use the same number of translation levels as a 48-bit one. This behavior was changed by commit 1401bef7 ("arm64: mm: Always update TCR_EL1 from __cpu_set_tcr_t0sz()"), which causes the unsupported T0SZ value for a 52-bit VA to be programmed into TCR_EL1. While some hardware simply ignores this, Mark reports that Amberwing systems choke on this, resulting in a broken boot. But even before that commit, the unsupported idmap_t0sz value was exposed to KVM and used to program TCR_EL2 incorrectly as well. Given that we already have to deal with address spaces being either 48-bit or 52-bit in size, the cleanest approach seems to be to simply default to a 48-bit VA ID map, and only switch to a 52-bit one if the placement of the kernel in DRAM requires it. This is guaranteed not to happen unless the system is actually 52-bit VA capable. Fixes: 90ec95cd ("arm64: mm: Introduce VA_BITS_MIN") Reported-by:
Mark Salter <msalter@redhat.com> Link: http://lore.kernel.org/r/20210310003216.410037-1-msalter@redhat.com Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210310171515.416643-2-ardb@kernel.org Signed-off-by:
-
Daiyue Zhang authored
[ Upstream commit 14fbbc82 ] Commit b0841eef ("configfs: provide exclusion between IO and removals") uses ->frag_dead to mark the fragment state, thus no bothering with extra refcount on config_item when opening a file. The configfs_get_config_item was removed in __configfs_open_file, but not with config_item_put. So the refcount on config_item will lost its balance, causing use-after-free issues in some occasions like this: Test: 1. Mount configfs on /config with read-only items: drwxrwx--- 289 root root 0 2021-04-01 11:55 /config drwxr-xr-x 2 root root 0 2021-04-01 11:54 /config/a --w--w--w- 1 root root 4096 2021-04-01 11:53 /config/a/1.txt ...... 2. Then run: for file in /config do echo $file grep -R 'key' $file done 3. __configfs_open_file will be called in parallel, the first one got called will do: if (file->f_mode & FMODE_READ) { if (!(inode->i_mode & S_IRUGO)) goto out_put_module; config_item_put(buffer->item); kref_put() package_details_release() kfree() the other one will run into use-after-free issues like this: BUG: KASAN: use-after-free in __configfs_open_file+0x1bc/0x3b0 Read of size 8 at addr fffffff155f02480 by task grep/13096 CPU: 0 PID: 13096 Comm: grep VIP: 00 Tainted: G W 4.14.116-kasan #1 TGID: 13096 Comm: grep Call trace: dump_stack+0x118/0x160 kasan_report+0x22c/0x294 __asan_load8+0x80/0x88 __configfs_open_file+0x1bc/0x3b0 configfs_open_file+0x28/0x34 do_dentry_open+0x2cc/0x5c0 vfs_open+0x80/0xe0 path_openat+0xd8c/0x2988 do_filp_open+0x1c4/0x2fc do_sys_open+0x23c/0x404 SyS_openat+0x38/0x48 Allocated by task 2138: kasan_kmalloc+0xe0/0x1ac kmem_cache_alloc_trace+0x334/0x394 packages_make_item+0x4c/0x180 configfs_mkdir+0x358/0x740 vfs_mkdir2+0x1bc/0x2e8 SyS_mkdirat+0x154/0x23c el0_svc_naked+0x34/0x38 Freed by task 13096: kasan_slab_free+0xb8/0x194 kfree+0x13c/0x910 package_details_release+0x524/0x56c kref_put+0xc4/0x104 config_item_put+0x24/0x34 __configfs_open_file+0x35c/0x3b0 configfs_open_file+0x28/0x34 do_dentry_open+0x2cc/0x5c0 vfs_open+0x80/0xe0 path_openat+0xd8c/0x2988 do_filp_open+0x1c4/0x2fc do_sys_open+0x23c/0x404 SyS_openat+0x38/0x48 el0_svc_naked+0x34/0x38 To fix this issue, remove the config_item_put in __configfs_open_file to balance the refcount of config_item. Fixes: b0841eef ("configfs: provide exclusion between IO and removals") Signed-off-by:
Daiyue Zhang <zhangdaiyue1@huawei.com> Signed-off-by:
Yi Chen <chenyi77@huawei.com> Signed-off-by:
Ge Qiu <qiuge@huawei.com> Reviewed-by:
Chao Yu <yuchao0@huawei.com> Acked-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Jia-Ju Bai authored
[ Upstream commit df66617b ] When create_singlethread_workqueue returns NULL to card->event_wq, no error return code of rsxx_pci_probe() is assigned. To fix this bug, st is assigned with -ENOMEM in this case. Fixes: 8722ff8c ("block: IBM RamSan 70/80 device driver") Reported-by:
TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Link: https://lore.kernel.org/r/20210310033017.4023-1-baijiaju1990@gmail.com Signed-off-by:
-
Ondrej Mosnacek authored
[ Upstream commit 53cb2454 ] An xattr 'get' handler is expected to return the length of the value on success, yet _nfs4_get_security_label() (and consequently also nfs4_xattr_get_nfs4_label(), which is used as an xattr handler) returns just 0 on success. Fix this by returning label.len instead, which contains the length of the result. Fixes: aa9c2669 ("NFS: Client implementation of Labeled-NFS") Signed-off-by:
Ondrej Mosnacek <omosnace@redhat.com> Reviewed-by:
James Morris <jamorris@linux.microsoft.com> Reviewed-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Trond Myklebust authored
[ Upstream commit 47397915 ] The fact that the lookup revalidation failed, does not mean that the inode contents have changed. Fixes: 5ceb9d7f ("NFS: Refactor nfs_lookup_revalidate()") Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
Trond Myklebust authored
[ Upstream commit 82e7ca13 ] There should be no reason to expect the directory permissions to change just because the directory contents changed or a negative lookup timed out. So let's avoid doing a full call to nfs_mark_for_revalidate() in that case. Furthermore, if this is a negative dentry, and we haven't actually done a new lookup, then we have no reason yet to believe the directory has changed at all. So let's remove the gratuitous directory inode invalidation altogether when called from nfs_lookup_revalidate_negative(). Reported-by:
Geert Jansen <gerardu@amazon.com> Fixes: 5ceb9d7f ("NFS: Refactor nfs_lookup_revalidate()") Signed-off-by:
-
Benjamin Coddington authored
[ Upstream commit f0940f4b ] We could recurse into NFS doing memory reclaim while sending a sync task, which might result in a deadlock. Set memalloc_nofs_save for sync task execution. Fixes: a1231fda ("SUNRPC: Set memalloc_nofs_save() on all rpciod/xprtiod jobs") Signed-off-by:
Benjamin Coddington <bcodding@redhat.com> Signed-off-by:
-
Anshuman Khandual authored
[ Upstream commit eeb0753b ] pfn_valid() validates a pfn but basically it checks for a valid struct page backing for that pfn. It should always return positive for memory ranges backed with struct page mapping. But currently pfn_valid() fails for all ZONE_DEVICE based memory types even though they have struct page mapping. pfn_valid() asserts that there is a memblock entry for a given pfn without MEMBLOCK_NOMAP flag being set. The problem with ZONE_DEVICE based memory is that they do not have memblock entries. Hence memblock_is_map_memory() will invariably fail via memblock_search() for a ZONE_DEVICE based address. This eventually fails pfn_valid() which is wrong. memblock_is_map_memory() needs to be skipped for such memory ranges. As ZONE_DEVICE memory gets hotplugged into the system via memremap_pages() called from a driver, their respective memory sections will not have SECTION_IS_EARLY set. Normal hotplug memory will never have MEMBLOCK_NOMAP set in their memblock regions. Because the flag MEMBLOCK_NOMAP was specifically designed and set for firmware reserved memory regions. memblock_is_map_memory() can just be skipped as its always going to be positive and that will be an optimization for the normal hotplug memory. Like ZONE_DEVICE based memory, all normal hotplugged memory too will not have SECTION_IS_EARLY set for their sections Skipping memblock_is_map_memory() for all non early memory sections would fix pfn_valid() problem for ZONE_DEVICE based memory and also improve its performance for normal hotplug memory as well. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Acked-by:
David Hildenbrand <david@redhat.com> Fixes: 73b20c84 ("arm64: mm: implement pte_devmap support") Signed-off-by:
Anshuman Khandual <anshuman.khandual@arm.com> Acked-by:
-
Sergey Shtylyov authored
[ Upstream commit 75be7fb7 ] According to the RZ/A1H Group, RZ/A1M Group User's Manual: Hardware, Rev. 4.00, the TRSCER register has bit 9 reserved, hence we can't use the driver's default TRSCER mask. Add the explicit initializer for sh_eth_cpu_data::trscer_err_mask for R7S72100. Fixes: db893473 ("sh_eth: Add support for r7s72100") Signed-off-by:
Sergey Shtylyov <s.shtylyov@omprussia.ru> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
