linux-ext4 - Re: [PATCH] Add a pair of system calls to make extended file stats available [ver #3]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <21105.1278683946@redhat.com>
Date:	Fri, 09 Jul 2010 14:59:06 +0100
From:	David Howells <dhowells@...hat.com>
To:	Michael Kerrisk <mtk.manpages@...il.com>
Cc:	dhowells@...hat.com, linux-fsdevel@...r.kernel.org,
	linux-cifs@...r.kernel.org, linux-kernel@...r.kernel.org,
	samba-technical@...ts.samba.org, linux-ext4@...r.kernel.org,
	linux-api@...r.kernel.org
Subject: Re: [PATCH] Add a pair of system calls to make extended file stats available [ver #3]

Michael Kerrisk <mtk.manpages@...il.com> wrote:

> >        struct xstat_parameters {
> >                unsigned long long      request_mask;
> 
> Poor name, since it's a value-result arg? Better maybe something like
> "field_mask"?

No.  The contents of xstat_parameters aren't changed.  request_mask is what
you're asking for, result_mask in the xstat struct is what you actually got.

result_mask may be more or less than request_mask as the filesystem isn't
obliged to supply anything you didn't ask for, and may not be able to supply
something you did ask for, and may give you stuff anyway that you didn't ask
for if it's trivial to do so.

> There is no XSTAT_REQUEST__GET_ANYWAY, AFAICS. I guess here you meant
> XSTAT_REQUEST__EXTENDED_STATS? Or?

Yep.  I forgot to change that in the patch description.

> This case is almost certainly a user error, so why not simply return
> an error (-1 and ERANGE or E2BIG)? The above approach invites
> userspace errors of the form:
> 
> if (xtat(...) < 0) { /* How users often check for error */
>     /* I'll handle the error */
> } else {
>     /* The call succeeded; I'm fine */
> }

I suppose.

> If you are looking for a way to inform the user about the required
> buffer size, I think it would be better to take a leaf from the
> getxattr(2) book: if 'buflen' is zero, then do nothing with the output
> arg, but return the size that would be required.

That's reasonable.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html