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: <20200302103400.vk3cki7agfq2zhpv@ws.net.home>
Date:   Mon, 2 Mar 2020 11:34:00 +0100
From:   Karel Zak <kzak@...hat.com>
To:     Miklos Szeredi <miklos@...redi.hu>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ian Kent <raven@...maw.net>,
        Miklos Szeredi <mszeredi@...hat.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        Steven Whitehouse <swhiteho@...hat.com>,
        David Howells <dhowells@...hat.com>,
        viro <viro@...iv.linux.org.uk>,
        Christian Brauner <christian@...uner.io>,
        Jann Horn <jannh@...gle.com>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Linux API <linux-api@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Lennart Poettering <lennart@...ttering.net>,
        Zbigniew Jędrzejewski-Szmek <zbyszek@...waw.pl>,
        util-linux@...r.kernel.org
Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver
 #17]

On Fri, Feb 28, 2020 at 05:24:23PM +0100, Miklos Szeredi wrote:
> ned-By: MIMEDefang 2.78 on 10.11.54.4
> 
> On Fri, Feb 28, 2020 at 1:27 PM Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> 
> > > Superblocks and mounts could get enumerated by a unique identifier.
> > > mnt_id seems to be good for mounts, s_dev may or may not be good for
> > > superblock, but  s_id (as introduced in this patchset) could be used
> > > instead.
> >
> > So what would the sysfs tree look like with this?
> 
> For a start something like this:
> 
> mounts/$MOUNT_ID/
>   parent -> ../$PARENT_ID
>   super -> ../../supers/$SUPER_ID
>   root: path from mount root to fs root (could be optional as usually
> they are the same)
>   mountpoint -> $MOUNTPOINT
>   flags: mount flags
>   propagation: mount propagation
>   children/$CHILD_ID -> ../../$CHILD_ID
> 
>  supers/$SUPER_ID/
>    type: fstype
>    source: mount source (devname)
>    options:

What about use-cases where I have no ID, but I have mountpoint path
(e.g. "umount /foo")?  In this case I have to go to open() + fsinfo()
and then sysfs does not make sense for me, right?

    Karel

-- 
 Karel Zak  <kzak@...hat.com>
 http://karelzak.blogspot.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