[git pull] bcachefs locking fix

[git pull] bcachefs locking fix

[Al Viro]

Looks like Kent hadn't merged that into his branch for some reason;
IIRC, he'd been OK with the fix and had no objections to that stuff
sitting in -next, so...

Kent, if you *do* have objections, please make them now.

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git tags/pull-bcachefs-fix

for you to fetch changes up to bbe6a7c899e7f265c5a6d01a178336a405e98ed6:

  bch2_ioctl_subvolume_destroy(): fix locking (2023-11-15 22:47:58 -0500)

----------------------------------------------------------------
fix buggered locking in bch2_ioctl_subvolume_destroy()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

----------------------------------------------------------------
Al Viro (2):
      new helper: user_path_locked_at()
      bch2_ioctl_subvolume_destroy(): fix locking

 fs/bcachefs/fs-ioctl.c | 31 +++++++++++++++++--------------
 fs/namei.c             | 16 +++++++++++++---
 include/linux/namei.h  |  1 +
 3 files changed, 31 insertions(+), 17 deletions(-)

Re: [git pull] bcachefs locking fix

[Kent Overstreet]

On Fri, Jan 12, 2024 at 07:29:54AM +0000, Al Viro wrote:
> Looks like Kent hadn't merged that into his branch for some reason;
> IIRC, he'd been OK with the fix and had no objections to that stuff
> sitting in -next, so...

I did, but then you said something about duplicate commit IDs? I thought
that meant they were going through your tree.

> Kent, if you *do* have objections, please make them now.
> 
> The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:
> 
>   Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git tags/pull-bcachefs-fix
> 
> for you to fetch changes up to bbe6a7c899e7f265c5a6d01a178336a405e98ed6:
> 
>   bch2_ioctl_subvolume_destroy(): fix locking (2023-11-15 22:47:58 -0500)
> 
> ----------------------------------------------------------------
> fix buggered locking in bch2_ioctl_subvolume_destroy()
> 
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Acked-by: Kent Overstreet <kent.overstreet@linux.dev>
 
> ----------------------------------------------------------------
> Al Viro (2):
>       new helper: user_path_locked_at()
>       bch2_ioctl_subvolume_destroy(): fix locking
> 
>  fs/bcachefs/fs-ioctl.c | 31 +++++++++++++++++--------------
>  fs/namei.c             | 16 +++++++++++++---
>  include/linux/namei.h  |  1 +
>  3 files changed, 31 insertions(+), 17 deletions(-)

Re: [git pull] bcachefs locking fix

[Al Viro]

On Fri, Jan 12, 2024 at 10:22:39AM -0500, Kent Overstreet wrote:
> On Fri, Jan 12, 2024 at 07:29:54AM +0000, Al Viro wrote:
> > Looks like Kent hadn't merged that into his branch for some reason;
> > IIRC, he'd been OK with the fix and had no objections to that stuff
> > sitting in -next, so...
> 
> I did, but then you said something about duplicate commit IDs? I thought
> that meant they were going through your tree.

Huh?  Same patch applied in two trees => problem.  A tree pulling a branch
from another => perfectly fine, as long as the branch pulled is not rebased
in the first tree.  So something like "I have a patch your tree needs,
but I might end up doing more stuff on top of it for my own work" can be
solved by creating a never-rebased branch in my tree, with just the stuff
that might need to be shared and telling you to pull from it.  After that each
of us can ignore the other tree.  No conflicts in -next, no worries about
the order of pull requests to mainline...

Re: [git pull] bcachefs locking fix

[pr-tracker-bot]

The pull request you sent on Fri, 12 Jan 2024 07:29:54 +0000:

> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git tags/pull-bcachefs-fix

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f16ab99c2eba233bc97b9f9cc374f7a371fcc363

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [git pull] bcachefs locking fix

[Kent Overstreet]

On Fri, Jan 12, 2024 at 07:25:40PM +0000, Al Viro wrote:
> On Fri, Jan 12, 2024 at 10:22:39AM -0500, Kent Overstreet wrote:
> > On Fri, Jan 12, 2024 at 07:29:54AM +0000, Al Viro wrote:
> > > Looks like Kent hadn't merged that into his branch for some reason;
> > > IIRC, he'd been OK with the fix and had no objections to that stuff
> > > sitting in -next, so...
> > 
> > I did, but then you said something about duplicate commit IDs? I thought
> > that meant they were going through your tree.
> 
> Huh?  Same patch applied in two trees => problem.  A tree pulling a branch
> from another => perfectly fine, as long as the branch pulled is not rebased
> in the first tree.  So something like "I have a patch your tree needs,
> but I might end up doing more stuff on top of it for my own work" can be
> solved by creating a never-rebased branch in my tree, with just the stuff
> that might need to be shared and telling you to pull from it.  After that each
> of us can ignore the other tree.  No conflicts in -next, no worries about
> the order of pull requests to mainline...

I'm confused about what rebasing has to do with this?

I was assuming the patches would take the same route into Linus's tree
as into -next, that just seemed simplest to me; I'm completely fine with
either taking them into my tree or you sending them directly, I'd
already looked at them.

Or was the issue that they were in your -next branch because you had
other stuff on top of them, but you still thought I was taking them?