Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80 2024-11-08T05:05:53+00:00 2024-11-08T05:05:53+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-11-08T03:18:02+00:00 urn:sha1:f8f1dde6868139f2294786365c56d7ff5cc3f4e7 This fixes an assertion pop where we try to navigate to the target of the backpointer, and the path level isn't what we expect. Reported-by: syzbot+b17df21b4d370f2dc330@syzkaller.appspotmail.com Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 2024-10-20T22:08:53+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-10-20T20:48:31+00:00 urn:sha1:e04ee8608914d00812e4a10288cf8d8905ced849 Reported-by: Marcin Mirosław <marcin@mejor.pl> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 2024-10-13T21:55:33+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-10-12T21:03:30+00:00 urn:sha1:9f25dbe0bf91108be38c690628910c3ee85f6c1c Reported-by: syzbot+f8c98a50c323635be65d@syzkaller.appspotmail.com Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 2024-10-09T20:42:53+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-10-07T22:04:21+00:00 urn:sha1:19773ec997201a45b3a1b5f1171897cba0f30bab - Fix failure to validate that accounting replicas entries point to valid devices: this wasn't a real bug since they'd be cleaned up by GC, but is still something we should know about - Fix failure to validate that dev_data_type entries point to valid devices: this does fix a real bug, since bch2_accounting_read() would then try to copy the counters to that device and pop an inconsistent error when the device didn't exist - Remove accounting entries that are zeroed or invalid: if we're not validating them we need to get rid of them: they might not exist in the superblock, so we need the to trigger the superblock mark path when they're readded. This fixes the replication.ktest rereplicate test, which was failing with "superblock not marked for replicas..." Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 2024-10-09T20:42:51+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-09-30T02:11:37+00:00 urn:sha1:9b23fdbd5d29beb5bd272c304e0d978edd32f513 There's an inherent race in taking a snapshot while an unlinked file is open, and then reattaching it in the child snapshot. In the interior snapshot node the file will appear unlinked, as though it should be deleted - it's not referenced by anything in that snapshot - but we can't delete it, because the file data is referenced by the child snapshot. This was being handled incorrectly with propagate_key_to_snapshot_leaves() - but that doesn't resolve the fundamental inconsistency of "this file looks like it should be deleted according to normal rules, but - ". To fix this, we need to fix the rule for when an inode is deleted. The previous rule, ignoring snapshots (there was no well-defined rule for with snapshots) was: Unlinked, non open files are deleted, either at recovery time or during online fsck The new rule is: Unlinked, non open files, that do not exist in child snapshots, are deleted. To make this work transactionally, we add a new inode flag, BCH_INODE_has_child_snapshot; it overrides BCH_INODE_unlinked when considering whether to delete an inode, or put it on the deleted list. For transactional consistency, clearing it handled by the inode trigger: when deleting an inode we check if there are parent inodes which can now have the BCH_INODE_has_child_snapshot flag cleared. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 2024-10-05T00:25:32+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-09-30T03:38:37+00:00 urn:sha1:c9306a91c3fdc9915f5408561ea432c70b03383b We want to check for this early so it can be reattached if necessary in check_unreachable_inodes(); better than letting it be deleted and having the children reattached, losing their filenames. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 2024-10-05T00:25:32+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-09-30T02:38:04+00:00 urn:sha1:c7da5ee2e5cc30faca49e3ea9dbecf8f6ee4f1ea link count works differently in bcachefs - it's only nonzero for files with multiple hardlinks, which means we can also avoid checking it except for files that are known to have hardlinks. That means we need a few different checks instead; in particular, we don't want fsck to delet a file that has a dirent pointing to it. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 2024-10-05T00:25:32+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-09-28T19:27:37+00:00 urn:sha1:1c6051bbd76b2767d6acef6a1d0bdf99aa319273 It's legal for regular files to have missing backpointers (due to hardlinks), and fsck should automatically add them, but for directories this is an error that should be flagged. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 2024-10-05T00:25:32+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-10-01T23:08:37+00:00 urn:sha1:260af1562ec14353824da24fe7acc179a902558e The fragmentation_lru field hasn't been needed since we reworked the LRU btrees to use the btree write buffer; previously it was used to resolve collisions, but the revised LRU btree uses the backpointer (the bucket) as part of the key. It should have been deleted at the time of the LRU rework; since it wasn't, that left places for bugs to hide, in check/repair. This fixes LRU fsck on a filesystem image helpfully provided by a user who disappeared before I could get his name for the reported-by. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 2024-10-05T00:25:31+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-10-01T20:26:21+00:00 urn:sha1:1bea714c532abf101e939a90b8c920ef9205cfa3 Errors are getting marked as AUTOFIX once they've been (re)-tested and audited. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>