Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp70621ybb; Thu, 9 Apr 2020 17:29:39 -0700 (PDT) X-Google-Smtp-Source: APiQypLMMbsKJhUmIBIXGvU4E9sRmghsLjcaIo/woMxe7ueI6eHyWjjSySQVfmcRxnKYrVfz2OI5 X-Received: by 2002:aed:3968:: with SMTP id l95mr1534958qte.268.1586478579345; Thu, 09 Apr 2020 17:29:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586478579; cv=none; d=google.com; s=arc-20160816; b=UXzZOQyqQE1xeP/5WwROi9XZHz85I7aOd5/aR8IGFcK8DPPLB1SVUY+CZZIYTlSRcY YLwDFRKwumI0BZsaEsuVnQaJvtzXL9rfFh44q0IsduwsW+MTLenpJdHMjM4vK8ngvuQV kU1X2Y7k3YLtoYmylaU1jjKG8DcvdsWIjfUoZ0zDRvRtoNQJyOSQOaccf5+GEEHp2S9q 3b9cJiDioBnQdKkjuk2sQpAcK3X+xFWuHclYJ7jkMkOj0adQZaxX99UxDkdpv/OUtyGY Y1KOPKptuqFtx0+DYvEr4SnwSdnT0tgvFJk965Qv5DVvp2wpbj7ZQR852o3BxevgPf2C yZwA== 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; bh=lamDOo+YZ70xEYgvAxaVbO72OIKKSLrd9VWu/Mlbkng=; b=envaMJrNlJL849XlagU8cWT3y2P0CZ5/yoizKvMQ/qLbaFPOa7ZsQR/4wwtufLQCDT 4QLxnq3pDTWhW6V/pPCwjIVAKrtbl7+EGr9Q7LEjtyHhKp9hN/wwWLNfZQO2eBzMFUhY IX/veuBNjNAe2f7I4QnBXn9ojy88IYiTLQ49fGXAahimdlIou8L7gWHjdTPCoruh+Diz f9V2s49AhQSREmtQntL3H8LDx5kXcDI9KgJ5W+L/JdQzeUAKPyneUR0hWriW3BOZCf8J vA+ZJF4vGwNK7htjprU8bSvB2AMP+hHH1iJIEHi9EXkl3jjR/GdwjldeNg4etT5zwskN vEBg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-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 w23si244054qtn.255.2020.04.09.17.29.16; Thu, 09 Apr 2020 17:29:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-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-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726871AbgDJA1n (ORCPT + 99 others); Thu, 9 Apr 2020 20:27:43 -0400 Received: from mail105.syd.optusnet.com.au ([211.29.132.249]:54089 "EHLO mail105.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726867AbgDJA1n (ORCPT ); Thu, 9 Apr 2020 20:27:43 -0400 Received: from dread.disaster.area (pa49-180-167-53.pa.nsw.optusnet.com.au [49.180.167.53]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 4E4F63A2DB2; Fri, 10 Apr 2020 10:27:39 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1jMhWD-00061P-Vl; Fri, 10 Apr 2020 10:27:37 +1000 Date: Fri, 10 Apr 2020 10:27:37 +1000 From: Dave Chinner To: Christoph Hellwig Cc: Ira Weiny , linux-kernel@vger.kernel.org, "Darrick J. Wong" , Dan Williams , "Theodore Y. Ts'o" , Jan Kara , Jeff Moyer , linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH V6 6/8] fs/xfs: Combine xfs_diflags_to_linux() and xfs_diflags_to_iflags() Message-ID: <20200410002737.GT24067@dread.disaster.area> References: <20200407182958.568475-1-ira.weiny@intel.com> <20200407182958.568475-7-ira.weiny@intel.com> <20200408020827.GI24067@dread.disaster.area> <20200408170923.GC569068@iweiny-DESK2.sc.intel.com> <20200408210236.GK24067@dread.disaster.area> <20200408220734.GA664132@iweiny-DESK2.sc.intel.com> <20200408232106.GO24067@dread.disaster.area> <20200409001206.GD664132@iweiny-DESK2.sc.intel.com> <20200409004921.GS24067@dread.disaster.area> <20200409124031.GA18171@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200409124031.GA18171@lst.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=LYdCFQXi c=1 sm=1 tr=0 a=2xmR08VVv0jSFCMMkhec0Q==:117 a=2xmR08VVv0jSFCMMkhec0Q==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=cl8xLZFz6L8A:10 a=VwQbUJbxAAAA:8 a=7-415B0cAAAA:8 a=QVMKFbu1P_vDNoMgm84A:9 a=CjuIK1q_8ugA:10 a=AjGcO6oz07-iQ99wixmX:22 a=biEYGPWJfzWAr4FL6Ov7:22 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Apr 09, 2020 at 02:40:31PM +0200, Christoph Hellwig wrote: > On Thu, Apr 09, 2020 at 10:49:21AM +1000, Dave Chinner wrote: > > > Christoph did say: > > > > > > "A reasonably smart application can try to evict itself." > > > > > > -- https://lore.kernel.org/lkml/20200403072731.GA24176@lst.de/ > > > > I'd love to know how an unprivileged application can force the > > eviction of an inode from cache. > > Where did the "unprivileged" suddenly come from? I'm assuming that applications are being run without the root permissions needed to run drop_caches. i.e. the apps are unprivileged, and therefore can't brute force inode cache eviction. That's why I'm asking what mechanism these applications are using to evict inodes on demand without requiring elevated privileges, because I can't see how they'd acheive this... Cheers, Dave. -- Dave Chinner david@fromorbit.com