On Tue, Apr 7, 2020 at 11:09 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 7 Apr 2020 11:02:31 +0800 Yafang Shao <laoar.shao@xxxxxxxxx> wrote: > > > On Tue, Apr 7, 2020 at 7:23 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Tue, 7 Apr 2020 00:56:03 +0800 Yafang Shao <laoar.shao@xxxxxxxxx> wrote: > > > > > > > When I run my memcg testcase which creates lots of memcgs, I found > > > > there're unexpected out of memory logs while there're still enough > > > > available free memory. The error log is, > > > > mkdir: cannot create directory 'foo.65533': Cannot allocate memory > > > > > > > > The reason is when we try to create more than MEM_CGROUP_ID_MAX memcgs, an > > > > -ENOMEM errno will be set by mem_cgroup_css_alloc(), but the right errno > > > > should be -EBUSY "Device or resource busy". That is same with > > > > memcg_alloc_cache_id(). > > > > > > > > As the errno really misled me, we should make it right. After this patch, > > > > the error log will be, > > > > mkdir: cannot create directory 'foo.65533': Device or resource busy > > > > > > Thanks. > > > > > > Was a -stable backport considered? > > > > I only backported to our kernel version 4.18, but I'm not sure whether > > it will apply to -stable or not. > > Seems this issue is introduced long time ago. I will try to backport > > it to -stable. > > Should I try it based on 5.5.y and 5.6.y only ? Or all the LTS kernel > > versions ? > > What I'm asking (of you and of reviewers) is whether this issue is > sufficiently serious to require fixing in -stable kernels. The > patch merging details can be sorted out later. > > I think it is worth to cc stable, as this errno will mislead the user. Thanks Yafang