Kirill Tkhai 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
Kirill Tkhai 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
David Howells 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
David Howells 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
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
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
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
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
On 03.08.2018 13:31, David Howells wrote:
> The reproducer can be reduced to:
>
> #define _GNU_SOURCE
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> const char
On 03.08.2018 13:31, David Howells wrote:
> The reproducer can be reduced to:
>
> #define _GNU_SOURCE
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> const char
The reproducer can be reduced to:
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
const char path[] = "./file0";
int main()
{
The reproducer can be reduced to:
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
const char path[] = "./file0";
int main()
{
On 02.08.2018 23:47, Andrew Morton wrote:
> On Thu, 02 Aug 2018 14:00:52 +0300 Kirill Tkhai 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:
On 02.08.2018 23:47, Andrew Morton wrote:
> On Thu, 02 Aug 2018 14:00:52 +0300 Kirill Tkhai 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:
On 02.08.2018 20:26, Yang Shi wrote:
> On Thu, Aug 2, 2018 at 9:54 AM, Shakeel Butt wrote:
>> On Thu, Aug 2, 2018 at 9:47 AM Yang Shi wrote:
>>>
>>> On Thu, Aug 2, 2018 at 4:00 AM, Kirill Tkhai wrote:
In case of shrink_slab_memcg() we do not zero nid, when shrinker
is not numa-aware.
On 02.08.2018 20:26, Yang Shi wrote:
> On Thu, Aug 2, 2018 at 9:54 AM, Shakeel Butt wrote:
>> On Thu, Aug 2, 2018 at 9:47 AM Yang Shi wrote:
>>>
>>> On Thu, Aug 2, 2018 at 4:00 AM, Kirill Tkhai wrote:
In case of shrink_slab_memcg() we do not zero nid, when shrinker
is not numa-aware.
On Thu, 02 Aug 2018 14:00:52 +0300 Kirill Tkhai 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),
On Thu, 02 Aug 2018 14:00:52 +0300 Kirill Tkhai 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),
On Thu, Aug 2, 2018 at 9:54 AM, Shakeel Butt wrote:
> On Thu, Aug 2, 2018 at 9:47 AM Yang Shi wrote:
>>
>> On Thu, Aug 2, 2018 at 4:00 AM, Kirill Tkhai 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
On Thu, Aug 2, 2018 at 9:54 AM, Shakeel Butt wrote:
> On Thu, Aug 2, 2018 at 9:47 AM Yang Shi wrote:
>>
>> On Thu, Aug 2, 2018 at 4:00 AM, Kirill Tkhai 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
On Thu, Aug 2, 2018 at 9:47 AM Yang Shi wrote:
>
> On Thu, Aug 2, 2018 at 4:00 AM, Kirill Tkhai 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
On Thu, Aug 2, 2018 at 9:47 AM Yang Shi wrote:
>
> On Thu, Aug 2, 2018 at 4:00 AM, Kirill Tkhai 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
On Thu, Aug 2, 2018 at 4:00 AM, Kirill Tkhai 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
On Thu, Aug 2, 2018 at 4:00 AM, Kirill Tkhai 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
22 matches
Mail list logo
