Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752327AbdIMQZe (ORCPT ); Wed, 13 Sep 2017 12:25:34 -0400 Received: from mail-io0-f169.google.com ([209.85.223.169]:46364 "EHLO mail-io0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751863AbdIMQZ0 (ORCPT ); Wed, 13 Sep 2017 12:25:26 -0400 X-Google-Smtp-Source: AOwi7QDV5FXQ5g/yj1/obt+VjZ245ImDSHJhxzt4ZzW0PYc/9U/H8UdkOr3k/cRKj1Lty4Ohdzs7Wxy2mIr1EiG3zcU= MIME-Version: 1.0 In-Reply-To: <20170913140528.GA19278@veci.piliscsaba.szeredi.hu> References: <20170913140528.GA19278@veci.piliscsaba.szeredi.hu> From: Linus Torvalds Date: Wed, 13 Sep 2017 09:25:25 -0700 X-Google-Sender-Auth: FBvofNks2R0QqwMo2mpkrdMRqL8 Message-ID: Subject: Re: [GIT PULL] overlayfs update for 4.14 To: Miklos Szeredi , Al Viro Cc: Linux Kernel Mailing List , linux-fsdevel , linux-unionfs@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1616 Lines: 33 On Wed, Sep 13, 2017 at 7:05 AM, Miklos Szeredi wrote: > > There are also some bug fixes, one in particular (random ioctl's shouldn't be > able to modify lower layers) that touches some vfs code, but of course no-op for > non-overlay fs. Argh. I _despise_ those changes to 'd_real()'. I reall ythink you should have made it a bit in the f_flags argument instead. The whole "pick the upper file" is _very_ similar to the file->f_flags bits conceptually - those change how accesses are done in other ways (eg O_DIRECT etc), and it's entirely possible that some day maybe you'd even want to expose it to user space as a O_UPPER flag to open (which would then only succeed if the file is in the upper overlay, and never open the lower filesystem). So adding _another_ field that is only for overlayfs and makes absolutely no sense in any other context is nasty. It's wrong. That's not a "VFS layer interface" any more. It's just an ugly hack that makes no sense outside of overlayfs. Try to make it something that makes conceptual sense, and isn't just an overlayfs issue. For example, maybe for cachefs the bit could mean "give me the cached copy without doing validation or looking anything new up". Try to make it something that actually makes sense from a higher-level perspective, where overlayfs is just one implementation, not the driving force. See what I'm saying? THAT is what VFS layer interfaces should all be about, not about "this one specific filesystem needs this one specific f*cking ugly hack". I've pulled it, but I really think you should change this. Linus