All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab()
@ 2018-08-02 11:00 Kirill Tkhai
  2018-08-02 16:47 ` Yang Shi
  2018-08-02 20:47 ` Andrew Morton
  0 siblings, 2 replies; 13+ messages in thread
From: Kirill Tkhai @ 2018-08-02 11:00 UTC (permalink / raw)
  To: akpm, ktkhai, vdavydov.dev, mhocko, aryabinin, ying.huang,
	penguin-kernel, willy, shakeelb, jbacik, linux-mm, linux-kernel

In case of shrink_slab_memcg() we do not zero nid, when shrinker
is not numa-aware. This is not a real problem, since currently
all memcg-aware shrinkers are numa-aware too (we have two:
super_block shrinker and workingset shrinker), but something may
change in the future.

(Andrew, this may be merged to mm-iterate-only-over-charged-shrinkers-during-memcg-shrink_slab)

Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
 mm/vmscan.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index ea0a46166e8e..0d980e801b8a 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -455,6 +455,9 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl,
 					  : SHRINK_BATCH;
 	long scanned = 0, next_deferred;
 
+	if (!(shrinker->flags & SHRINKER_NUMA_AWARE))
+		nid = 0;
+
 	freeable = shrinker->count_objects(shrinker, shrinkctl);
 	if (freeable == 0 || freeable == SHRINK_EMPTY)
 		return freeable;
@@ -680,9 +683,6 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
 			.memcg = memcg,
 		};
 
