Message-ID: <3f4f7090-7009-4509-9122-b75a0d9ce32c@redhat.com>
Date: Thu, 18 Jul 2024 17:48:50 -0400
From: Waiman Long <longman@...hat.com>
To: Kent Overstreet <kent.overstreet@...ux.dev>,
 Linus Torvalds <torvalds@...ux-foundation.org>
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 7/18/24 17:20, Kent Overstreet wrote:
> 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)
>   
>
That should be good enough.

Thanks,
Longman

Powered by blists - more mailing lists