From: Michal Hocko <mhocko@kernel.org>
To: Georgi Nikolov <gnikolov@icdsoft.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org,
netfilter-devel@vger.kernel.org
Subject: Re: [Bug 200651] New: cgroups iptables-restor: vmalloc: allocation failure
Date: Mon, 30 Jul 2018 15:57:44 +0200 [thread overview]
Message-ID: <20180730135744.GT24267@dhcp22.suse.cz> (raw)
In-Reply-To: <ff19099f-e0f5-d2b2-e124-cc12d2e05dc1@icdsoft.com>
On Mon 30-07-18 16:37:07, Georgi Nikolov wrote:
> On 07/26/2018 12:02 PM, Georgi Nikolov wrote:
[...]
> > Here is the patch applied to this version which masks errors:
> >
> > --- net/netfilter/x_tables.c 2018-06-18 14:18:21.138347416 +0300
> > +++ net/netfilter/x_tables.c 2018-07-26 11:58:01.721932962 +0300
> > @@ -1059,9 +1059,19 @@
> > * than shoot all processes down before realizing there is nothing
> > * more to reclaim.
> > */
> > - info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > +/* info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > if (!info)
> > return NULL;
> > +*/
> > +
> > + if (sz <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER))
> > + info = kmalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
> > + if (!info) {
> > + info = __vmalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY,
> > + PAGE_KERNEL);
> > + if (!info)
> > + return NULL;
> > + }
> >
> > memset(info, 0, sizeof(*info));
> > info->size = size;
> >
> >
> > I will try to reproduce it with only
> >
> > info = kvmalloc(sz, GFP_KERNEL);
> >
> > Regards,
> >
> > --
> > Georgi Nikolov
> >
>
> Hello,
>
> Without GFP_NORETRY problem disappears.
Hmm, there are two allocation paths which have __GFP_NORETRY here.
I expect you have removed both of them, right?
kvmalloc implicitly performs __GFP_NORETRY on kmalloc path but it
doesn't have it for the vmalloc fallback. This would match
kvmalloc(GFP_KERNEL). I thought you were testing this code path
previously but there is some confusion flying around because you have
claimed that the regressions started with eacd86ca3b036. If the
regression is really with __GFP_NORETRY being used for the vmalloc
fallback which would be kvmalloc(GFP_KERNEL | __GFP_NORETRY) then
I am still confused because that would match the original code.
> What is correct way to fix it.
> - inside xt_alloc_table_info remove GFP_NORETRY from kvmalloc or add
> this flag only for sizes bigger than some threshold
This would reintroduce issue fixed by 0537250fdc6c8. Note that
kvmalloc(GFP_KERNEL | __GFP_NORETRY) is more or less equivalent to the
original code (well, except for __GFP_NOWARN).
> - inside kvmalloc_node remove GFP_NORETRY from
> __vmalloc_node_flags_caller (i don't know if it honors this flag, or
> the problem is elsewhere)
No, not really. This is basically equivalent to kvmalloc(GFP_KERNEL).
I strongly suspect that this is not a regression in this code but rather
a side effect of larger memory fragmentation caused by something else.
In any case do you see this failure also without artificial test case
with a standard workload?
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-07-30 13:57 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-200651-27@https.bugzilla.kernel.org/>
2018-07-25 19:52 ` Andrew Morton
2018-07-26 7:18 ` Vlastimil Babka
2018-07-26 7:26 ` Michal Hocko
2018-07-26 7:34 ` Vlastimil Babka
2018-07-26 7:42 ` Michal Hocko
2018-07-26 7:50 ` Vlastimil Babka
2018-07-26 8:03 ` Michal Hocko
2018-07-26 8:31 ` Vlastimil Babka
2018-07-26 8:48 ` Vlastimil Babka
2018-07-26 9:02 ` Georgi Nikolov
2018-07-30 13:37 ` Georgi Nikolov
2018-07-30 13:57 ` Michal Hocko [this message]
2018-07-30 15:54 ` Georgi Nikolov
2018-07-30 18:38 ` Michal Hocko
2018-07-30 18:51 ` Georgi Nikolov
2018-07-31 6:38 ` Vlastimil Babka
2018-07-31 13:55 ` Georgi Nikolov
2018-07-31 14:05 ` Florian Westphal
2018-07-31 14:25 ` Georgi Nikolov
2018-08-01 7:17 ` Vlastimil Babka
2018-08-01 7:34 ` Vlastimil Babka
2018-08-01 8:33 ` Michal Hocko
2018-08-01 16:03 ` Georgi Nikolov
2018-08-02 8:50 ` Michal Hocko
2018-08-02 9:25 ` Pablo Neira Ayuso
2018-08-02 10:44 ` Michal Hocko
2018-08-06 8:42 ` Georgi Nikolov
2018-08-07 11:02 ` Georgi Nikolov
2018-08-07 11:09 ` Michal Hocko
2018-08-07 11:19 ` Florian Westphal
2018-08-07 11:26 ` Michal Hocko
2018-08-07 11:30 ` Florian Westphal
2018-08-07 11:38 ` Michal Hocko
2018-08-07 11:31 ` Vlastimil Babka
2018-08-07 13:35 ` Mike Rapoport
2018-08-07 11:29 ` Vlastimil Babka
2018-08-07 11:37 ` Michal Hocko
2018-08-07 18:23 ` Florian Westphal
2018-08-07 19:30 ` Michal Hocko
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180730135744.GT24267@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bugzilla-daemon@bugzilla.kernel.org \
--cc=gnikolov@icdsoft.com \
--cc=linux-mm@kvack.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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