From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-f193.google.com ([209.85.213.193]:41600 "EHLO mail-yb0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750949AbeEaEaH (ORCPT ); Thu, 31 May 2018 00:30:07 -0400 MIME-Version: 1.0 In-Reply-To: <20180530210556.GD2717@redhat.com> References: <20180529144612.16675-1-mszeredi@redhat.com> <20180529144612.16675-17-mszeredi@redhat.com> <20180530210556.GD2717@redhat.com> From: Amir Goldstein Date: Thu, 31 May 2018 07:30:06 +0300 Message-ID: Subject: Re: [PATCH 16/28] ovl: Do not expose metacopy only dentry from d_real() To: Vivek Goyal Cc: Miklos Szeredi , overlayfs , linux-fsdevel , linux-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, May 31, 2018 at 12:05 AM, Vivek Goyal wrote: > On Tue, May 29, 2018 at 04:46:00PM +0200, Miklos Szeredi wrote: >> From: Vivek Goyal >> >> Metacopy dentry/inode is internal to overlay and is never exposed outside >> of it. Exception is metacopy upper file used for fsync(). Modify d_real() >> to look for dentries/inode which have data, but also allow matching upper >> inode without data for the fsync case. >> > > Hi Miklos, > > I am not able to see how in fsync() path d_real() gets called. If we > decide to do fsync() on upper metacopy, then opening upper will not > go through d_real(). And we never issue fsync() on lower. > > So I am scratching my head while trying to understand the d_real() and > fsync() connection. > fsync() exposes real meta inode to vfs, so file_dentry() needs to be able to find the real meta upper dentry. Thanks, Amir.