On 8/14/2020 1:05 PM, Linus Torvalds (torva...@linux-foundation.org) wrote:
> Honestly, I really think you may want an extended [f]statfs(), not
> some mount tracking.
>
> Linus
Linus,
Thank you for the reply. Perhaps some of the communication disconnect
is due to which thread
On Wed, Aug 12, 2020 at 11:30 PM Al Viro wrote:
>
> On Wed, Aug 12, 2020 at 07:33:26PM +0100, Al Viro wrote:
>
> > BTW, what would such opened files look like from /proc/*/fd/* POV? And
> > what would happen if you walk _through_ that symlink, with e.g. ".."
> > following it? Or with names of th
On Wed, Aug 12, 2020 at 8:33 PM Al Viro wrote:
>
> On Wed, Aug 12, 2020 at 06:39:11PM +0100, Al Viro wrote:
> > On Wed, Aug 12, 2020 at 07:16:37PM +0200, Miklos Szeredi wrote:
> > > On Wed, Aug 12, 2020 at 6:33 PM Al Viro wrote:
> > > >
> > > > On Wed, Aug 12, 2020 at 05:13:14PM +0200, Miklos Sze
On Wed, Aug 12, 2020 at 8:53 PM Jeffrey E Altman wrote:
>
> For the AFS community, fsinfo offers a method of exposing some server
> and volume properties that are obtained via "path ioctls" in OpenAFS and
> AuriStorFS. Some example of properties that might be exposed include
> answers to question
On Mi, 12.08.20 11:18, Linus Torvalds (torva...@linux-foundation.org) wrote:
> On Tue, Aug 11, 2020 at 5:05 PM David Howells wrote:
> >
> > Well, the start of it was my proposal of an fsinfo() system call.
>
> Ugh. Ok, it's that thing.
>
> This all seems *WAY* over-designed - both your fsinfo and
On 8/12/2020 2:18 PM, Linus Torvalds (torva...@linux-foundation.org) wrote:
> What's wrong with fstatfs()? All the extra magic metadata seems to not
> really be anything people really care about.
>
> What people are actually asking for seems to be some unique mount ID,
> and we have 16 bytes of sp
On Wed, Aug 12, 2020 at 07:33:26PM +0100, Al Viro wrote:
> BTW, what would such opened files look like from /proc/*/fd/* POV? And
> what would happen if you walk _through_ that symlink, with e.g. ".."
> following it? Or with names of those attributes, for that matter...
> What about a normal ope
On Wed, Aug 12, 2020 at 06:39:11PM +0100, Al Viro wrote:
> On Wed, Aug 12, 2020 at 07:16:37PM +0200, Miklos Szeredi wrote:
> > On Wed, Aug 12, 2020 at 6:33 PM Al Viro wrote:
> > >
> > > On Wed, Aug 12, 2020 at 05:13:14PM +0200, Miklos Szeredi wrote:
> >
> > > > Why does it have to have a struct m
On Tue, Aug 11, 2020 at 5:05 PM David Howells wrote:
>
> Well, the start of it was my proposal of an fsinfo() system call.
Ugh. Ok, it's that thing.
This all seems *WAY* over-designed - both your fsinfo and Miklos' version.
What's wrong with fstatfs()? All the extra magic metadata seems to not
On Wed, Aug 12, 2020 at 07:16:37PM +0200, Miklos Szeredi wrote:
> On Wed, Aug 12, 2020 at 6:33 PM Al Viro wrote:
> >
> > On Wed, Aug 12, 2020 at 05:13:14PM +0200, Miklos Szeredi wrote:
>
> > > Why does it have to have a struct mount? It does not have to use
> > > dentry/mount based path lookup.
On Wed, Aug 12, 2020 at 6:33 PM Al Viro wrote:
>
> On Wed, Aug 12, 2020 at 05:13:14PM +0200, Miklos Szeredi wrote:
> > Why does it have to have a struct mount? It does not have to use
> > dentry/mount based path lookup.
>
> What the fuck? So we suddenly get an additional class of objects
> serv
On Wed, Aug 12, 2020 at 05:13:14PM +0200, Miklos Szeredi wrote:
> > Lovely. And what of fchdir() to those?
>
> Not allowed.
Not allowed _how_? Existing check is "is it a directory"; what do you
propose? IIRC, you've mentioned using readdir() in that context, so
it's not that you only allow to
Miklos Szeredi wrote:
> Why does it have to have a struct mount? It does not have to use
> dentry/mount based path lookup.
file->f_path.mnt
David
On Wed, Aug 12, 2020 at 5:08 PM Al Viro wrote:
>
> On Wed, Aug 12, 2020 at 04:46:20PM +0200, Miklos Szeredi wrote:
>
> > > "Can those suckers be passed to
> > > ...at() as starting points?
> >
> > No.
>
> Lovely. And what of fchdir() to those?
Not allowed.
> Are they all non-directories?
> Beca
On Wed, Aug 12, 2020 at 04:46:20PM +0200, Miklos Szeredi wrote:
> > "Can those suckers be passed to
> > ...at() as starting points?
>
> No.
Lovely. And what of fchdir() to those? Are they all non-directories?
Because the starting point of ...at() can be simulated that way...
> > Can they be
On Wed, Aug 12, 2020 at 4:40 PM Al Viro wrote:
>
> On Wed, Aug 12, 2020 at 09:23:23AM +0200, Miklos Szeredi wrote:
>
> > Anyway, starting with just introducing the alt namespace without
> > unification seems to be a good first step. If that turns out to be
> > workable, we can revisit unification
On Wed, Aug 12, 2020 at 09:23:23AM +0200, Miklos Szeredi wrote:
> Anyway, starting with just introducing the alt namespace without
> unification seems to be a good first step. If that turns out to be
> workable, we can revisit unification later.
Start with coming up with answers to the questions
Miklos Szeredi wrote:
> The point is that generic operations already exist and no need to add
> new, specialized ones to access metadata.
open and read already exist, yes, but the metadata isn't currently in
convenient inodes and dentries that you can just walk through. So you're
going to end u
On Wed, Aug 12, 2020 at 3:54 PM David Howells wrote:
>
> Linus Torvalds wrote:
>
> > IOW, if you do something more along the lines of
> >
> >fd = open(""foo/bar", O_PATH);
> >metadatafd = openat(fd, "metadataname", O_ALT);
> >
> > it might be workable.
>
> What is it going to walk
On Wed, Aug 12, 2020 at 3:33 PM David Howells wrote:
>
> Miklos Szeredi wrote:
>
> > You said yourself, that what's really needed is e.g. consistent
> > snapshot of a complete mount tree topology. And to get the complete
> > topology FSINFO_ATTR_MOUNT_TOPOLOGY and FSINFO_ATTR_MOUNT_CHILDREN are
Linus Torvalds wrote:
> IOW, if you do something more along the lines of
>
>fd = open(""foo/bar", O_PATH);
>metadatafd = openat(fd, "metadataname", O_ALT);
>
> it might be workable.
What is it going to walk through? You need to end up with an inode and dentry
from somewhere.
Miklos Szeredi wrote:
> You said yourself, that what's really needed is e.g. consistent
> snapshot of a complete mount tree topology. And to get the complete
> topology FSINFO_ATTR_MOUNT_TOPOLOGY and FSINFO_ATTR_MOUNT_CHILDREN are
> needed for *each* individual mount.
That's not entirely true.
On Wed, Aug 12, 2020 at 12:14 PM Karel Zak wrote:
> For example, by fsinfo(FSINFO_ATTR_MOUNT_TOPOLOGY) you get all
> mountpoint propagation setting and relations by one syscall,
That's just an arbitrary grouping of attributes.
You said yourself, that what's really needed is e.g. consistent
sna
On Tue, Aug 11, 2020 at 08:20:24AM -0700, Linus Torvalds wrote:
> IOW, if you do something more along the lines of
>
>fd = open(""foo/bar", O_PATH);
>metadatafd = openat(fd, "metadataname", O_ALT);
>
> it might be workable.
I have thought we want to replace mountinfo to reduce ov
On Wed, Aug 12, 2020 at 10:29 AM David Howells wrote:
>
> Miklos Szeredi wrote:
>
> > Worried about performance? Io-uring will allow you to do all those
> > five syscalls (or many more) with just one I/O submission.
>
> io_uring isn't going to help here. We're talking about synchronous reads.
>
Miklos Szeredi wrote:
> Worried about performance? Io-uring will allow you to do all those
> five syscalls (or many more) with just one I/O submission.
io_uring isn't going to help here. We're talking about synchronous reads.
AIUI, you're adding a couple more syscalls to the list and running s
On Wed, Aug 12, 2020 at 2:05 AM David Howells wrote:
> > {
> > int fd, attrfd;
> >
> > fd = open(path, O_PATH);
> > attrfd = openat(fd, name, O_ALT);
> > close(fd);
> > read(attrfd, value, size);
> > close(attrfd);
> > }
>
> Please don't go down this path. You'r
On Tue, Aug 11, 2020 at 11:19 PM Linus Torvalds
wrote:
>
> On Tue, Aug 11, 2020 at 1:56 PM Miklos Szeredi wrote:
> >
> > So that's where O_ALT comes in. If the application is consenting,
> > then that should prevent exploits. Or?
>
> If the application is consenting AND GETS IT RIGHT it shoul
On Tue, 2020-08-11 at 21:39 +0200, Christian Brauner wrote:
> On Tue, Aug 11, 2020 at 09:05:22AM -0700, Linus Torvalds wrote:
> > On Tue, Aug 11, 2020 at 8:30 AM Miklos Szeredi
> > wrote:
> > > What's the disadvantage of doing it with a single lookup WITH an
> > > enabling flag?
> > >
> > > It's
Linus Torvalds wrote:
> [ I missed the beginning of this discussion, so maybe this was already
> suggested ]
Well, the start of it was my proposal of an fsinfo() system call. That at its
simplest takes an object reference (eg. a path) and an integer attribute ID (it
could use a string instead,
On 8/11/2020 1:28 PM, Miklos Szeredi wrote:
> On Tue, Aug 11, 2020 at 6:17 PM Casey Schaufler
> wrote:
>
>> Since ab has known meaning, and lots of applications
>> play loose with '/', its really dangerous to treat the string as
>> special. We only get away with '.' and '..' because their
On Tue, Aug 11, 2020 at 10:28:31PM +0200, Miklos Szeredi wrote:
> On Tue, Aug 11, 2020 at 6:17 PM Casey Schaufler
> wrote:
>
> > Since ab has known meaning, and lots of applications
> > play loose with '/', its really dangerous to treat the string as
> > special. We only get away with '.
On Tue, Aug 11, 2020 at 1:56 PM Miklos Szeredi wrote:
>
> So that's where O_ALT comes in. If the application is consenting,
> then that should prevent exploits. Or?
If the application is consenting AND GETS IT RIGHT it should prevent exploits.
But that's a big deal.
Why not just do it the w
On Tue, Aug 11, 2020 at 1:56 PM Miklos Szeredi wrote:
>
> On Tue, Aug 11, 2020 at 10:37 PM Jann Horn wrote:
> > If you change the semantics of path strings, you'd have to be
> > confident that the new semantics fit nicely with all the path
> > validation routines that exist scattered across users
On Tue, Aug 11, 2020 at 10:37 PM Jann Horn wrote:
> If you change the semantics of path strings, you'd have to be
> confident that the new semantics fit nicely with all the path
> validation routines that exist scattered across userspace, and don't
> expose new interfaces through file server softw
On Tue, Aug 11, 2020 at 10:29 PM Miklos Szeredi wrote:
> On Tue, Aug 11, 2020 at 6:17 PM Casey Schaufler
> wrote:
> > Since ab has known meaning, and lots of applications
> > play loose with '/', its really dangerous to treat the string as
> > special. We only get away with '.' and '..'
On Tue, Aug 11, 2020 at 6:17 PM Casey Schaufler wrote:
> Since ab has known meaning, and lots of applications
> play loose with '/', its really dangerous to treat the string as
> special. We only get away with '.' and '..' because their behavior
> was defined before many of y'all were bor
On Tue, Aug 11, 2020 at 09:31:05PM +0200, Lennart Poettering wrote:
> On Di, 11.08.20 20:49, Miklos Szeredi (mik...@szeredi.hu) wrote:
>
> > On Tue, Aug 11, 2020 at 6:05 PM Linus Torvalds
> > wrote:
> >
> > > and then people do "$(srctree)/". If you haven't seen that kind of
> > > pattern where t
On Tue, Aug 11, 2020 at 09:05:22AM -0700, Linus Torvalds wrote:
> On Tue, Aug 11, 2020 at 8:30 AM Miklos Szeredi wrote:
> >
> > What's the disadvantage of doing it with a single lookup WITH an enabling
> > flag?
> >
> > It's definitely not going to break anything, so no backward
> > compatibility
On Di, 11.08.20 20:49, Miklos Szeredi (mik...@szeredi.hu) wrote:
> On Tue, Aug 11, 2020 at 6:05 PM Linus Torvalds
> wrote:
>
> > and then people do "$(srctree)/". If you haven't seen that kind of
> > pattern where the pathname has two (or sometimes more!) slashes in the
> > middle, you've led a v
On Tue, Aug 11, 2020 at 6:05 PM Linus Torvalds
wrote:
> and then people do "$(srctree)/". If you haven't seen that kind of
> pattern where the pathname has two (or sometimes more!) slashes in the
> middle, you've led a very sheltered life.
Oh, I have. That's why I opted for triple slashes, sin
On Tue, Aug 11, 2020 at 09:09:36AM -0700, Linus Torvalds wrote:
> On Tue, Aug 11, 2020 at 9:05 AM Al Viro wrote:
> >
> > Except that you suddenly see non-directory dentries get children.
> > And a lot of dcache-related logics needs to be changed if that
> > becomes possible.
>
> Yeah, I think you
On Tue, Aug 11, 2020 at 9:17 AM Casey Schaufler wrote:
>
> This doesn't work so well for setxattr(), which we want to be atomic.
Well, it's not like the old interfaces could go away. But yes, doing
metadatafd = openat(fd, "metadataname", O_ALT | O_CREAT | O_EXCL)
to create a new xattr (
On 8/11/2020 8:39 AM, Andy Lutomirski wrote:
>
>> On Aug 11, 2020, at 8:20 AM, Linus Torvalds
>> wrote:
>>
>> [ I missed the beginning of this discussion, so maybe this was already
>> suggested ]
>>
>>> On Tue, Aug 11, 2020 at 6:54 AM Miklos Szeredi wrote:
>>>
E.g.
openat(AT_FDCWD, "
On Tue, Aug 11, 2020 at 9:05 AM Al Viro wrote:
>
> Except that you suddenly see non-directory dentries get children.
> And a lot of dcache-related logics needs to be changed if that
> becomes possible.
Yeah, I think you'd basically need to associate a (dynamic)
mount-point to that path when you s
On Tue, Aug 11, 2020 at 8:30 AM Miklos Szeredi wrote:
>
> What's the disadvantage of doing it with a single lookup WITH an enabling
> flag?
>
> It's definitely not going to break anything, so no backward
> compatibility issues whatsoever.
No backwards compatibility issues for existing programs,
On Tue, Aug 11, 2020 at 08:20:24AM -0700, Linus Torvalds wrote:
> I don't think this works for the reasons Al says, but a slight
> modification might.
>
> IOW, if you do something more along the lines of
>
>fd = open(""foo/bar", O_PATH);
>metadatafd = openat(fd, "metadataname", O
> On Aug 11, 2020, at 8:20 AM, Linus Torvalds
> wrote:
>
> [ I missed the beginning of this discussion, so maybe this was already
> suggested ]
>
>> On Tue, Aug 11, 2020 at 6:54 AM Miklos Szeredi wrote:
>>
>>>
>>> E.g.
>>> openat(AT_FDCWD, "foo/bar//mnt/info", O_RDONLY | O_ALT);
>>
>>
On Tue, Aug 11, 2020 at 5:20 PM Linus Torvalds
wrote:
>
> [ I missed the beginning of this discussion, so maybe this was already
> suggested ]
>
> On Tue, Aug 11, 2020 at 6:54 AM Miklos Szeredi wrote:
> >
> > >
> > > E.g.
> > > openat(AT_FDCWD, "foo/bar//mnt/info", O_RDONLY | O_ALT);
> >
> > Pr
[ I missed the beginning of this discussion, so maybe this was already
suggested ]
On Tue, Aug 11, 2020 at 6:54 AM Miklos Szeredi wrote:
>
> >
> > E.g.
> > openat(AT_FDCWD, "foo/bar//mnt/info", O_RDONLY | O_ALT);
>
> Proof of concept patch and test program below.
I don't think this works for t
On Tue, Aug 11, 2020 at 4:42 PM Al Viro wrote:
>
> On Tue, Aug 11, 2020 at 04:36:32PM +0200, Miklos Szeredi wrote:
>
> > > > - strip off trailing part after first instance of ///
> > > > - perform path lookup as normal
> > > > - resolve meta path after /// on result of normal lookup
> > >
> > >
On Tue, Aug 11, 2020 at 04:36:32PM +0200, Miklos Szeredi wrote:
> > > - strip off trailing part after first instance of ///
> > > - perform path lookup as normal
> > > - resolve meta path after /// on result of normal lookup
> >
> > ... and interpolation of relative symlink body into the pathna
On Tue, Aug 11, 2020 at 4:31 PM Al Viro wrote:
>
> On Tue, Aug 11, 2020 at 04:22:19PM +0200, Miklos Szeredi wrote:
> > On Tue, Aug 11, 2020 at 4:08 PM Al Viro wrote:
> > >
> > > On Tue, Aug 11, 2020 at 03:54:19PM +0200, Miklos Szeredi wrote:
> > > > On Wed, Aug 05, 2020 at 10:24:23AM +0200, Miklo
On Tue, Aug 11, 2020 at 10:33:59AM -0400, Tang Jiye wrote:
> anyone knows how to post a question?
Generally the way you just have, except that you generally
put it *after* the relevant parts of the quoted text (and
removes the irrelevant ones).
On Tue, Aug 11, 2020 at 04:22:19PM +0200, Miklos Szeredi wrote:
> On Tue, Aug 11, 2020 at 4:08 PM Al Viro wrote:
> >
> > On Tue, Aug 11, 2020 at 03:54:19PM +0200, Miklos Szeredi wrote:
> > > On Wed, Aug 05, 2020 at 10:24:23AM +0200, Miklos Szeredi wrote:
> > > > On Tue, Aug 4, 2020 at 4:36 PM Mikl
On Tue, Aug 11, 2020 at 4:08 PM Al Viro wrote:
>
> On Tue, Aug 11, 2020 at 03:54:19PM +0200, Miklos Szeredi wrote:
> > On Wed, Aug 05, 2020 at 10:24:23AM +0200, Miklos Szeredi wrote:
> > > On Tue, Aug 4, 2020 at 4:36 PM Miklos Szeredi wrote:
> > >
> > > > I think we already lost that with the xat
On Tue, Aug 11, 2020 at 03:54:19PM +0200, Miklos Szeredi wrote:
> On Wed, Aug 05, 2020 at 10:24:23AM +0200, Miklos Szeredi wrote:
> > On Tue, Aug 4, 2020 at 4:36 PM Miklos Szeredi wrote:
> >
> > > I think we already lost that with the xattr API, that should have been
> > > done in a way that fits
On Wed, Aug 05, 2020 at 10:24:23AM +0200, Miklos Szeredi wrote:
> On Tue, Aug 4, 2020 at 4:36 PM Miklos Szeredi wrote:
>
> > I think we already lost that with the xattr API, that should have been
> > done in a way that fits this philosophy. But given that we have "/"
> > as the only special pur
On Tue, Aug 4, 2020 at 4:36 PM Miklos Szeredi wrote:
> I think we already lost that with the xattr API, that should have been
> done in a way that fits this philosophy. But given that we have "/"
> as the only special purpose char in filenames, and even repetitions
> are allowed, it's hard to t
59 matches
Mail list logo
