aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-09-04fuse: allow idmapped mountsAlexander Mikhalitsyn2-4/+28
Now we have everything in place and we can allow idmapped mounts by setting the FS_ALLOW_IDMAP flag. Notice that real availability of idmapped mounts will depend on the fuse daemon. Fuse daemon have to set FUSE_ALLOW_IDMAP flag in the FUSE_INIT reply. To discuss: - we enable idmapped mounts support only if "default_permissions" mode is enabled, because otherwise we would need to deal with UID/GID mappings in the userspace side OR provide the userspace with idmapped req->in.h.uid/req->in.h.gid values which is not something that we probably want to. Idmapped mounts philosophy is not about faking caller uid/gid. Some extra links and examples: - libfuse support https://github.com/mihalicyn/libfuse/commits/idmap_support - fuse-overlayfs support: https://github.com/mihalicyn/fuse-overlayfs/commits/idmap_support - cephfs-fuse conversion example https://github.com/mihalicyn/ceph/commits/fuse_idmap - glusterfs conversion example https://github.com/mihalicyn/glusterfs/commits/fuse_idmap Signed-off-by: Alexander Mikhalitsyn <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2024-09-04fuse: warn if fuse_access is called when idmapped mounts are allowedAlexander Mikhalitsyn1-0/+8
It is not possible with the current fuse code, but let's protect ourselves from regressions in the future. Signed-off-by: Alexander Mikhalitsyn <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2024-09-04fuse: handle idmappings properly in ->write_iter()Alexander Mikhalitsyn1-1/+2
This is needed to properly clear suid/sgid. Signed-off-by: Alexander Mikhalitsyn <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2024-09-04fuse: support idmapped ->rename opAlexander Mikhalitsyn1-4/+5
RENAME_WHITEOUT is a special case of ->rename and we need to take idmappings into account there. Signed-off-by: Alexander Mikhalitsyn <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2024-09-04fuse: support idmapped ->set_aclAlexander Mikhalitsyn1-2/+2
It's just a matter of adjusting a permission check condition for S_ISGID flag. All the rest is already handled in the generic VFS code. Notice that this permission check is the analog of what we have in posix_acl_update_mode() generic helper, but fuse doesn't use this helper as on the kernel side we don't care about ensuring that POSIX ACL and CHMOD permissions are in sync as it is a responsibility of a userspace daemon to handle that. For the same reason we don't have a calls to posix_acl_chmod(), while most of other filesystem do. Signed-off-by: Alexander Mikhalitsyn <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2024-09-04fuse: drop idmap argument from __fuse_get_aclAlexander Mikhalitsyn1-4/+2
We don't need to have idmap in the __fuse_get_acl as we don't have any use for it. In the current POSIX ACL implementation, idmapped mounts are taken into account on the userspace/kernel border (see vfs_set_acl_idmapped_mnt() and vfs_posix_acl_to_xattr()). Signed-off-by: Alexander Mikhalitsyn <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2024-09-04fuse: support idmapped ->setattr opAlexander Mikhalitsyn3-14/+26
Need to translate uid and gid in case of chown(2). Signed-off-by: Alexander Mikhalitsyn <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2024-09-04fuse: support idmapped ->permission inode opAlexander Mikhalitsyn1-2/+2
We only cover the case when "default_permissions" flag is used. A reason for that is that otherwise all the permission checks are done in the userspace and we have to deal with VFS idmapping in the userspace (which is bad), alternatively we have to provide the userspace with idmapped req->in.h.uid/req->in.h.gid which is also not align with VFS idmaps philosophy. Signed-off-by: Alexander Mikhalitsyn <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2024-09-04fuse: support idmapped getattr inode opAlexander Mikhalitsyn1-20/+24
We have to: - pass an idmapping to the generic_fillattr() to properly handle UIG/GID mapping for the userspace. - pass -/- to fuse_fillattr() (analog of generic_fillattr() in fuse). Difference between these two is that generic_fillattr() takes all the stat() data from the inode directly, while fuse_fillattr() codepath takes a fresh data just from the userspace reply on the FUSE_GETATTR request. In some cases we can just pass &nop_mnt_idmap, because idmapping won't be used in these codepaths. For example, when 3rd argument of fuse_do_getattr() is NULL then idmap argument is not used. Signed-off-by: Alexander Mikhalitsyn <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2024-09-04fuse: support idmap for mkdir/mknod/symlink/create/tmpfileAlexander Mikhalitsyn1-18/+20
We have all the infrastructure in place, we just need to pass an idmapping here. Signed-off-by: Alexander Mikhalitsyn <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2024-09-04fuse: support idmapped FUSE_EXT_GROUPSAlexander Mikhalitsyn1-7/+12
We don't need to remap parent_gid, but have to adjust group membership checks and take idmapping into account. Signed-off-by: Alexander Mikhalitsyn <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2024-09-04fuse: add an idmap argument to fuse_simple_requestAlexander Mikhalitsyn9-44/+47
If idmap == NULL *and* filesystem daemon declared idmapped mounts support, then uid/gid values in a fuse header will be -1. No functional changes intended. Signed-off-by: Alexander Mikhalitsyn <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2024-09-04fuse: add basic infrastructure to support idmappingsAlexander Mikhalitsyn3-12/+41
Add some preparational changes in fuse_get_req/fuse_force_creds to handle idmappings. Miklos suggested [1], [2] to change the meaning of in.h.uid/in.h.gid fields when daemon declares support for idmapped mounts. In a new semantic, we fill uid/gid values in fuse header with a id-mapped caller uid/gid (for requests which create new inodes), for all the rest cases we just send -1 to userspace. No functional changes intended. Link: https://lore.kernel.org/all/CAJfpegsVY97_5mHSc06mSw79FehFWtoXT=hhTUK_E-Yhr7OAuQ@mail.gmail.com/ [1] Link: https://lore.kernel.org/all/CAJfpegtHQsEUuFq1k4ZbTD3E1h-GsrN3PWyv7X8cg6sfU_W2Yw@mail.gmail.com/ [2] Signed-off-by: Alexander Mikhalitsyn <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2024-09-04namespace: introduce SB_I_NOIDMAP flagAlexander Mikhalitsyn2-0/+5
Right now we determine if filesystem support vfs idmappings or not basing on the FS_ALLOW_IDMAP flag presence. This "static" way works perfecly well for local filesystems like ext4, xfs, btrfs, etc. But for network-like filesystems like fuse, cephfs this approach is not ideal, because sometimes proper support of vfs idmaps requires some extensions for the on-wire protocol, which implies that changes have to be made not only in the Linux kernel code but also in the 3rd party components like libfuse, cephfs MDS server and so on. We have seen that issue during our work on cephfs idmapped mounts [1] with Christian, but right now I'm working on the idmapped mounts support for fuse/virtiofs and I think that it is a right time for this extension. [1] 5ccd8530dd7 ("ceph: handle idmapped mounts in create_request_message()") Suggested-by: Christian Brauner <[email protected]> Signed-off-by: Alexander Mikhalitsyn <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2024-09-04dt-bindings: PCI: layerscape-pci: Add deprecated property 'num-viewport'Frank Li1-0/+8
Copy the 'num-viewport' property from snps,dw-pcie-common.yaml to fsl,layerscape-pcie.yaml to address the following warning: /arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dtb: pcie@3400000: Unevaluated properties are not allowed ('num-viewport' was unexpected) This is necessary due to historical reasons where fsl,layerscape-pcie.yaml does not directly reference snps,dw-pcie-common.yaml. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Frank Li <[email protected]> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <[email protected]> Acked-by: Rob Herring (Arm) <[email protected]>
2024-09-04kvm: Note an RCU quiescent state on guest exitLeonardo Bras2-3/+13
As of today, KVM notes a quiescent state only in guest entry, which is good as it avoids the guest being interrupted for current RCU operations. While the guest vcpu runs, it can be interrupted by a timer IRQ that will check for any RCU operations waiting for this CPU. In case there are any of such, it invokes rcu_core() in order to sched-out the current thread and note a quiescent state. This occasional schedule work will introduce tens of microsseconds of latency, which is really bad for vcpus running latency-sensitive applications, such as real-time workloads. So, note a quiescent state in guest exit, so the interrupted guests is able to deal with any pending RCU operations before being required to invoke rcu_core(), and thus avoid the overhead of related scheduler work. Signed-off-by: Leonardo Bras <[email protected]> Acked-by: Paul E. McKenney <[email protected]> Acked-by: Sean Christopherson <[email protected]> Message-ID: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2024-09-04arm64: dts: allwinner: a64: Add GPU thermal trips to the SoC dtsiDragan Simic1-0/+16
Add thermal trips for the two GPU thermal sensors found in the Allwinner A64. There's only one GPU OPP defined since the commit 1428f0c19f9c ("arm64: dts: allwinner: a64: Run GPU at 432 MHz"), so defining only the critical thermal trips makes sense for the A64's two GPU thermal zones. Having these critical thermal trips defined ensures that no hot spots develop inside the SoC die that exceed the maximum junction temperature. That might have been possible before, although quite unlikely, because the CPU and GPU portions of the SoC are packed closely inside the SoC, so the overheating GPU would inevitably result in the heat soaking into the CPU portion of the SoC, causing the CPU thermal sensor to return high readings and trigger the CPU critical thermal trips. However, it's better not to rely on the heat soak and have the critical GPU thermal trips properly defined instead. Signed-off-by: Dragan Simic <[email protected]> Tested-by: Norayr Chilingarian <[email protected]> Link: https://lore.kernel.org/r/0a6110a7b27a050bd58ab3663087eecd8e873ac0.1724126053.git.dsimic@manjaro.org Signed-off-by: Chen-Yu Tsai <[email protected]>
2024-09-04arm64: dts: allwinner: h700: Add charger for Anbernic RG35XXChris Morgan1-0/+21
Add the necessary nodes for the AXP717 to allow for monitoring the USB and battery charger. Signed-off-by: Chris Morgan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Chen-Yu Tsai <[email protected]>
2024-09-04dt-bindings: PCI: layerscape-pci: Replace fsl,lx2160a-pcie with ↵Frank Li1-12/+14
fsl,lx2160ar2-pcie The fsl,lx2160a-pcie compatible is used for mobivel according to the Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt file. Whereas the fsl,layerscape-pcie is used for DesignWare PCIe controller binding. So change it to fsl,lx2160ar2-pcie and allow a fall back to fsl,ls2088a-pcie. While at it, sort compatible string. Fixes: 24cd7ecb3886 ("dt-bindings: PCI: layerscape-pci: Convert to YAML format") Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Frank Li <[email protected]> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Rob Herring (Arm) <[email protected]>
2024-09-04dt-bindings: PCI: socionext,uniphier-pcie-ep: Add top-level constraintsKrzysztof Kozlowski1-2/+6
Properties with variable number of items per each device are expected to have widest constraints in top-level "properties:" block and further customized (narrowed) in "if:then:". Add missing top-level constraints for clock-names and reset-names. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Kunihiko Hayashi <[email protected]> Reviewed-by: Rob Herring (Arm) <[email protected]>
2024-09-04dt-bindings: PCI: renesas,pci-rcar-gen2: Add top-level constraintsKrzysztof Kozlowski1-2/+6
Properties with variable number of items per each device are expected to have widest constraints in top-level "properties:" block and further customized (narrowed) in "if:then:". Add missing top-level constraints for clocks and clock-names. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Rob Herring (Arm) <[email protected]>
2024-09-04dt-bindings: PCI: hisilicon,kirin-pcie: Add top-level constraintsKrzysztof Kozlowski1-1/+2
Properties with variable number of items per each device are expected to have widest constraints in top-level "properties:" block and further customized (narrowed) in "if:then:". Add missing top-level constraints for clock-names and reset-names. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Rob Herring (Arm) <[email protected]>
2024-09-04PCI: j721e: Add suspend and resume supportThéo Lebrun1-6/+92
Add suspend and resume support. Only the Root Complex mode is supported. During the suspend stage PERST# is asserted, then deasserted during the resume stage. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Théo Lebrun <[email protected]> Signed-off-by: Thomas Richard <[email protected]> [kwilczynski: commit log, update references to the PCI SIG specification] Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Siddharth Vadapalli <[email protected]>
2024-09-04PCI: j721e: Use T_PERST_CLK_US macroThomas Richard1-1/+1
Use the T_PERST_CLK_US macro, and the fsleep() function instead of usleep_range(). Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Thomas Richard <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]>
2024-09-04PCI: Add T_PERST_CLK_US macroThomas Richard1-1/+16
The "Power Sequencing and Reset Signal Timings" table of the PCI Express Card Electromechanical Specification, Revision 5.1, Section 2.9.2, indicates PERST# should be deasserted after minimum of 100us once REFCLK is stable (symbol T_PERST-CLK). Add a macro so that PCIe controller drivers can use it. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Thomas Richard <[email protected]> [kwilczynski: commit log, update sleep interval macros code comments] Signed-off-by: Krzysztof Wilczyński <[email protected]>
2024-09-04docs: update dev-tools/kcsan.rst url about KTSANHaoyang Liu1-1/+2
The KTSAN doc has moved to https://github.com/google/kernel-sanitizers/blob/master/KTSAN.md. Update the url in kcsan.rst accordingly. Signed-off-by: Haoyang Liu <[email protected]> Reviewed-by: Dongliang Mu <[email protected]> Acked-by: Marco Elver <[email protected]> Signed-off-by: Jonathan Corbet <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-09-04ARM: 9418/1: dma-mapping: Use iommu_paging_domain_alloc()Jason Gunthorpe1-2/+4
Since arm_iommu_create_mapping() now accepts the device, let's replace iommu_domain_alloc() with iommu_paging_domain_alloc() to retire the former. Signed-off-by: Lu Baolu <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Vasant Hegde <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> Acked-by: Jeff Johnson <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]>
2024-09-04ARM: 9417/1: dma-mapping: Pass device to arm_iommu_create_mapping()Jason Gunthorpe6-11/+9
All users of ARM IOMMU mappings create them for a particular device, so change the interface to accept the device rather than forcing a vague indirection through a bus type. This prepares for making a similar change to iommu_domain_alloc() itself. Signed-off-by: Robin Murphy <[email protected]> Signed-off-by: Lu Baolu <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Vasant Hegde <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> Acked-by: Jeff Johnson <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]>
2024-09-04block: fix integer overflow in BLKSECDISCARDAlexey Dobriyan1-4/+5
I independently rediscovered commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 block: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: uint64_t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): a.out: attempt to access beyond end of device loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 bio_check_eod: 3286214 callbacks suppressed Signed-off-by: Alexey Dobriyan <[email protected]> Link: https://lore.kernel.org/r/9e64057f-650a-46d1-b9f7-34af391536ef@p183 Signed-off-by: Jens Axboe <[email protected]>
2024-09-04ARM: 9416/1: amba: make amba_bustype constantKunwu Chan2-2/+2
Since commit d492cc2573a0 ("driver core: device.h: make struct bus_type a const *"), the driver core can properly handle constant struct bus_type, move the amba_bustype 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 <[email protected]> Suggested-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Kunwu Chan <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]>
2024-09-04PCI: brcmstb: Don't conflate the reset rescal with PHY ctrlJim Quinlan1-3/+14
Add a "has_phy" field indicating that the internal PHY has SW control that requires configuration. Some previous chips only required the firing of the "rescal" reset controller. This change requires us to give the 7216 SoC its own cfg_data structure. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Jim Quinlan <[email protected]> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <[email protected]> Tested-by: Florian Fainelli <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Stanimir Varbanov <[email protected]>
2024-09-04PCI: brcmstb: Remove two unused constants from driverJim Quinlan1-5/+0
Remove two constants in the driver which are no longer used: RGR1_SW_INIT_1_INIT_MASK and RGR1_SW_INIT_1_INIT_SHIFT. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Jim Quinlan <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Tested-by: Florian Fainelli <[email protected]> Reviewed-by: Stanimir Varbanov <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]>
2024-09-04PCI: brcmstb: PCI: brcmstb: Make HARD_DEBUG, INTR2_CPU_BASE offsets SoC-specificJim Quinlan1-15/+24
Do preparatory work for the 7712 SoC, which is introduced in a future commit. Our HW design has changed two register offsets for the 7712, where previously it was a common value for all Broadcom SoCs with PCIe cores. Specifically, the two offsets are to the registers HARD_DEBUG and INTR2_CPU_BASE. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Jim Quinlan <[email protected]> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <[email protected]> Tested-by: Florian Fainelli <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Stanimir Varbanov <[email protected]>
2024-09-04PCI: brcmstb: Use swinit reset if availableJim Quinlan1-0/+24
The 7712 SoC adds a software init reset device for the PCIe HW. If found in the DT node, use it. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Jim Quinlan <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]>
2024-09-04PCI: brcmstb: Use bridge reset if availableJim Quinlan1-1/+17
The 7712 SoC has a bridge reset which can be described in the device tree. Use it if present. Otherwise, continue to use the legacy method to reset the bridge. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Jim Quinlan <[email protected]> [kwilczynski: commit log, refactored function brcm_pcie_bridge_sw_init_set_generic()] Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Stanimir Varbanov <[email protected]>
2024-09-04printk: Avoid false positive lockdep report for legacy printingJohn Ogness1-20/+63
Legacy console printing from printk() caller context may invoke the console driver from atomic context. This leads to a lockdep splat because the console driver will acquire a sleeping lock and the caller may already hold a spinning lock. This is noticed by lockdep on !PREEMPT_RT configurations because it will lead to a problem on PREEMPT_RT. However, on PREEMPT_RT the printing path from atomic context is always avoided and the console driver is always invoked from a dedicated thread. Thus the lockdep splat on !PREEMPT_RT is a false positive. For !PREEMPT_RT override the lock-context before invoking the console driver to avoid the false positive. Do not override the lock-context for PREEMPT_RT in order to allow lockdep to catch any real locking context issues related to the write callback usage. Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04printk: nbcon: Assign nice -20 for printing threadsJohn Ogness2-0/+12
It is important that console printing threads are scheduled shortly after a printk call and with generous runtime budgets. Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04printk: Implement legacy printer kthread for PREEMPT_RTJohn Ogness3-18/+159
The write() callback of legacy consoles usually makes use of spinlocks. This is not permitted with PREEMPT_RT in atomic contexts. For PREEMPT_RT, create a new kthread to handle printing of all the legacy consoles (and nbcon consoles if boot consoles are registered). This allows legacy consoles to work on PREEMPT_RT without requiring modification. (However they will not have the reliability properties guaranteed by nbcon atomic consoles.) Use the existing printk_kthreads_check_locked() to start/stop the legacy kthread as needed. Introduce the macro force_legacy_kthread() to query if the forced threading of legacy consoles is in effect. Although currently only enabled for PREEMPT_RT, this acts as a simple mechanism for the future to allow other preemption models to easily take advantage of the non-interference property provided by the legacy kthread. When force_legacy_kthread() is true, the legacy kthread fulfills the role of the console_flush_type @legacy_offload by waking the legacy kthread instead of printing via the console_lock in the irq_work. If the legacy kthread is not yet available, no legacy printing takes place (unless in panic). If for some reason the legacy kthread fails to create, any legacy consoles are unregistered. With force_legacy_kthread(), the legacy kthread is a critical component for legacy consoles. These changes only affect CONFIG_PREEMPT_RT. Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04tty: sysfs: Add nbcon support for 'active'John Ogness1-1/+1
Allow the 'active' attribute to list nbcon consoles. Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04proc: Add nbcon support for /proc/consolesJohn Ogness1-2/+3
Update /proc/consoles output to show 'W' if an nbcon console is registered. Since the write_thread() callback is mandatory, it enough just to check if it is an nbcon console. Also update /proc/consoles output to show 'N' if it is an nbcon console. Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04proc: consoles: Add notation to c_start/c_stopJohn Ogness1-0/+2
fs/proc/consoles.c:78:13: warning: context imbalance in 'c_start' - wrong count at exit fs/proc/consoles.c:104:13: warning: context imbalance in 'c_stop' - unexpected unlock Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04printk: nbcon: Show replay message on takeoverJohn Ogness4-0/+40
An emergency or panic context can takeover console ownership while the current owner was printing a printk message. The atomic printer will re-print the message that the previous owner was printing. However, this can look confusing to the user and may even seem as though a message was lost. [3430014.1 [3430014.181123] usb 1-2: Product: USB Audio Add a new field @nbcon_prev_seq to struct console to track the sequence number to print that was assigned to the previous console owner. If this matches the sequence number to print that the current owner is assigned, then a takeover must have occurred. In this case, print an additional message to inform the user that the previous message is being printed again. [3430014.1 ** replaying previous printk message ** [3430014.181123] usb 1-2: Product: USB Audio Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04printk: Provide helper for message prependingJohn Ogness1-11/+25
In order to support prepending different texts to printk messages, split out the prepending code into a helper function. Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04printk: nbcon: Rely on kthreads for normal operationJohn Ogness3-7/+84
Once the kthread is running and available (i.e. @printk_kthreads_running is set), the kthread becomes responsible for flushing any pending messages which are added in NBCON_PRIO_NORMAL context. Namely the legacy console_flush_all() and device_release() no longer flush the console. And nbcon_atomic_flush_pending() used by nbcon_cpu_emergency_exit() no longer flushes messages added after the emergency messages. The console context is safe when used by the kthread only when one of the following conditions are true: 1. Other caller acquires the console context with NBCON_PRIO_NORMAL with preemption disabled. It will release the context before rescheduling. 2. Other caller acquires the console context with NBCON_PRIO_NORMAL under the device_lock. 3. The kthread is the only context which acquires the console with NBCON_PRIO_NORMAL. This is satisfied for all atomic printing call sites: nbcon_legacy_emit_next_record() (#1) nbcon_atomic_flush_pending_con() (#1) nbcon_device_release() (#2) It is even double guaranteed when @printk_kthreads_running is set because then _only_ the kthread will print for NBCON_PRIO_NORMAL. (#3) Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04printk: nbcon: Use thread callback if in task context for legacyJohn Ogness3-45/+59
When printing via console_lock, the write_atomic() callback is used for nbcon consoles. However, if it is known that the current context is a task context, the write_thread() callback can be used instead. Using write_thread() instead of write_atomic() helps to reduce large disabled preemption regions when the device_lock does not disable preemption. This is mainly a preparatory change to allow avoiding write_atomic() completely during normal operation if boot consoles are registered. As a side-effect, it also allows consolidating the printing code for legacy printing and the kthread printer. Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04printk: nbcon: Relocate nbcon_atomic_emit_one()John Ogness1-39/+39
Move nbcon_atomic_emit_one() so that it can be used by nbcon_kthread_func() in a follow-up commit. Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04printk: nbcon: Introduce printer kthreadsThomas Gleixner4-0/+420
Provide the main implementation for running a printer kthread per nbcon console that is takeover/handover aware. This includes: - new mandatory write_thread() callback - kthread creation - kthread main printing loop - kthread wakeup mechanism - kthread shutdown kthread creation is a bit tricky because consoles may register before kthreads can be created. In such cases, registration will succeed, even though no kthread exists. Once kthreads can be created, an early_initcall will set @printk_kthreads_ready. If there are no registered boot consoles, the early_initcall creates the kthreads for all registered nbcon consoles. If kthread creation fails, the related console is unregistered. If there are registered boot consoles when @printk_kthreads_ready is set, no kthreads are created until the final boot console unregisters. Once kthread creation finally occurs, @printk_kthreads_running is set so that the system knows kthreads are available for all registered nbcon consoles. If @printk_kthreads_running is already set when the console is registering, the kthread is created during registration. If kthread creation fails, the registration will fail. Until @printk_kthreads_running is set, console printing occurs directly via the console_lock. kthread shutdown on system shutdown/reboot is necessary to ensure the printer kthreads finish their printing so that the system can cleanly transition back to direct printing via the console_lock in order to reliably push out the final shutdown/reboot messages. @printk_kthreads_running is cleared before shutting down the individual kthreads. The kthread uses a new mandatory write_thread() callback that is called with both device_lock() and the console context acquired. The console ownership handling is necessary for synchronization against write_atomic() which is synchronized only via the console context ownership. The device_lock() serializes acquiring the console context with NBCON_PRIO_NORMAL. It is needed in case the device_lock() does not disable preemption. It prevents the following race: CPU0 CPU1 [ task A ] nbcon_context_try_acquire() # success with NORMAL prio # .unsafe == false; // safe for takeover [ schedule: task A -> B ] WARN_ON() nbcon_atomic_flush_pending() nbcon_context_try_acquire() # success with EMERGENCY prio # flushing nbcon_context_release() # HERE: con->nbcon_state is free # to take by anyone !!! nbcon_context_try_acquire() # success with NORMAL prio [ task B ] [ schedule: task B -> A ] nbcon_enter_unsafe() nbcon_context_can_proceed() BUG: nbcon_context_can_proceed() returns "true" because the console is owned by a context on CPU0 with NBCON_PRIO_NORMAL. But it should return "false". The console is owned by a context from task B and we do the check in a context from task A. Note that with these changes, the printer kthreads do not yet take over full responsibility for nbcon printing during normal operation. These changes only focus on the lifecycle of the kthreads. Co-developed-by: John Ogness <[email protected]> Signed-off-by: John Ogness <[email protected]> Signed-off-by: Thomas Gleixner (Intel) <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04printk: nbcon: Init @nbcon_seq to highest possibleJohn Ogness2-1/+9
When initializing an nbcon console, have nbcon_alloc() set @nbcon_seq to the highest possible sequence number. For all practical purposes, this will guarantee that the console will have nothing to print until later when @nbcon_seq is set to the proper initial printing value. This will be particularly important once kthread printing is introduced because nbcon_alloc() can create/start the kthread before the desired initial sequence number is known. Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04printk: nbcon: Add context to usable() and emit()John Ogness3-21/+27
The nbcon consoles will have two callbacks to be used for different contexts. In order to determine if an nbcon console is usable, console_is_usable() must know if it is a context that will need to use the optional write_atomic() callback. Also, nbcon_emit_next_record() must know which callback it needs to call. Add an extra parameter @use_atomic to console_is_usable() and nbcon_emit_next_record() to specify this. Since so far only the write_atomic() callback exists, @use_atomic is set to true for all call sites. For legacy consoles, @use_atomic is not used. Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04printk: Flush console on unregister_console()John Ogness1-2/+7
Ensure consoles have flushed pending records before unregistering. The console should print up to at least its related "console disabled" record. Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.