From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB75EC433DF for ; Fri, 12 Jun 2020 01:58:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7BD45206DC for ; Fri, 12 Jun 2020 01:58:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7BD45206DC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 23CCA8D00AD; Thu, 11 Jun 2020 21:58:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EDD28D00A0; Thu, 11 Jun 2020 21:58:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12B078D00AD; Thu, 11 Jun 2020 21:58:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0097.hostedemail.com [216.40.44.97]) by kanga.kvack.org (Postfix) with ESMTP id F108C8D00A0 for ; Thu, 11 Jun 2020 21:58:50 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id ADE0C1EE6 for ; Fri, 12 Jun 2020 01:58:50 +0000 (UTC) X-FDA: 76918901220.09.veil07_030286b26dd8 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id 89479180AD838 for ; Fri, 12 Jun 2020 01:58:50 +0000 (UTC) X-HE-Tag: veil07_030286b26dd8 X-Filterd-Recvd-Size: 2450 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Fri, 12 Jun 2020 01:58:50 +0000 (UTC) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.93 #3 (Red Hat Linux)) id 1jjYxu-007MwO-TA; Fri, 12 Jun 2020 01:58:42 +0000 Date: Fri, 12 Jun 2020 02:58:42 +0100 From: Al Viro To: Mike Kravetz Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, overlayfs , linux-kernel@vger.kernel.org, Miklos Szeredi , Matthew Wilcox , Colin Walters , Andrew Morton , syzbot , syzkaller-bugs Subject: Re: [PATCH v4 1/2] hugetlb: use f_mode & FMODE_HUGETLBFS to identify hugetlbfs files Message-ID: <20200612015842.GC23230@ZenIV.linux.org.uk> References: <20200612004644.255692-1-mike.kravetz@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200612004644.255692-1-mike.kravetz@oracle.com> X-Rspamd-Queue-Id: 89479180AD838 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jun 11, 2020 at 05:46:43PM -0700, Mike Kravetz wrote: > The routine is_file_hugepages() checks f_op == hugetlbfs_file_operations > to determine if the file resides in hugetlbfs. This is problematic when > the file is on a union or overlay. Instead, define a new file mode > FMODE_HUGETLBFS which is set when a hugetlbfs file is opened. The mode > can easily be copied to other 'files' derived from the original hugetlbfs > file. > > With this change hugetlbfs_file_operations can be static as it should be. > > There is also a (duplicate) set of shm file operations used for the routine > is_file_shm_hugepages(). Instead of setting/using special f_op's, just > propagate the FMODE_HUGETLBFS mode. This means is_file_shm_hugepages() and > the duplicate f_ops can be removed. s/HUGETLBFS/HUGEPAGES/, please. > While cleaning things up, change the name of is_file_hugepages() to > is_file_hugetlbfs(). The term hugepages is a bit ambiguous. Don't, especially since the very next patch adds such on overlayfs... Incidentally, can a hugetlbfs be a lower layer, while the upper one is a normal filesystem? What should happen on copyup?