[GIT PULL] fuse update for 6.15

[GIT PULL] fuse update for 6.15

[Miklos Szeredi]

Hi Linus,

Please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git
tags/fuse-update-6.15

- Allow connection to server to time out (Joanne Koong)

- If server doesn't support creating a hard link, return EPERM rather
than ENOSYS (Matt Johnston)

- Allow file names longer than 1024 chars (Bernd Schubert)

- Fix a possible race if request on io_uring queue is interrupted
(Bernd Schubert)

- Misc fixes and cleanups

Commit 1dfe2a220e9c ("fuse: fix uring race condition for null
dereference of fc") in this queue has already been merged into
v6.14-final through Christian's tree (commit d9ecc77193ca).   For some
reason this causes a merge conflict, the resolution of which is to
just take the version from this pull (i.e. remove the atomic_set()).

Thanks,
Miklos
---

Bernd Schubert (3):
      fuse: {io-uring} Fix a possible req cancellation race
      fuse: Allocate only namelen buf memory in fuse_notify_
      fuse: Increase FUSE_NAME_MAX to PATH_MAX

Joanne Koong (4):
      fuse: add kernel-enforced timeout option for requests
      fuse: add default_request_timeout and max_request_timeout sysctls
      fuse: fix uring race condition for null dereference of fc
      fuse: remove unneeded atomic set in uring creation

Luis Henriques (1):
      fuse: removed unused function fuse_uring_create() from header

Matt Johnston (1):
      fuse: Return EPERM rather than ENOSYS from link()

Miklos Szeredi (1):
      fuse: optmize missing FUSE_LINK support

---
 Documentation/admin-guide/sysctl/fs.rst |  25 +++++
 fs/fuse/dev.c                           | 162 +++++++++++++++++++++++++++-----
 fs/fuse/dev_uring.c                     |  47 +++++++--
 fs/fuse/dev_uring_i.h                   |  18 ++--
 fs/fuse/dir.c                           |  11 ++-
 fs/fuse/fuse_dev_i.h                    |   4 +
 fs/fuse/fuse_i.h                        |  47 ++++++++-
 fs/fuse/inode.c                         |  51 +++++++++-
 fs/fuse/sysctl.c                        |  24 +++++
 include/uapi/linux/fuse.h               |  12 ++-
 10 files changed, 358 insertions(+), 43 deletions(-)

Re: [GIT PULL] fuse update for 6.15

[Linus Torvalds]

On Tue, 1 Apr 2025 at 04:02, Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> Commit 1dfe2a220e9c ("fuse: fix uring race condition for null
> dereference of fc") in this queue has already been merged into
> v6.14-final through Christian's tree (commit d9ecc77193ca).   For some
> reason this causes a merge conflict, the resolution of which is to
> just take the version from this pull (i.e. remove the atomic_set()).

Yup, those "made in both branches" kinds of conflicts are trivial to resolve.

In case you wonder about the "for some reason" part: I say that they
are "trivial to resolve", but they are trivial to resolve only when
it's clear that you should take the *other* changes that the other
branch does.

So put another way: both branches did X (that "fix race condition"
thing) but as different commits, so they had separate history.

But then only one branch did Y (the "remove unneeded atomic set in
uring creation") that is right next to X.

Now, when I look at it and understand the semantics of the patch, I go
"oh, ok, both sides did X, but you also did Y, so I'll take that X+Y
thing". Simple.

But it's simple only because I understand the semantics of the
patches, and I see that I should take the union of the work.

git won't do that, because while there are "patch queue" systems that
do in fact use that exact logic of "both did patch X, the other side
also did patch Y", git is not a patch queue system - and I think patch
queue systems are actually wrong for anything more complicated.

So git will look at the original shared state, and the state of both
sides at the *end*, and make the merge decisions on that basis
(resolving things with a three-way merge if both sides did changes -
that's the simplified case for the simple history situation, at
least).

And in that model, you don't have "both did X, and then one side did
Y". You have "one side did A, the other side did B, and they weren't
the same".

I also will claim that it's the safer thing to do, because who knows
*why* one side did Y and the other side didn't? Without understanding
the semantics of Y, it's very much not clear.

For example, maybe the other side didn't do Y because Y was a quick
hack bug-fix to get things working, and instead simply fixed it at
some deeper level elsewhere that made the quick hack pointless and
possibly even wrong.

So just automatically doing some patch algebra can cause problems.

Of course, the git model of merging can *also* cause problems.

For an example of something that the git merge model will get wrong is
if both sides do 'X', but one side notices that 'X' was horribly buggy
and reverts it, and the other side doesn't.

Now when you merge the two, git will see "one side made no changes at
all, the other side did X" and at that point will merge 'X' and
basically undo the revert.

That *may* be the right thing to do. Again, maybe the other side
didn't revert because the other side fixed the bug properly. But the
*safe* thing would probably have been to treat it as that X+Y vs X
thing, and ask for manual intervention by marking it as a conflict.

But git won't do that, because git will see X+Y as being no change at
all, and then the logic is "one side did nothing, the other side did
new development, when you merge the two you obviously take the new
development".

And that's ignoring the whole issue with three-way merging that git
then does for when there are changes on both sides: it's a traditional
and generally very good strategy, but it can certainly also end up
doing mis-merges when there are semantic conflicts that don't show up
as overlapping changes.

End result: there are no automated merge models that always get the
right answer. The git merge model does work well, but there is no
perfect.

One good thing about the git model is that it tends to be fairly
simple to explain *why* it does something. It's not rocket science.
Merge conflicts really are fairly simple: both sides changed the same
area in different ways.

Of course, things get complicated when code movement or complex
history is involved. Or when the two changes simply clash on a
fundamental level and weren't at all about that kind of "A+B" vs "just
A" situation.

         Linus

Re: [GIT PULL] fuse update for 6.15

[pr-tracker-bot]

The pull request you sent on Tue, 1 Apr 2025 13:02:35 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git tags/fuse-update-6.15

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

Thank you!

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