fusefs: ensure that FUSE ops' headers' unique values are actually unique
ClosedPublic
Actions

Authored by asomers on Jun 18 2021, 12:18 AM.

Details

Reviewers

emaste
pfg

Commits

rG46138f337bd8: fusefs: ensure that FUSE ops' headers' unique values are actually unique
rG27d55441668a: fusefs: ensure that FUSE ops' headers' unique values are actually unique
rG5403f2c163f7: fusefs: ensure that FUSE ops' headers' unique values are actually unique

Summary

fusefs: delete dead code

It was always dead, accidentally included in SVN r345876.

MFC after: 2 weeks

fusefs: also debug INIT operations in the test suite

MFC after: 2 weeks

fusefs: ensure that FUSE ops' headers' unique values are actually unique

Every FUSE operation has a unique value in its header. As the name
implies, these values are supposed to be unique among all outstanding
operations. And since FUSE_INTERRUPT is asynchronous and racy, it is
desirable that the unique values be unique among all operations that are
"close in time".

Ensure that they are actually unique by incrementing them whenever we
reuse a fuse_dispatcher object, for example during fsync, write, and
listextattr.

PR: 244686
MFC after: 2 weeks

Test Plan

Assertions added to existing test suite.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

asomers created this revision.Jun 18 2021, 12:18 AM

Herald added a subscriber: imp. · View Herald TranscriptJun 18 2021, 12:18 AM

asomers requested review of this revision.Jun 18 2021, 12:18 AM

Harbormaster completed remote builds in B39968: Diff 91042.Jun 18 2021, 12:18 AM

asomers retitled this revision from fusefs: delete dead code to fusefs: ensure that FUSE ops' headers' unique values are actually unique.Jun 18 2021, 2:35 AM

pfg accepted this revision.Jun 19 2021, 8:38 PM

This revision is now accepted and ready to land.Jun 19 2021, 8:38 PM

Closed by commit rG5403f2c163f7: fusefs: ensure that FUSE ops' headers' unique values are actually unique (authored by asomers). · Explain WhyJun 19 2021, 8:47 PM

This revision was automatically updated to reflect the committed changes.

asomers added a commit: rG5403f2c163f7: fusefs: ensure that FUSE ops' headers' unique values are actually unique.

asomers added a commit: rG27d55441668a: fusefs: ensure that FUSE ops' headers' unique values are actually unique.Jul 4 2021, 12:06 AM

asomers added a commit: rG46138f337bd8: fusefs: ensure that FUSE ops' headers' unique values are actually unique.Jul 27 2021, 5:34 PM

Revision Contents
Changeset List

Path

Size

sys/

fs/

fuse/

fuse_ipc.c

34 lines

tests/

sys/

fs/

fusefs/

mockfs.hh

3 lines

mockfs.cc

9 lines

Diff 91125

View Options

sys/fs/fuse/fuse_ipc.c

Show First 20 Lines • Show All 47 Lines • ▼ Show 20 Lines

.Fa fd

is a descriptor to be operated on by

.Fa cmd

as described below.

Depending on the value of

.Fa cmd ,

.Fn fcntl

can take an additional third argument

.Fa "long arg" .

.Fa arg .

jhbUnsubmitted

Done

Maybe just say the type of the 3rd arg depends on the operation (and document the type for each operation that takes the third arg) instead of trying to assume it's a single type? In CheriBSD we have a wrapper in libc to deal with this and have fcntl() as a truly var-args function. On existing platforms var-args is close enough to work for passing syscall arguments, but not all ABIs require this. (var-args are passed as a block in a bounded pointer on CHERI platforms and not just a continuation of register arguments).

