- 09 Nov, 2020 17 commits
-
-
Harald Freudenberger authored
This patch adds notifications to userspace for two important conditions of the ap bus: I) Initial ap bus scan done. This indicates that the initial scan of all the ap devices (cards, queues) is complete and ap devices have been build up for all the hardware found. This condition is signaled with 1) An ap bus change uevent send to userspace with an environment key/value pair "INITSCAN=done": # udevadm monitor -k -p ... KERNEL[97.830919] change /devices/ap (ap) ACTION=change DEVPATH=/devices/ap SUBSYSTEM=ap INITSCAN=done SEQNUM=10421 2) A sysfs attribute /sys/bus/ap/scans which shows the number of completed ap bus scans done since bus init. So a value of 1 or greater signals that the initial ap bus scan is complete. Note: The initial ap bus scan complete condition is fulfilled and will be signaled even if there was no ap resource found. II) APQN driver bindings complete. This indicates that all APQNs have been bound to an zcrypt or alternate device driver. Only with the help of an device driver an APQN can be used for crypto load. So the binding complete condition is the starting point for user space to be sure all crypto resources on the ap bus are available for use. This condition is signaled with 1) An ap bus change uevent send to userspace with an environment key/value pair "BINDINGS=complete": # udevadm monitor -k -p ... KERNEL[97.830975] change /devices/ap (ap) ACTION=change DEVPATH=/devices/ap SUBSYSTEM=ap BINDINGS=complete SEQNUM=10422 2) A sysfs attribute /sys/bus/ap/bindings showing "<nr of bound apqns>/<total nr of apqns> (complete)" when all available apqns have been bound to device drivers, or "<nr of bound apqns>/<total nr of apqns>" when there are some apqns not bound to an device driver. Note: The binding complete condition is also fulfilled, when there are no apqns available to bind any device driver. In this case the binding complete will be signaled AFTER init scan is done. Note: This condition may arise multiple times when after initial scan modifications on the bindings take place. For example a manual unbind of an APQN switches the binding complete condition off. When at a later time the unbound APQNs are bound with an device driver the binding is (again) complete resulting in another uevent and marking the bindings sysfs attribute with '(complete)'. There is also a new function to be used within the kernel: int ap_wait_init_apqn_bindings_complete(unsigned long timeout) Interface to wait for the AP bus to have done one initial ap bus scan and all detected APQNs have been bound to device drivers. If these both conditions are not fulfilled, this function blocks on a condition with wait_for_completion_interruptible_timeout(). If these both conditions are fulfilled (before the timeout hits) the return value is 0. If the timeout (in jiffies) hits instead -ETIME is returned. On failures negative return values are returned to the caller. Please note that further unbind/bind actions after initial binding complete is through do not cause this function to block again. Reviewed-by:Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by:
Harald Freudenberger <freude@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com>
-
Christian Borntraeger authored
The s390-trng does provide 100% entropy. The quality value is supported to be between 1 and 1024 and not 1..1000. Use 1024 to make this driver the preferred one. If we ever have a better driver that has the same quality but is faster we can change this again when merging the new driver. No need to be conservative. This makes sure that the hw variant is preferred over things like virtio-rng, where the hypervisor has a potential to be misconfigured and thus should have a slightly lower confidence. Cc: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
Daniel Vetter authored
Way back it was a reasonable assumptions that iomem mappings never change the pfn range they point at. But this has changed: - gpu drivers dynamically manage their memory nowadays, invalidating ptes with unmap_mapping_range when buffers get moved - contiguous dma allocations have moved from dedicated carvetouts to cma regions. This means if we miss the unmap the pfn might contain pagecache or anon memory (well anything allocated with GFP_MOVEABLE) - even /dev/mem now invalidates mappings when the kernel requests that iomem region when CONFIG_IO_STRICT_DEVMEM is set, see commit 3234ac66 ("/dev/mem: Revoke mappings when a driver claims the region") Accessing pfns obtained from ptes without holding all the locks is therefore no longer a good idea. Fix this. Since zpci_memcpy_from|toio seems to not do anything nefarious with locks we just need to open code get_pfn and follow_pfn and make sure we drop the locks only after we're done. The write function also needs the copy_from_user move, since we can't take userspace faults while holding the mmap sem. Reviewed-by:
Gerald Schaefer <gerald.schaefer@linux.ibm.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: John Hubbard <jhubbard@nvidia.com> Cc: JÃ
© rôme Glisse <jglisse@redhat.com> Cc: Jan Kara <jack@suse.cz> Cc: linux-mm@kvack.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-media@vger.kernel.org Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Cc: linux-s390@vger.kernel.org Cc: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by:
-
Vasily Gorbik authored
And move it earlier in the decompressor. Reviewed-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
-
Vasily Gorbik authored
Also correct rounding downs in estimation calculations. Reviewed-by:
Alexander Egorenkov <egorenar@linux.ibm.com> Signed-off-by:
-
Vasily Gorbik authored
It is relying on _REGION1_SHIFT / _REGION2_SHIFT values which come from asm/pgtable.h, so include it. Reviewed-by:
-
Vasily Gorbik authored
Kasan early code is only working on init_mm, remove unneeded pgd parameter from kasan_copy_shadow and rename it to kasan_copy_shadow_mapping. Reviewed-by:
-
Vasily Gorbik authored
Kasan has nothing to do with vmemmap, strip vmemmap from function names to avoid confusing people. Reviewed-by:
-
Vasily Gorbik authored
Fixes the following warning with CONFIG_KERNEL_UNCOMPRESSED=y arch/s390/boot/compressed/decompressor.h:6:46: warning: non-void function does not return a value [-Wreturn-type] static inline void *decompress_kernel(void) {} ^ Signed-off-by: -
Heiko Carstens authored
To make sure that the vmalloc area size is for almost all cases large enough let it depend on the (potential) physical memory size. There is still the possibility to override this with the vmalloc kernel command line parameter. Reviewed-by:
Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by:
-
Heiko Carstens authored
We've seen several occurences in the past where the default vmalloc size of 128GB is not sufficient. Therefore extend the default size. Reviewed-by:
-
Vasily Gorbik authored
Since commit 29d37e5b ("s390/protvirt: add ultravisor initialization") vmax is adjusted to the ultravisor secure storage limit. This limit is currently applied when 4-level paging is used. Later vmax is also used to align vmemmap address to the top region table entry border. When vmax is set to the ultravisor secure storage limit this is no longer the case. Instead of changing vmax, make only MODULES_END be affected by the secure storage limit, so that vmax stays intact for further vmemmap address alignment. Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
-
Vasily Gorbik authored
Compiling the kernel with Kasan disables automatic 3-level vs 4-level kernel space paging selection, because the shadow memory offset has to be known at compile time and there is no such offset which would be acceptable for both 3 and 4-level paging. Instead S390_4_LEVEL_PAGING option was introduced which allowed to pick how many paging levels to use under Kasan. With the introduction of protected virtualization, kernel memory layout may be affected due to ultravisor secure storage limit. This adds additional complexity into how memory layout would look like in combination with Kasan predefined shadow memory offsets. To simplify this make Kasan 4-level paging default and remove Kasan 3-level paging support. Suggested-by:
-
Vasily Gorbik authored
s390_base_ext_handler_fn haven't been used since its introduction in commit ab14de6c ("[S390] Convert memory detection into C code."). s390_base_ext_handler itself is currently falsely storing 16 registers at __LC_SAVE_AREA_ASYNC rewriting several following lowcore values: cpu_flags, return_psw, return_mcck_psw, sync_enter_timer and async_enter_timer. Besides that s390_base_ext_handler itself is only potentially hiding EXT interrupts which should not have happen in the first place. Any piece of code which requires EXT interrupts before fully functional ext_int_handler is enabled has to do it on its own, like this is done by sclp_early_cmd() which is doing EXT interrupts handling synchronously in sclp_early_wait_irq(). With s390_base_ext_handler removed unexpected EXT interrupt leads to disabled wait with the address 0x1b0 (__LC_EXT_NEW_PSW), which is currently setup in the decompressor. Reviewed-by:
-
Vasily Gorbik authored
Currently udelay relies on working EXT interrupts handler, which is not the case during early startup. In such cases udelay_simple() has to be used instead. To avoid mistakes of calling udelay too early, which could happen from the common code as well - make udelay work for the early code by introducing static branch and redirecting all udelay calls to udelay_simple until EXT interrupts handler is fully initialized and async stack is allocated. Reviewed-by:
-
Vasily Gorbik authored
Set io/ext handlers to disabled wait in the initial lowcore, so that they are effective right from the kernel start, when a boot method used does not rewrite this part of the lowcore for its own needs (i.e. kexec, z/vm ipl reader boot, qemu direct boot, load from removable media or server). When the kernel is loaded by zipl, scsi loader or qemu loader, some or all of the io/ext/pgm handlers addresses might be rewritten. Rewrite them to initial values again as early as possible. Reviewed-by:
-
Linus Torvalds authored
-
- 08 Nov, 2020 13 commits
-
-
Linus Torvalds authored
Merge tag 'driver-core-5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core documentation fixes from Greg KH: "Some small Documentation fixes that were fallout from the larger documentation update we did in 5.10-rc2. Nothing major here at all, but all of these have been in linux-next and resolve build warnings when building the documentation files" * tag 'driver-core-5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: Documentation: remove mic/index from misc-devices/index.rst scripts: get_api.pl: Add sub-titles to ABI output scripts: get_abi.pl: Don't let ABI files to create subtitles docs: leds: index.rst: add a missing file docs: ABI: sysfs-class-net: fix a typo docs: ABI: sysfs-driver-dma-ioatdma: what starts with /sys
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/ttyLinus Torvalds authored
Pull tty/serial fixes from Greg KH: "Here are a small number of small tty and serial fixes for some reported problems for the tty core, vt code, and some serial drivers. They include fixes for: - a buggy and obsolete vt font ioctl removal - 8250_mtk serial baudrate runtime warnings - imx serial earlycon build configuration fix - txx9 serial driver error path cleanup issues - tty core fix in release_tty that can be triggered by trying to bind an invalid serial port name to a speakup console device Almost all of these have been in linux-next without any problems, the only one that hasn't, just deletes code :)" * tag 'tty-5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: vt: Disable KD_FONT_OP_COPY tty: fix crash in release_tty if tty->port is not set serial: txx9: add missing platform_driver_unregister() on error in serial_txx9_init tty: serial: imx: enable earlycon by default if IMX_SERIAL_CONSOLE is enabled serial: 8250_mtk: Fix uart_get_baud_rate warning -
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds authored
Pull USB fixes from Greg KH: "Here are some small USB fixes and new device ids: - USB gadget fixes for some reported issues - Fixes for the ever-troublesome apple fastcharge driver, hopefully we finally have it right. - More USB core quirks for odd devices - USB serial driver fixes for some long-standing issues that were recently found - some new USB serial driver device ids All have been in linux-next with no reported issues" * tag 'usb-5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: USB: apple-mfi-fastcharge: fix reference leak in apple_mfi_fc_set_property usb: mtu3: fix panic in mtu3_gadget_stop() USB: serial: option: add Telit FN980 composition 0x1055 USB: serial: option: add LE910Cx compositions 0x1203, 0x1230, 0x1231 USB: serial: cyberjack: fix write-URB completion race USB: Add NO_LPM quirk for Kingston flash drive USB: serial: option: add Quectel EC200T module support usb: raw-gadget: fix memory leak in gadget_setup usb: dwc2: Avoid leaving the error_debugfs label unused usb: dwc3: ep0: Fix delay status handling usb: gadget: fsl: fix null pointer checking usb: gadget: goku_udc: fix potential crashes in probe usb: dwc3: pci: add support for the Intel Alder Lake-S -
Eddy Wu authored
current->group_leader->exit_signal may change during copy_process() if current->real_parent exits. Move the assignment inside tasklist_lock to avoid the race. Signed-off-by:
Eddy Wu <eddy_wu@trendmicro.com> Acked-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Daniel Vetter authored
It's buggy: On Fri, Nov 06, 2020 at 10:30:08PM +0800, Minh Yuan wrote: > We recently discovered a slab-out-of-bounds read in fbcon in the latest > kernel ( v5.10-rc2 for now ). The root cause of this vulnerability is that > "fbcon_do_set_font" did not handle "vc->vc_font.data" and > "vc->vc_font.height" correctly, and the patch > <https://lkml.org/lkml/2020/9/27/223> for VT_RESIZEX can't handle this > issue. > > Specifically, we use KD_FONT_OP_SET to set a small font.data for tty6, and > use KD_FONT_OP_SET again to set a large font.height for tty1. After that, > we use KD_FONT_OP_COPY to assign tty6's vc_font.data to tty1's vc_font.data > in "fbcon_do_set_font", while tty1 retains the original larger > height. Obviously, this will cause an out-of-bounds read, because we can > access a smaller vc_font.data with a larger vc_font.height. Further there was only one user ever. - Android's loadfont, busybox and console-tools only ever use OP_GET and OP_SET - fbset documentation only mentions the kernel cmdline font: option, not anything else. - systemd used OP_COPY before release 232 published in Nov 2016 Now unfortunately the crucial report seems to have gone down with gmane, and the commit message doesn't say much. But the pull request hints at OP_COPY being broken https://github.com/systemd/systemd/pull/3651 So in other words, this never worked, and the only project which foolishly every tried to use it, realized that rather quickly too. Instead of trying to fix security issues here on dead code by adding missing checks, fix the entire thing by removing the functionality. Note that systemd code using the OP_COPY function ignored the return value, so it doesn't matter what we're doing here really - just in case a lone server somewhere happens to be extremely unlucky and running an affected old version of systemd. The relevant code from font_copy_to_all_vcs() in systemd was: /* copy font from active VT, where the font was uploaded to */ cfo.op = KD_FONT_OP_COPY; cfo.height = vcs.v_active-1; /* tty1 == index 0 */ (void) ioctl(vcfd, KDFONTOP, &cfo); Note this just disables the ioctl, garbage collecting the now unused callbacks is left for -next. v2: Tetsuo found the old mail, which allowed me to find it on another archive. Add the link too. Acked-by:
Peilin Ye <yepeilin.cs@gmail.com> Reported-by:
Minh Yuan <yuanmingbuaa@gmail.com> References: https://lists.freedesktop.org/archives/systemd-devel/2016-June/036935.html References: https://github.com/systemd/systemd/pull/3651 Cc: Greg KH <greg@kroah.com> Cc: Peilin Ye <yepeilin.cs@gmail.com> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds authored
Pull xfs fixes from Darrick Wong: - Fix an uninitialized struct problem - Fix an iomap problem zeroing unwritten EOF blocks - Fix some clumsy error handling when writeback fails on filesystems with blocksize < pagesize - Fix a retry loop not resetting loop variables properly - Fix scrub flagging rtinherit inodes on a non-rt fs, since the kernel actually does permit that combination - Fix excessive page cache flushing when unsharing part of a file * tag 'xfs-5.10-fixes-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: only flush the unshared range in xfs_reflink_unshare xfs: fix scrub flagging rtinherit even if there is no rt device xfs: fix missing CoW blocks writeback conversion retry iomap: clean up writeback state logic on writepage error iomap: support partial page discard on writeback block mapping failure xfs: flush new eof page on truncate to avoid post-eof corruption xfs: set xefi_discard when creating a deferred agfl free log intent item
-
Linus Torvalds authored
Merge procfs splice read fixes from Christoph Hellwig: "Greg reported a problem due to the fact that Android tests use procfs files to test splice, which stopped working with the changes for set_fs() removal. This series adds read_iter support for seq_file, and uses those for various proc files using seq_file to restore splice read support" [ Side note: Christoph initially had a scripted "move everything over" patch, which looks fine, but I personally would prefer us to actively discourage splice() on random files. So this does just the minimal basic core set of proc file op conversions. For completeness, and in case people care, that script was sed -i -e 's/\.proc_read\(\s*=\s*\)seq_read/\.proc_read_iter\1seq_read_iter/g' but I'll wait and see if somebody has a strong argument for using splice on random small /proc files before I'd run it on the whole kernel. - Linus ] * emailed patches from Christoph Hellwig <hch@lst.de>: proc "seq files": switch to ->read_iter proc "single files": switch to ->read_iter proc/stat: switch to ->read_iter proc/cpuinfo: switch to ->read_iter proc: wire up generic_file_splice_read for iter ops seq_file: add seq_read_iter -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Thomas Gleixner: "A set of x86 fixes: - Use SYM_FUNC_START_WEAK in the mem* ASM functions instead of a combination of .weak and SYM_FUNC_START_LOCAL which makes LLVMs integrated assembler upset - Correct the mitigation selection logic which prevented the related prctl to work correctly - Make the UV5 hubless system work correctly by fixing up the malformed table entries and adding the missing ones" * tag 'x86-urgent-2020-11-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/platform/uv: Recognize UV5 hubless system identifier x86/platform/uv: Remove spaces from OEM IDs x86/platform/uv: Fix missing OEM_TABLE_ID x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP x86/lib: Change .weak to SYM_FUNC_START_WEAK for arch/x86/lib/mem*_64.S -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fix from Thomas Gleixner: "A single fix for the perf core plugging a memory leak in the address filter parser" * tag 'perf-urgent-2020-11-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/core: Fix a memory leak in perf_event_parse_addr_filter()
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull futex fix from Thomas Gleixner: "A single fix for the futex code where an intermediate state in the underlying RT mutex was not handled correctly and triggering a BUG() instead of treating it as another variant of retry condition" * tag 'locking-urgent-2020-11-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: futex: Handle transient "ownerless" rtmutex state correctly
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fixes from Thomas Gleixner: "A set of fixes for interrupt chip drivers: - Fix the fallout of the IPI as interrupt conversion in Kconfig and the BCM2836 interrupt chip driver - Fixes for interrupt affinity setting and the handling of hierarchical irq domains in the SiFive PLIC driver - Make the unmapped event handling in the TI SCI driver work correctly - A few minor fixes and cleanups in various chip drivers and Kconfig" * tag 'irq-urgent-2020-11-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: dt-bindings: irqchip: ti, sci-inta: Fix diagram indentation for unmapped events irqchip/ti-sci-inta: Add support for unmapped event handling dt-bindings: irqchip: ti, sci-inta: Update for unmapped event handling irqchip/renesas-intc-irqpin: Merge irlm_bit and needs_irlm irqchip/sifive-plic: Fix chip_data access within a hierarchy irqchip/sifive-plic: Fix broken irq_set_affinity() callback irqchip/stm32-exti: Add all LP timer exti direct events support irqchip/bcm2836: Fix missing __init annotation irqchip/mips: Drop selection of IRQ_DOMAIN_HIERARCHY irqchip/mst: Make mst_intc_of_init static irqchip/mst: MST_IRQ should depend on ARCH_MEDIATEK or ARCH_MSTARV7 genirq: Let GENERIC_IRQ_IPI select IRQ_DOMAIN_HIERARCHY -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull entry code fix from Thomas Gleixner: "A single fix for the generic entry code to correct the wrong assumption that the lockdep interrupt state needs not to be established before calling the RCU check" * tag 'core-urgent-2020-11-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: entry: Fix the incorrect ordering of lockdep and RCU check
-
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds authored
Pull powerpc fixes from Michael Ellerman: - fix miscompilation with GCC 4.9 by using asm_goto_volatile for put_user() - fix for an RCU splat at boot caused by a recent lockdep change - fix for a possible deadlock in our EEH debugfs code - several fixes for handling of _PAGE_ACCESSED on 32-bit platforms - build fix when CONFIG_NUMA=n Thanks to Andreas Schwab, Christophe Leroy, Oliver O'Halloran, Qian Cai, and Scott Cheloha. * tag 'powerpc-5.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/numa: Fix build when CONFIG_NUMA=n powerpc/8xx: Manage _PAGE_ACCESSED through APG bits in L1 entry powerpc/8xx: Always fault when _PAGE_ACCESSED is not set powerpc/40x: Always fault when _PAGE_ACCESSED is not set powerpc/603: Always fault when _PAGE_ACCESSED is not set powerpc: Use asm_goto_volatile for put_user() powerpc/smp: Call rcu_cpu_starting() earlier powerpc/eeh_cache: Fix a possible debugfs deadlock
-
- 07 Nov, 2020 10 commits
-
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull block fixes from Jens Axboe: - NVMe pull request from Christoph: - revert a nvme_queue size optimization (Keith Bush) - fabrics timeout races fixes (Chao Leng and Sagi Grimberg)" - null_blk zone locking fix (Damien) * tag 'block-5.10-2020-11-07' of git://git.kernel.dk/linux-block: null_blk: Fix scheduling in atomic with zoned mode nvme-tcp: avoid repeated request completion nvme-rdma: avoid repeated request completion nvme-tcp: avoid race between time out and tear down nvme-rdma: avoid race between time out and tear down nvme: introduce nvme_sync_io_queues Revert "nvme-pci: remove last_sq_tail" -
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull io_uring fixes from Jens Axboe: "A set of fixes for io_uring: - SQPOLL cancelation fixes - Two fixes for the io_identity COW - Cancelation overflow fix (Pavel) - Drain request cancelation fix (Pavel) - Link timeout race fix (Pavel)" * tag 'io_uring-5.10-2020-11-07' of git://git.kernel.dk/linux-block: io_uring: fix link lookup racing with link timeout io_uring: use correct pointer for io_uring_show_cred() io_uring: don't forget to task-cancel drained reqs io_uring: fix overflowed cancel w/ linked ->files io_uring: drop req/tctx io_identity separately io_uring: ensure consistent view of original task ->mm from SQPOLL io_uring: properly handle SQPOLL request cancelations io-wq: cancel request if it's asking for files and we don't have them
-
Mike Galbraith authored
Gratian managed to trigger the BUG_ON(!newowner) in fixup_pi_state_owner(). This is one possible chain of events leading to this: Task Prio Operation T1 120 lock(F) T2 120 lock(F) -> blocks (top waiter) T3 50 (RT) lock(F) -> boosts T1 and blocks (new top waiter) XX timeout/ -> wakes T2 signal T1 50 unlock(F) -> wakes T3 (rtmutex->owner == NULL, waiter bit is set) T2 120 cleanup -> try_to_take_mutex() fails because T3 is the top waiter and the lower priority T2 cannot steal the lock. -> fixup_pi_state_owner() sees newowner == NULL -> BUG_ON() The comment states that this is invalid and rt_mutex_real_owner() must return a non NULL owner when the trylock failed, but in case of a queued and woken up waiter rt_mutex_real_owner() == NULL is a valid transient state. The higher priority waiter has simply not yet managed to take over the rtmutex. The BUG_ON() is therefore wrong and this is just another retry condition in fixup_pi_state_owner(). Drop the locks, so that T3 can make progress, and then try the fixup again. Gratian provided a great analysis, traces and a reproducer. The analysis is to the point, but it confused the hell out of that tglx dude who had to page in all the futex horrors again. Condensed version is above. [ tglx: Wrote comment and changelog ] Fixes: c1e2f0ea ("futex: Avoid violating the 10th rule of futex") Reported-by:Gratian Crisan <gratian.crisan@ni.com> Signed-off-by:
Mike Galbraith <efault@gmx.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87a6w6x7bb.fsf@ni.com Link: https://lore.kernel.org/r/87sg9pkvf7.fsf@nanos.tec.linutronix.de
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c fixes from Wolfram Sang: "Driver bugfixes for I2C. Most of them are for the new mlxbf driver which got more exposure after rc1. The sh_mobile patch should already have reached you during the merge window, but I accidently dropped it. However, since it fixes a problem with rebooting, it is still fine for rc3" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: designware: slave should do WRITE_REQUESTED before WRITE_RECEIVED i2c: designware: call i2c_dw_read_clear_intrbits_slave() once i2c: mlxbf: I2C_MLXBF should depend on MELLANOX_PLATFORM i2c: mlxbf: Update author and maintainer email info i2c: mlxbf: Update reference clock frequency i2c: mlxbf: Remove unecessary wrapper functions i2c: mlxbf: Fix resrticted cast warning of sparse i2c: mlxbf: Add CONFIG_ACPI to guard ACPI function call i2c: sh_mobile: implement atomic transfers i2c: mediatek: move dma reset before i2c reset
-
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linuxLinus Torvalds authored
Pull RISC-V fixes from Palmer Dabbelt: - SPDX comment style fix - ignore memory that is unusable - avoid setting a kernel text offset for the !MMU kernels, where skipping the first page of memory is both unnecessary and costly - avoid passing the flag bits in satp to pfn_to_virt() - fix __put_kernel_nofault, where we had the arguments to __put_user_nocheck reversed - workaround for a bug in the FU540 to avoid triggering PMP issues during early boot - change to how we pull symbols out of the vDSO. The old mechanism was removed from binutils-2.35 (and has been backported to Debian's 2.34) * tag 'riscv-for-linus-5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: RISC-V: Fix the VDSO symbol generaton for binutils-2.35+ RISC-V: Use non-PGD mappings for early DTB access riscv: uaccess: fix __put_kernel_nofault() riscv: fix pfn_to_virt err in do_page_fault(). riscv: Set text_offset correctly for M-Mode RISC-V: Remove any memblock representing unusable memory area risc-v: kernel: ftrace: Fixes improper SPDX comment style
-
Greg Kroah-Hartman authored
Merge tag 'usb-serial-5.10-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fixes for 5.10-rc3 Here's a fix for a long-standing issue with the cyberjack driver and some new device ids. All have been in linux-next with no reported issues. * tag 'usb-serial-5.10-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: option: add Telit FN980 composition 0x1055 USB: serial: option: add LE910Cx compositions 0x1203, 0x1230, 0x1231 USB: serial: cyberjack: fix write-URB completion race USB: serial: option: add Quectel EC200T module support
-
kiyin(尹亮) authored
As shown through runtime testing, the "filename" allocation is not always freed in perf_event_parse_addr_filter(). There are three possible ways that this could happen: - It could be allocated twice on subsequent iterations through the loop, - or leaked on the success path, - or on the failure path. Clean up the code flow to make it obvious that 'filename' is always freed in the reallocation path and in the two return paths as well. We rely on the fact that kfree(NULL) is NOP and filename is initialized with NULL. This fixes the leak. No other side effects expected. [ Dan Carpenter: cleaned up the code flow & added a changelog. ] [ Ingo Molnar: updated the changelog some more. ] Fixes: 375637bc ("perf/core: Introduce address range filtering") Signed-off-by:
"kiyin(尹亮)" <kiyin@tencent.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Cc: "Srivatsa S. Bhat" <srivatsa@csail.mit.edu> Cc: Anthony Liguori <aliguori@amazon.com> -- kernel/events/core.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-)
-
Mike Travis authored
Testing shows a problem in that UV5 hubless systems were not being recognized. Add them to the list of OEM IDs checked. Fixes: 6c779442 ("Add UV5 direct references") Signed-off-by:
Mike Travis <mike.travis@hpe.com> Signed-off-by:
-
Mike Travis authored
Testing shows that trailing spaces caused problems with the OEM_ID and the OEM_TABLE_ID. One being that the OEM_ID would not string compare correctly. Another the OEM_ID and OEM_TABLE_ID would be concatenated in the printout. Remove any trailing spaces. Fixes: 1e61f5a9 ("Add and decode Arch Type in UVsystab") Signed-off-by:
-
Mike Travis authored
Testing shows a problem in that the OEM_TABLE_ID was missing for hubless systems. This is used to determine the APIC type (legacy or extended). Add the OEM_TABLE_ID to the early hubless processing. Fixes: 1e61f5a9 ("Add and decode Arch Type in UVsystab") Signed-off-by:
-
