From patchwork Tue May 29 14:46:07 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miklos Szeredi X-Patchwork-Id: 10435757 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 33EF8602BF for ; Tue, 29 May 2018 14:48:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 25AA82864E for ; Tue, 29 May 2018 14:48:05 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1AA4A28658; Tue, 29 May 2018 14:48:05 +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=-7.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=unavailable 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 BA4E42864E for ; Tue, 29 May 2018 14:48:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935334AbeE2OrI (ORCPT ); Tue, 29 May 2018 10:47:08 -0400 Received: from mail-wm0-f41.google.com ([74.125.82.41]:54696 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936665AbeE2Oqo (ORCPT ); Tue, 29 May 2018 10:46:44 -0400 Received: by mail-wm0-f41.google.com with SMTP id f6-v6so41375554wmc.4 for ; Tue, 29 May 2018 07:46:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=F527eWQ+7/1ZR5pSgHCOehipcknksX246tZ2xU0d26I=; b=p/pBs7qL5Jfpy7c4uAIzu8u/Ay4znxb4Qt6x8RUJGlsj4pU1jn4nPzjfMEfvKNAzi8 ECyK9HA3pwX3ovHv0XtHOb6r7MdNtIMsQc01ATzoUauQ+di+gScAK1k9duDxzjr1oFim 5YaRmakog0TcUrHA/Yo06g2MVAIc2mZhK3de1FXTKk629052zh+8iXm1tcduHVhGEG/6 2z+yeDAn5dilSBVQmOtibJ8DZ86kok1yyZGW5QjnIwsUytsXjS4U3kbzzj28URD4b70e CvIMxFwkSeAgkDGUylYrOXRnN7A7Eb8L1FssLcy72D/+3Sae+Hx1BiXb0XV6/pG25To/ QXjQ== X-Gm-Message-State: ALKqPwe8w4GL3fqGXq6RGagTvmauDNpouHQ6qFyAnBMyXnDwZREdohdB ijrjArKEnakiynZQ7yA47/jsKHzY67g= X-Google-Smtp-Source: ADUXVKIlI2VQ0pAyEcl/ArskIU5cuMAGcbQh0f6dE+xNoe3pJW86VfVEMQ6tQReyWXcsOLR40t4rzA== X-Received: by 2002:a1c:ee58:: with SMTP id m85-v6mr13034485wmh.44.1527605203359; Tue, 29 May 2018 07:46:43 -0700 (PDT) Received: from veci.piliscsaba.redhat.com (catv-176-63-54-97.catv.broadband.hu. [176.63.54.97]) by smtp.gmail.com with ESMTPSA id n71-v6sm20942227wmi.14.2018.05.29.07.46.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 29 May 2018 07:46:42 -0700 (PDT) From: Miklos Szeredi To: linux-unionfs@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 23/28] ovl: Set redirect on upper inode when it is linked Date: Tue, 29 May 2018 16:46:07 +0200 Message-Id: <20180529144612.16675-24-mszeredi@redhat.com> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20180529144612.16675-1-mszeredi@redhat.com> References: <20180529144612.16675-1-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 From: Vivek Goyal When we create a hardlink to a metacopy upper file, first the redirect on that inode. Path based lookup will not work with newly created link and redirect will solve that issue. Also use absolute redirect as two hardlinks could be in different directores and relative redirect will not work. I have not put any additional locking around setting redirects while introducing redirects for non-dir files. For now it feels like existing locking is sufficient. If that's not the case, we will have add more locking. Following is my rationale about why do I think current locking seems ok. Basic problem for non-dir files is that more than on dentry could be pointing to same inode and in theory only relying on dentry based locks (d->d_lock) did not seem sufficient. We set redirect upon rename and upon link creation. In both the paths for non-dir file, VFS locks both source and target inodes (->i_rwsem). That means vfs rename and link operations on same source and target can't he happening in parallel (Even if there are multiple dentries pointing to same inode). So that probably means that at a time on an inode, only one call of ovl_set_redirect() could be working and we don't need additional locking in ovl_set_redirect(). ovl_inode->redirect is initialized only when inode is created new. That means it should not race with any other path and setting ovl_inode->redirect should be fine. Reading of ovl_inode->redirect happens in ovl_get_redirect() path. And this called only in ovl_set_redirect(). And ovl_set_redirect() already seemed to be protected using ->i_rwsem. That means ovl_set_redirect() and ovl_get_redirect() on source/target inode should not make progress in parallel and is mutually exclusive. Hence no additional locking required. Now, only case where ovl_set_redirect() and ovl_get_redirect() could race seems to be case of absolute redirects where ovl_get_redirect() has to travel up the tree. In that case we already take d->d_lock and that should be sufficient as directories will not have multiple dentries pointing to same inode. So given VFS locking and current usage of redirect, current locking around redirect seems to be ok for non-dir as well. Once we have the logic to remove redirect when metacopy file gets copied up, then we probably will need additional locking. Signed-off-by: Vivek Goyal Reviewed-by: Amir Goldstein Signed-off-by: Miklos Szeredi --- fs/overlayfs/dir.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c index 1658961a9762..7063e0f588cc 100644 --- a/fs/overlayfs/dir.c +++ b/fs/overlayfs/dir.c @@ -24,6 +24,8 @@ module_param_named(redirect_max, ovl_redirect_max, ushort, 0644); MODULE_PARM_DESC(ovl_redirect_max, "Maximum length of absolute redirect xattr value"); +static int ovl_set_redirect(struct dentry *dentry, bool samedir); + int ovl_cleanup(struct inode *wdir, struct dentry *wdentry) { int err; @@ -656,6 +658,12 @@ static int ovl_link(struct dentry *old, struct inode *newdir, if (err) goto out_drop_write; + if (ovl_is_metacopy_dentry(old)) { + err = ovl_set_redirect(old, false); + if (err) + goto out_drop_write; + } + err = ovl_nlink_start(old, &locked); if (err) goto out_drop_write;