All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Christoph Hellwig <hch@infradead.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-unionfs@vger.kernel.org
Subject: Re: [GIT PULL] overlayfs update for 4.18
Date: Sun, 10 Jun 2018 06:54:38 +0100	[thread overview]
Message-ID: <20180610055326.GR30522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20180609065208.GA31572@infradead.org>

On Fri, Jun 08, 2018 at 11:52:08PM -0700, Christoph Hellwig wrote:
> On Fri, Jun 08, 2018 at 02:13:30PM +0200, Miklos Szeredi wrote:
> > Hi Linus,
> > 
> > Please pull from:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git tags/ovl-update-4.18
> > 
> > This contains two new features:
> > 
> >  1) Stack file operations: this allows removal of several hacks from the
> >     VFS, proper interaction of read-only open files with copy-up,
> >     possibility to implement fs modifying ioctls properly, and others.
> 
> Which includews all kinds of NAKed or at least non-acked VFS changes.

Umm...  The worst of yours had been ->pre_mmap(), right?  He *did* drop that...

> Please get these through Als tree after proper review first.

OK, summary of sort (see fsdevel thread for details):
	* path_open() is dubious; why not simply use vfsmount/dentry from the
right layer when opening an underlying file?  Then it would be vfs_open()...
	* ovl_mmap() is broken, plain and simple.  Failure ends up leaking
a layer struct file *and* doing double fput() on overlayfs one.
	* ovl_mmap() is also trivially DoSable - you can trigger tons and tons
of reopens, each sticking a new (writable layer) struct file into a vma.
We *do* want some scheme avoiding once-per-operations reopens in the
copied-up-after-r/o-open case.  See possible kinda-sorta solution on fsdevel;
I'm not sure I like it, though.

The rest is pretty minor.

  parent reply	other threads:[~2018-06-10  5:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-08 12:13 [GIT PULL] overlayfs update for 4.18 Miklos Szeredi
2018-06-09  6:52 ` Christoph Hellwig
2018-06-09 21:42   ` Linus Torvalds
2018-06-09 23:55     ` Al Viro
2018-06-11  6:09     ` Christoph Hellwig
2018-06-10  5:54   ` Al Viro [this message]
2018-06-11  6:10     ` Christoph Hellwig
2018-06-11  8:41     ` Miklos Szeredi
2018-06-11 16:27       ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2018-05-29 13:21 Miklos Szeredi
2018-05-29 13:59 ` Christoph Hellwig
2018-05-29 14:12   ` Miklos Szeredi
2018-05-30  8:36     ` Miklos Szeredi
2018-05-30 22:27       ` Dave Chinner
2018-06-01 15:26 ` Miklos Szeredi
2018-06-01 16:18   ` Randy Dunlap
2018-06-01 17:03     ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180610055326.GR30522@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.