| Message ID | 20240112072954.GC1674809@ZenIV (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [git,pull] bcachefs locking fix | expand |
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(-)
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...
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!
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?
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(-)