jhb: Maybe just say the type of the 3rd arg depends on the operation (and document the type for each…

kibAuthorUnsubmitted

Done

I pushed everything but this change, the review is updated with the man page changes.

kib: I pushed everything but this change, the review is updated with the man page changes.

Unless otherwise noted below for a specific operation,

emasteUnsubmitted

Done

maybe "with type dependent on the specific operation"

or maybe

can take an additional third argument
.Fa arg.
Unless otherwise noted below for a specific operation,
.Fa arg
has type
.Vt int .

emaste: maybe "with type dependent on the specific operation" or maybe ``` can take an additional…

.Fa arg

has type

.Vt int .

.Bl -tag -width F_DUP2FD_CLOEXEC

.It Dv F_DUPFD

Return a new descriptor as follows:

.Pp

.Bl -bullet -compact -offset 4n

.It

Lowest numbered available descriptor greater than or equal to

.Fa arg .

▲ Show 20 Lines • Show All 121 Lines • ▼ Show 20 Lines

.It Dv F_GET_SEALS

Get seals associated with the file, if the underlying filesystem supports seals.

.It Dv F_ISUNIONSTACK

Check if the vnode is part of a union stack (either the "union" flag from

.Xr mount 2

or unionfs).

This is a hack not intended to be used outside of libc.

.It Dv F_KINFO

Fills a

markjUnsubmitted

Done

.It Dv F_KINFO

- Fills

+ Fills a

.Vt struct kinfo_file

markj:

.Vt struct kinfo_file

for the file referenced by the specified file descriptor.

The

.Fa arg

argument should point to the storage for

.Vt struct kinfo_file .

The

.Va kf_structsize

▲ Show 20 Lines • Show All 78 Lines • ▼ Show 20 Lines

Seals are on a per-inode basis and require support by the underlying filesystem.

If the underlying filesystem does not support seals,

.Dv F_ADD_SEALS

and

.Dv F_GET_SEALS

will fail and return

.Dv EINVAL .

.Pp

Several commands are available for doing advisory file locking;

Several operations are available for doing advisory file locking;

emasteUnsubmitted

Done

Is "command" or "operation" the better term, in general? I think we should be consistent between this sentence and the added text above/below

emaste: Is "command" or "operation" the better term, in general? I think we should be consistent…

they all operate on the following structure:

.Bd -literal

struct flock {

off_t l_start; /* starting offset */

off_t l_len; /* len = 0 means until end of file */

pid_t l_pid; /* lock owner */

short l_type; /* lock type: read/write, etc. */

short l_whence; /* type of l_start */

int l_sysid; /* remote system id or zero for local */

};

.Ed

These advisory file locking operations take a pointer to

emasteUnsubmitted

Done

These commands take a pointer to struct flock as the third argument arg.
or
These advisory file locking commands take a pointer to struct flock as the third argument arg.

emaste: These commands take a pointer to struct flock as the third argument arg. or These advisory file…

emasteUnsubmitted

Done

Maybe "operations" here too for consistency?
But from the context this one is clear so I don't mind either way.

emaste: Maybe "operations" here too for consistency? But from the context this one is clear so I don't…

.Vt struct flock

as the third argument

.Fa arg .

The commands available for advisory record locking are as follows:

.Bl -tag -width F_SETLKWX

.It Dv F_GETLK

Get the first lock that blocks the lock description pointed to by the

third argument,

.Fa arg ,

taken as a pointer to a

.Fa "struct flock"

▲ Show 20 Lines • Show All 477 Lines • Show Last 20 Lines

View Options

tests/sys/fs/fusefs/mockfs.hh

Show First 20 Lines • Show All 47 Lines • ▼ Show 20 Lines

.Fa fd

is a descriptor to be operated on by

.Fa cmd

as described below.

Depending on the value of

.Fa cmd ,

.Fn fcntl

can take an additional third argument

.Fa "long arg" .

.Fa arg .

jhbUnsubmitted

Done

jhb: Maybe just say the type of the 3rd arg depends on the operation (and document the type for each…

kibAuthorUnsubmitted

Done

I pushed everything but this change, the review is updated with the man page changes.

kib: I pushed everything but this change, the review is updated with the man page changes.

Unless otherwise noted below for a specific operation,

emasteUnsubmitted

Done

maybe "with type dependent on the specific operation"

or maybe

can take an additional third argument
.Fa arg.
Unless otherwise noted below for a specific operation,
.Fa arg
has type
.Vt int .

emaste: maybe "with type dependent on the specific operation" or maybe ``` can take an additional…

.Fa arg

has type

.Vt int .

.Bl -tag -width F_DUP2FD_CLOEXEC

.It Dv F_DUPFD

Return a new descriptor as follows:

.Pp

.Bl -bullet -compact -offset 4n

.It

Lowest numbered available descriptor greater than or equal to

.Fa arg .

▲ Show 20 Lines • Show All 121 Lines • ▼ Show 20 Lines

.It Dv F_GET_SEALS

Get seals associated with the file, if the underlying filesystem supports seals.

.It Dv F_ISUNIONSTACK

Check if the vnode is part of a union stack (either the "union" flag from

.Xr mount 2

or unionfs).

This is a hack not intended to be used outside of libc.

.It Dv F_KINFO

Fills a

markjUnsubmitted

Done

.It Dv F_KINFO

- Fills

+ Fills a

.Vt struct kinfo_file

markj:

.Vt struct kinfo_file

for the file referenced by the specified file descriptor.

The

.Fa arg

argument should point to the storage for

.Vt struct kinfo_file .

The

.Va kf_structsize

▲ Show 20 Lines • Show All 78 Lines • ▼ Show 20 Lines

Seals are on a per-inode basis and require support by the underlying filesystem.

If the underlying filesystem does not support seals,

.Dv F_ADD_SEALS

and

.Dv F_GET_SEALS

will fail and return

.Dv EINVAL .

.Pp

Several commands are available for doing advisory file locking;

Several operations are available for doing advisory file locking;

emasteUnsubmitted

Done

Is "command" or "operation" the better term, in general? I think we should be consistent between this sentence and the added text above/below

emaste: Is "command" or "operation" the better term, in general? I think we should be consistent…

they all operate on the following structure:

.Bd -literal

struct flock {

off_t l_start; /* starting offset */

off_t l_len; /* len = 0 means until end of file */

pid_t l_pid; /* lock owner */

short l_type; /* lock type: read/write, etc. */

short l_whence; /* type of l_start */

int l_sysid; /* remote system id or zero for local */

};

.Ed

These advisory file locking operations take a pointer to

emasteUnsubmitted

Done

These commands take a pointer to struct flock as the third argument arg.
or
These advisory file locking commands take a pointer to struct flock as the third argument arg.

emaste: These commands take a pointer to struct flock as the third argument arg. or These advisory file…

emasteUnsubmitted

Done

Maybe "operations" here too for consistency?
But from the context this one is clear so I don't mind either way.

emaste: Maybe "operations" here too for consistency? But from the context this one is clear so I don't…

.Vt struct flock

as the third argument

.Fa arg .

The commands available for advisory record locking are as follows:

.Bl -tag -width F_SETLKWX

.It Dv F_GETLK

Get the first lock that blocks the lock description pointed to by the

third argument,

.Fa arg ,

taken as a pointer to a

.Fa "struct flock"

▲ Show 20 Lines • Show All 477 Lines • Show Last 20 Lines

View Options

tests/sys/fs/fusefs/mockfs.cc

Show First 20 Lines • Show All 47 Lines • ▼ Show 20 Lines

.Fa fd

is a descriptor to be operated on by

.Fa cmd

as described below.

Depending on the value of

.Fa cmd ,

.Fn fcntl

can take an additional third argument

.Fa "long arg" .

.Fa arg .

jhbUnsubmitted

Done

jhb: Maybe just say the type of the 3rd arg depends on the operation (and document the type for each…

kibAuthorUnsubmitted

Done

I pushed everything but this change, the review is updated with the man page changes.

kib: I pushed everything but this change, the review is updated with the man page changes.

Unless otherwise noted below for a specific operation,

emasteUnsubmitted

Done

maybe "with type dependent on the specific operation"

or maybe

can take an additional third argument
.Fa arg.
Unless otherwise noted below for a specific operation,
.Fa arg
has type
.Vt int .

emaste: maybe "with type dependent on the specific operation" or maybe ``` can take an additional…

.Fa arg

has type

.Vt int .

.Bl -tag -width F_DUP2FD_CLOEXEC

.It Dv F_DUPFD

Return a new descriptor as follows:

.Pp

.Bl -bullet -compact -offset 4n

.It

Lowest numbered available descriptor greater than or equal to

.Fa arg .

▲ Show 20 Lines • Show All 121 Lines • ▼ Show 20 Lines

.It Dv F_GET_SEALS

Get seals associated with the file, if the underlying filesystem supports seals.

.It Dv F_ISUNIONSTACK

Check if the vnode is part of a union stack (either the "union" flag from

.Xr mount 2

or unionfs).

This is a hack not intended to be used outside of libc.

.It Dv F_KINFO

Fills a

markjUnsubmitted

Done

.It Dv F_KINFO

- Fills

+ Fills a

.Vt struct kinfo_file

markj:

.Vt struct kinfo_file

for the file referenced by the specified file descriptor.

The

.Fa arg

argument should point to the storage for

.Vt struct kinfo_file .

The

.Va kf_structsize

▲ Show 20 Lines • Show All 78 Lines • ▼ Show 20 Lines

Seals are on a per-inode basis and require support by the underlying filesystem.

If the underlying filesystem does not support seals,

.Dv F_ADD_SEALS

and

.Dv F_GET_SEALS

will fail and return

.Dv EINVAL .

.Pp

Several commands are available for doing advisory file locking;

Several operations are available for doing advisory file locking;

emasteUnsubmitted

Done

Is "command" or "operation" the better term, in general? I think we should be consistent between this sentence and the added text above/below

emaste: Is "command" or "operation" the better term, in general? I think we should be consistent…

they all operate on the following structure:

.Bd -literal

struct flock {

off_t l_start; /* starting offset */

off_t l_len; /* len = 0 means until end of file */

pid_t l_pid; /* lock owner */

short l_type; /* lock type: read/write, etc. */

short l_whence; /* type of l_start */

int l_sysid; /* remote system id or zero for local */

};

.Ed

These advisory file locking operations take a pointer to

emasteUnsubmitted

Done

These commands take a pointer to struct flock as the third argument arg.
or
These advisory file locking commands take a pointer to struct flock as the third argument arg.

emaste: These commands take a pointer to struct flock as the third argument arg. or These advisory file…

emasteUnsubmitted

Done

Maybe "operations" here too for consistency?
But from the context this one is clear so I don't mind either way.

emaste: Maybe "operations" here too for consistency? But from the context this one is clear so I don't…

.Vt struct flock

as the third argument

.Fa arg .

The commands available for advisory record locking are as follows:

.Bl -tag -width F_SETLKWX

.It Dv F_GETLK

Get the first lock that blocks the lock description pointed to by the

third argument,

.Fa arg ,

taken as a pointer to a

.Fa "struct flock"

▲ Show 20 Lines • Show All 477 Lines • Show Last 20 Lines

fusefs: ensure that FUSE ops' headers' unique values are actually uniqueClosedPublicActions

Details

Diff Detail

Event Timeline

Revision ContentsChangeset List

Diff 91125

sys/fs/fuse/fuse_ipc.c

tests/sys/fs/fusefs/mockfs.hh

tests/sys/fs/fusefs/mockfs.cc

fusefs: ensure that FUSE ops' headers' unique values are actually unique
ClosedPublic
Actions

Revision Contents
Changeset List