On 08/13/2018 03:58 AM, Kirill A. Shutemov wrote:
> On Sun, Aug 12, 2018 at 08:41:08PM -0700, Mike Kravetz wrote:
>> The page migration code employs try_to_unmap() to try and unmap the
>> source page. This is accomplished by using rmap_walk to find all
>> vmas where the
dde65c9940 ("shared page table for hugetlb page")
Signed-off-by: Mike Kravetz
---
v2: Fixed build issue for !CONFIG_HUGETLB_PAGE and typos in comment
include/linux/hugetlb.h | 6 ++
mm/rmap.c | 21 +
2 files changed, 27 insertions(+)
diff --git a/inclu
range is flushed if
huge_pmd_unshare succeeds and unmaps a PUD_SUZE area.
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 53 +++-
1 file changed, 44 insertions(+), 9 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index fd155dc52117
page")
Cc: sta...@vger.kernel.org
Signed-off-by: Mike Kravetz
---
include/linux/hugetlb.h | 14 ++
mm/hugetlb.c| 40 +++
mm/rmap.c | 42 ++---
3 files changed, 93 insertions(+), 3 deleti
advantage of the new routine
huge_pmd_sharing_possible() to adjust flushing ranges in the cases
where huge PMD sharing is possible. There is no copy to stable for this
patch as it has not been reported as an issue and discovered only via
code inspection.
Mike Kravetz (2):
mm: migration: fix migration of
te to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Mike-Kravetz/huge_pmd_unshare-migration-and-flushing/20180822-050255
> config: i386-tinyconfig (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> #
te to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Mike-Kravetz/huge_pmd_unshare-migration-and-flushing/20180822-050255
> config: sparc64-allyesconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2
ration of huge PMD shared pages issue. That is sort
of a Tested-by :).
Just wanted to point out that it was pretty easy to hit this issue. It
was easier than the issue I am working. And, the issue I am trying to
address was seen in a real customer environment. So, I would not be
surprised to see this issue in real customer environments as well.
If you (or others) think we should go forward with these patches, I can
spend some time doing a review. Already did a 'quick look' some time back.
--
Mike Kravetz
On 08/22/2018 05:28 AM, Michal Hocko wrote:
> On Tue 21-08-18 18:10:42, Mike Kravetz wrote:
> [...]
>> diff --git a/mm/rmap.c b/mm/rmap.c
>> index eb477809a5c0..8cf853a4b093 100644
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -1362,11 +1362,21 @@ static boo
On 08/22/2018 02:05 PM, Kirill A. Shutemov wrote:
> On Tue, Aug 21, 2018 at 06:10:42PM -0700, Mike Kravetz wrote:
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 3103099f64fd..f085019a4724 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -4555,6 +45
On 08/23/2018 01:21 AM, Kirill A. Shutemov wrote:
> On Thu, Aug 23, 2018 at 09:30:35AM +0200, Michal Hocko wrote:
>> On Wed 22-08-18 09:48:16, Mike Kravetz wrote:
>>> On 08/22/2018 05:28 AM, Michal Hocko wrote:
>>>> On Tue 21-08-18 18:10:42, Mike Kravetz wrote:
&g
On 08/23/2018 05:48 AM, Michal Hocko wrote:
> On Tue 21-08-18 18:10:42, Mike Kravetz wrote:
> [...]
>
> OK, after burning myself when trying to be clever here it seems like
> your proposed solution is indeed simpler.
>
>> +bool huge_pmd_sharing_possible(st
On 08/23/2018 10:01 AM, Mike Kravetz wrote:
> On 08/23/2018 05:48 AM, Michal Hocko wrote:
>> On Tue 21-08-18 18:10:42, Mike Kravetz wrote:
>> [...]
>>
>> OK, after burning myself when trying to be clever here it seems like
>> your proposed solutio
that this range is flushed
if huge_pmd_unshare succeeds and unmaps a PUD_SUZE area.
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 53 +++-
1 file changed, 44 insertions(+), 9 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index
routine as suggested by
Kirill.
v3-v5: Address build errors if !CONFIG_HUGETLB_PAGE and
!CONFIG_ARCH_WANT_HUGE_PMD_SHARE
Mike Kravetz (2):
mm: migration: fix migration of huge PMD shared pages
hugetlb: take PMD sharing into account when flushing tlb/caches
include/linux/huge
page")
Cc: sta...@vger.kernel.org
Signed-off-by: Mike Kravetz
---
include/linux/hugetlb.h | 14 ++
mm/hugetlb.c| 40 +--
mm/rmap.c | 42 ++---
3 files changed, 91 insertions(+), 5 deleti
On 08/24/2018 01:41 AM, Michal Hocko wrote:
> On Thu 23-08-18 13:59:16, Mike Kravetz wrote:
>
> Acked-by: Michal Hocko
>
> One nit below.
>
> [...]
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 3103099f64fd..a73c5728e961 100644
>> --- a/mm/hugetl
On 07/05/2018 04:07 AM, Alexandre Ghiti wrote:
> arm, arm64, ia64, parisc, powerpc, sh, sparc, x86 architectures
> use the same version of huge_pte_none, so move this generic
> implementation into asm-generic/hugetlb.h.
>
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> Signed-of
add. We do
>> initialize the rest explicitly already.
>
> Forgot to mention that after that is addressed you can add
> Acked-by: Michal Hocko
Cannon,
How about if you make this change suggested by Michal, and I will submit
a separate patch to revert the patch which added the phys field to
huge_bootmem_page structure.
FWIW,
Reviewed-by: Mike Kravetz
--
Mike Kravetz
line").
There are no users of this field and supporting code, so remove it.
Signed-off-by: Mike Kravetz
---
include/linux/hugetlb.h | 3 ---
mm/hugetlb.c| 9 +
2 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.
On 07/11/2018 01:57 PM, Davidlohr Bueso wrote:
> On Wed, 11 Jul 2018, Mike Kravetz wrote:
>
>> This reverts commit ee8f248d266e ("hugetlb: add phys addr to struct
>> huge_bootmem_page")
>>
>> At one time powerpc used this field and supporting code.
unt of time as with 0, as opposed to the 25+
> minutes it would take before.
>
> Signed-off-by: Cannon Matthews
Thanks,
Acked-by: Mike Kravetz
--
Mike Kravetz
> ---
> v2: removed the memset of the huge_bootmem_page area and added
> INIT_LIST_HEAD instead.
>
> mm/hugetlb.c
+ *entry properly works, and
> + * - other mm code walking over page table is aware of pud-aligned
> + *hwpoison entries.
> + */
> + if (huge_page_size(page_hstate(head)) > PMD_SIZE) {
> + action_result(pfn, MF_MSG_NON_PMD_HUGE, MF_IGNORED
Remove memfd and file sealing routines from shmem.c, and enable
the use of the new files (memfd.c and memfd.h).
A new config option MEMFD_CREATE is defined that is enabled if
TMPFS -or- HUGETLBFS is enabled.
Signed-off-by: Mike Kravetz
---
fs/Kconfig | 3 +
fs/fcntl.c
applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Mike-Kravetz/restructure-memfd-code/20180131-023405
> base: git://git.cmpxchg.org/linux-mmotm.git master
> reproduce:
> # apt-
-off-by: Mike Kravetz
---
include/linux/memfd.h | 16 +++
mm/memfd.c| 342 ++
2 files changed, 358 insertions(+)
create mode 100644 include/linux/memfd.h
create mode 100644 mm/memfd.c
diff --git a/include/linux/memfd.h b/include/linux
HUGETLBFS_I will be referenced (but not used) in code outside #ifdef
CONFIG_HUGETLBFS. Move the definition to prevent compiler errors.
Signed-off-by: Mike Kravetz
---
include/linux/hugetlb.h | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a
of more than MAX_ORDER contiguous pages?".
Not sure that we should be adding to the current alloc_contig_range
interface until we decide it is something which will be useful long term.
--
Mike Kravetz
this was sent as a RFC, one comment suggested combining patches 2
and 3 so that we would not have 'new unused' files between patches. If
this is desired, I can make the change. For me, it is easier to read
as separate patches.
v2:
- Fixed sparse warnings inherited from existing code
he 1st madvise() event.
>
> Do pgd size pages work properly?
Adding Anshuman and Aneesh as they added pgd support for power. And,
this patch will disable that as well IIUC.
This patch makes sense for x86. My only concern/question is for other
archs which may have huge page sizes defined w
- hugetlbfs, split out the required
memfd code to separate files.
These files are not used until a subsequent patch which deletes
duplicate code in the orifinal files and enables their use.
Signed-off-by: Mike Kravetz
---
include/linux/memfd.h | 16 +++
mm/memfd.c| 341
Remove memfd and file sealing routines from shmem.c, and enable
the use of the new files (memfd.c and memfd.h).
A new config option MEMFD_CREATE is defined that is enabled if
TMPFS -or- HUGETLBFS is enabled.
Signed-off-by: Mike Kravetz
---
fs/Kconfig | 3 +
fs/fcntl.c
HUGETLBFS_I will be referenced (but not used) in code outside #ifdef
CONFIG_HUGETLBFS. Move the definition to prevent compiler errors.
Signed-off-by: Mike Kravetz
---
include/linux/hugetlb.h | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a
this was sent as a RFC, one comment suggested combining patches 2
and 3 so that we would not have 'new unused' files between patches. If
this is desired, I can make the change. For me, it is easier to read
as separate patches.
Mike Kravetz (3):
mm: hugetlbfs: move HUGETLBFS_I
t this new functionality.
Signed-off-by: Mike Kravetz
---
Changes in v2
* Updated commit message and comments as suggested by Andrew Morton
mm/page_alloc.c | 8
mm/page_isolation.c | 18 +-
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/mm/page_al
On 03/02/2018 05:39 PM, Mike Kravetz wrote:
> On 03/02/2018 04:56 PM, Andrew Morton wrote:
>> On Fri, 2 Mar 2018 16:38:33 -0800 Mike Kravetz
>> wrote:
>>
>>> On 03/02/2018 04:06 PM, Andrew Morton wrote:
>>>> On Mon, 26 Feb 201
On 04/12/2018 01:40 PM, Reinette Chatre wrote:
> Hi Mike,
>
> On 2/15/2018 12:22 PM, Reinette Chatre wrote:
>> On 2/12/2018 2:20 PM, Mike Kravetz wrote:
>>> These patches came out of the "[RFC] mmap(MAP_CONTIG)" discussions at:
>>> http://lkml.ker
s
created via shmget/shmat have their vm_ops replaced. Therefore, this
split callout is never made.
The shm vm_ops do indirectly call the original vm_ops routines as needed.
Therefore, I would suggest a patch something like the following instead.
If we move forward with the patch, we should inclu
On 03/20/2018 02:26 PM, Mike Kravetz wrote:
> Thanks Laurent!
>
> This bug was introduced by 31383c6865a5. Dan's changes for 31383c6865a5
> seem pretty straight forward. It simply replaces an explicit check when
> splitting a vma to a new vm_ops split callout. Unfortunately
gt;split() to
vm_operations_struct")
Signed-off-by: Mike Kravetz
Reported by: Laurent Dufour
Tested-by: Laurent Dufour
Acked-by: Michal Hocko
Cc: sta...@vger.kernel.org
---
Changes in v2
* Updated commit message
* Cc stable
ipc/shm.c | 12
1 file changed, 12 insertions(+
On 03/21/2018 01:56 PM, Andrew Morton wrote:
> On Wed, 21 Mar 2018 09:13:14 -0700 Mike Kravetz
> wrote:
>>
>> +static int shm_split(struct vm_area_struct *vma, unsigned long addr)
>> +{
>> +struct file *file = vma->vm_file;
>> +struct
hmem.c are fixed
in patch 1. Patch 2 updates comments and file checking such that patch
3 is only code movement.
Mike Kravetz (3):
mm/shmem: add __rcu annotations and properly deref radix entry
mm/shmem: update file sealing comments and file checking
mm: restructure memfd code
-off-by: Mike Kravetz
---
mm/shmem.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index c7bad16fe884..be20fc388dcb 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2734,11 +2734,11 @@ static int shmem_wait_for_pins(struct
changes are made to the code: restructuring only.
Signed-off-by: Mike Kravetz
---
fs/Kconfig | 3 +
fs/fcntl.c | 2 +-
include/linux/memfd.h| 16 +++
include/linux/shmem_fs.h | 13 --
mm/Makefile | 1 +
mm/memfd.c | 344
In preparation for memfd code restucture, clean up sparse warnings.
Most changes required adding __rcu annotations. The routine
find_swap_entry was modified to properly deference radix tree
entries.
Signed-off-by: Mike Kravetz
Signed-off-by: Matthew Wilcox
---
mm/shmem.c | 20
On 04/09/2018 06:41 PM, Matthew Wilcox wrote:
> On Mon, Apr 09, 2018 at 04:05:05PM -0700, Mike Kravetz wrote:
>> +/*
>> + * We need a tag: a new tag would expand every radix_tree_node by 8 bytes,
>> + * so reuse a tag which we firmly believe is never set or cleared on shmem
>From f9f98e0d6fd87af4b48befbad757467f834a868c Mon Sep 17 00:00:00 2001
From: Mike Kravetz
Date: Mon, 9 Apr 2018 13:04:38 -0700
Subject: [PATCH 2/3] mm/shmem: update file sealing comments and file checking
In preparation for memfd code restructure, update comments,
definitions and function names dealing with file sealing to
indic
On 04/09/2018 08:03 PM, Mike Kravetz wrote:
> On 04/09/2018 06:41 PM, Matthew Wilcox wrote:
>> On Mon, Apr 09, 2018 at 04:05:05PM -0700, Mike Kravetz wrote:
>>> +/*
>>> + * We need a tag: a new tag would expand every radix_tree_node by 8 bytes,
>>> + * so re
off-by: Mike Kravetz
---
fs/hugetlbfs/inode.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 8fe1b0aa2896..cb288dec5564 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -127,12 +127,13 @@ static
On 03/07/2018 05:35 PM, Yisheng Xie wrote:
> Hi Mike,
>
> On 2018/3/8 7:59, Mike Kravetz wrote:
>> A vma with vm_pgoff large enough to overflow a loff_t type when
>> converted to a byte offset can be passed via the remap_file_pages
>> system call. The hugetlbfs mmap r
On 03/07/2018 08:25 PM, Mike Kravetz wrote:
> On 03/07/2018 05:35 PM, Yisheng Xie wrote:
>> However, region_chg makes me a litter puzzle that when its return value < 0,
>> sometime
>> adds_in_progress is added like this case, while sometime it is not. so why
>
his code was incomplete and did not
take the remap_file_pages system call into account.
Fixes: 045c7a3f53d9 ("hugetlbfs: fix offset overflow in hugetlbfs mmap")
Cc:
Reported-by: Nic Losby
Signed-off-by: Mike Kravetz
---
Changes in v2
* Use bitmask for overflow check as suggested b
On 03/08/2018 02:15 PM, Andrew Morton wrote:
> On Thu, 8 Mar 2018 13:05:02 -0800 Mike Kravetz
> wrote:
>
>> A vma with vm_pgoff large enough to overflow a loff_t type when
>> converted to a byte offset can be passed via the remap_file_pages
>> system call. The huge
his code was incomplete and did not
take the remap_file_pages system call into account.
Fixes: 045c7a3f53d9 ("hugetlbfs: fix offset overflow in hugetlbfs mmap")
Cc:
Reported-by: Nic Losby
Signed-off-by: Mike Kravetz
---
Changes in v3
* Use a simpler mask computation as suggested by
On 03/13/2018 02:14 PM, Andrew Morton wrote:
> On Fri, 9 Mar 2018 14:47:31 -0800 Mike Kravetz
> wrote:
>
>> start_isolate_page_range() is used to set the migrate type of a
>> set of pageblocks to MIGRATE_ISOLATE while attempting to start
>> a migration operation
e host system (and some other changes).
To me, this seems like step in the wrong direction. But, I could
be totally wrong and perhaps self tests should primarily target the
host system header files.
--
Mike Kravetz
gt;
>> Signed-off-by: Yongkai Wu
>> Acked-by: Michal Hocko
>> Acked-by: Mike Kravetz
Thank you for fixing the formatting and commit message.
Adding Andrew on so he can add to his tree as appropriatre. Also Cc'ing Michal.
>> ---
>> mm/hugetlb.c | 5 +++--
&g
ation to the
change log (commit message) and fix the formatting of the patch.
Can you tell us more about the root cause of your issue? What was the issue?
How could you reproduce it? How did you solve it?
--
Mike Kravetz
dition, callers
of huge_pte_alloc continue to hold the semaphore until finished with
the ptep.
- i_mmap_rwsem is held in write mode whenever huge_pmd_unshare is called.
Cc:
Fixes: 39dde65c9940 ("shared page table for hugetlb page")
Signed-off-by: Mike Kravetz
t eliminate the race. i_mmap_rwsem is now held in read
mode for the duration of page fault processing. Hold i_mmap_rwsem
longer in truncation and hold punch code to cover the call to
remove_inode_hugepages.
Cc:
Fixes: ebed4bfc8da8 ("hugetlb: fix absurd HugePages_Rsvd")
Signed-off-by: M
After expanding i_mmap_rwsem use for better shared pmd and page fault/
truncation synchronization, remove code that is no longer necessary.
Cc:
Fixes: ebed4bfc8da8 ("hugetlb: fix absurd HugePages_Rsvd")
Signed-off-by: Mike Kravetz
---
fs/hugetlbfs/in
o separate patches addressing each issue.
Hopefully, this is easier to understand/review.
Mike Kravetz (3):
hugetlbfs: use i_mmap_rwsem for more pmd sharing synchronization
hugetlbfs: Use i_mmap_rwsem to fix page fault/truncate race
hugetlbfs: remove unnecessary code after i_mmap_rwsem synchroniz
n't find any code that sets phys.
Although, it is potentially used in gather_bootmem_prealloc(). It appears
powerpc used this field at one time, but no longer does.
Am I missing something?
Not an issue with this patch, rather existing code. I'd prefer not to do
the memset(
tfd is/can be enabled for impacted architectures.
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> ---
> fs/userfaultfd.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index 123bf7d516fc..594d192b2331 1006
off-by: Cannon Matthews
My only suggestion would be to remove the mention of 2M pages in the
commit message. Thanks for adding this.
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> ---
> mm/hugetlb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
&
allocator.
I really do not think hugetlbfs overcommit will provide any benefit over
THP for your use case. Also, new user space code is required to "fall back"
to normal pages in the case of hugetlbfs page allocation failure. This
is not needed in the THP case.
--
Mike Kravetz
er inline support of the compilers,
> the indirect call will be optimized to be the direct call. Our tests
> show no performance change with the patch.
>
> This patch is a code cleanup without functionality change.
>
> Signed-off-by: "Huang, Ying"
> Suggested-by:
ry area from the begin to the end, so
> cause copy on write. For each child process, other child processes
> could be seen as other workloads which generate heavy cache pressure.
> At the same time, the IPC (instruction per cycle) increased from 0.63
> to 0.78, and the time spent in user sp
> the "address" is renamed to "haddr" in hugetlb_cow() in this patch.
> Next patch will use target subpage address in hugetlb_cow() too.
>
> The patch is just code cleanup without any functionality changes.
>
> Signed-off-by: "Huang, Ying"
> Suggested-
ge after the page fault under heavy cache contention.
>
> Signed-off-by: "Huang, Ying"
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> Cc: Mike Kravetz
> Cc: Michal Hocko
> Cc: David Rientjes
> Cc: Andrea Arcangeli
> Cc: "Kirill A. Shutemov"
> Cc: Andi
DONE
> ok 1..2 selftests: memfd: run_fuse_test.sh [PASS]
> selftests: memfd: run_hugetlbfs_test.sh
>
> Please run memfd with hugetlbfs test as root
> not ok 1..3 selftests: memfd: run_hugetlbfs_test.sh [SKIP]
>
> Signed-off-by: Shuah Khan (Samsung OSG)
Thanks for all your
On 05/30/2018 01:02 AM, Michal Hocko wrote:
> On Tue 29-05-18 15:21:14, Mike Kravetz wrote:
>> Just a quick heads up. I noticed a change in libhugetlbfs testing starting
>> with v4.17-rc1.
>>
>> V4.16 libhugetlbfs test results
>> ** TEST SUM
nmapped the overlapping page. However, this does not seem right.
--
Mike Kravetz
ection. Unlike the case in ad55eac74f20, the access
permissions on section 1 (RE) are different than section 2 (RW). If we
allowed the previous MAP_FIXED behavior, we would be changing part of a
read only section to read write. This is exactly what MAP_FIXED_NOREPLACE
was designed to prevent.
--
Mike Kravetz
oad which generates heavy cache
> pressure. At the same time, the cache miss rate reduced from ~36.3%
> to ~25.6%, the IPC (instruction per cycle) increased from 0.3 to 0.37,
> and the time spent in user space is reduced ~19.3%.
>
Agree with Michal that commit message looks better.
r in which sub-pages are to be copied. IIUC, you
added the same algorithm for sub-page ordering to copy_huge_page()
that was previously added to clear_huge_page(). Correct? If so,
then perhaps a common helper could be used by both the clear and copy
huge page routines. It would also make maintenance easier.
--
Mike Kravetz
On 05/18/2018 02:12 AM, Vlastimil Babka wrote:
> On 05/04/2018 01:29 AM, Mike Kravetz wrote:
>> free_contig_range() is currently defined as:
>> void free_contig_range(unsigned long pfn, unsigned nr_pages);
>> change to,
>> void free_contig_range(unsigned long
. hugetlb.c and hugetlb.h are
not 100% hugetlbfs, but a majority of their content is hugetlbfs
related.
Signed-off-by: Mike Kravetz
---
MAINTAINERS | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9051a9ca24a2..c7a5eb074eb1 100644
--- a
On 08/14/2018 01:48 AM, Kirill A. Shutemov wrote:
> On Mon, Aug 13, 2018 at 11:21:41PM +0000, Mike Kravetz wrote:
>> On 08/13/2018 03:58 AM, Kirill A. Shutemov wrote:
>>> On Sun, Aug 12, 2018 at 08:41:08PM -0700, Mike Kravetz wrote:
>>>> I am not %100 sure on the req
On 12/17/18 2:25 AM, Aneesh Kumar K.V wrote:
> On 12/4/18 1:38 AM, Mike Kravetz wrote:
>> hugetlbfs page faults can race with truncate and hole punch operations.
>> Current code in the page fault path attempts to handle this by 'backing
>> out' operations if we e
Tkhai
Thanks for cleaning this up!
Reviewed-by: Mike Kravetz
--
Mike Kravetz
On 12/17/18 10:42 AM, Mike Kravetz wrote:
> On 12/17/18 2:25 AM, Aneesh Kumar K.V wrote:
>> On 12/4/18 1:38 AM, Mike Kravetz wrote:
>>>
>>> Instead of writing the required complicated code for this rare
>>> occurrence, just eliminate the race. i_mmap_rwsem
On 12/18/18 2:10 PM, Andrew Morton wrote:
> On Mon, 17 Dec 2018 16:17:52 -0800 Mike Kravetz
> wrote:
>
>> ...
>>
>>> As you suggested in a comment to the subsequent patch, it would be better to
>>> combine the patches and remove the dead code when it
7-1-mike.krav...@oracle.com
Comments made by Naoya were addressed.
Mike Kravetz (2):
hugetlbfs: use i_mmap_rwsem for more pmd sharing synchronization
hugetlbfs: Use i_mmap_rwsem to fix page fault/truncate race
fs/hugetlbfs/inode.c | 50 +
mm/hugetlb.c
dition, callers
of huge_pte_alloc continue to hold the semaphore until finished with
the ptep.
- i_mmap_rwsem is held in write mode whenever huge_pmd_unshare is called.
Cc:
Fixes: 39dde65c9940 ("shared page table for hugetlb page")
Signed-off-by: Mike Kravetz
7; as it can not longer happen. Remove the dead code
and expand comments to explain reasoning. Similarly, checks for races
with truncation in the page fault path can be simplified and removed.
Cc:
Fixes: ebed4bfc8da8 ("hugetlb: fix absurd HugePages_Rsvd")
Signed-off-by: Mike
On 12/21/18 2:05 AM, Kirill A. Shutemov wrote:
> On Tue, Dec 18, 2018 at 02:35:56PM -0800, Mike Kravetz wrote:
>> While looking at BUGs associated with invalid huge page map counts,
>> it was discovered and observed that a huge pte pointer could become
>> 'invalid' a
On 12/21/18 2:28 AM, Kirill A. Shutemov wrote:
> On Tue, Dec 18, 2018 at 02:35:57PM -0800, Mike Kravetz wrote:
>> Instead of writing the required complicated code for this rare
>> occurrence, just eliminate the race. i_mmap_rwsem is now held in read
>> mode for the d
On 12/21/18 12:21 PM, Kirill A. Shutemov wrote:
> On Fri, Dec 21, 2018 at 10:28:25AM -0800, Mike Kravetz wrote:
>> On 12/21/18 2:28 AM, Kirill A. Shutemov wrote:
>>> On Tue, Dec 18, 2018 at 02:35:57PM -0800, Mike Kravetz wrote:
>>>> Instead of writing the required
Comments made by Naoya were addressed.
Mike Kravetz (2):
hugetlbfs: use i_mmap_rwsem for more pmd sharing synchronization
hugetlbfs: Use i_mmap_rwsem to fix page fault/truncate race
fs/hugetlbfs/inode.c | 61 +++-
mm/hugetl
dition, callers
of huge_pte_alloc continue to hold the semaphore until finished with
the ptep.
- i_mmap_rwsem is held in write mode whenever huge_pmd_unshare is called.
Cc:
Fixes: 39dde65c9940 ("shared page table for hugetlb page")
Signed-off-by: Mike Kravetz
7; as it can not longer happen. Remove the dead code
and expand comments to explain reasoning. Similarly, checks for races
with truncation in the page fault path can be simplified and removed.
Cc:
Fixes: ebed4bfc8da8 ("hugetlb: fix absurd HugePages_Rsvd")
Signed-off-by: Mike
ng synchronization")
> url:
> https://github.com/0day-ci/linux/commits/Mike-Kravetz/hugetlbfs-use-i_mmap_rwsem-for-better-synchronization/20181223-095226
>
>
> in testcase: vm-scalability
> on test machine: 104 threads Intel(R) Xeon(R) Platinum 8170 CPU @ 2.10GHz
> with 64G me
issue.
Reported-by: Jan Stancek
Signed-off-by: Mike Kravetz
---
fs/hugetlbfs/inode.c | 61
mm/hugetlb.c | 21 +++
2 files changed, 44 insertions(+), 38 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index
hugetlbfs synchronization issues.
Therefore, revert this patch while working an another approach to the
underlying issues.
Reported-by: Jan Stancek
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c| 64 +++--
mm/memory-failure.c | 16 ++--
mm
On 12/27/18 3:44 AM, Colin Ian King wrote:
> Hi,
>
> Static analysis with CoverityScan on linux-next detected a potential
> null pointer dereference with the following commit:
>
> From d8a1051ed4ba55679ef24e838a1942c9c40f0a14 Mon Sep 17 00:00:00 2001
> From: Mike Kravetz
On 12/27/18 6:45 PM, Andrew Morton wrote:
> On Thu, 27 Dec 2018 11:24:31 -0800 Mike Kravetz
> wrote:
>> It would be better to make an explicit check for mapping != null before
>> calling i_mmap_lock_write/try_to_unmap. In this way, unrelated changes to
>> code above will
On 10/8/18 1:03 AM, Kirill A. Shutemov wrote:
> On Sun, Oct 07, 2018 at 04:38:48PM -0700, Mike Kravetz wrote:
>> The following hugetlbfs truncate/page fault race can be recreated
>> with programs doing something like the following.
>>
>> A huegtlbfs file is mmap(MAP_SHA
On 10/25/18 5:42 PM, Naoya Horiguchi wrote:
> Hi Mike,
>
> On Tue, Oct 23, 2018 at 09:50:53PM -0700, Mike Kravetz wrote:
>> Now, anopther task truncates the hugetlbfs file. As part of truncation,
>> it unmaps everyone who has the file mapped. If a task has a shared p
tle sense to even try to drop hugetlbfs
pagecache pages, so disable calls to these filesystems in drop_caches
code.
Fixes: 70c3547e36f5 ("hugetlbfs: add hugetlbfs_fallocate()")
Cc: sta...@vger.kernel.org
Signed-off-by: Mike Kravetz
---
fs/drop_caches.c | 7 +++
mm/hugetlb.c | 6 ++
101 - 200 of 1393 matches
Mail list logo
