Message-ID: <5ypgzehnp2b3z2e5qfu2ezdtyk4dc4gnlvme54hm77aypl3flj@xlpjs7dbmkwu>
Date: Thu, 18 Jul 2024 17:20:54 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Linus Torvalds <torvalds@...ux-foundation.org>, 
	Waiman Long <longman@...hat.com>
Cc: linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs changes for 6.11

On Wed, Jul 17, 2024 at 11:53:04AM GMT, Linus Torvalds wrote:
> On Sun, 14 Jul 2024 at 18:26, Kent Overstreet <kent.overstreet@...ux.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.overstreet@...ux.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 <longman@...hat.com>
Signed-off-by: Kent Overstreet <kent.overstreet@...ux.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)
 

Powered by blists - more mailing lists