All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Andrey Albershteyn <aalbersh@kernel.org>
Cc: linux-man@vger.kernel.org, linux-xfs@vger.kernel.org,
	 linux-fsdevel@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	djwong@kernel.org,  linux-api@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	 Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	 Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	 Adrian Hunter <adrian.hunter@intel.com>,
	James Clark <james.clark@linaro.org>,
	 linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] man/man2: introduce man page for file_getattr/file_setattr syscalls
Date: Fri, 11 Sep 2026 13:56:55 +0200	[thread overview]
Message-ID: <aqPrI5F-IE6_lmK7@devuan> (raw)
In-Reply-To: <aqPg20OSbTsxRd6-@aalbersh-thinkpadx1carbongen13.rmtcz.csb>

[-- Attachment #1: Type: text/plain, Size: 2912 bytes --]

[CC += PERFORMANCE EVENTS SUBSYSTEM maintainers]

Hi Andrey,

> Date: 2026-09-11 13:17:12+0200
> From: Andrey Albershteyn <aalbersh@kernel.org>
>
> Hi Alejandro,
> 
> Thanks for the review, I will apply your suggestions, responses to
> some of the questions below:
> 
[...]
> > > +The
> > > +.I flags
> > > +argument is a bit mask, available flags are:
> > 
> > The usual language we use for this is:
> > 
> > 	The
> > 	.I flags
> > 	argument contains
> > 	a bitwise OR of zero or more of the following constants:
> > 
> > See for example readv(2).
> 
> I will use "constants" then (the readv uses "following flags")

Ok.

> > There are some minor variations of this in other pages, and I should
> > make them more uniform.
> > 
[...]
> > > +.TP
> > > +.B EBADF
> > > +.I pathname
> > > +is relative but
> > > +.I dirfd
> > > +is neither
> > > +.B AT_FDCWD
> > > +nor a valid file descriptor.
> > > +.TP
> > > +.B EBADF
> > > +.I pathname
> > > +is an empty string,
> > > +.B AT_EMPTY_PATH
> > > +was specified,
> > > +but
> > > +.I dirfd
> > > +is an invalid file descriptor.
> > 
> > I was wondering: is it valid to specify AT_EMPTY_PATH, use an empty
> > string, and use AT_FDCWD as the dirfd?  That should act on the current
> > working directory itself, right?  Or is that not supported?
> 
> Yes, this is valid combination. I can describe this case.

Thanks!  I think using wording similar to the one above would be enough:

	but
	.I dirfd
	is neither
	.B AT_FDCWD
	nor a valid file descriptor.

[...]
> > > +.TP
> > > +.B EINVAL
> > > +.I size
> > > +is smaller than
> > > +.BR FILE_ATTR_SIZE_VER0 .
> > 
> > perf_event_open(2) reports E2BIG for a size smaller than
> > PERF_ATTR_SIZE_VER0.  This seems unnecessarily inconsistent.  I'm not
> > sure which I'd say is more appropriate, but I'd expect them to be
> > consistent.  I mentioned perf_event_open(2) because that's the only page
> > that has a *_VER0 constant and documents an error if a size is smaller
> > than it.  There's also mount_setattr(2) which documents
> > MOUNT_ATTR_SIZE_VER0, but it's not documented in ERRORS.
> > 
> > I think kernel maintainers should have a look at the different APIs that
> > have such a value, and discuss whether the error codes should be made
> > uniform retroactively, or whether we should accept the existing
> > divergence but decide on an error code for new APIs.
> > 
> > I've CCed linux-api@.
> 
> The MOUNT_ATTR_SIZE_VER0 also returns an EINVAL

Thanks!  I'll document that.

> I'm in favor of EINVAL as E2BIG is probably a more confusing naming
> for the too small argument.

I think I agree.

I've CCd the maintainers of perf_event_open(2).  Can perf_event_open(2)
be changed to report EINVAL?  Or is that mistake set in stone?


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2026-09-11 11:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10 10:41 [PATCH v2] man/man2: introduce man page for file_getattr/file_setattr syscalls Andrey Albershteyn
2026-09-10 13:20 ` Alejandro Colomar
2026-09-10 16:12   ` Darrick J. Wong
2026-09-10 16:31     ` Alejandro Colomar
2026-09-10 16:44       ` Darrick J. Wong
2026-09-10 16:50         ` Alejandro Colomar
2026-09-10 22:38           ` quotactl(2) (was: [PATCH v2] man/man2: introduce man page for file_getattr/file_setattr syscalls) Alejandro Colomar
2026-09-15 18:10             ` Darrick J. Wong
2026-09-15 20:46               ` Alejandro Colomar
2026-09-11 11:17   ` [PATCH v2] man/man2: introduce man page for file_getattr/file_setattr syscalls Andrey Albershteyn
2026-09-11 11:56     ` Alejandro Colomar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aqPrI5F-IE6_lmK7@devuan \
    --to=alx@kernel.org \
    --cc=aalbersh@kernel.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=jolsa@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.