From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756139AbdKCQC3 convert rfc822-to-8bit (ORCPT ); Fri, 3 Nov 2017 12:02:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49688 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752323AbdKCQC2 (ORCPT ); Fri, 3 Nov 2017 12:02:28 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BF800C0587FF Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlureau@redhat.com Date: Fri, 3 Nov 2017 12:02:26 -0400 (EDT) From: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau To: Mike Kravetz Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, aarcange@redhat.com, hughd@google.com, nyc@holomorphy.com Message-ID: <847029229.35880816.1509724946936.JavaMail.zimbra@redhat.com> In-Reply-To: References: <20171031184052.25253-1-marcandre.lureau@redhat.com> <20171031184052.25253-3-marcandre.lureau@redhat.com> Subject: Re: [PATCH 2/6] shmem: rename functions that are memfd-related MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [10.36.112.63, 10.4.195.15] Thread-Topic: shmem: rename functions that are memfd-related Thread-Index: 5Rvsr/R+VWJpkdjKolWRb9A4wNfR7w== X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 03 Nov 2017 16:02:27 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi ----- Original Message ----- > On 10/31/2017 11:40 AM, Marc-André Lureau wrote: > > Those functions are called for memfd files, backed by shmem or > > hugetlb (the next patches will handle hugetlb). > > > > Signed-off-by: Marc-André Lureau > > --- > > fs/fcntl.c | 2 +- > > include/linux/shmem_fs.h | 4 ++-- > > mm/shmem.c | 10 +++++----- > > 3 files changed, 8 insertions(+), 8 deletions(-) > > > > diff --git a/fs/fcntl.c b/fs/fcntl.c > > index 448a1119f0be..752c23743616 100644 > > --- a/fs/fcntl.c > > +++ b/fs/fcntl.c > > @@ -417,7 +417,7 @@ static long do_fcntl(int fd, unsigned int cmd, unsigned > > long arg, > > break; > > case F_ADD_SEALS: > > case F_GET_SEALS: > > - err = shmem_fcntl(filp, cmd, arg); > > + err = memfd_fcntl(filp, cmd, arg); > > break; > > case F_GET_RW_HINT: > > case F_SET_RW_HINT: > > diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h > > index 557d0c3b6eca..0dac8c0f4aa4 100644 > > --- a/include/linux/shmem_fs.h > > +++ b/include/linux/shmem_fs.h > > @@ -109,11 +109,11 @@ extern void shmem_uncharge(struct inode *inode, long > > pages); > > > > #ifdef CONFIG_TMPFS > > > > -extern long shmem_fcntl(struct file *file, unsigned int cmd, unsigned long > > arg); > > +extern long memfd_fcntl(struct file *file, unsigned int cmd, unsigned long > > arg); > > > > #else > > > > -static inline long shmem_fcntl(struct file *f, unsigned int c, unsigned > > long a) > > +static inline long memfd_fcntl(struct file *f, unsigned int c, unsigned > > long a) > > { > > return -EINVAL; > > } > > Do we want memfd_fcntl() to work for hugetlbfs if CONFIG_TMPFS is not > defined? I admit that having CONFIG_HUGETLBFS defined without CONFIG_TMPFS > is unlikely, but I think possible. Based on the above #ifdef/#else, I > think hugetlbfs seals will not work if CONFIG_TMPFS is not defined. Good point, memfd_create() will not exists either. I think this is a separate concern, and preexisting from this patch series though. Ack the function renaming part? > -- > Mike Kravetz > > > diff --git a/mm/shmem.c b/mm/shmem.c > > index 37260c5e12fa..b7811979611f 100644 > > --- a/mm/shmem.c > > +++ b/mm/shmem.c > > @@ -2722,7 +2722,7 @@ static int shmem_wait_for_pins(struct address_space > > *mapping) > > F_SEAL_GROW | \ > > F_SEAL_WRITE) > > > > -static int shmem_add_seals(struct file *file, unsigned int seals) > > +static int memfd_add_seals(struct file *file, unsigned int seals) > > { > > struct inode *inode = file_inode(file); > > struct shmem_inode_info *info = SHMEM_I(inode); > > @@ -2792,7 +2792,7 @@ static int shmem_add_seals(struct file *file, > > unsigned int seals) > > return error; > > } > > > > -static int shmem_get_seals(struct file *file) > > +static int memfd_get_seals(struct file *file) > > { > > if (file->f_op != &shmem_file_operations) > > return -EINVAL; > > @@ -2800,7 +2800,7 @@ static int shmem_get_seals(struct file *file) > > return SHMEM_I(file_inode(file))->seals; > > } > > > > -long shmem_fcntl(struct file *file, unsigned int cmd, unsigned long arg) > > +long memfd_fcntl(struct file *file, unsigned int cmd, unsigned long arg) > > { > > long error; > > > > @@ -2810,10 +2810,10 @@ long shmem_fcntl(struct file *file, unsigned int > > cmd, unsigned long arg) > > if (arg > UINT_MAX) > > return -EINVAL; > > > > - error = shmem_add_seals(file, arg); > > + error = memfd_add_seals(file, arg); > > break; > > case F_GET_SEALS: > > - error = shmem_get_seals(file); > > + error = memfd_get_seals(file); > > break; > > default: > > error = -EINVAL; > > > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org >