Received: by 10.192.165.148 with SMTP id m20csp58341imm; Thu, 19 Apr 2018 12:59:44 -0700 (PDT) X-Google-Smtp-Source: AIpwx48dk7r8us5Fge49loNRHa610qXoHqRVIOHu75YW+/tw7t6LcK7i9rXkJSFIL3fmdbrYvMEP X-Received: by 10.99.65.6 with SMTP id o6mr6298469pga.57.1524167983979; Thu, 19 Apr 2018 12:59:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524167983; cv=none; d=google.com; s=arc-20160816; b=GG1deDEgkjwKsyEAXPvd7FRnkmdXVQh3ctgoaqX6ZzTqFoTtkX46d7WFG/sdmDi/hD PLwDEk5rBhskC2rqRuXSKWpHiQTwgWEeTtEekPmkFj/4n4TvabMiawwMSFDXCy8LvAkV nBlnOutjJgGEojssSWu9EVHW+LwxM3F8bdzHR1dzCedzFkrxTFVah/ItWveti/Sea9y0 SpD8DySAQRBktLNzb/4phyiZf5iuSfntosVqcW3Sn23ETx1imbwbfje9JG7uMgurQDLf R9V+XhGdRvzpJH3EeuU3KNAtuMpaealuLI46zlqLEg25yzAyvdEZusdkHqTrB95+/dd8 +sYg== 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=JlgeZOHBqgIGbX9mGLkawRdLo22U8wo/HS2mQ82nYg4=; b=rO2Tbj6l2Y9EGpJgNH/g0LhodSfI4NTvhEebnIhhEdoYCDXYnCwuXNpo4GkUZbsfZh M1p4zXeea6K3liHe8LKi7pVwSU2EhkyD1F5YkFt/lp+QJAJRE2p3DPpY9C+OMbWll+eE VYOuWwsEdbskkpo3TX8uROyJm+R0e5I/+sAvN2oIvmh1Jd0RUegJhAcPASnL1wR6dhXf /d58q4k/yHzTfD/UwQnol8VoqqDuhLi4lPkQ1M8pwforIScKkulnWcqlkQOu9579WKwP sFiviBzG1C0EcX975ngh1JGHFTFcxF/E90rxt2++hkNv7L8gWBqFoJJeTri1xIzFufgc 7wMg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t198si3610616pgc.600.2018.04.19.12.58.59; Thu, 19 Apr 2018 12:59:43 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753385AbeDSTyx (ORCPT + 99 others); Thu, 19 Apr 2018 15:54:53 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:50494 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752153AbeDSTyv (ORCPT ); Thu, 19 Apr 2018 15:54:51 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BB99681A88BD; Thu, 19 Apr 2018 19:54:50 +0000 (UTC) Received: from horse.redhat.com (ovpn-121-25.rdu2.redhat.com [10.10.121.25]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5749A215CDA7; Thu, 19 Apr 2018 19:54:50 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id 8F27B223C30; Thu, 19 Apr 2018 15:54:49 -0400 (EDT) Date: Thu, 19 Apr 2018 15:54:49 -0400 From: Vivek Goyal To: Miklos Szeredi Cc: Steven Rostedt , Amir Goldstein , Miklos Szeredi , overlayfs , linux-fsdevel , linux-kernel , Howard McLauchlan Subject: Re: [RFC PATCH 31/35] Revert "vfs: add d_real_inode() helper" Message-ID: <20180419195449.GC9451@redhat.com> References: <20180412150826.20988-1-mszeredi@redhat.com> <20180412150826.20988-32-mszeredi@redhat.com> <20180418093845.19ca33f3@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 19 Apr 2018 19:54:50 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 19 Apr 2018 19:54:50 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'vgoyal@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 18, 2018 at 03:49:02PM +0200, Miklos Szeredi wrote: > On Wed, Apr 18, 2018 at 3:38 PM, Steven Rostedt wrote: > > On Wed, 18 Apr 2018 13:42:03 +0200 > > Miklos Szeredi wrote: > > > >> On Wed, Apr 18, 2018 at 10:19 AM, Amir Goldstein wrote: > >> > On Thu, Apr 12, 2018 at 6:08 PM, Miklos Szeredi wrote: > >> >> This reverts commit a118084432d642eeccb961c7c8cc61525a941fcb. > >> >> > >> >> No user of d_real_inode() remains, so it can be removed. > >> >> > >> > > >> > FYI, there is a new user in v4.17-rc1 added by commit > >> > f0a2aa5a2a40 tracing/uprobe: Add support for overlayfs > >> > > >> > Seems like this patch got merged without any CC to overlayfs > >> > mailing list nor maintainer? > > > > It appeared to be a small change with lots of reviewers. I didn't think > > it was something to notify the overlayfs folks with. But perhaps I was > > wrong. > > The patch is correct. The code surrounding it isn't, though. > > > > >> > > >> > Not sure yet if overlayfs-rorw patches would allow reverting this > >> > change. > >> > >> Not trivial, because uprobe is looking at i_mapping to get a list of > >> current memory maps. We could set i_mapping at overlay inode > >> initialization time, but we definitely can't *change* i_mapping at > >> copy up. Which is bound to result in some weird inconsistencies. So > >> likely we'll need to keep d_real_inode() for the time being. > > > > I just received this patch: > > > > http://lkml.kernel.org/r/20180418062907.3210386-1-songliubraving@fb.com > > > > Which removes this code. Can you review it and I'll take it. > > It shouldn't remove d_real_inode(), because that part is correct and > fixes a real bug in handling overlayfs files. I am wondering what does it practically mean for metdata only copy up patches. Given this is uprobe code, I am assuming its modifying some executable code dynamically. And for the the case of metadata only copy up, it will return inode of lower. That probably means, as long as all running instances of that exeutable are using that inode, things will work fine. But if for some reason somebody opens that file for WRITE and triggers copy up and new instances of same binary will not see the probe taking affect? Which is probably very similar to what will happen if a lower executable is copied up. Having said that, in normal cases there should not be a need to copy up a binary in normal circumstances. Am I missing the point completely. Thanks Vivek