-		if (!(shrinker->flags & SHRINKER_NUMA_AWARE))
-			sc.nid = 0;
-
 		ret = do_shrink_slab(&sc, shrinker, priority);
 		if (ret == SHRINK_EMPTY)
 			ret = 0;


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab()
  2018-08-02 11:00 [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab() Kirill Tkhai
@ 2018-08-02 16:47 ` Yang Shi
  2018-08-02 16:54   ` Shakeel Butt
  2018-08-02 20:47 ` Andrew Morton
  1 sibling, 1 reply; 13+ messages in thread
From: Yang Shi @ 2018-08-02 16:47 UTC (permalink / raw)
  To: Kirill Tkhai
  Cc: Andrew Morton, Vladimir Davydov, mhocko, aryabinin, ying.huang,
	penguin-kernel, willy, Shakeel Butt, jbacik, linux-mm,
	Linux Kernel Mailing List

On Thu, Aug 2, 2018 at 4:00 AM, Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
> In case of shrink_slab_memcg() we do not zero nid, when shrinker
> is not numa-aware. This is not a real problem, since currently
> all memcg-aware shrinkers are numa-aware too (we have two:

Actually, this is not true. huge_zero_page_shrinker is NOT numa-aware.
deferred_split_shrinker is numa-aware.

Thanks,
Yang


> super_block shrinker and workingset shrinker), but something may
> change in the future.
>
> (Andrew, this may be merged to mm-iterate-only-over-charged-shrinkers-during-memcg-shrink_slab)
>
> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
> ---
>  mm/vmscan.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index ea0a46166e8e..0d980e801b8a 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -455,6 +455,9 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl,
>                                           : SHRINK_BATCH;
>         long scanned = 0, next_deferred;
>
> +       if (!(shrinker->flags & SHRINKER_NUMA_AWARE))
> +               nid = 0;
> +
>         freeable = shrinker->count_objects(shrinker, shrinkctl);
>         if (freeable == 0 || freeable == SHRINK_EMPTY)
>                 return freeable;
> @@ -680,9 +683,6 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>                         .memcg = memcg,
>                 };
>
> -               if (!(shrinker->flags & SHRINKER_NUMA_AWARE))
> -                       sc.nid = 0;
> -
>                 ret = do_shrink_slab(&sc, shrinker, priority);
>                 if (ret == SHRINK_EMPTY)
>                         ret = 0;
>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab()
  2018-08-02 16:47 ` Yang Shi
@ 2018-08-02 16:54   ` Shakeel Butt
  2018-08-02 17:26     ` Yang Shi
  0 siblings, 1 reply; 13+ messages in thread
From: Shakeel Butt @ 2018-08-02 16:54 UTC (permalink / raw)
  To: shy828301
  Cc: Kirill Tkhai, Andrew Morton, Vladimir Davydov, Michal Hocko,
	Andrey Ryabinin, Huang Ying, Tetsuo Handa, Matthew Wilcox,
	jbacik, Linux MM, LKML

On Thu, Aug 2, 2018 at 9:47 AM Yang Shi <shy828301@gmail.com> wrote:
>
> On Thu, Aug 2, 2018 at 4:00 AM, Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
> > In case of shrink_slab_memcg() we do not zero nid, when shrinker
> > is not numa-aware. This is not a real problem, since currently
> > all memcg-aware shrinkers are numa-aware too (we have two:
>
> Actually, this is not true. huge_zero_page_shrinker is NOT numa-aware.
> deferred_split_shrinker is numa-aware.
>

But both huge_zero_page_shrinker and huge_zero_page_shrinker are not
memcg-aware shrinkers. I think Kirill is saying all memcg-aware
shrinkers are also numa-aware shrinkers.

Shakeel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab()
  2018-08-02 16:54   ` Shakeel Butt
@ 2018-08-02 17:26     ` Yang Shi
  2018-08-03  7:11       ` Kirill Tkhai
  0 siblings, 1 reply; 13+ messages in thread
From: Yang Shi @ 2018-08-02 17:26 UTC (permalink / raw)
  To: Shakeel Butt
  Cc: Kirill Tkhai, Andrew Morton, Vladimir Davydov, Michal Hocko,
	Andrey Ryabinin, Huang Ying, Tetsuo Handa, Matthew Wilcox,
	jbacik, Linux MM, LKML

On Thu, Aug 2, 2018 at 9:54 AM, Shakeel Butt <shakeelb@google.com> wrote:
> On Thu, Aug 2, 2018 at 9:47 AM Yang Shi <shy828301@gmail.com> wrote:
>>
>> On Thu, Aug 2, 2018 at 4:00 AM, Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>> > In case of shrink_slab_memcg() we do not zero nid, when shrinker
>> > is not numa-aware. This is not a real problem, since currently
>> > all memcg-aware shrinkers are numa-aware too (we have two:
>>
>> Actually, this is not true. huge_zero_page_shrinker is NOT numa-aware.
>> deferred_split_shrinker is numa-aware.
>>
>
> But both huge_zero_page_shrinker and huge_zero_page_shrinker are not
> memcg-aware shrinkers. I think Kirill is saying all memcg-aware
> shrinkers are also numa-aware shrinkers.

Aha, thanks for reminding. Yes, I missed that memcg-aware part.

>
> Shakeel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab()
  2018-08-02 11:00 [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab() Kirill Tkhai
  2018-08-02 16:47 ` Yang Shi
@ 2018-08-02 20:47 ` Andrew Morton
  2018-08-03  9:02   ` Kirill Tkhai
                     ` (2 more replies)
  1 sibling, 3 replies; 13+ messages in thread
From: Andrew Morton @ 2018-08-02 20:47 UTC (permalink / raw)
  To: Kirill Tkhai
  Cc: vdavydov.dev, mhocko, aryabinin, ying.huang, penguin-kernel,
	willy, shakeelb, jbacik, linux-mm, linux-kernel

On Thu, 02 Aug 2018 14:00:52 +0300 Kirill Tkhai <ktkhai@virtuozzo.com> wrote:

> In case of shrink_slab_memcg() we do not zero nid, when shrinker
> is not numa-aware. This is not a real problem, since currently
> all memcg-aware shrinkers are numa-aware too (we have two:
> super_block shrinker and workingset shrinker), but something may
> change in the future.

Fair enough.

> (Andrew, this may be merged to mm-iterate-only-over-charged-shrinkers-during-memcg-shrink_slab)

It got a bit messy so I got lazy and queued it as a separate patch.

btw, I have a note that https://lkml.org/lkml/2018/7/7/32 was caused by
this patch series.  Is that the case and do you know if this was
addressed?


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab()
  2018-08-02 17:26     ` Yang Shi
@ 2018-08-03  7:11       ` Kirill Tkhai
  0 siblings, 0 replies; 13+ messages in thread
From: Kirill Tkhai @ 2018-08-03  7:11 UTC (permalink / raw)
  To: Yang Shi, Shakeel Butt
  Cc: Andrew Morton, Vladimir Davydov, Michal Hocko, Andrey Ryabinin,
	Huang Ying, Tetsuo Handa, Matthew Wilcox, jbacik, Linux MM, LKML

On 02.08.2018 20:26, Yang Shi wrote:
> On Thu, Aug 2, 2018 at 9:54 AM, Shakeel Butt <shakeelb@google.com> wrote:
>> On Thu, Aug 2, 2018 at 9:47 AM Yang Shi <shy828301@gmail.com> wrote:
>>>
>>> On Thu, Aug 2, 2018 at 4:00 AM, Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>>>> In case of shrink_slab_memcg() we do not zero nid, when shrinker
>>>> is not numa-aware. This is not a real problem, since currently
>>>> all memcg-aware shrinkers are numa-aware too (we have two:
>>>
>>> Actually, this is not true. huge_zero_page_shrinker is NOT numa-aware.
>>> deferred_split_shrinker is numa-aware.
>>>
>>
>> But both huge_zero_page_shrinker and huge_zero_page_shrinker are not
>> memcg-aware shrinkers. I think Kirill is saying all memcg-aware
>> shrinkers are also numa-aware shrinkers.
> 
> Aha, thanks for reminding. Yes, I missed that memcg-aware part.

Yes, I mean workingset_shadow_shrinker.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab()
  2018-08-02 20:47 ` Andrew Morton
@ 2018-08-03  9:02   ` Kirill Tkhai
  2018-08-03 10:31   ` David Howells
  2018-08-03 11:18     ` David Howells
  2 siblings, 0 replies; 13+ messages in thread
From: Kirill Tkhai @ 2018-08-03  9:02 UTC (permalink / raw)
  To: Andrew Morton, linux-kernel, David Howells
  Cc: vdavydov.dev, mhocko, aryabinin, ying.huang, penguin-kernel,
	willy, shakeelb, jbacik, linux-mm

On 02.08.2018 23:47, Andrew Morton wrote:
> On Thu, 02 Aug 2018 14:00:52 +0300 Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
> 
>> In case of shrink_slab_memcg() we do not zero nid, when shrinker
>> is not numa-aware. This is not a real problem, since currently
>> all memcg-aware shrinkers are numa-aware too (we have two:
>> super_block shrinker and workingset shrinker), but something may
>> change in the future.
> 
> Fair enough.
> 
>> (Andrew, this may be merged to mm-iterate-only-over-charged-shrinkers-during-memcg-shrink_slab)
> 
> It got a bit messy so I got lazy and queued it as a separate patch.
> 
> btw, I have a note that https://lkml.org/lkml/2018/7/7/32 was caused by
> this patch series.  Is that the case and do you know if this was
> addressed?

It's not related to the patchset. Bisect leads to:

commit c6aeb9d4c351 (HEAD, refs/bisect/bad)
Author: David Howells <dhowells@redhat.com>
Date:   Sun Jun 24 00:20:10 2018 +0100

kernfs, sysfs, cgroup, intel_rdt: Support fs_context

CC David.

David, please see reproducer at https://lkml.org/lkml/2018/7/7/32

Kirill

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab()
  2018-08-02 20:47 ` Andrew Morton
  2018-08-03  9:02   ` Kirill Tkhai
@ 2018-08-03 10:31   ` David Howells
  2018-08-03 10:59     ` Kirill Tkhai
  2018-08-03 11:18     ` David Howells
  2 siblings, 1 reply; 13+ messages in thread
From: David Howells @ 2018-08-03 10:31 UTC (permalink / raw)
  To: Kirill Tkhai
  Cc: dhowells, Andrew Morton, linux-kernel, vdavydov.dev, mhocko,
	aryabinin, ying.huang, penguin-kernel, willy, shakeelb, jbacik,
	linux-mm

The reproducer can be reduced to:

	#define _GNU_SOURCE
	#include <endian.h>
	#include <stdint.h>
	#include <string.h>
	#include <stdio.h>
	#include <sys/syscall.h>
	#include <sys/stat.h>
	#include <sys/mount.h>
	#include <unistd.h>
	#include <fcntl.h>

	const char path[] = "./file0";

	int main()
	{
		mkdir(path, 0);
		mount(path, path, "cgroup2", 0, 0);
		chroot(path);
		umount2(path, 0);
		return 0;
	}

and I've found two bugs (see attached patch).  The issue is that
do_remount_sb() is called with fc == NULL from umount(), but both
cgroup_reconfigure() and do_remount_sb() dereference fc unconditionally.

But!  I'm not sure why the reproducer works at all because the umount2() call
is *after* the chroot, so should fail on ENOENT before it even gets that far.
In fact, umount2() can be called multiple times, apparently successfully, and
doesn't actually unmount anything.

David
---
diff --git a/fs/super.c b/fs/super.c
index 3fe5d12b7697..321fbc244570 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -978,7 +978,10 @@ int do_remount_sb(struct super_block *sb, int sb_flags, void *data,
 	    sb->s_op->remount_fs) {
 		if (sb->s_op->reconfigure) {
 			retval = sb->s_op->reconfigure(sb, fc);
-			sb_flags = fc->sb_flags;
+			if (fc)
+				sb_flags = fc->sb_flags;
+			else
+				sb_flags = sb->s_flags;
 			if (retval == 0)
 				security_sb_reconfigure(fc);
 		} else {
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index f3238f38d152..48275fdce053 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -1796,9 +1796,11 @@ static void apply_cgroup_root_flags(unsigned int root_flags)
 
 static int cgroup_reconfigure(struct kernfs_root *kf_root, struct fs_context *fc)
 {
-	struct cgroup_fs_context *ctx = cgroup_fc2context(fc);
+	if (fc) {
+		struct cgroup_fs_context *ctx = cgroup_fc2context(fc);
 
-	apply_cgroup_root_flags(ctx->flags);
+		apply_cgroup_root_flags(ctx->flags);
+	}
 	return 0;
 }
 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab()
  2018-08-03 10:31   ` David Howells
@ 2018-08-03 10:59     ` Kirill Tkhai
  2018-08-03 11:04       ` Kirill Tkhai
  2018-08-03 12:00       ` David Howells
  0 siblings, 2 replies; 13+ messages in thread
From: Kirill Tkhai @ 2018-08-03 10:59 UTC (permalink / raw)
  To: David Howells
  Cc: Andrew Morton, linux-kernel, vdavydov.dev, mhocko, aryabinin,
	ying.huang, penguin-kernel, willy, shakeelb, jbacik, linux-mm

On 03.08.2018 13:31, David Howells wrote:
> The reproducer can be reduced to:
> 
> 	#define _GNU_SOURCE
> 	#include <endian.h>
> 	#include <stdint.h>
> 	#include <string.h>
> 	#include <stdio.h>
> 	#include <sys/syscall.h>
> 	#include <sys/stat.h>
> 	#include <sys/mount.h>
> 	#include <unistd.h>
> 	#include <fcntl.h>
> 
> 	const char path[] = "./file0";
> 
> 	int main()
> 	{
> 		mkdir(path, 0);
> 		mount(path, path, "cgroup2", 0, 0);
> 		chroot(path);
> 		umount2(path, 0);
> 		return 0;
> 	}
> 
> and I've found two bugs (see attached patch).  The issue is that
> do_remount_sb() is called with fc == NULL from umount(), but both
> cgroup_reconfigure() and do_remount_sb() dereference fc unconditionally.
>
> But!  I'm not sure why the reproducer works at all because the umount2() call
> is *after* the chroot, so should fail on ENOENT before it even gets that far.
> In fact, umount2() can be called multiple times, apparently successfully, and
> doesn't actually unmount anything.

Before I also try to check why it works; just reporting you that the patch
works the problem in my environment. Thanks, David.

> ---
> diff --git a/fs/super.c b/fs/super.c
> index 3fe5d12b7697..321fbc244570 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -978,7 +978,10 @@ int do_remount_sb(struct super_block *sb, int sb_flags, void *data,
>  	    sb->s_op->remount_fs) {
>  		if (sb->s_op->reconfigure) {
>  			retval = sb->s_op->reconfigure(sb, fc);
> -			sb_flags = fc->sb_flags;
> +			if (fc)
> +				sb_flags = fc->sb_flags;
> +			else
> +				sb_flags = sb->s_flags;
>  			if (retval == 0)
>  				security_sb_reconfigure(fc);
>  		} else {
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index f3238f38d152..48275fdce053 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -1796,9 +1796,11 @@ static void apply_cgroup_root_flags(unsigned int root_flags)
>  
>  static int cgroup_reconfigure(struct kernfs_root *kf_root, struct fs_context *fc)
>  {
> -	struct cgroup_fs_context *ctx = cgroup_fc2context(fc);
> +	if (fc) {
> +		struct cgroup_fs_context *ctx = cgroup_fc2context(fc);
>  
> -	apply_cgroup_root_flags(ctx->flags);
> +		apply_cgroup_root_flags(ctx->flags);
> +	}
>  	return 0;
>  }
>  
> 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab()
  2018-08-03 10:59     ` Kirill Tkhai
@ 2018-08-03 11:04       ` Kirill Tkhai
  2018-08-03 12:00       ` David Howells
  1 sibling, 0 replies; 13+ messages in thread
From: Kirill Tkhai @ 2018-08-03 11:04 UTC (permalink / raw)
  To: David Howells
  Cc: Andrew Morton, linux-kernel, vdavydov.dev, mhocko, aryabinin,
	ying.huang, penguin-kernel, willy, shakeelb, jbacik, linux-mm

On 03.08.2018 13:59, Kirill Tkhai wrote:
> On 03.08.2018 13:31, David Howells wrote:
>> The reproducer can be reduced to:
>>
>> 	#define _GNU_SOURCE
>> 	#include <endian.h>
>> 	#include <stdint.h>
>> 	#include <string.h>
>> 	#include <stdio.h>
>> 	#include <sys/syscall.h>
>> 	#include <sys/stat.h>
>> 	#include <sys/mount.h>
>> 	#include <unistd.h>
>> 	#include <fcntl.h>
>>
>> 	const char path[] = "./file0";
>>
>> 	int main()
>> 	{
>> 		mkdir(path, 0);
>> 		mount(path, path, "cgroup2", 0, 0);
>> 		chroot(path);
>> 		umount2(path, 0);
>> 		return 0;
>> 	}
>>
>> and I've found two bugs (see attached patch).  The issue is that
>> do_remount_sb() is called with fc == NULL from umount(), but both
>> cgroup_reconfigure() and do_remount_sb() dereference fc unconditionally.
>>
>> But!  I'm not sure why the reproducer works at all because the umount2() call
>> is *after* the chroot, so should fail on ENOENT before it even gets that far.
>> In fact, umount2() can be called multiple times, apparently successfully, and
>> doesn't actually unmount anything.
> 
> Before I also try to check why it works; just reporting you that the patch
> works the problem in my environment. Thanks, David.

patch *fixes* the problem

> 
>> ---
>> diff --git a/fs/super.c b/fs/super.c
>> index 3fe5d12b7697..321fbc244570 100644
>> --- a/fs/super.c
>> +++ b/fs/super.c
>> @@ -978,7 +978,10 @@ int do_remount_sb(struct super_block *sb, int sb_flags, void *data,
>>  	    sb->s_op->remount_fs) {
>>  		if (sb->s_op->reconfigure) {
>>  			retval = sb->s_op->reconfigure(sb, fc);
>> -			sb_flags = fc->sb_flags;
>> +			if (fc)
>> +				sb_flags = fc->sb_flags;
>> +			else
>> +				sb_flags = sb->s_flags;
>>  			if (retval == 0)
>>  				security_sb_reconfigure(fc);
>>  		} else {
>> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
>> index f3238f38d152..48275fdce053 100644
>> --- a/kernel/cgroup/cgroup.c
>> +++ b/kernel/cgroup/cgroup.c
>> @@ -1796,9 +1796,11 @@ static void apply_cgroup_root_flags(unsigned int root_flags)
>>  
>>  static int cgroup_reconfigure(struct kernfs_root *kf_root, struct fs_context *fc)
>>  {
>> -	struct cgroup_fs_context *ctx = cgroup_fc2context(fc);
>> +	if (fc) {
>> +		struct cgroup_fs_context *ctx = cgroup_fc2context(fc);
>>  
>> -	apply_cgroup_root_flags(ctx->flags);
>> +		apply_cgroup_root_flags(ctx->flags);
>> +	}
>>  	return 0;
>>  }
>>  
>>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab()
  2018-08-02 20:47 ` Andrew Morton
@ 2018-08-03 11:18     ` David Howells
  2018-08-03 10:31   ` David Howells
  2018-08-03 11:18     ` David Howells
  2 siblings, 0 replies; 13+ messages in thread
From: David Howells @ 2018-08-03 11:18 UTC (permalink / raw)
  Cc: dhowells, Kirill Tkhai, Andrew Morton, linux-kernel,
	vdavydov.dev, mhocko, aryabinin, ying.huang, penguin-kernel,
	willy, shakeelb, jbacik, linux-mm

David Howells <dhowells@redhat.com> wrote:

> But!  I'm not sure why the reproducer works at all because the umount2() call
> is *after* the chroot, so should fail on ENOENT before it even gets that
> far.

No, it shouldn't.  It did chroot() not chdir().

> In fact, umount2() can be called multiple times, apparently successfully, and
> doesn't actually unmount anything.

Okay, because it chroot'd into the directory.  Should it return EBUSY though?

David

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab()
@ 2018-08-03 11:18     ` David Howells
  0 siblings, 0 replies; 13+ messages in thread
From: David Howells @ 2018-08-03 11:18 UTC (permalink / raw)
  Cc: dhowells, Kirill Tkhai, Andrew Morton, linux-kernel,
	vdavydov.dev, mhocko, aryabinin, ying.huang, penguin-kernel,
	willy, shakeelb, jbacik, linux-mm

David Howells <dhowells@redhat.com> wrote:

> But!  I'm not sure why the reproducer works at all because the umount2() call
> is *after* the chroot, so should fail on ENOENT before it even gets that
> far.

No, it shouldn't.  It did chroot() not chdir().

> In fact, umount2() can be called multiple times, apparently successfully, and
> doesn't actually unmount anything.

Okay, because it chroot'd into the directory.  Should it return EBUSY though?

David

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab()
  2018-08-03 10:59     ` Kirill Tkhai
  2018-08-03 11:04       ` Kirill Tkhai
@ 2018-08-03 12:00       ` David Howells
  1 sibling, 0 replies; 13+ messages in thread
From: David Howells @ 2018-08-03 12:00 UTC (permalink / raw)
  To: Kirill Tkhai
  Cc: dhowells, Andrew Morton, linux-kernel, vdavydov.dev, mhocko,
	aryabinin, ying.huang, penguin-kernel, willy, shakeelb, jbacik,
	linux-mm

Kirill Tkhai <ktkhai@virtuozzo.com> wrote:

> > Before I also try to check why it works; just reporting you that the patch
> > works the problem in my environment. Thanks, David.
> 
> patch *fixes* the problem

Thanks.  I've folded the patch in.

David

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2018-08-03 12:00 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-08-02 11:00 [PATCH] mm: Move check for SHRINKER_NUMA_AWARE to do_shrink_slab() Kirill Tkhai
2018-08-02 16:47 ` Yang Shi
2018-08-02 16:54   ` Shakeel Butt
2018-08-02 17:26     ` Yang Shi
2018-08-03  7:11       ` Kirill Tkhai
2018-08-02 20:47 ` Andrew Morton
2018-08-03  9:02   ` Kirill Tkhai
2018-08-03 10:31   ` David Howells
2018-08-03 10:59     ` Kirill Tkhai
2018-08-03 11:04       ` Kirill Tkhai
2018-08-03 12:00       ` David Howells
2018-08-03 11:18   ` David Howells
2018-08-03 11:18     ` David Howells

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.