linux-kernel - Re: [PATCH 00/19] VFS: Filesystem information and notifications [ver #16]

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 19 Feb 2020 15:46:13 +0100
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     David Howells <dhowells@...hat.com>
Cc:     viro@...iv.linux.org.uk, raven@...maw.net, mszeredi@...hat.com,
        christian@...uner.io, linux-api@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/19] VFS: Filesystem information and notifications [ver
 #16]

On Tue, Feb 18, 2020 at 05:04:55PM +0000, David Howells wrote:
> 
> Here are a set of patches that adds system calls, that (a) allow
> information about the VFS, mount topology, superblock and files to be
> retrieved and (b) allow for notifications of mount topology rearrangement
> events, mount and superblock attribute changes and other superblock events,
> such as errors.
> 
> ============================
> FILESYSTEM INFORMATION QUERY
> ============================
> 
> The first system call, fsinfo(), allows information about the filesystem at
> a particular path point to be queried as a set of attributes, some of which
> may have more than one value.
> 
> Attribute values are of four basic types:
> 
>  (1) Version dependent-length structure (size defined by type).
> 
>  (2) Variable-length string (up to 4096, including NUL).
> 
>  (3) List of structures (up to INT_MAX size).
> 
>  (4) Opaque blob (up to INT_MAX size).

I mainly have an organizational question. :) This is a huge patchset
with lots and lots of (good) features. Wouldn't it make sense to make
the fsinfo() syscall a completely separate patchset from the
watch_mount() and watch_sb() syscalls? It seems that they don't need to
depend on each other at all. This would make reviewing this so much
nicer and likely would mean that fsinfo() could proceed a little faster.

Christian