- 14 Feb, 2024 2 commits
-
-
Nathan Chancellor authored
When building with CONFIG_LD_ORPHAN_WARN after selecting CONFIG_ARCH_HAS_LD_ORPHAN_WARN, there are a lot of warnings around '.data.rel' sections: s390-linux-ld: warning: orphan section `.data.rel' from `kernel/sched/build_utility.o' being placed in section `.data.rel' s390-linux-ld: warning: orphan section `.data.rel.local' from `kernel/sched/build_utility.o' being placed in section `.data.rel.local' s390-linux-ld: warning: orphan section `.data.rel.ro' from `kernel/sched/build_utility.o' being placed in section `.data.rel.ro' s390-linux-ld: warning: orphan section `.data.rel.ro.local' from `kernel/sched/build_utility.o' being placed in section `.data.rel.ro.local' Describe these in vmlinux.lds.S so there is no more warning and the sections are placed consistently between linkers. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Justin Stitt <justinstitt@google.com> Link: https://lore.kernel.org/r/20240207-s390-lld-and-orphan-warn-v1-2-8a665b3346ab@kernel.orgSigned-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Nathan Chancellor authored
arch/s390/boot/vmlinux uses a different linker script and build rules than the main vmlinux, so the '--orphan-handling' flag is not applied to it. Add support for '--orphan-handling' so that all sections are properly described in the linker script, which helps eliminate bugs between linker implementations having different orphan section heuristics. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Justin Stitt <justinstitt@google.com> Link: https://lore.kernel.org/r/20240207-s390-lld-and-orphan-warn-v1-1-8a665b3346ab@kernel.orgSigned-off-by: Heiko Carstens <hca@linux.ibm.com>
-
- 12 Feb, 2024 2 commits
-
-
Heiko Carstens authored
Move the switch_to() implementation to process.c and use the generic switch_to.h header file instead, like some other architectures. This addresses also the oddity that the old switch_to() implementation assigns the return value of __switch_to() to 'prev' instead of 'last', like it should. Remove also all includes of switch_to.h from C files, except process.c. Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Heiko Carstens authored
save_access_regs() and restore_access_regs() are only available by including switch_to.h. This is done by a couple of C files, which have nothing to do with switch_to(), but only need these functions. Move both functions to a new header file and improve the implementation: - Get rid of typedef - Add memory access instrumentation support - Use long displacement instructions lamy/stamy instead of lam/stam - all current users end up with better code because of this Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
- 09 Feb, 2024 30 commits
-
-
Alexander Gordeev authored
Fix virtual vs physical address confusion. This does not fix a bug since virtual and physical address spaces are currently the same. Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Heiko Carstens authored
Code sections in s390 specific kernel code which use floating point or vector registers all come with a 520 byte stack variable to save already in use registers, if required. With INIT_STACK_ALL_PATTERN or INIT_STACK_ALL_ZERO enabled this variable will always be initialized on function entry in addition to saving register contents, which contradicts the intention (performance improvement) of such code sections. Therefore provide a DECLARE_KERNEL_FPU_ONSTACK() macro which provides struct kernel_fpu variables with an __uninitialized attribute, and convert all existing code to use this. This way only this specific type of stack variable will not be initialized, regardless of config options. Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20240205154844.3757121-3-hca@linux.ibm.comSigned-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Heiko Carstens authored
With INIT_STACK_ALL_PATTERN or INIT_STACK_ALL_ZERO enabled the kernel will be compiled with -ftrivial-auto-var-init=<...> which causes initialization of stack variables at function entry time. In order to avoid the performance impact that comes with this users can use the "uninitialized" attribute to prevent such initialization. Therefore provide the __uninitialized macro which can be used for cases where INIT_STACK_ALL_PATTERN or INIT_STACK_ALL_ZERO is enabled, but only selected variables should not be initialized. Acked-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20240205154844.3757121-2-hca@linux.ibm.comSigned-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the matrix_bus variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net> Acked-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: "Jason J. Herne" <jjherne@linux.ibm.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240203-bus_cleanup-s390-v1-6-ac891afc7282@marliere.netSigned-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the ap_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240203-bus_cleanup-s390-v1-5-ac891afc7282@marliere.netSigned-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the scm_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240203-bus_cleanup-s390-v1-4-ac891afc7282@marliere.netSigned-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the ccw_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240203-bus_cleanup-s390-v1-3-ac891afc7282@marliere.netSigned-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the css_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240203-bus_cleanup-s390-v1-2-ac891afc7282@marliere.netSigned-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the ccwgroup_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240203-bus_cleanup-s390-v1-1-ac891afc7282@marliere.netSigned-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the stp_subsys variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240204-bus_cleanup-s390_time-v1-1-d2120156982a@marliere.netSigned-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Nathan Chancellor authored
'-fPIC' as an option to the linker does not do what it seems like it should. With ld.bfd, it is treated as '-f PIC', which does not make sense based on the meaning of '-f': -f SHLIB, --auxiliary SHLIB Auxiliary filter for shared object symbol table When building with ld.lld (currently under review in a GitHub pull request), it just errors out because '-f' means nothing and neither does '-fPIC': ld.lld: error: unknown argument '-fPIC' '-fPIC' was blindly copied from CFLAGS when the vDSO stopped being linked with '$(CC)', it should not be needed. Remove it to clear up the build failure with ld.lld. Fixes: 2b2a2584 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO") Link: https://github.com/llvm/llvm-project/pull/75643Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Fangrui Song <maskray@google.com> Link: https://lore.kernel.org/r/20240130-s390-vdso-drop-fpic-from-ldflags-v1-1-094ad104fc55@kernel.orgSigned-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Heiko Carstens authored
The measurement block origin address is an absolute address; therefore add a missing virt_to_phys() translation to the cmf_activate() inline assembly. This doesn't fix a bug, since virtual and physical addresses are currently identical. Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Acked-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Heiko Carstens authored
The address of the measurement block can be anywhere in 64 bit absolute space. See description of the schm instruction in the Principles of Operation. Therefore remove the GFP_DMA flag when allocating the block. Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Peter Oberparleiter authored
Remove GFP_DMA flag when allocating memory to be used for CHSC control blocks. The CHSC instruction can access memory beyond the DMA zone. Suggested-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Sven Schnelle authored
Stefan reported a test case fail in libc. The test runs with randomize_va_space set to zero, i.e. disabled randomization. Additionally, it runs the program with the dynamic loader. Looking at the failure showed that the heap was placed right before some pages mapped from the binary. This made memory allocation fail after a few allocations. Normally, when address randomization is switched off and the binary is loaded from the dynamic loader, the kernel places the binary below the 128MB top gap. So the address map would look like this: 3fff7fd1000-3fff7fd2000 r--p 00000000 5e:01 1447115 /lib/ld64.so.1 3fff7fd2000-3fff7ff2000 r-xp 00001000 5e:01 1447115 /lib/ld64.so.1 3fff7ff2000-3fff7ffc000 r--p 00021000 5e:01 1447115 /lib/ld64.so.1 3fff7ffc000-3fff7ffe000 r--p 0002a000 5e:01 1447115 /lib/ld64.so.1 3fff7ffe000-3fff8000000 rw-p 0002c000 5e:01 1447115 /lib/ld64.so.1 3fff8000000-3fff8021000 rw-p 00000000 00:00 0 [heap] 3fffffda000-3ffffffb000 rw-p 00000000 00:00 0 [stack] 3ffffffc000-3ffffffe000 r--p 00000000 00:00 0 [vvar] 3ffffffe000-40000000000 r-xp 00000000 00:00 0 [vdso] However, commit 1f6b83e5 ("s390: avoid z13 cache aliasing") introduced a mmap alignment mask of 8MB. With this commit, the memory map now looks like this: 3fff7f80000-3fff7f81000 r--p 00000000 5e:01 1447115 /lib/ld64.so.1 3fff7f81000-3fff7fa1000 r-xp 00001000 5e:01 1447115 /lib/ld64.so.1 3fff7fa1000-3fff7fab000 r--p 00021000 5e:01 1447115 /lib/ld64.so.1 3fff7fab000-3fff7fad000 r--p 0002a000 5e:01 1447115 /lib/ld64.so.1 3fff7fad000-3fff7faf000 rw-p 0002c000 5e:01 1447115 /lib/ld64.so.1 3fff7faf000-3fff7fd0000 rw-p 00000000 00:00 0 [heap] 3fff7fdc000-3fff8000000 rw-p 00000000 00:00 0 3fffffda000-3ffffffb000 rw-p 00000000 00:00 0 [stack] 3ffffffc000-3ffffffe000 r--p 00000000 00:00 0 [vvar] 3ffffffe000-40000000000 r-xp 00000000 00:00 0 [vdso] The reason for this placement is that the elf loader loads the binary to end at mmap_base (0x3fff8000000 on s390). This would result in a start address of 0x3fff7fd1000, but due to the alignment requirement of 8MB, mmap chooses 0x3fff7f80000. This causes a gap between the end of the mapped binary and mmap_base. When the next non-shared and non-file pages are mapped, mmap searches from top to bottom and the first free space it finds is the gap which is now present. This leaves only a few pages for the heap. With enabled address space randomization this doesn't happen because the binary is mapped to a completely different memory area. Fix this by disabling the mmap alignment when address space randomization is disabled. This is in line with what other architectures are doing. Reported-by: Stefan Liebler <stli@linux.ibm.com> Tested-by: Stefan Liebler <stli@linux.ibm.com> Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Heiko Carstens authored
Remove GFP_DMA flag when allocating memory to be used for diagnose 304. Diagnose 304 can access memory beyond the DMA zone. Suggested-by: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Thomas Richter authored
diag14() is currently only used by the vmur device driver. The third parameter, called subcommand, determines the type of the first parameter. For some subcommands the value of the first parameter is an address to a memory buffer and needs virtual to physical address conversion. Other subcommands interpret the first parameter is an integer. This doesn't fix a bug since virtual and physical addresses are currently the same. Suggested-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Thomas Richter authored
Add missing virt_to_phys() / phys_to_virt() translation to alloc_chan_prog() and free_chan_prog(). This doesn't fix a bug since virtual and physical addresses are currently the same. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Sven Schnelle authored
The common timekeeping code steers the clock by adjusting the multiplier value of the clock. With the current value of 1000 precision is lost when the clock is steered with a userspace daemon. Increase the multiplier and the shift values to increase precision. Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Thomas Richter authored
paicrypt_init() return incorrect error code in case the number of PAI crypto counters is too high. Change the return code to -E2BIG. Please merge with d0b0efedc7fe Reported-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Thomas Richter authored
The number of sysfs files to be exported by the PAI device drivers depends on the hardware version level. Use the value returned by the hardware as the maximum number of counters to be exported in the sysfs attribute tree. Without the fix, older machine generation export counter names based on paiXXXX_ctrnames static array info, which can be inaccurate, as this array could also contain newer counter names in the future. This ensures proper pai counter sysfs attributes for both newer generation and older generation processors. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Thomas Richter authored
When the device driver is initialized, it checks the number of possible counters. Should this number be too high, emit an error and return. Reported-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Thomas Richter authored
When the device drivers are initialized, a sysfs directory is created. This contains many attributes which are allocated with kzalloc(). Should it fail, the memory for the attributes already created is freed in attr_event_free(). Its second parameter is number of attribute elements to delete. This parameter is off by one. When i. e. the 10th attribute fails to get created, attributes numbered 0 to 9 should be deleted. Currently only attributes numbered 0 to 8 are deleted. Fixes: 39d62336 ("s390/pai: add support for cryptography counters") Reported-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Heiko Carstens authored
Add missing virt_to_phys() translation to diag0c(). This doesn't fix a bug since virtual and physical addresses are currently the same. Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Heiko Carstens authored
Add missing virt_to_phys() translation to __hypfs_sprp_diag304(). This doesn't fix a bug since virtual and physical addresses are currently the same. Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Gerald Schaefer authored
Fix virtual vs physical address confusion (which currently are the same). Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Alexander Gordeev authored
Fix virtual vs physical address confusion (which currently are the same). Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Heiko Carstens authored
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Heiko Carstens authored
It looks like all distributions will enable INIT_STACK_ALL_ZERO. Reflect that in the default configurations. Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
Heiko Carstens authored
CONFIG_COMPAT is disabled by default, however compat code still needs to be compile tested. Add a compat topic configuration target which allows to enable it easily. Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
-
- 04 Feb, 2024 6 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4Linus Torvalds authored
Pull ext4 fixes from Ted Ts'o: "Miscellaneous bug fixes and cleanups in ext4's multi-block allocator and extent handling code" * tag 'for-linus-6.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: (23 commits) ext4: make ext4_set_iomap() recognize IOMAP_DELALLOC map type ext4: make ext4_map_blocks() distinguish delalloc only extent ext4: add a hole extent entry in cache after punch ext4: correct the hole length returned by ext4_map_blocks() ext4: convert to exclusive lock while inserting delalloc extents ext4: refactor ext4_da_map_blocks() ext4: remove 'needed' in trace_ext4_discard_preallocations ext4: remove unnecessary parameter "needed" in ext4_discard_preallocations ext4: remove unused return value of ext4_mb_release_group_pa ext4: remove unused return value of ext4_mb_release_inode_pa ext4: remove unused return value of ext4_mb_release ext4: remove unused ext4_allocation_context::ac_groups_considered ext4: remove unneeded return value of ext4_mb_release_context ext4: remove unused parameter ngroup in ext4_mb_choose_next_group_*() ext4: remove unused return value of __mb_check_buddy ext4: mark the group block bitmap as corrupted before reporting an error ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal() ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found() ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt ext4: avoid bb_free and bb_fragments inconsistency in mb_free_blocks() ...
-
git://git.samba.org/sfrench/cifs-2.6Linus Torvalds authored
Pull smb client fixes from Steve French: "Five smb3 client fixes, mostly multichannel related: - four multichannel fixes including fix for channel allocation when multiple inactive channels, fix for unneeded race in channel deallocation, correct redundant channel scaling, and redundant multichannel disabling scenarios - add warning if max compound requests reached" * tag 'v6.8-rc3-smb-client-fixes' of git://git.samba.org/sfrench/cifs-2.6: smb: client: increase number of PDUs allowed in a compound request cifs: failure to add channel on iface should bump up weight cifs: do not search for channel if server is terminating cifs: avoid redundant calls to disable multichannel cifs: make sure that channel scaling is done only once
-
git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds authored
Pull xfs fixes from Chandan Babu: - Clear XFS_ATTR_INCOMPLETE filter on removing xattr from a node format attribute fork - Remove conditional compilation of realtime geometry validator functions to prevent confusing error messages from being printed on the console during the mount operation * tag 'xfs-6.8-fixes-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: remove conditional building of rt geometry validator functions xfs: reset XFS_ATTR_INCOMPLETE filter on node removal
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-miscLinus Torvalds authored
Pull char/misc driver fixes from Greg KH: "Here are three tiny driver fixes for 6.8-rc3. They include: - Android binder long-term bug with epoll finally being fixed - fastrpc driver shutdown bugfix - open-dice lockdep fix All of these have been in linux-next this week with no reported issues" * tag 'char-misc-6.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: binder: signal epoll threads of self-work misc: open-dice: Fix spurious lockdep warning misc: fastrpc: Mark all sessions as invalid in cb_remove
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/ttyLinus Torvalds authored
Pull tty and serial driver fixes from Greg KH: "Here are some small tty and serial driver fixes for 6.8-rc3 that resolve a number of reported issues. Included in here are: - rs485 flag definition fix that affected the user/kernel abi in -rc1 - max310x driver fixes - 8250_pci1xxxx driver off-by-one fix - uart_tiocmget locking race fix All of these have been in linux-next for over a week with no reported issues" * tag 'tty-6.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: serial: max310x: prevent infinite while() loop in port startup serial: max310x: fail probe if clock crystal is unstable serial: max310x: improve crystal stable clock detection serial: max310x: set default value when reading clock ready bit serial: core: Fix atomicity violation in uart_tiocmget serial: 8250_pci1xxxx: fix off by one in pci1xxxx_process_read_data() tty: serial: Fix bit order in RS485 flag definitions
-