[lkml]   [2017]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 0/3] restructure memfd code
On 11/21/2017 08:32 AM, Khalid Aziz wrote:
> On Wed, 2017-11-08 at 17:41 -0800, Mike Kravetz wrote:
>> With the addition of memfd hugetlbfs support, we now have the
>> situation
>> where memfd depends on TMPFS -or- HUGETLBFS. Previously, memfd was
>> only
>> supported on tmpfs, so it made sense that the code resides in
>> shmem.c.
>> This patch series moves the memfd code to separate files (memfd.c and
>> memfd.h). It creates a new config option MEMFD_CREATE that is
>> defined
>> if either TMPFS or HUGETLBFS is defined.
>> In the current code, memfd is only functional if TMPFS is
>> defined. If
>> HUGETLFS is defined and TMPFS is not defined, then memfd
>> functionality
>> will not be available for hugetlbfs. This does not cause BUGs, just
>> a
>> potential lack of desired functionality.
>> Another way to approach this issue would be to simply make HUGETLBFS
>> depend on TMPFS.
>> This patch series is built on top of the Marc-André Lureau v3 series
>> "memfd: add sealing to hugetlb-backed memory":
>> Mike Kravetz (3):
>> mm: hugetlbfs: move HUGETLBFS_I outside #ifdef CONFIG_HUGETLBFS
>> mm: memfd: split out memfd for use by multiple filesystems
>> mm: memfd: remove memfd code from shmem files and use new memfd
>> files
> Hi Mike,
> This looks like a useful change. After applying patch 2, you end up
> with duplicate definitions of number of symbols though. Although those
> duplicates will not cause compilation problems since memfd.c is not
> compiled until after patch 3 has been applied, would it make more sense
> to combine moving of all code in one patch?

Thanks Khalid,

I was aware of this situation when creating the patch. It was broken out
as above simply to make it easier to review/understand. Not sure if that
is actually the case. The other option was as you suggested to simply
combine the add/remove as a single patch.

I am somewhat waiting to see how Marc-André Lureau's file sealing series
progresses as this series touches the same code.
Mike Kravetz

 \ /
  Last update: 2017-11-22 01:40    [W:0.052 / U:8.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site