Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4790833imm; Mon, 11 Jun 2018 19:41:17 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLg5YjRO/Pabcdg33A/zpAys2xwKXbD3/VibWTIHRCnQH8gYxYn4S4MENkx/r3G7i87GdR7 X-Received: by 2002:a17:902:b786:: with SMTP id e6-v6mr1854652pls.260.1528771277852; Mon, 11 Jun 2018 19:41:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528771277; cv=none; d=google.com; s=arc-20160816; b=xfLeSH2EU2O9tblh9VkUYr5k46e+l4eA2EY7OzW5bzk30nWjMnitD2QvisM7TUJsXt KVuEKkCAK+DVOJP6sJyE55D8Tx2jkOI2UyeVX10wi7NJoRZFfFgh32VIknHkkoql4UGC ZGMBU8PvjLJh3aza0J+y6ooMHh9D8qOVAKHcRbblCdTe5CTgoI290IY/yhp/6FNJEd1m 2uEJHnbSxwVB+jg0oYpVbPIeETAMZeK8Ko2SWQkTaybC4FkaHQ3NjKCp3Hhdy4qz3XGF f9oEnOoO7JmW0CV9U0c7cdQ5usFeV4c3v1UpZKegK8udUHJaFEo7ndOnsFjd6lUevyuP 4VQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=DF57yjkj7iK4xXS8dSYqYKKtEp09kb4rQa6+JszxZvU=; b=jX2exyMKUgfjClhgDdKm9wGoPfaAk05QOCb42xVZQId3CMmObDUatwMxxwPQzbo1PH IsQwo5N4bQVuxGt48rNRjDiQKLMszs2+4uk1q+/IRK11cPoTcfzBoMc9OgMRnBD+PN1m h9KM7A1amZa6bITSGgmOHdjreU/NSgEF2sOnSA+UnAZBRZ++KUVPdXWP+OBmOBPxtc5m Cj4pwmRdIAqBP8d1pEe5liNbjff7eHFSW/gyFbUL7iTYw3wIt1/uNFGubIOz+6vUq3V4 z8rp5R9ArHCypnY13o5/RgHCI+ziaEmCxmfaUyevYq+84xSMv5h9I0/Ehi5LLCAs1lMP nPhA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w2-v6si7147204pgs.59.2018.06.11.19.41.03; Mon, 11 Jun 2018 19:41:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935146AbeFLCkd (ORCPT + 99 others); Mon, 11 Jun 2018 22:40:33 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:42444 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935004AbeFLCkc (ORCPT ); Mon, 11 Jun 2018 22:40:32 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1fSZEU-0006yj-1U; Tue, 12 Jun 2018 02:40:30 +0000 Date: Tue, 12 Jun 2018 03:40:30 +0100 From: Al Viro To: Miklos Szeredi Cc: Miklos Szeredi , overlayfs , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds Subject: Re: [PATCH 14/39] ovl: stack file ops Message-ID: <20180612024029.GZ30522@ZenIV.linux.org.uk> References: <20180529144339.16538-1-mszeredi@redhat.com> <20180529144339.16538-15-mszeredi@redhat.com> <20180610041243.GJ30522@ZenIV.linux.org.uk> <20180612022926.GY30522@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180612022926.GY30522@ZenIV.linux.org.uk> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 12, 2018 at 03:29:26AM +0100, Al Viro wrote: > It might (or might not) work for the filesystems you'd been testing > on, but it's a lot of trouble waiting to happen. Hell, try and use > ecryptfs as lower layer, see how fast it'll blow up. Sure, it's > a dumb testcase, but I don't see how to check if something more > realistic is trouble-free. > > I'd been trying to come up with some way to salvage that kludge of yours, > but I don't see any solutions. We don't have good proxies for "this > filesystem might be unsafe as lower layer" ;-/ Note that anything that uses file_dentry() anywhere near ->open(), ->read_iter() or ->write_iter() is an instant trouble with your scheme. Such as int nfs_open(struct inode *inode, struct file *filp) { struct nfs_open_context *ctx; ctx = alloc_nfs_open_context(file_dentry(filp), filp->f_mode, filp); if (IS_ERR(ctx)) return PTR_ERR(ctx); nfs_file_set_open_context(filp, ctx); put_nfs_open_context(ctx); nfs_fscache_open_file(inode, filp); return 0; } You do want to support NFS for lower layers, right?