From patchwork Thu Dec 1 10:14:56 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miklos Szeredi X-Patchwork-Id: 9455753 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 4B7CC60515 for ; Thu, 1 Dec 2016 10:17:12 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3B66A283BB for ; Thu, 1 Dec 2016 10:17:12 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2F1702845D; Thu, 1 Dec 2016 10:17:12 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BE249283BB for ; Thu, 1 Dec 2016 10:17:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755726AbcLAKRA (ORCPT ); Thu, 1 Dec 2016 05:17:00 -0500 Received: from mail-wj0-f174.google.com ([209.85.210.174]:33453 "EHLO mail-wj0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755814AbcLAKPI (ORCPT ); Thu, 1 Dec 2016 05:15:08 -0500 Received: by mail-wj0-f174.google.com with SMTP id xy5so199957771wjc.0 for ; Thu, 01 Dec 2016 02:15:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=SElWhlhRXVTr2ND91O8hxLH9pzXRBX0D9ps+6rqWH0M=; b=ZRDjcjANteLI4Qn7R5i+WWMe4NlQoii9skIuYBhnTd30kC2kdT81d1qW3K2TwNJCKs 2h9LeJNOJPg6A+R4/Q1Qw6Rq0UFwFPCSwW5O0vcse2h33fvh7FM++jY1TQXZBxnTaH5x +vusWR+42Je+nuP3yi93UT7pBpoQ3P/NjNgaNi0nhTPfX6Cd4rq1y7ibIkxOA1TgkPqE artlaVgGtcNXdkgAhSdYLAaRQ5Tz83a9jV93u4uuhbz49O1T8W2K9RxXY2f+OLuwlJF/ rJZcfL1voQbfTTMOe8Y0QhsHh3Knx5T8cHRNNvlHWn9OzFdS9VNxZWGuyYrI2DsoaYHt xoyQ== X-Gm-Message-State: AKaTC02H2xlg0QrAquTissQeO1uKa2CW097nnwAgZ8RTbS5bbBiv9/4Lwo8hzL+bmCeiwpXa X-Received: by 10.194.0.167 with SMTP id 7mr31100253wjf.80.1480587306980; Thu, 01 Dec 2016 02:15:06 -0800 (PST) Received: from veci.piliscsaba.szeredi.hu (pool-dsl-2c-0018.externet.hu. [217.173.44.24]) by smtp.gmail.com with ESMTPSA id ab10sm77218141wjc.45.2016.12.01.02.15.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Dec 2016 02:15:06 -0800 (PST) From: Miklos Szeredi To: Al Viro Cc: linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: [PATCH 1/8] vfs: allow overlayfs to intercept file ops Date: Thu, 1 Dec 2016 11:14:56 +0100 Message-Id: <1480587303-25088-2-git-send-email-mszeredi@redhat.com> X-Mailer: git-send-email 2.5.5 In-Reply-To: <1480587303-25088-1-git-send-email-mszeredi@redhat.com> References: <1480587303-25088-1-git-send-email-mszeredi@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Almost all of the time overlayfs just wants to let underlying filesystems handle file operations on regular files. There is a rare corner case, namely when a file residing a read-only (lower) layer is: - opened for O_RDONLY - opened for O_WRONLY - contents modified - contents read back though O_RDONLY fd Currently overlayfs gives inconsistent result in this case, since the O_RDONLY file refers to the lower, unmodified file, even after the copy up has happened. This happens very rarely, so a) we want the normal cases (when no copy up happens) still go as fast as possible; b) we can let the corner case go slow. The proposed solution is to allow overlayfs to intercept file operations if it wants (O_RDONLY open of file on lower layer), but still let the file be owned by the underlying layer. This means everything in filp, including the private_data, is controlled by the underlying layer (as it has been until now) with the exception of f_op, which comes from overlayfs. This patch doesn't change the actual behavior, it just adds the vfs change necessary and then unconditionally sets the f_op back to the underlying file's ops. For non-overlayfs, this doesn't change anything. Signed-off-by: Miklos Szeredi --- fs/open.c | 2 +- fs/overlayfs/inode.c | 18 ++++++++++++++++++ 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/fs/open.c b/fs/open.c index 8a0254b56780..453ef5581389 100644 --- a/fs/open.c +++ b/fs/open.c @@ -734,7 +734,7 @@ static int do_dentry_open(struct file *f, if (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode)) f->f_mode |= FMODE_ATOMIC_POS; - f->f_op = fops_get(inode->i_fop); + f->f_op = fops_get(f->f_path.dentry->d_inode->i_fop); if (unlikely(WARN_ON(!f->f_op))) { error = -ENODEV; goto cleanup_all; diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c index a10e948d24fa..1981a5514f51 100644 --- a/fs/overlayfs/inode.c +++ b/fs/overlayfs/inode.c @@ -11,6 +11,7 @@ #include #include #include +#include #include "overlayfs.h" static int ovl_copy_up_truncate(struct dentry *dentry) @@ -333,6 +334,22 @@ static const struct inode_operations ovl_symlink_inode_operations = { .update_time = ovl_update_time, }; +static int ovl_open(struct inode *inode, struct file *file) +{ + int ret = 0; + + /* Want fops from real inode */ + replace_fops(file, inode->i_fop); + if (file->f_op->open) + ret = file->f_op->open(inode, file); + + return ret; +} + +static const struct file_operations ovl_file_operations = { + .open = ovl_open, +}; + static void ovl_fill_inode(struct inode *inode, umode_t mode, dev_t rdev) { inode->i_ino = get_next_ino(); @@ -345,6 +362,7 @@ static void ovl_fill_inode(struct inode *inode, umode_t mode, dev_t rdev) switch (mode & S_IFMT) { case S_IFREG: inode->i_op = &ovl_file_inode_operations; + inode->i_fop = &ovl_file_operations; break; case S_IFDIR: