From: Yafang Shao <firstname.lastname@example.org>
To: Michal Hocko <email@example.com>
Cc: Andrew Morton <firstname.lastname@example.org>,
Matthew Wilcox <email@example.com>,
Johannes Weiner <firstname.lastname@example.org>,
Vladimir Davydov <email@example.com>,
Linux MM <firstname.lastname@example.org>
Subject: Re: [PATCH v3] mm, memcg: fix error return value of mem_cgroup_css_alloc()
Date: Tue, 7 Apr 2020 17:31:33 +0800 [thread overview]
Message-ID: <CALOAHbDNOaug-0x--wSPp+6kX6+f6FO7JXhDYLF6TwGrJ+TVhA@mail.gmail.com> (raw)
On Tue, Apr 7, 2020 at 2:43 PM Michal Hocko <email@example.com> wrote:
> [I have only now noticed there was another version posted. Please try to
> wait a bit longer for other feedback before reposting a newer version]
Sure I will. sorry about that.
But after we send a patch, we always don't know in which state this
patch is, e.g. Changes Requested, Not Applicable, Rejected, Needs
Review / ACK and etc, as listed in netdev list. That could give us
an explicit instruction on what to do next.
> On Tue 07-04-20 11:11:13, Yafang Shao wrote:
> > On Tue, Apr 7, 2020 at 11:09 AM Andrew Morton <firstname.lastname@example.org> wrote:
> > >
> > > On Tue, 7 Apr 2020 11:02:31 +0800 Yafang Shao <email@example.com> wrote:
> > >
> > > > On Tue, Apr 7, 2020 at 7:23 AM Andrew Morton <firstname.lastname@example.org> wrote:
> > > > >
> > > > > On Tue, 7 Apr 2020 00:56:03 +0800 Yafang Shao <email@example.com> 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().
> See my comment about EBUSY in the previous version
From the perspective of mkdir(2), it is better to use ENOSPC here. But
I'm not sure whether it is better to update the man page of mkdir(2)
I checked the explaination about ENOSPC in 73f576c04b94 ("mm:
memcontrol: fix cgroup creation failure after many small jobs")
carefully, but I don't a clear idea which one is better now.
Per Matthew, EBUSY is better, while per you, ENOSPC is better.
Matthew, would you mind to give more detailed explanation ?
> > > > > > 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.
> We have idr failure path since 73f576c04b94 ("mm: memcontrol: fix cgroup
> creation failure after many small jobs") which is more than four years
> ago without anybody ever noticing. While I do agree that the existing
> behavior might be confusing I am not really sure this qualifies as
> stable material TBH.
next prev parent reply other threads:[~2020-04-07 9:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-06 16:56 [PATCH v3] mm, memcg: fix error return value of mem_cgroup_css_alloc() Yafang Shao
2020-04-06 23:23 ` Andrew Morton
2020-04-07 3:02 ` Yafang Shao
2020-04-07 3:09 ` Andrew Morton
2020-04-07 3:11 ` Yafang Shao
2020-04-07 6:43 ` Michal Hocko
2020-04-07 9:31 ` Yafang Shao [this message]
2020-04-07 11:10 ` Michal Hocko
2020-04-07 18:10 ` Johannes Weiner
2020-04-09 1:29 ` Andrew Morton
2020-04-09 6:57 ` Michal Hocko
2020-04-09 13:59 ` Yafang Shao
2020-04-09 14:07 ` Michal Hocko
2020-04-20 23:44 ` Andrew Morton
2020-04-21 14:44 ` Johannes Weiner
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).