On Sat, Aug 25, 2018 at 11:36:15PM +0100, Al Viro wrote:
> On Sat, Aug 25, 2018 at 01:57:16PM -0700, Matthew Wilcox wrote:
>
> > > > Right, but that code also assumes it's dealing with files.
> > >
> > > I'm looking forward to your analysis of all code related to dentry tree,
> > > with an eye towards the places where such asserts are quietly made...
> >
> > I really was hoping not to change the dentry tree at all.
>
> Umhm... Just what, pray tell, would be used to hold the stream name when
> you are creating/removing/renaming it? And why are we talking about the
> use of existing syscalls for that thing? In effect, you are multiplexing
> entirely new syscalls, with different pathname resolution, etc. upon the
> existing ones, using that new AT_... flag to select them.
>
> Better yet, you need some new objects to represent those things, since
> you don't want any informative dentries. And not fs-private ones, at
> that, since those new syscalls of yours would have to operate on them
> (after all, renaming something opened would probably be expected to
> have the opened descriptor to keep accessing the same object, wouldn't
> it?)
Let's look at it this way ... suppose we have an fcntl F_SETSTREAM.
And our API looks like:
fd = open("/a/b/c", O_RDWR);
fcntl(fd, F_SETSTREAM, "verity");
read(fd, ...);
>From a VFS point of view, we just change file->f_inode to point to a
different inode. We probably also have to change file->f_op. Do we
also need to change file->f_path.dentry?
