mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-10 20:48:12 +00:00
1,267,977 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Qais Yousef
|
b361c9027b |
sched: Add a new function to compare if two cpus have the same capacity
The new helper function is needed to help blk-mq check if it needs to dispatch the softirq on another CPU to match the performance level the IO requester is running at. This is important on HMP systems where not all CPUs have the same compute capacity. Signed-off-by: Qais Yousef <qyousef@layalina.io> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20240223155749.2958009-2-qyousef@layalina.io Signed-off-by: Jens Axboe <axboe@kernel.dk> |
||
Keith Busch
|
8a08c5fd89 |
blk-lib: check for kill signal
Some of these block operations can access a significant capacity and take longer than the user expected. A user may change their mind about wanting to run that command and attempt to kill the process and do something else with their device. But since the task is uninterruptable, they have to wait for it to finish, which could be many hours. Check for a fatal signal at each iteration so the user doesn't have to wait for their regretted operation to complete naturally. Reported-by: Conrad Meyer <conradmeyer@meta.com> Tested-by: Nilay Shroff <nilay@linux.ibm.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Link: https://lore.kernel.org/r/20240223155910.3622666-5-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk> |
||
|
Keith Busch
|
0eb4db4706 |
block: io wait hang check helper
This is the same in two places, and another will be added soon. Create a helper for it. Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Link: https://lore.kernel.org/r/20240223155910.3622666-4-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk> |
||
|
Keith Busch
|
76a27e1b53 |
block: cleanup __blkdev_issue_write_zeroes
Use min to calculate the next number of sectors like everyone else. Reviewed-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Link: https://lore.kernel.org/r/20240223155910.3622666-3-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk> |
||
|
Keith Busch
|
5affe497c3 |
block: blkdev_issue_secure_erase loop style
Use consistent coding style in this file. All the other loops for the same purpose use "while (nr_sects)", so they win. Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Link: https://lore.kernel.org/r/20240223155910.3622666-2-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk> |
||
Ankit Agrawal
|
a39d3a966a |
vfio: Convey kvm that the vfio-pci device is wc safe
The VM_ALLOW_ANY_UNCACHED flag is implemented for ARM64, allowing KVM stage 2 device mapping attributes to use Normal-NC rather than DEVICE_nGnRE, which allows guest mappings supporting write-combining attributes (WC). ARM does not architecturally guarantee this is safe, and indeed some MMIO regions like the GICv2 VCPU interface can trigger uncontained faults if Normal-NC is used. To safely use VFIO in KVM the platform must guarantee full safety in the guest where no action taken against a MMIO mapping can trigger an uncontained failure. The expectation is that most VFIO PCI platforms support this for both mapping types, at least in common flows, based on some expectations of how PCI IP is integrated. So make vfio-pci set the VM_ALLOW_ANY_UNCACHED flag. Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Link: https://lore.kernel.org/r/20240224150546.368-5-ankita@nvidia.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev> |
||
|
Ankit Agrawal
|
8c47ce3e1d |
KVM: arm64: Set io memory s2 pte as normalnc for vfio pci device
To provide VM with the ability to get device IO memory with NormalNC property, map device MMIO in KVM for ARM64 at stage2 as NormalNC. Having NormalNC S2 default puts guests in control (based on [1], "Combining stage 1 and stage 2 memory type attributes") of device MMIO regions memory mappings. The rules are summarized below: ([(S1) - stage1], [(S2) - stage 2]) S1 | S2 | Result NORMAL-WB | NORMAL-NC | NORMAL-NC NORMAL-WT | NORMAL-NC | NORMAL-NC NORMAL-NC | NORMAL-NC | NORMAL-NC DEVICE<attr> | NORMAL-NC | DEVICE<attr> Still this cannot be generalized to non PCI devices such as GICv2. There is insufficient information and uncertainity in the behavior of non PCI driver. A driver must indicate support using the new flag VM_ALLOW_ANY_UNCACHED. Adapt KVM to make use of the flag VM_ALLOW_ANY_UNCACHED as indicator to activate the S2 setting to NormalNc. [1] section D8.5.5 of DDI0487J_a_a-profile_architecture_reference_manual.pdf Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Link: https://lore.kernel.org/r/20240224150546.368-4-ankita@nvidia.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev> |
||
|
Ankit Agrawal
|
5c656fcdd6 |
mm: Introduce new flag to indicate wc safe
The VM_ALLOW_ANY_UNCACHED flag is implemented for ARM64, allowing KVM stage 2 device mapping attributes to use NormalNC rather than DEVICE_nGnRE, which allows guest mappings supporting write-combining attributes (WC). ARM does not architecturally guarantee this is safe, and indeed some MMIO regions like the GICv2 VCPU interface can trigger uncontained faults if NormalNC is used. Even worse, the expectation is that there are platforms where even DEVICE_nGnRE can allow uncontained faults in corner cases. Unfortunately existing ARM IP requires platform integration to take responsibility to prevent this. To safely use VFIO in KVM the platform must guarantee full safety in the guest where no action taken against a MMIO mapping can trigger an uncontained failure. The assumption is that most VFIO PCI platforms support this for both mapping types, at least in common flows, based on some expectations of how PCI IP is integrated. This can be enabled more broadly, for instance into vfio-platform drivers, but only after the platform vendor completes auditing for safety. The VMA flag VM_ALLOW_ANY_UNCACHED was found to be the simplest and cleanest way to communicate the information from VFIO to KVM that mapping the region in S2 as NormalNC is safe. KVM consumes it to activate the code that does the S2 mapping as NormalNC. Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Acked-by: David Hildenbrand <david@redhat.com> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Link: https://lore.kernel.org/r/20240224150546.368-3-ankita@nvidia.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev> |
||
|
Ankit Agrawal
|
c034ec84e8 |
KVM: arm64: Introduce new flag for non-cacheable IO memory
Currently, KVM for ARM64 maps at stage 2 memory that is considered device (i.e. it is not RAM) with DEVICE_nGnRE memory attributes; this setting overrides (as per the ARM architecture [1]) any device MMIO mapping present at stage 1, resulting in a set-up whereby a guest operating system cannot determine device MMIO mapping memory attributes on its own but it is always overridden by the KVM stage 2 default. This set-up does not allow guest operating systems to select device memory attributes independently from KVM stage-2 mappings (refer to [1], "Combining stage 1 and stage 2 memory type attributes"), which turns out to be an issue in that guest operating systems (e.g. Linux) may request to map devices MMIO regions with memory attributes that guarantee better performance (e.g. gathering attribute - that for some devices can generate larger PCIe memory writes TLPs) and specific operations (e.g. unaligned transactions) such as the NormalNC memory type. The default device stage 2 mapping was chosen in KVM for ARM64 since it was considered safer (i.e. it would not allow guests to trigger uncontained failures ultimately crashing the machine) but this turned out to be asynchronous (SError) defeating the purpose. Failures containability is a property of the platform and is independent from the memory type used for MMIO device memory mappings. Actually, DEVICE_nGnRE memory type is even more problematic than Normal-NC memory type in terms of faults containability in that e.g. aborts triggered on DEVICE_nGnRE loads cannot be made, architecturally, synchronous (i.e. that would imply that the processor should issue at most 1 load transaction at a time - it cannot pipeline them - otherwise the synchronous abort semantics would break the no-speculation attribute attached to DEVICE_XXX memory). This means that regardless of the combined stage1+stage2 mappings a platform is safe if and only if device transactions cannot trigger uncontained failures and that in turn relies on platform capabilities and the device type being assigned (i.e. PCIe AER/DPC error containment and RAS architecture[3]); therefore the default KVM device stage 2 memory attributes play no role in making device assignment safer for a given platform (if the platform design adheres to design guidelines outlined in [3]) and therefore can be relaxed. For all these reasons, relax the KVM stage 2 device memory attributes from DEVICE_nGnRE to Normal-NC. The NormalNC was chosen over a different Normal memory type default at stage-2 (e.g. Normal Write-through) to avoid cache allocation/snooping. Relaxing S2 KVM device MMIO mappings to Normal-NC is not expected to trigger any issue on guest device reclaim use cases either (i.e. device MMIO unmap followed by a device reset) at least for PCIe devices, in that in PCIe a device reset is architected and carried out through PCI config space transactions that are naturally ordered with respect to MMIO transactions according to the PCI ordering rules. Having Normal-NC S2 default puts guests in control (thanks to stage1+stage2 combined memory attributes rules [1]) of device MMIO regions memory mappings, according to the rules described in [1] and summarized here ([(S1) - stage1], [(S2) - stage 2]): S1 | S2 | Result NORMAL-WB | NORMAL-NC | NORMAL-NC NORMAL-WT | NORMAL-NC | NORMAL-NC NORMAL-NC | NORMAL-NC | NORMAL-NC DEVICE<attr> | NORMAL-NC | DEVICE<attr> It is worth noting that currently, to map devices MMIO space to user space in a device pass-through use case the VFIO framework applies memory attributes derived from pgprot_noncached() settings applied to VMAs, which result in device-nGnRnE memory attributes for the stage-1 VMM mappings. This means that a userspace mapping for device MMIO space carried out with the current VFIO framework and a guest OS mapping for the same MMIO space may result in a mismatched alias as described in [2]. Defaulting KVM device stage-2 mappings to Normal-NC attributes does not change anything in this respect, in that the mismatched aliases would only affect (refer to [2] for a detailed explanation) ordering between the userspace and GuestOS mappings resulting stream of transactions (i.e. it does not cause loss of property for either stream of transactions on its own), which is harmless given that the userspace and GuestOS access to the device is carried out through independent transactions streams. A Normal-NC flag is not present today. So add a new kvm_pgtable_prot (KVM_PGTABLE_PROT_NORMAL_NC) flag for it, along with its corresponding PTE value 0x5 (0b101) determined from [1]. Lastly, adapt the stage2 PTE property setter function (stage2_set_prot_attr) to handle the NormalNC attribute. The entire discussion leading to this patch series may be followed through the following links. Link: https://lore.kernel.org/all/20230907181459.18145-3-ankita@nvidia.com Link: https://lore.kernel.org/r/20231205033015.10044-1-ankita@nvidia.com [1] section D8.5.5 - DDI0487J_a_a-profile_architecture_reference_manual.pdf [2] section B2.8 - DDI0487J_a_a-profile_architecture_reference_manual.pdf [3] sections 1.7.7.3/1.8.5.2/appendix C - DEN0029H_SBSA_7.1.pdf Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Will Deacon <will@kernel.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Link: https://lore.kernel.org/r/20240224150546.368-2-ankita@nvidia.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev> |
||
Vasileios Amoiridis
|
a9dd9ba323 |
iio: pressure: Fixes BMP38x and BMP390 SPI support
According to the datasheet of BMP38x and BMP390 devices, for an SPI
read operation the first byte that is returned needs to be dropped,
and the rest of the bytes are the actual data returned from the
sensor.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Fixes:
|
||
Linus Torvalds
|
f2e367d6ad |
- Fix DM integrity and verity targets to not use excessive stack when
they recheck in the error path. -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEJfWUX4UqZ4x1O2wixSPxCi2dA1oFAmXaEswACgkQxSPxCi2d A1oT2Qf/c1opgjRUe+yY/v7nWf4paufSj2O4LYAy/qQBU7IS9CcXQPzi/pKlfEo8 60OZfa5gfrCAla79se7hHI/mxReq7CI5nFvYDyqQ1JZQ/djG/4cN/oWf5fQ12pon /ET1IzaZ+Mom+5wDBeQBLoQwXTA1ru5Bi1OiUe9Ed3wzadZQQks5s65fPnc0emGJ ClyaXiiCt4Dy36E5GmuPpmPB4ZJ57SwcnFWDFIeCHEbIQk36APkZ22z7lqGObjw2 ANO1l59k6ojzmaXLi9pw/J/o/qyfNR0MpeI7SpmtJzhSZKeGKsUX2GlJ9QBhViJp XL/+7MbSRJ43IY1lomoHZm1vxe0aPg== =sQPX -----END PGP SIGNATURE----- Merge tag 'for-6.8/dm-fix-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fix from Mike Snitzer: - Fix DM integrity and verity targets to not use excessive stack when they recheck in the error path. * tag 'for-6.8/dm-fix-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm-integrity, dm-verity: reduce stack usage for recheck |
||
|
Linus Torvalds
|
6d20acbf3e |
SCSI fixes on 20240224
Six fixes: the four driver ones are pretty trivial. The larger two core changes are to try to fix various USB attached devices which have somewhat eccentric ways of handling the VPD and other mode pages which necessitate multiple revalidates (that were removed in the interests of efficiency) and updating the heuristic for supported VPD pages. Signed-off-by: James E.J. Bottomley <jejb@linux.ibm.com> -----BEGIN PGP SIGNATURE----- iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCZdkyyyYcamFtZXMuYm90 dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishS2KAP0V8RVm U1gUoE4doIV9WdK8Dv0MUxnOpYVvjhRjM8PA1QEAwaPJivC91smxJv4MOIDq0PL3 9qyMwQq4jWH/2zS14p8= =8aq+ -----END PGP SIGNATURE----- Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Six fixes: the four driver ones are pretty trivial. The larger two core changes are to try to fix various USB attached devices which have somewhat eccentric ways of handling the VPD and other mode pages which necessitate multiple revalidates (that were removed in the interests of efficiency) and updating the heuristic for supported VPD pages" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: jazz_esp: Only build if SCSI core is builtin scsi: smartpqi: Fix disable_managed_interrupts scsi: ufs: Uninitialized variable in ufshcd_devfreq_target() scsi: target: pscsi: Fix bio_put() for error case scsi: core: Consult supported VPD page list prior to fetching page scsi: sd: usb_storage: uas: Access media prior to querying device properties |
||
|
Linus Torvalds
|
fef85269a1 |
Passing on a bugfix for host drivers
-----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAmXZIXIACgkQFA3kzBSg KbZC3A/+I6QRwH0mh/DhkmimbNXPogPYnO3CfoZdLKkVefIFLc2Vm9y5VmpW4G3/ yVrIZSaYbMBNJky3LfFwPV2WPcgxRvDHM8JFuLYoEw2mJtD6e71OgDxwZ2Io3vI+ DMx35H92sKf2Ohvqtofkyjeb0xIgc9SuQL8yf+bBO4q4H62eS2E+flnsLWIZWvRT NhG+gbu9LcOrPEpjmsGIf/4c1siMraUy342dSWjk6h3ndzokCkViTgZf2MXpLoMa MYLyNdC+xBvePZcngexd3JC0qhaSi1FQxM2U7xnXYeibTl5q2gSrzWNXptqNfXLk IZCBWOt3K7LZgHXEf5Gzyh8o2q2jBsxbu3/BZEYuNImCtkCAX1+9JS0y8aCNmaBH oPXdhaPmdaJMdh4AYFn36p5VOWWrSsK5H1XzTkPNjPMtYJqnHmCWPAVOULCRwEcd BSmwggVhh6wkW3xTObTRer/IjziCu43E/lW8KUXpn1cdyw4POAzT/On+B3vrm6vX Ay5h1dVqUPIs7k2clZzsbXi8rPp5Myr1/hxOrDxH4vP3jv6OAlWz93KuHi2Fg66t 71qmDumDq2Tr9A/tM9duQmZ72OwNS/1UqDVXg0Zk83frEpxjSmKC7ngDM2TNJ10E LMW1y0gAT9AzaJTvdAaLbzZmGrDNHjjqHLcLxo00UmAZw6JVP8I= =QxF6 -----END PGP SIGNATURE----- Merge tag 'i2c-for-6.8-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fix from Wolfram Sang: "A bugfix for host drivers" * tag 'i2c-for-6.8-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: imx: when being a target, mark the last read as processed |
||
|
Linus Torvalds
|
c6a597fcc7 |
LoongArch fixes for v6.8-rc6
-----BEGIN PGP SIGNATURE----- iQJKBAABCAA0FiEEzOlt8mkP+tbeiYy5AoYrw/LiJnoFAmXZeF4WHGNoZW5odWFj YWlAa2VybmVsLm9yZwAKCRAChivD8uImepF0D/9vFZTcp0RYeSg8ja6Hw5sPpCtO FbUepaxp7GnLzTAdCtrcNSGkKau4fWmo96fNcvs9Nshy08aemD8qLI9QH64oyLrJ K4YXk9MgU4ye5T71PHqSn5BMuVrNkeVt2Qe+2VCH15ZANTCkdComdLoxdkJa5N3M naOearhfh8qY0GHEVZFeBDkkcAU+xghi6//xwp3sd7562uUGsvXjiykog6JwNON5 Bzet22YigCkb5jSm5nyTS5DXEiNUDHd06mPp8yN6RLFPcN1nEiw1xviPGlKJZbwm dgoYgbMZCz668x7Lw/Uga2wmZm4HyxcEagcHJDZEGmnO++8a8fQUMTG00rQqEinG XvwmFHgDReaKoDaEA5R+fPEoMR7akWkXv5hbLz+ym+gfpGfyAX8fIkEd8Vh8DmgL IMJdH4AXYZhXxJbNiLOnWRB4NUjvxS86QS4o2HJMO6WsSvF8MB0ZOR17ROVM9ABP vb/EDfTdN5KYRvg6vBrUKNtw87NYm97uBjPCdwf/PfZqNGQ8wcdDQ4oiSh92cF5c Vd3T0YwAO45mW6EmzrhXgNh9JmYvNn1jqsX6pqGRY5FQ+6wZf4TfhZzCvlM8ShoX NElM1gbtT63nxDFFWVrxTQtabFQy4CVzQSjVoaCffs9Xt3ZQucGo3v6r7tnC1MqR gjM9WTQH4IK0y63fnQ== =tRG3 -----END PGP SIGNATURE----- Merge tag 'loongarch-fixes-6.8-3' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson Pull LoongArch fixes from Huacai Chen: "Fix two cpu-hotplug issues, fix the init sequence about FDT system, fix the coding style of dts, and fix the wrong CPUCFG ID handling of KVM" * tag 'loongarch-fixes-6.8-3' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: LoongArch: KVM: Streamline kvm_check_cpucfg() and improve comments LoongArch: KVM: Rename _kvm_get_cpucfg() to _kvm_get_cpucfg_mask() LoongArch: KVM: Fix input validation of _kvm_get_cpucfg() & kvm_check_cpucfg() LoongArch: dts: Minor whitespace cleanup LoongArch: Call early_init_fdt_scan_reserved_mem() earlier LoongArch: Update cpu_sibling_map when disabling nonboot CPUs LoongArch: Disable IRQ before init_fn() for nonboot CPUs |
||
Masahiro Yamada
|
c8c178e0ae |
ARM: 9353/1: remove unneeded entry for CONFIG_FRAME_POINTER
This is no-op. FRAME_POINTER is defined in lib/Kconfig.debug. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> |
||
Kees Cook
|
8f09b8b4fa |
ARM: 9351/1: fault: Add "cut here" line for prefetch aborts
The common pattern in arm is to emit a "8<--- cut here ---" line for faults, but it was missing for do_PrefetchAbort(). Add it. Cc: Wang Kefeng <wangkefeng.wang@huawei.com> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: linux-arm-kernel@lists.infradead.org Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> |
||
|
Kees Cook
|
169f9102f9 |
ARM: 9350/1: fault: Implement copy_from_kernel_nofault_allowed()
Under PAN emulation when dumping backtraces from things like the LKDTM EXEC_USERSPACE test[1], a double fault (which would hang a CPU) would happen because of dump_instr() attempting to read a userspace address. Make sure copy_from_kernel_nofault() does not attempt this any more. Closes: https://lava.sirena.org.uk/scheduler/job/497571 Link: https://lore.kernel.org/all/202401181125.D48DCB4C@keescook/ [1] Reported-by: Mark Brown <broonie@kernel.org> Suggested-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Mark Brown <broonie@kernel.org> Cc: Wang Kefeng <wangkefeng.wang@huawei.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> |
||
|
Kees Cook
|
daa559570d |
ARM: 9349/1: unwind: Add missing "Call trace:" line
Every other architecture in Linux includes the line "Call trace:" before backtraces. In some cases ARM would print "Backtrace:", but this was only via 1 specific call path, and wasn't included in CPU Oops nor things like KASAN, UBSAN, etc that called dump_stack(). Regularize this line so CI systems and other things (like LKDTM) that depend on parsing "Call trace:" out of dmesg will see it for ARM. Before this patch: UBSAN: array-index-out-of-bounds in ../drivers/misc/lkdtm/bugs.c:376:16 index 8 is out of range for type 'char [8]' CPU: 0 PID: 1402 Comm: cat Not tainted 6.7.0-rc2 #1 Hardware name: Generic DT based system dump_backtrace from show_stack+0x20/0x24 r7:00000042 r6:00000000 r5:60070013 r4:80cf5d7c show_stack from dump_stack_lvl+0x88/0x98 dump_stack_lvl from dump_stack+0x18/0x1c r7:00000042 r6:00000008 r5:00000008 r4:80fab118 dump_stack from ubsan_epilogue+0x10/0x3c ubsan_epilogue from __ubsan_handle_out_of_bounds+0x80/0x84 ... After this patch: UBSAN: array-index-out-of-bounds in ../drivers/misc/lkdtm/bugs.c:376:16 index 8 is out of range for type 'char [8]' CPU: 0 PID: 1402 Comm: cat Not tainted 6.7.0-rc2 #1 Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:00000042 r6:00000000 r5:60070013 r4:80cf5d7c show_stack from dump_stack_lvl+0x88/0x98 dump_stack_lvl from dump_stack+0x18/0x1c r7:00000042 r6:00000008 r5:00000008 r4:80fab118 dump_stack from ubsan_epilogue+0x10/0x3c ubsan_epilogue from __ubsan_handle_out_of_bounds+0x80/0x84 ... Link: https://lore.kernel.org/r/20240110215554.work.460-kees@kernel.org Reported-by: Mark Brown <broonie@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Vladimir Murzin <vladimir.murzin@arm.com> Cc: Zhen Lei <thunder.leizhen@huawei.com> Cc: Keith Packard <keithpac@amazon.com> Cc: Haibo Li <haibo.li@mediatek.com> Cc: <linux-arm-kernel@lists.infradead.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> |
||
Randy Dunlap
|
154c56d80b |
ARM: 9334/1: mm: init: remove misuse of kernel-doc comment
Change the "/**" beginning of comment to the common "/*" comment since the comment is not in kernel-doc format. This prevents a kernel-doc warning: arch/arm/mm/init.c:422: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * update_sections_early intended to be called only through stop_machine Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: linux-arm-kernel@lists.infradead.org Cc: patches@armlinux.org.uk Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> |
||
Jean-Baptiste Maneyrol
|
60caa8b33b |
iio: imu: inv_mpu6050: fix FIFO parsing when empty
Now that we are reading the full FIFO in the interrupt handler,
it is possible to have an emply FIFO since we are still receiving
1 interrupt per data. Handle correctly this case instead of having
an error causing a reset of the FIFO.
Fixes:
|
||
Arnd Bergmann
|
66ad2fbcdb |
dm-integrity, dm-verity: reduce stack usage for recheck
The newly added integrity_recheck() function has another larger stack allocation, just like its caller integrity_metadata(). When it gets inlined, the combination of the two exceeds the warning limit for 32-bit architectures and possibly risks an overflow when this is called from a deep call chain through a file system: drivers/md/dm-integrity.c:1767:13: error: stack frame size (1048) exceeds limit (1024) in 'integrity_metadata' [-Werror,-Wframe-larger-than] 1767 | static void integrity_metadata(struct work_struct *w) Since the caller at this point is done using its checksum buffer, just reuse the same buffer in the new function to avoid the double allocation. [Mikulas: add "noinline" to integrity_recheck and verity_recheck. These functions are only called on error, so they shouldn't bloat the stack frame or code size of the caller.] Fixes: |
||
Pierre Gondois
|
88debc6975 |
cpufreq: Remove references to 10ms min sampling rate
A minimum sampling rate value of 10ms was introduced in: commit |
||
Srinivas Pandruvada
|
1f4b7fdd71 |
cpufreq: intel_pstate: Update default EPPs for Meteor Lake
Update default balanced_performance EPP to 115 and performance EPP to 16. Changing the balanced_performance EPP has better performance/watt compared to default powerup EPP value of 128. Changing the performance EPP to 0x10 shows reduced power for similar performance as EPP 0. On small form factor devices this is beneficial as lower power results in lower CPU and skin temperature. This results in reduced thermal throttling and higher performance. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
||
|
Srinivas Pandruvada
|
240a8da623 |
cpufreq: intel_pstate: Allow model specific EPPs
The current implementation allows model specific EPP override for balanced_performance. Add feature to allow model specific EPP for all predefined EPP strings. For example for some CPU models, even changing performance EPP has benefits Use a mask of EPPs as driver_data instead of just balanced_performance. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
||
Doug Smythies
|
f0a0fc10ab |
cpufreq: intel_pstate: fix pstate limits enforcement for adjust_perf call back
There is a loophole in pstate limit clamping for the intel_cpufreq CPU
frequency scaling driver (intel_pstate in passive mode), schedutil CPU
frequency scaling governor, HWP (HardWare Pstate) control enabled, when
the adjust_perf call back path is used.
Fix it.
Fixes:
|
||
Bjorn Helgaas
|
75841d89f3 |
KVM: arm64: Fix typos
Fix typos, most reported by "codespell arch/arm64". Only touches comments, no code changes. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: James Morse <james.morse@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Zenghui Yu <yuzenghui@huawei.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: kvmarm@lists.linux.dev Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20240103231605.1801364-6-helgaas@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev> |
||
Eric Biggers
|
8c62f31edd |
fscrypt: shrink the size of struct fscrypt_inode_info slightly
Shrink the size of struct fscrypt_inode_info by 8 bytes by packing the small fields into the 64 bits after ci_enc_key. Link: https://lore.kernel.org/r/20240224060103.91037-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> |
||
|
Eric Biggers
|
2f944c66ae |
fscrypt: write CBC-CTS instead of CTS-CBC
Calling CBC with ciphertext stealing "CBC-CTS" seems to be more common than calling it "CTS-CBC". E.g., CBC-CTS is used by OpenSSL, Crypto++, RFC3962, and RFC6803. The NIST SP800-38A addendum uses CBC-CS1, CBC-CS2, and CBC-CS3, distinguishing between different CTS conventions but similarly putting the CBC part first. In the interest of avoiding any idiosyncratic terminology, update the fscrypt documentation and the fscrypt_mode "friendly names" to align with the more common convention. Changing the "friendly names" only affects some log messages. The actual mode constants in the API are unchanged; those call it simply "CTS". Add a note to the documentation that clarifies that "CBC" and "CTS" in the API really mean CBC-ESSIV and CBC-CTS, respectively. Link: https://lore.kernel.org/r/20240224053550.44659-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> |
||
Darrick J. Wong
|
1e5efd72a2 |
xfs: fix log recovery erroring out on refcount recovery failure
Per the comment in the error case of xfs_reflink_recover_cow, zero out
any error (after shutting down the log) so that we actually kill any new
intent items that might have gotten logged by later recovery steps.
Discovered by xfs/434, which few people actually seem to run.
Fixes:
|
||
Chandan Babu R
|
e6469b22bd |
xfs: clean up symbolic link code [v29.3 18/18]
This series cleans up a few bits of the symbolic link code as needed for future projects. Online repair requires the ability to commit fixed fork-based filesystem metadata such as directories, xattrs, and symbolic links atomically, so we need to rearrange the symlink code before we land the atomic extent swapping. Accomplish this by moving the remote symlink target block code and declarations to xfs_symlink_remote.[ch]. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYwAKCRBKO3ySh0YR ppvvAP0S+kTZ96zROb68pfy4xo5X0mcFvtuHQo4mc4Mu6UZf0AD+Lr/Xdnj/J9k1 8FEV933MFzWHINeeGUpaN8zgZBCvKA0= =Lgry -----END PGP SIGNATURE----- Merge tag 'symlink-cleanups-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: clean up symbolic link code This series cleans up a few bits of the symbolic link code as needed for future projects. Online repair requires the ability to commit fixed fork-based filesystem metadata such as directories, xattrs, and symbolic links atomically, so we need to rearrange the symlink code before we land the atomic extent swapping. Accomplish this by moving the remote symlink target block code and declarations to xfs_symlink_remote.[ch]. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'symlink-cleanups-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: move symlink target write function to libxfs xfs: move remote symlink target read function to libxfs xfs: move xfs_symlink_remote.c declarations to xfs_symlink_remote.h |
||
|
Chandan Babu R
|
6723ca9997 |
xfs: support attrfork and unwritten BUIs [v29.3 17/18]
In preparation for atomic extent swapping and the online repair functionality that wants atomic extent swaps, enhance the BUI code so that we can support deferred work on the extended attribute fork and on unwritten extents. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYwAKCRBKO3ySh0YR pnrTAP9dlLFGNBbmsOBR2KxzC56gShXMXHzytjxdMhh4JjnyJgD/XVTJYSxZuX9z VbWq8ZyCZwvS/onTnQw7WQcdhIkDTAo= =WQpT -----END PGP SIGNATURE----- Merge tag 'expand-bmap-intent-usage_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: support attrfork and unwritten BUIs In preparation for atomic extent swapping and the online repair functionality that wants atomic extent swaps, enhance the BUI code so that we can support deferred work on the extended attribute fork and on unwritten extents. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'expand-bmap-intent-usage_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: xfs_bmap_finish_one should map unwritten extents properly xfs: support deferred bmap updates on the attr fork |
||
|
Chandan Babu R
|
4e3f7e7ab8 |
xfs: widen BUI formats to support realtime [v29.3 16/18]
Atomic extent swapping (and later, reverse mapping and reflink) on the realtime device needs to be able to defer file mapping and extent freeing work in much the same manner as is required on the data volume. Make the BUI log items operate on rt extents in preparation for atomic swapping and realtime rmap. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYgAKCRBKO3ySh0YR poOrAPwPw7LSL7/19Q2pIr1UsI798Opw079T2n8FHAVK1weEzQD/TzGgglrTu0Fx CHKYwjtIDw8drMli/6XWSAcE1JcuIAo= =KBwk -----END PGP SIGNATURE----- Merge tag 'realtime-bmap-intents-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: widen BUI formats to support realtime Atomic extent swapping (and later, reverse mapping and reflink) on the realtime device needs to be able to defer file mapping and extent freeing work in much the same manner as is required on the data volume. Make the BUI log items operate on rt extents in preparation for atomic swapping and realtime rmap. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'realtime-bmap-intents-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: support recovering bmap intent items targetting realtime extents xfs: add a realtime flag to the bmap update log redo items xfs: fix xfs_bunmapi to allow unmapping of partial rt extents |
||
|
Chandan Babu R
|
10ea6158b4 |
xfs: bmap log intent cleanups [v29.3 15/18]
The next major target of online repair are metadata that are persisted in blocks mapped by a file fork. In other words, we want to repair directories, extended attributes, symbolic links, and the realtime free space information. For file-based metadata, we assume that the space metadata is correct, which enables repair to construct new versions of the metadata in a temporary file. We then need to swap the file fork mappings of the two files atomically. With this patchset, we begin constructing such a facility based on the existing bmap log items and a new extent swap log item. This series cleans up a few parts of the file block mapping log intent code before we start adding support for realtime bmap intents. Most of it involves cleaning up tracepoints so that more of the data extraction logic ends up in the tracepoint code and not the tracepoint call site, which should reduce overhead further when tracepoints are disabled. There is also a change to pass bmap intents all the way back to the bmap code instead of unboxing the intent values and re-boxing them after the _finish_one function completes. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYgAKCRBKO3ySh0YR phAMAP9huan/JlVi4QwzTh363EQLk72fQxMleGvVLetY5ZMMOQEA/yUdBGbJyRxn D1gqrr68KFf61NKxrJir41djeeqKjQw= =ex04 -----END PGP SIGNATURE----- Merge tag 'bmap-intent-cleanups-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: bmap log intent cleanups The next major target of online repair are metadata that are persisted in blocks mapped by a file fork. In other words, we want to repair directories, extended attributes, symbolic links, and the realtime free space information. For file-based metadata, we assume that the space metadata is correct, which enables repair to construct new versions of the metadata in a temporary file. We then need to swap the file fork mappings of the two files atomically. With this patchset, we begin constructing such a facility based on the existing bmap log items and a new extent swap log item. This series cleans up a few parts of the file block mapping log intent code before we start adding support for realtime bmap intents. Most of it involves cleaning up tracepoints so that more of the data extraction logic ends up in the tracepoint code and not the tracepoint call site, which should reduce overhead further when tracepoints are disabled. There is also a change to pass bmap intents all the way back to the bmap code instead of unboxing the intent values and re-boxing them after the _finish_one function completes. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'bmap-intent-cleanups-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: add a xattr_entry helper xfs: move xfs_bmap_defer_add to xfs_bmap_item.c xfs: reuse xfs_bmap_update_cancel_item xfs: add a bi_entry helper xfs: remove xfs_trans_set_bmap_flags xfs: clean up bmap log intent item tracepoint callsites xfs: split tracepoint classes for deferred items |
||
|
Chandan Babu R
|
74acb70535 |
xfs: reduce refcount repair memory usage [v29.3 14/18]
The refcountbt repair code has serious memory usage problems when the block sharing factor of the filesystem is very high. This can happen if a deduplication tool has been run against the filesystem, or if the fs stores reflinked VM images that have been aging for a long time. Recall that the original reference counting algorithm walks the reverse mapping records of the filesystem to generate reference counts. For any given block in the AG, the rmap bag structure contains the all rmap records that cover that block; the refcount is the size of that bag. For online repair, the bag doesn't need the owner, offset, or state flag information, so it discards those. This halves the record size, but the bag structure still stores one excerpted record for each reverse mapping. If the sharing count is high, this will use a LOT of memory storing redundant records. In the extreme case, 100k mappings to the same piece of space will consume 100k*16 bytes = 1.6M of memory. For offline repair, the bag stores the owner values so that we know which inodes need to be marked as being reflink inodes. If a deduplication tool has been run and there are many blocks within a file pointing to the same physical space, this will stll use a lot of memory to store redundant records. The solution to this problem is to deduplicate the bag records when possible by adding a reference count to the bag record, and changing the bag add function to detect an existing record to bump the refcount. In the above example, the 100k mappings will now use 24 bytes of memory. These lookups can be done efficiently with a btree, so we create a new refcount bag btree type (inside of online repair). This is why we refactored the btree code in the previous patchset. The btree conversion also dramatically reduces the runtime of the refcount generation algorithm, because the code to delete all bag records that end at a given agblock now only has to delete one record instead of (using the example above) 100k records. As an added benefit, record deletion now gives back the unused xfile space, which it did not do previously. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYgAKCRBKO3ySh0YR piYKAP49HMCG0qAUM78QVBjRYDUzTnzh4X052PbYXiGKvFf+xgD/ajUbn+pL12TH Et2H9pN6V7T+S74dwWdw+km02Mgo0wI= =HJC0 -----END PGP SIGNATURE----- Merge tag 'repair-refcount-scalability-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: reduce refcount repair memory usage The refcountbt repair code has serious memory usage problems when the block sharing factor of the filesystem is very high. This can happen if a deduplication tool has been run against the filesystem, or if the fs stores reflinked VM images that have been aging for a long time. Recall that the original reference counting algorithm walks the reverse mapping records of the filesystem to generate reference counts. For any given block in the AG, the rmap bag structure contains the all rmap records that cover that block; the refcount is the size of that bag. For online repair, the bag doesn't need the owner, offset, or state flag information, so it discards those. This halves the record size, but the bag structure still stores one excerpted record for each reverse mapping. If the sharing count is high, this will use a LOT of memory storing redundant records. In the extreme case, 100k mappings to the same piece of space will consume 100k*16 bytes = 1.6M of memory. For offline repair, the bag stores the owner values so that we know which inodes need to be marked as being reflink inodes. If a deduplication tool has been run and there are many blocks within a file pointing to the same physical space, this will stll use a lot of memory to store redundant records. The solution to this problem is to deduplicate the bag records when possible by adding a reference count to the bag record, and changing the bag add function to detect an existing record to bump the refcount. In the above example, the 100k mappings will now use 24 bytes of memory. These lookups can be done efficiently with a btree, so we create a new refcount bag btree type (inside of online repair). This is why we refactored the btree code in the previous patchset. The btree conversion also dramatically reduces the runtime of the refcount generation algorithm, because the code to delete all bag records that end at a given agblock now only has to delete one record instead of (using the example above) 100k records. As an added benefit, record deletion now gives back the unused xfile space, which it did not do previously. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'repair-refcount-scalability-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: port refcount repair to the new refcount bag structure xfs: create refcount bag structure for btree repairs xfs: define an in-memory btree for storing refcount bag info during repairs |
||
|
Chandan Babu R
|
fd43925cad |
xfs: online repair of rmap btrees [v29.3 13/18]
We have now constructed the four tools that we need to scan the filesystem looking for reverse mappings: an inode scanner, hooks to receive live updates from other writer threads, the ability to construct btrees in memory, and a btree bulk loader. This series glues those three together, enabling us to scan the filesystem for mappings and keep it up to date while other writers run, and then commit the new btree to disk atomically. To reduce the size of each patch, the functionality is left disabled until the end of the series and broken up into three patches: one to create the mechanics of scanning the filesystem, a second to transition to in-memory btrees, and a third to set up the live hooks. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYgAKCRBKO3ySh0YR plVEAP9K4IYNtRvVfC88M3x1fHLKU7EEhBubZtVx7IxWYvttRQEA+km0YW61p46G B459ut4jBZ78M//oZC0OmttRRWC0rgk= =WGZR -----END PGP SIGNATURE----- Merge tag 'repair-rmap-btree-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: online repair of rmap btrees We have now constructed the four tools that we need to scan the filesystem looking for reverse mappings: an inode scanner, hooks to receive live updates from other writer threads, the ability to construct btrees in memory, and a btree bulk loader. This series glues those three together, enabling us to scan the filesystem for mappings and keep it up to date while other writers run, and then commit the new btree to disk atomically. To reduce the size of each patch, the functionality is left disabled until the end of the series and broken up into three patches: one to create the mechanics of scanning the filesystem, a second to transition to in-memory btrees, and a third to set up the live hooks. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'repair-rmap-btree-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: hook live rmap operations during a repair operation xfs: create a shadow rmap btree during rmap repair xfs: repair the rmapbt xfs: create agblock bitmap helper to count the number of set regions xfs: create a helper to decide if a file mapping targets the rt volume |
||
|
Chandan Babu R
|
8394a97c4b |
xfs: support in-memory btrees [v29.3 12/18]
Online repair of the reverse-mapping btrees presens some unique challenges. To construct a new reverse mapping btree, we must scan the entire filesystem, but we cannot afford to quiesce the entire filesystem for the potentially lengthy scan. For rmap btrees, therefore, we relax our requirements of totally atomic repairs. Instead, repairs will scan all inodes, construct a new reverse mapping dataset, format a new btree, and commit it before anyone trips over the corruption. This is exactly the same strategy as was used in the quotacheck and nlink scanners. Unfortunately, the xfarray cannot perform key-based lookups and is therefore unsuitable for supporting live updates. Luckily, we already a data structure that maintains an indexed rmap recordset -- the existing rmap btree code! Hence we port the existing btree and buffer target code to be able to create a btree using the xfile we developed earlier. Live hooks keep the in-memory btree up to date for any resources that have already been scanned. This approach is not maximally memory efficient, but we can use the same rmap code that we do everywhere else, which provides improved stability without growing the code base even more. Note that in-memory btree blocks are always page sized. This patchset modifies the kernel xfs buffer cache to be capable of using a xfile (aka a shmem file) as a backing device. It then augments the btree code to support creating btree cursors with buffers that come from a buftarg other than the data device (namely an xfile-backed buftarg). For the userspace xfs buffer cache, we instead use a memfd or an O_TMPFILE file as a backing device. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYgAKCRBKO3ySh0YR pqHwAQCjqXCvbqrWgMC/oYWuuDkYul79mqZw7PF58tdWpsOnzwD/dkyt7FBpAaAA GCaCIpWwOPErZ0LMT2fH6CqZyndSxw8= =vdwY -----END PGP SIGNATURE----- Merge tag 'in-memory-btrees-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: support in-memory btrees Online repair of the reverse-mapping btrees presens some unique challenges. To construct a new reverse mapping btree, we must scan the entire filesystem, but we cannot afford to quiesce the entire filesystem for the potentially lengthy scan. For rmap btrees, therefore, we relax our requirements of totally atomic repairs. Instead, repairs will scan all inodes, construct a new reverse mapping dataset, format a new btree, and commit it before anyone trips over the corruption. This is exactly the same strategy as was used in the quotacheck and nlink scanners. Unfortunately, the xfarray cannot perform key-based lookups and is therefore unsuitable for supporting live updates. Luckily, we already a data structure that maintains an indexed rmap recordset -- the existing rmap btree code! Hence we port the existing btree and buffer target code to be able to create a btree using the xfile we developed earlier. Live hooks keep the in-memory btree up to date for any resources that have already been scanned. This approach is not maximally memory efficient, but we can use the same rmap code that we do everywhere else, which provides improved stability without growing the code base even more. Note that in-memory btree blocks are always page sized. This patchset modifies the kernel xfs buffer cache to be capable of using a xfile (aka a shmem file) as a backing device. It then augments the btree code to support creating btree cursors with buffers that come from a buftarg other than the data device (namely an xfile-backed buftarg). For the userspace xfs buffer cache, we instead use a memfd or an O_TMPFILE file as a backing device. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'in-memory-btrees-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: launder in-memory btree buffers before transaction commit xfs: support in-memory btrees xfs: add a xfs_btree_ptrs_equal helper xfs: support in-memory buffer cache targets xfs: teach buftargs to maintain their own buffer hashtable |
||
|
Chandan Babu R
|
aa8fb4bb7d |
xfs: buftarg cleanups [v29.3 11/18]
Clean up the buffer target code in preparation for adding the ability to target tmpfs files. That will enable the creation of in memory btrees. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYgAKCRBKO3ySh0YR pi3lAQCo1U4Qp5ftsgR2FdjpxKofWJr7qqpXFMvDZhQSCF1yTAEAiRz018fUVTtt Hb9xUmu0XrHErtJN++23/O0Q4TmM4A0= =T7wJ -----END PGP SIGNATURE----- Merge tag 'buftarg-cleanups-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: buftarg cleanups Clean up the buffer target code in preparation for adding the ability to target tmpfs files. That will enable the creation of in memory btrees. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'buftarg-cleanups-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: move setting bt_logical_sectorsize out of xfs_setsize_buftarg xfs: remove xfs_setsize_buftarg_early xfs: remove the xfs_buftarg_t typedef |
||
|
Chandan Babu R
|
a7ade7e13d |
xfs: btree readahead cleanups [v29.3 10/18]
Minor cleanups for the btree block readahead code. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYQAKCRBKO3ySh0YR pmF2AQCvxmU219Wjaa25Bkor40UGpcgy4T5xbFdSFT8umdPxXAD+IdVsIUm6pPmk gr4+OPqIwJbGUaz3GJHg5qO6Wh+orQY= =rxd3 -----END PGP SIGNATURE----- Merge tag 'btree-readahead-cleanups-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: btree readahead cleanups Minor cleanups for the btree block readahead code. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'btree-readahead-cleanups-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: split xfs_buf_rele for cached vs uncached buffers xfs: move and rename xfs_btree_read_bufl xfs: remove xfs_btree_reada_bufs xfs: remove xfs_btree_reada_bufl |
||
|
Chandan Babu R
|
169c030a95 |
xfs: btree check cleanups [v29.3 09/18]
Minor cleanups for the btree block pointer checking code. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYQAKCRBKO3ySh0YR psBVAP4ik1Cj5KPP75mJws4duDycYjy9Wm0ZucNjUD19iQbo9wEAqXwFZuUm/wuJ TbCPVZ9EWtqg7pInrOSK+GmoOjUciQM= =FpUY -----END PGP SIGNATURE----- Merge tag 'btree-check-cleanups-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: btree check cleanups Minor cleanups for the btree block pointer checking code. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'btree-check-cleanups-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: factor out a __xfs_btree_check_lblock_hdr helper xfs: rename btree helpers that depends on the block number representation xfs: consolidate btree block verification xfs: tighten up validation of root block in inode forks xfs: remove the crc variable in __xfs_btree_check_lblock xfs: misc cleanups for __xfs_btree_check_sblock xfs: consolidate btree ptr checking xfs: open code xfs_btree_check_lptr in xfs_bmap_btree_to_extents xfs: simplify xfs_btree_check_lblock_siblings xfs: simplify xfs_btree_check_sblock_siblings |
||
|
Chandan Babu R
|
ee138217c3 |
xfs: remove bc_btnum from btree cursors [v29.3 08/18]
From Christoph Hellwig, This series continues the migration of btree geometry information out of the cursor structure and into the ops structure. This time around, we replace the btree type enumeration (btnum) with an explicit name string in the btree ops structure. This enables easy creation of /any/ new btree type without having to mess with libxfs. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYQAKCRBKO3ySh0YR ppPOAP9QUT/PSvFdaSSKr64DAIy/fNE5qusmDfmBeQY/uMqOAQEAr75VaDV77JA3 KYIXiQVu6siZrRzVOC7T6oANii7+Ugk= =1Tbm -----END PGP SIGNATURE----- Merge tag 'btree-remove-btnum-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: remove bc_btnum from btree cursors From Christoph Hellwig, This series continues the migration of btree geometry information out of the cursor structure and into the ops structure. This time around, we replace the btree type enumeration (btnum) with an explicit name string in the btree ops structure. This enables easy creation of /any/ new btree type without having to mess with libxfs. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'btree-remove-btnum-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: remove xfs_btnum_t xfs: pass a 'bool is_finobt' to xfs_inobt_insert xfs: split xfs_inobt_init_cursor xfs: split xfs_inobt_insert_sprec xfs: remove the which variable in xchk_iallocbt xfs: remove the btnum argument to xfs_inobt_count_blocks xfs: remove xfs_inobt_cur xfs: split xfs_allocbt_init_cursor xfs: refactor the btree cursor allocation logic in xchk_ag_btcur_init xfs: add a sick_mask to struct xfs_btree_ops xfs: add a name field to struct xfs_btree_ops xfs: split the agf_roots and agf_levels arrays xfs: remove xfs_bmbt_stage_cursor xfs: fold xfs_bmbt_init_common into xfs_bmbt_init_cursor xfs: make staging file forks explicit xfs: make full use of xfs_btree_stage_ifakeroot in xfs_bmbt_stage_cursor xfs: remove xfs_rmapbt_stage_cursor xfs: fold xfs_rmapbt_init_common into xfs_rmapbt_init_cursor xfs: remove xfs_refcountbt_stage_cursor xfs: fold xfs_refcountbt_init_common into xfs_refcountbt_init_cursor xfs: remove xfs_inobt_stage_cursor xfs: fold xfs_inobt_init_common into xfs_inobt_init_cursor xfs: remove xfs_allocbt_stage_cursor xfs: fold xfs_allocbt_init_common into xfs_allocbt_init_cursor xfs: don't override bc_ops for staging btrees xfs: add a xfs_btree_init_ptr_from_cur xfs: move comment about two 2 keys per pointer in the rmap btree |
||
|
Chandan Babu R
|
681cb87b6a |
xfs: move btree geometry to ops struct [v29.3 07/18]
This patchset prepares the generic btree code to allow for the creation of new btree types outside of libxfs. The end goal here is for online fsck to be able to create its own in-memory btrees that will be used to improve the performance (and reduce the memory requirements of) the refcount btree. To enable this, I decided that the btree ops structure is the ideal place to encode all of the geometry information about a btree. The btree ops struture already contains the buffer ops (and hence the btree block magic numbers) as well as the key and record sizes, so it doesn't seem all that farfetched to encode the XFS_BTREE_ flags that determine the geometry (ROOT_IN_INODE, LONG_PTRS, etc). The rest of the patchset cleans up the btree functions that initialize btree blocks and btree buffers. The bulk of this work is to replace btree geometry related function call arguments with a single pointer to the ops structure, and then clean up everything else around that. As a side effect, we rename the functions. Later, Christoph Hellwig and I merged together a bunch more cleanups that he wanted to do for a while. All the btree geometry information is now in the btree ops structure, we've created an explicit btree type (ag, inode, mem) and moved the per-btree type information to a separate union. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYQAKCRBKO3ySh0YR puvdAQDMAehLo8djvsi4dipw1+v7kgD11/H1sD4qsHQTc2UuGAEA3me2bHB36o1k bDL7Vmsin6BazStkoqCGhc18x8MW3w4= =0Fis -----END PGP SIGNATURE----- Merge tag 'btree-geometry-in-ops-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: move btree geometry to ops struct This patchset prepares the generic btree code to allow for the creation of new btree types outside of libxfs. The end goal here is for online fsck to be able to create its own in-memory btrees that will be used to improve the performance (and reduce the memory requirements of) the refcount btree. To enable this, I decided that the btree ops structure is the ideal place to encode all of the geometry information about a btree. The btree ops struture already contains the buffer ops (and hence the btree block magic numbers) as well as the key and record sizes, so it doesn't seem all that farfetched to encode the XFS_BTREE_ flags that determine the geometry (ROOT_IN_INODE, LONG_PTRS, etc). The rest of the patchset cleans up the btree functions that initialize btree blocks and btree buffers. The bulk of this work is to replace btree geometry related function call arguments with a single pointer to the ops structure, and then clean up everything else around that. As a side effect, we rename the functions. Later, Christoph Hellwig and I merged together a bunch more cleanups that he wanted to do for a while. All the btree geometry information is now in the btree ops structure, we've created an explicit btree type (ag, inode, mem) and moved the per-btree type information to a separate union. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'btree-geometry-in-ops-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: create predicate to determine if cursor is at inode root level xfs: split the per-btree union in struct xfs_btree_cur xfs: split out a btree type from the btree ops geometry flags xfs: store the btree pointer length in struct xfs_btree_ops xfs: factor out a btree block owner check xfs: factor out a xfs_btree_owner helper xfs: move the btree stats offset into struct btree_ops xfs: move lru refs to the btree ops structure xfs: set btree block buffer ops in _init_buf xfs: remove the unnecessary daddr paramter to _init_block xfs: btree convert xfs_btree_init_block to xfs_btree_init_buf calls xfs: rename btree block/buffer init functions xfs: initialize btree blocks using btree_ops structure xfs: extern some btree ops structures xfs: turn the allocbt cursor active field into a btree flag xfs: consolidate the xfs_alloc_lookup_* helpers xfs: remove bc_ino.flags xfs: encode the btree geometry flags in the btree ops structure xfs: fix imprecise logic in xchk_btree_check_block_owner xfs: drop XFS_BTREE_CRC_BLOCKS xfs: set the btree cursor bc_ops in xfs_btree_alloc_cursor xfs: consolidate btree block allocation tracepoints xfs: consolidate btree block freeing tracepoints |
||
|
Chandan Babu R
|
5d1bd19d83 |
xfs: online repair for fs summary counters [v29.3 06/18]
A longstanding deficiency in the online fs summary counter scrubbing code is that it hasn't any means to quiesce the incore percpu counters while it's running. There is no way to coordinate with other threads are reserving or freeing free space simultaneously, which leads to false error reports. Right now, if the discrepancy is large, we just sort of shrug and bail out with an incomplete flag, but this is lame. For repair activity, we actually /do/ need to stabilize the counters to get an accurate reading and install it in the percpu counter. To improve the former and enable the latter, allow the fscounters online fsck code to perform an exclusive mini-freeze on the filesystem. The exclusivity prevents userspace from thawing while we're running, and the mini-freeze means that we don't wait for the log to quiesce, which will make both speedier. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYQAKCRBKO3ySh0YR pjYgAQCHdKKwkD0bAZyKT6By30Vxiahey5HUrlLvg1QeGIzXlAD/e4oLwdfxYrcr 1wL7GTDix9eVJSMe7ZSgmxX4W9KVMAE= =CqKZ -----END PGP SIGNATURE----- Merge tag 'repair-fscounters-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: online repair for fs summary counters A longstanding deficiency in the online fs summary counter scrubbing code is that it hasn't any means to quiesce the incore percpu counters while it's running. There is no way to coordinate with other threads are reserving or freeing free space simultaneously, which leads to false error reports. Right now, if the discrepancy is large, we just sort of shrug and bail out with an incomplete flag, but this is lame. For repair activity, we actually /do/ need to stabilize the counters to get an accurate reading and install it in the percpu counter. To improve the former and enable the latter, allow the fscounters online fsck code to perform an exclusive mini-freeze on the filesystem. The exclusivity prevents userspace from thawing while we're running, and the mini-freeze means that we don't wait for the log to quiesce, which will make both speedier. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'repair-fscounters-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: repair summary counters |
||
|
Chandan Babu R
|
f107757953 |
xfs: indirect health reporting [v29.3 05/18]
This series enables the XFS health reporting infrastructure to remember indirect health concerns when resources are scarce. For example, if a scrub notices that there's something wrong with an inode's metadata but memory reclaim needs to free the incore inode, we want to record in the perag data the fact that there was some inode somewhere with an error. The perag structures never go away. The first two patches in this series set that up, and the third one provides a means for xfs_scrub to tell the kernel that it can forget the indirect problem report. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYAAKCRBKO3ySh0YR pvzvAQD1oxlTpXYLjT5xnhQHpg/nYoXUQdOqFLrMTH5i8mm9VQD+JmiLvIUCD5Au K4qtmq9MSO4XzTKDbx9B4l/rn0H4uQ0= =H6az -----END PGP SIGNATURE----- Merge tag 'indirect-health-reporting-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: indirect health reporting This series enables the XFS health reporting infrastructure to remember indirect health concerns when resources are scarce. For example, if a scrub notices that there's something wrong with an inode's metadata but memory reclaim needs to free the incore inode, we want to record in the perag data the fact that there was some inode somewhere with an error. The perag structures never go away. The first two patches in this series set that up, and the third one provides a means for xfs_scrub to tell the kernel that it can forget the indirect problem report. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'indirect-health-reporting-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: update health status if we get a clean bill of health xfs: remember sick inodes that get inactivated xfs: add secondary and indirect classes to the health tracking system |
||
|
Chandan Babu R
|
6fe1910e85 |
xfs: report corruption to the health trackers [v29.3 04/18]
Any time that the runtime code thinks it has found corrupt metadata, it should tell the health tracking subsystem that the corresponding part of the filesystem is sick. These reports come primarily from two places -- code that is reading a buffer that fails validation, and higher level pieces that observe a conflict involving multiple buffers. This patchset uses automated scanning to update all such callsites with a mark_sick call. Doing this enables the health system to record problem observed at runtime, which (for now) can prompt the sysadmin to run xfs_scrub, and (later) may enable more targetted fixing of the filesystem. Note: Earlier reviewers of this patchset suggested that the verifier functions themselves should be responsible for calling _mark_sick. In a higher level language this would be easily accomplished with lambda functions and closures. For the kernel, however, we'd have to create the necessary closures by hand, pass them to the buf_read calls, and then implement necessary state tracking to detach the xfs_buf from the closure at the necessary time. This is far too much work and complexity and will not be pursued further. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYAAKCRBKO3ySh0YR pi9LAQCgKJHvlmaM5JUNPoa06YCqxvsrDHRWQ0j7cZ/xm9AGSAEAmhDay+1oCDef PIPxJr//SvxXByCzttjjOA+TAouGFA0= =2Xjd -----END PGP SIGNATURE----- Merge tag 'corruption-health-reports-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: report corruption to the health trackers Any time that the runtime code thinks it has found corrupt metadata, it should tell the health tracking subsystem that the corresponding part of the filesystem is sick. These reports come primarily from two places -- code that is reading a buffer that fails validation, and higher level pieces that observe a conflict involving multiple buffers. This patchset uses automated scanning to update all such callsites with a mark_sick call. Doing this enables the health system to record problem observed at runtime, which (for now) can prompt the sysadmin to run xfs_scrub, and (later) may enable more targetted fixing of the filesystem. Note: Earlier reviewers of this patchset suggested that the verifier functions themselves should be responsible for calling _mark_sick. In a higher level language this would be easily accomplished with lambda functions and closures. For the kernel, however, we'd have to create the necessary closures by hand, pass them to the buf_read calls, and then implement necessary state tracking to detach the xfs_buf from the closure at the necessary time. This is far too much work and complexity and will not be pursued further. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'corruption-health-reports-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: report XFS_IS_CORRUPT errors to the health system xfs: report realtime metadata corruption errors to the health system xfs: report quota block corruption errors to the health system xfs: report inode corruption errors to the health system xfs: report symlink block corruption errors to the health system xfs: report dir/attr block corruption errors to the health system xfs: report btree block corruption errors to the health system xfs: report block map corruption errors to the health tracking system xfs: report ag header corruption errors to the health tracking system xfs: report fs corruption errors to the health tracking system xfs: separate the marking of sick and checked metadata |
||
|
Chandan Babu R
|
128d0fd1ab |
xfs: online repair of file link counts [v29.3 03/18]
Now that we've created the infrastructure to perform live scans of every file in the filesystem and the necessary hook infrastructure to observe live updates, use it to scan directories to compute the correct link counts for files in the filesystem, and reset those link counts. This patchset creates a tailored readdir implementation for scrub because the regular version has to cycle ILOCKs to copy information to userspace. We can't cycle the ILOCK during the nlink scan and we don't need all the other VFS support code (maintaining a readdir cursor and translating XFS structures to VFS structures and back) so it was easier to duplicate the code. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYAAKCRBKO3ySh0YR pjJwAP49J6UgZUDQMX4rQ5q2TbyHLnyvUzeiQ/Cc8IqXau5VxwD/U3QNPii5uUMw jNid2AMba4AkXkskU6fr4do8UwmPSQ4= =Dva/ -----END PGP SIGNATURE----- Merge tag 'scrub-nlinks-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: online repair of file link counts Now that we've created the infrastructure to perform live scans of every file in the filesystem and the necessary hook infrastructure to observe live updates, use it to scan directories to compute the correct link counts for files in the filesystem, and reset those link counts. This patchset creates a tailored readdir implementation for scrub because the regular version has to cycle ILOCKs to copy information to userspace. We can't cycle the ILOCK during the nlink scan and we don't need all the other VFS support code (maintaining a readdir cursor and translating XFS structures to VFS structures and back) so it was easier to duplicate the code. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'scrub-nlinks-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: teach repair to fix file nlinks xfs: track directory entry updates during live nlinks fsck xfs: teach scrub to check file nlinks xfs: report health of inode link counts |
||
|
Chandan Babu R
|
aa03f524a2 |
xfs: online repair of quota counters [v29.3 02/18]
This series uses the inode scanner and live update hook functionality introduced in the last patchset to implement quotacheck on a live filesystem. The quotacheck scrubber builds an incore copy of the dquot resource usage counters and compares it to the live dquots to report discrepancies. If the user chooses to repair the quota counters, the repair function visits each incore dquot to update the counts from the live information. The live update hooks are key to keeping the incore copy up to date. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYAAKCRBKO3ySh0YR pl+VAQDUflOVAEIKqwm+EaFFkbW7esxF4UYTn5N9Vj0hiLhogAD/SBOf/3fF58AI kwRwHDBtbDesuwZbTnaCo7Vj7Hq33wM= =2VuF -----END PGP SIGNATURE----- Merge tag 'repair-quotacheck-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: online repair of quota counters This series uses the inode scanner and live update hook functionality introduced in the last patchset to implement quotacheck on a live filesystem. The quotacheck scrubber builds an incore copy of the dquot resource usage counters and compares it to the live dquots to report discrepancies. If the user chooses to repair the quota counters, the repair function visits each incore dquot to update the counts from the live information. The live update hooks are key to keeping the incore copy up to date. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'repair-quotacheck-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: repair dquots based on live quotacheck results xfs: repair cannot update the summary counters when logging quota flags xfs: track quota updates during live quotacheck xfs: implement live quotacheck inode scan xfs: create a sparse load xfarray function xfs: create a helper to count per-device inode block usage xfs: create a xchk_trans_alloc_empty helper for scrub xfs: report the health of quota counts |
||
|
Chandan Babu R
|
8e3ef44f9b |
xfs: repair inode mode by scanning dirs [v29.3 01/18]
One missing piece of functionality in the inode record repair code is figuring out what to do with a file whose mode is so corrupt that we cannot tell us the type of the file. Originally this was done by guessing the mode from the ondisk inode contents, but Christoph didn't like that because it read from data fork block 0, which could be user controlled data. Therefore, I've replaced all that with a directory scanner that looks for any dirents that point to the file with the garbage mode. If so, the ftype in the dirent will tell us exactly what mode to set on the file. Since users cannot directly write to the ftype field of a dirent, this should be safe. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZdlBYAAKCRBKO3ySh0YR pvYaAQCdHMP4V94sw+jI46FHgqBAEEuqZUjq8cHwZPrtDzZc5QEA4fsbzR8yXJsw imsHjftkRhSEav0LVXhPCbaFfphbUQ0= =O1cc -----END PGP SIGNATURE----- Merge tag 'repair-inode-mode-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC xfs: repair inode mode by scanning dirs One missing piece of functionality in the inode record repair code is figuring out what to do with a file whose mode is so corrupt that we cannot tell us the type of the file. Originally this was done by guessing the mode from the ondisk inode contents, but Christoph didn't like that because it read from data fork block 0, which could be user controlled data. Therefore, I've replaced all that with a directory scanner that looks for any dirents that point to the file with the garbage mode. If so, the ftype in the dirent will tell us exactly what mode to set on the file. Since users cannot directly write to the ftype field of a dirent, this should be safe. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> * tag 'repair-inode-mode-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux: xfs: repair file modes by scanning for a dirent pointing to us xfs: create a macro for decoding ftypes in tracepoints xfs: create a predicate to determine if two xfs_names are the same xfs: create a static name for the dot entry too xfs: iscan batching should handle unallocated inodes too xfs: cache a bunch of inodes for repair scans xfs: stagger the starting AG of scrub iscans to reduce contention xfs: allow scrub to hook metadata updates in other writers xfs: implement live inode scan for scrub xfs: speed up xfs_iwalk_adjust_start a little bit |
||
Jakub Kicinski
|
d662c5b3ce |
tools: ynl: fix header guards
devlink and ethtool have a trailing _ in the header guard. I must have
copy/pasted it into new guards, assuming it's a headers_install artifact.
This fixes build if system headers are old.
Fixes:
|
||
|
Jakub Kicinski
|
5fd5403964 |
genetlink: make info in GENL_REQ_ATTR_CHECK() const
Make the local variable in GENL_REQ_ATTR_CHECK() const. genl_info_dump() returns a const pointer, so the macro is currently hard to use in genl dumps. Link: https://lore.kernel.org/r/20240222222819.156320-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Jakub Kicinski
|
6511743e01 |
Merge branch 'tools-ynl-couple-of-cmdline-enhancements'
Jiri Pirko says: ==================== tools: ynl: couple of cmdline enhancements This is part of the original "netlink: specs: devlink: add the rest of missing attribute definitions" set which was rejected [1]. These three patches enhances the cmdline user comfort, allowing to pass flag attribute with bool values and enum names instead of scalars. [1] https://lore.kernel.org/all/20240220181004.639af931@kernel.org/ ==================== Link: https://lore.kernel.org/r/20240222134351.224704-1-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org> |