On Wed, Jul 17, 2024 at 11:53:04AM GMT, Linus Torvalds wrote:
On Sun, 14 Jul 2024 at 18:26, Kent Overstreet <kent.overstr...@linux.dev> 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 <kent.overstr...@linux.dev>
Date: Thu, 18 Jul 2024 17:17:10 -0400
Subject: [PATCH] lockdep: Add comments for
lockdep_set_no{validate,track}_class()
Cc: Waiman Long <long...@redhat.com>
Signed-off-by: Kent Overstreet <kent.overstr...@linux.dev>
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)
