Re: [PATCH v5 2/3] man/man2: introduce man page for file_getattr(2) syscall

[Alejandro Colomar <alx@kernel.org>]

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

Hi Andrey,

> Date: 2026-10-14 11:14:07+0200
> From: Andrey Albershteyn <aalbersh@kernel.org>
>
> On 2026-10-11 19:06:32, Alejandro Colomar wrote:
> > Hi Andrey,
> > 
> > > +As with
> > > +.BR openat (2),
> > > +if
> > > +.I path
> > > +is relative,
> > > +then it is interpreted relative to the directory
> > > +referred to by the file descriptor
> > > +.IR dirfd .
> > > +The special
> > > +.I dirfd
> > > +value
> > > +.B AT_FDCWD
> > > +can be used to refer to the current working directory of the calling process.
> > > +If
> > > +.I path
> > > +is absolute,
> > > +then
> > > +.I dirfd
> > > +is ignored.
> > 
> > Is there any difference with openat(2) regarding the handling of 'path'
> > and 'dirfd'?  If not, we could say:
> > 
> > 	The
> > 	.I dirfd
> > 	and
> > 	.I path
> > 	arguments behave in the same way as in
> > 	.BR openat (2).
> > 
> > Is there any small difference, or is it exactly as in openat(2)?
> 
> The difference I found is that
> file_getattr(fd, NULL, ..., AT_EMPTY_PATH) succeeds but the
> openat(fd, NULL, O_EMPTYPATH) returns -EFAULT. openat() always wants
> an empty string while file_attr() can work with NULL.
> 
> 	The
> 	.I dirfd
> 	and
> 	.I path
> 	arguments behave in the same way as in
> 	.BR openat (2),
> 	with the divergence that
> 	.I path
> 	can be NULL meaning an empty string.
> 
> so maybe like this?

Sorry that I missed this email.  I had an attack from a nation-state,
and had to be very careful with my hardware and communications.  I will
probably say something more detailed on the mailing list, but I'll only
share some details encrypted with very few people to not give too much
information that might help them.  Anyway, when I got back to normal, I
missed this and some other emails.

And yes, this text seems good to me.  I see your new revision, so I'll
review that.  BTW, I wonder why there's this difference between
openat(2); was it on purpose?  Should we maybe require that callers use
an empty string with file_getattr(2) too?  Or perhaps allow NULL in
openat(2)?  (I prefer the former.)

In any case, I'll take your wording, since it documents reality.  I just
wonder whether reality should be changed.


Have a lovely night!
Alex

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

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