From: Eric Dumazet <eric.dumazet@gmail.com>
To: Tejun Heo <tj@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>
Cc: dennisszhou@gmail.com, Dmitry Vyukov <dvyukov@google.com>,
syzbot <syzbot+adb03f3f0bb57ce3acda@syzkaller.appspotmail.com>,
Alexei Starovoitov <ast@kernel.org>,
netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
syzkaller-bugs@googlegroups.com
Subject: Re: lost connection to test machine (4)
Date: Tue, 13 Feb 2018 05:35:26 -0800 [thread overview]
Message-ID: <1518528926.3715.173.camel@gmail.com> (raw)
In-Reply-To: <20180212200548.GG695913@devbig577.frc2.facebook.com>
On Mon, 2018-02-12 at 12:05 -0800, Tejun Heo wrote:
> On Mon, Feb 12, 2018 at 09:03:25AM -0800, Tejun Heo wrote:
> > Hello, Daniel.
> >
> > On Mon, Feb 12, 2018 at 06:00:13PM +0100, Daniel Borkmann wrote:
> > > [ +Dennis, +Tejun ]
> > >
> > > Looks like we're stuck in percpu allocator with key/value size of 4 bytes
> > > each and large number of entries (max_entries) in the reproducer in above
> > > link.
> > >
> > > Could we have some __GFP_NORETRY semantics and let allocations fail instead
> > > of triggering OOM killer?
> >
> > For some part, maybe, but not generally. The virt area allocation
> > goes down to page table allocation which is hard coded to use
> > GFP_KERNEL in arch mm code.
>
> So, the following should convert majority of allocations to use
> __GFP_NORETRY. It doesn't catch everything but should significantly
> lower the probability of hitting this and put this on the same footing
> as vmalloc. Can you see whether this is enough?
>
> Note that this patch isn't upstreamable. We definitely want to
> restrict this to the rebalance path, but it should be good enough for
> testing.
>
> Thanks.
>
> diff --git a/mm/percpu-vm.c b/mm/percpu-vm.c
> index 9158e5a..0b4739f 100644
> --- a/mm/percpu-vm.c
> +++ b/mm/percpu-vm.c
> @@ -81,7 +81,7 @@ static void pcpu_free_pages(struct pcpu_chunk *chunk,
> static int pcpu_alloc_pages(struct pcpu_chunk *chunk,
> struct page **pages, int page_start, int page_end)
> {
> - const gfp_t gfp = GFP_KERNEL | __GFP_HIGHMEM;
> + const gfp_t gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_NORETRY;
> unsigned int cpu, tcpu;
> int i;
>
Also I would consider using this fix as I had warnings of cpus being
stuck there for more than 50 ms :
diff --git a/mm/percpu-vm.c b/mm/percpu-vm.c
index 9158e5a81391ced4e268e3d5dd9879c2bc7280ce..6309b01ceb357be01e857e5f899429403836f41f 100644
--- a/mm/percpu-vm.c
+++ b/mm/percpu-vm.c
@@ -92,6 +92,7 @@ static int pcpu_alloc_pages(struct pcpu_chunk *chunk,
*pagep = alloc_pages_node(cpu_to_node(cpu), gfp, 0);
if (!*pagep)
goto err;
+ cond_resched();
}
}
return 0;
next prev parent reply other threads:[~2018-02-13 13:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <001a113f8734783e94056505f8fd@google.com>
2018-02-12 16:03 ` lost connection to test machine (4) Dmitry Vyukov
2018-02-12 17:00 ` Daniel Borkmann
2018-02-12 17:03 ` Tejun Heo
2018-02-12 20:05 ` Tejun Heo
2018-02-13 13:35 ` Eric Dumazet [this message]
2018-02-13 17:34 ` Dennis Zhou
2018-02-13 17:49 ` Eric Dumazet
2018-02-13 18:13 ` Dennis Zhou
2018-02-14 17:15 ` Dennis Zhou
2018-02-14 17:28 ` syzbot
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=1518528926.3715.173.camel@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=dennisszhou@gmail.com \
--cc=dvyukov@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=syzbot+adb03f3f0bb57ce3acda@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tj@kernel.org \
/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 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.