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] [thread-next>] [day] [month] [year] [list]
Message-Id: <46109C88-01C8-40A1-B44B-B76BF8C119C7@dilger.ca>
Date:	Thu, 26 Nov 2015 15:06:19 -0700
From:	Andreas Dilger <adilger@...ger.ca>
To:	David Howells <dhowells@...hat.com>
Cc:	Christoph Hellwig <hch@...radead.org>, arnd@...db.de,
	linux-afs@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org
Subject: Re: [RFC][PATCH 00/12] Enhanced file stat system call

On Nov 26, 2015, at 8:19 AM, David Howells <dhowells@...hat.com> wrote:
> 
> Christoph Hellwig <hch@...radead.org> wrote:
> 
>> from a quick look the statx bits looks fine in general.  I think Ted
>> last time had a problem with the IOC flag allocation, so you might
>> want to ping him.
> 
> Yeah - he commented on that.
> 
>> But fsinfo with the multiplexer and the void pointer is just horrible.
>> What were you thinking there?
> 
> I think the fsinfo data struct probably wants splitting up.

Could we separate the statx() and fsinfo() submissions so that this doesn't
block statx() landing indefinitely?  I think people are generally in support
of statx() as it is today, and it's been _sooo_ long in coming that I'd hate
to see it delayed further.  The statx() syscall definitely has value without
fsinfo() to improve the life of network filesystems.

Cheers, Andreas

>  Now this could be
> done in a number of ways, including:
> 
> (1) By adding multiple syscalls (statfsx, fsinfo, netfsinfo, ...) but each
>     one needs a bit in the kernel to handle the basics (path/fd lookup,
>     security check, buffer allocation and freeing, ...) which could all be in
>     common - hence the mux method.
> 
> (2) Adding an argument to the fsinfo syscall since it has at least one
>     syscall argument spare.
> 
> (3) Offloading some of the bits to standardised xattr calls.  The large
>     string fields (domain name, volume name, ...) would seem to be obvious
>     candidates for this.
> 
> Given that the core VFS gets to manage the contents of the buffer, it
> shouldn't be as controversial as pioctl().
> 
> 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


Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