Re: [GIT PULL] overlayfs update for 4.18

From: Miklos Szeredi
Date: Mon Jun 11 2018 - 04:41:36 EST

On Sun, Jun 10, 2018 at 7:54 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> 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:// 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.

Al, thanks for the review.

Posted incremental for the ovl_mmap() issues to -fsdevel. I'm pretty
confident that that addresses your comments.

Linus, would you still pull if Al's satisfied with that resolution?
I can post the fixes (just few liners) after the merge window.

I'm definitely not going to prepare another pull request this cycle if
the old one cannot be pulled.