linux-kernel - Re: [GIT PULL] overlayfs update for 4.14

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 14 Sep 2017 13:24:22 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Miklos Szeredi <miklos@...redi.hu>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        "linux-unionfs@...r.kernel.org" <linux-unionfs@...r.kernel.org>
Subject: Re: [GIT PULL] overlayfs update for 4.14

On Thu, Sep 14, 2017 at 1:12 PM, Miklos Szeredi <miklos@...redi.hu> wrote:
>
> I was saying that it's a bad idea to mix external and internal flags.
> That was the reason the two were separated on that API. I'm open to
> arguments about that.

The thing is, I don't think "upper layer" is any more internal than
"direct IO" is.

And I don't think it's necessarily overlayfs-specific. Other
filesystems have potential upper layers (eg things like caching
layers, where the "upper" layer could be "the cached copy").

And no, I'm, not saying we should expose things directly to user
space. We have lots of operations where we expose some flags to user
space but keep others internal (look at the VM_xyz flags for mmap, for
example - we obviously expose things like read/write/execute to user
space, but we have the MAYREAD/MAYWRITE/MAYEXEC flags in the same word
that are *not* something that user space can just set).

I just don't see any reason why those two "flags" arguments are separate.

              Linus