On Wed, Jul 17, 2024 at 11:53:04AM GMT, Linus Torvalds wrote: > On Sun, 14 Jul 2024 at 18:26, Kent Overstreet <[email protected]> > wrote: > > > > Hi Linus - another opossum for the posse: > > (The kernel naming tends to be related to some random event, in this > case we had a family of opossums under our shed for a couple of > months)
Oh cute :) > > bcachefs changes for 6.11-rc1 > > As Stephen pointed out, all of this seems to have been rebased > basically as the merge window opened, so if it was in linux-next, I > certainly can't easily validate it without having to compare patch ids > etc. DON'T DO THIS. I had to give this some thought; the proximate cause was just fat fingering/old reflexes, but the real issue that's been causing conflicts is that I've got testers running my trees who very much /do/ need to be on the latest tagged release. And I can't just leave it for them to do a rebase/merge, because a) they don't do that, and b) then I'm looking at logs with commits I can't reference. So - here's how my branches are going to be from now on: As before: - bcachefs-testing: code goes here first, until it's passed the testing automation. Don't run this unless you're working with me on something. - for-next: the subset of bcachefs-testing that's believed to be stable - bcachefs-for-upstream: queue for next pull request, generally just hotfixes But my master branch (previously the same as for-next) will now be for-next merged with the latest tag from your tree, and I may do similarly for bcachefs-for-upstream if it's needed. As a bonus, this means the testing automation will now be automatically testing my branch + your latest; this would have caught the breakage from Christoph's FUA changes back in 6.7. > Also, the changes to outside fs/bcachefs had questions that weren't answered. Yeah, those comments should have been added. Waiman, how's this? -- >8 -- >From 1d8cbc45ef1bab9be7119e0c5a6f8a05d5e2ca7d Mon Sep 17 00:00:00 2001 From: Kent Overstreet <[email protected]> Date: Thu, 18 Jul 2024 17:17:10 -0400 Subject: [PATCH] lockdep: Add comments for lockdep_set_no{validate,track}_class() Cc: Waiman Long <[email protected]> Signed-off-by: Kent Overstreet <[email protected]> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h index b76f1bcd2f7f..bdfbdb210fd7 100644 --- a/include/linux/lockdep.h +++ b/include/linux/lockdep.h @@ -178,9 +178,22 @@ static inline void lockdep_init_map(struct lockdep_map *lock, const char *name, (lock)->dep_map.wait_type_outer, \ (lock)->dep_map.lock_type) +/** + * lockdep_set_novalidate_class: disable checking of lock ordering on a given + * lock + * + * Lockdep will still record that this lock has been taken, and print held + * instances when dumping locks + */ #define lockdep_set_novalidate_class(lock) \ lockdep_set_class_and_name(lock, &__lockdep_no_validate__, #lock) +/** + * lockdep_set_notrack_class: disable lockdep tracking of a given lock entirely + * + * Bigger hammer than lockdep_set_novalidate_class: so far just for bcachefs, + * which takes more locks than lockdep is able to track (48). + */ #define lockdep_set_notrack_class(lock) \ lockdep_set_class_and_name(lock, &__lockdep_no_track__, #lock)
