From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: Andrey Konovalov <andreyknvl@google.com>,
Vlad Yasevich <vyasevich@gmail.com>,
linux-sctp@vger.kernel.org, netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Pablo Neira Ayuso <pablo@netfilter.org>,
Patrick McHardy <kaber@trash.net>,
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
"David S. Miller" <davem@davemloft.net>,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
Dmitry Vyukov <dvyukov@google.com>,
Kostya Serebryany <kcc@google.com>,
Eric Dumazet <edumazet@google.com>,
syzkaller <syzkaller@googlegroups.com>
Subject: Re: net/sctp: vmalloc allocation failure in sctp_setsockopt/xt_alloc_table_info
Date: Mon, 28 Nov 2016 15:13:12 +0000 [thread overview]
Message-ID: <20161128151312.GA13172@localhost.localdomain> (raw)
In-Reply-To: <20161128143931.GB29839@hmsreliant.think-freely.org>
On Mon, Nov 28, 2016 at 09:39:31AM -0500, Neil Horman wrote:
> On Mon, Nov 28, 2016 at 03:33:40PM +0100, Andrey Konovalov wrote:
> > On Mon, Nov 28, 2016 at 3:13 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > > On Mon, Nov 28, 2016 at 02:00:19PM +0100, Andrey Konovalov wrote:
> > >> Hi!
> > >>
> > >> I've got the following error report while running the syzkaller fuzzer.
> > >>
> > >> On commit d8e435f3ab6fea2ea324dce72b51dd7761747523 (Nov 26).
> > >>
> > >> A reproducer is attached.
> > >>
> > >> a.out: vmalloc: allocation failure, allocated 823562240 of 1427091456
> > >> bytes, mode:0x24000c2(GFP_KERNEL|__GFP_HIGHMEM)
> > >>
> > > How much total ram do you have in this system? The call appears to be
> > > attempting to allocate 1.3 Gb of data. Even using vmalloc to allow
> > > discontiguous allocation, thats alot of memory, and if enough is in use already,
> > > I could make the argument that this might be expected behavior.
> >
> > Hi Neail,
> >
> > I have 2 Gb.
> >
> That would be why. Allocating 65% of the available system memory will almost
> certainly lead to OOM failures quickly.
>
> > Just tested with 4 Gb, everything seems to be working fine.
> > So I guess this is not actually a bug and allocating 1.3 Gb is OK.
Still we probably should avoid the warn triggered by an userspace
application: (untested)
--8<--
diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
index fc4977456c30..b56a0e128fc3 100644
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -958,7 +958,8 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size)
if (sz <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER))
info = kmalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
if (!info) {
- info = vmalloc(sz);
+ info = __vmalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_HIGHMEM,
+ PAGE_KERNEL);
if (!info)
return NULL;
}
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: Andrey Konovalov <andreyknvl@google.com>,
Vlad Yasevich <vyasevich@gmail.com>,
linux-sctp@vger.kernel.org, netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Pablo Neira Ayuso <pablo@netfilter.org>,
Patrick McHardy <kaber@trash.net>,
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
"David S. Miller" <davem@davemloft.net>,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
Dmitry Vyukov <dvyukov@google.com>,
Kostya Serebryany <kcc@google.com>,
Eric Dumazet <edumazet@google.com>,
syzkaller <syzkaller@googlegroups.com>
Subject: Re: net/sctp: vmalloc allocation failure in sctp_setsockopt/xt_alloc_table_info
Date: Mon, 28 Nov 2016 13:13:12 -0200 [thread overview]
Message-ID: <20161128151312.GA13172@localhost.localdomain> (raw)
In-Reply-To: <20161128143931.GB29839@hmsreliant.think-freely.org>
On Mon, Nov 28, 2016 at 09:39:31AM -0500, Neil Horman wrote:
> On Mon, Nov 28, 2016 at 03:33:40PM +0100, Andrey Konovalov wrote:
> > On Mon, Nov 28, 2016 at 3:13 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > > On Mon, Nov 28, 2016 at 02:00:19PM +0100, Andrey Konovalov wrote:
> > >> Hi!
> > >>
> > >> I've got the following error report while running the syzkaller fuzzer.
> > >>
> > >> On commit d8e435f3ab6fea2ea324dce72b51dd7761747523 (Nov 26).
> > >>
> > >> A reproducer is attached.
> > >>
> > >> a.out: vmalloc: allocation failure, allocated 823562240 of 1427091456
> > >> bytes, mode:0x24000c2(GFP_KERNEL|__GFP_HIGHMEM)
> > >>
> > > How much total ram do you have in this system? The call appears to be
> > > attempting to allocate 1.3 Gb of data. Even using vmalloc to allow
> > > discontiguous allocation, thats alot of memory, and if enough is in use already,
> > > I could make the argument that this might be expected behavior.
> >
> > Hi Neail,
> >
> > I have 2 Gb.
> >
> That would be why. Allocating 65% of the available system memory will almost
> certainly lead to OOM failures quickly.
>
> > Just tested with 4 Gb, everything seems to be working fine.
> > So I guess this is not actually a bug and allocating 1.3 Gb is OK.
Still we probably should avoid the warn triggered by an userspace
application: (untested)
--8<--
diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
index fc4977456c30..b56a0e128fc3 100644
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -958,7 +958,8 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size)
if (sz <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER))
info = kmalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
if (!info) {
- info = vmalloc(sz);
+ info = __vmalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_HIGHMEM,
+ PAGE_KERNEL);
if (!info)
return NULL;
}
next prev parent reply other threads:[~2016-11-28 15:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-28 13:00 net/sctp: vmalloc allocation failure in sctp_setsockopt/xt_alloc_table_info Andrey Konovalov
2016-11-28 13:00 ` Andrey Konovalov
2016-11-28 14:13 ` Neil Horman
2016-11-28 14:13 ` Neil Horman
2016-11-28 14:33 ` Andrey Konovalov
2016-11-28 14:33 ` Andrey Konovalov
2016-11-28 14:39 ` Neil Horman
2016-11-28 14:39 ` Neil Horman
2016-11-28 15:13 ` Marcelo Ricardo Leitner [this message]
2016-11-28 15:13 ` Marcelo Ricardo Leitner
2016-11-28 17:46 ` Neil Horman
2016-11-28 17:46 ` Neil Horman
2016-11-28 17:47 ` Florian Westphal
2016-11-28 17:47 ` Florian Westphal
2016-11-28 17:56 ` Neil Horman
2016-11-28 17:56 ` Neil Horman
2016-11-28 18:09 ` Florian Westphal
2016-11-28 18:18 ` Marcelo Ricardo Leitner
2016-11-30 19:21 ` Marcelo Ricardo Leitner
2016-11-30 19:42 ` [PATCH] netfilter: avoid warn and OOM on vmalloc call Marcelo Ricardo Leitner
2016-12-01 9:42 ` Andrey Konovalov
2016-12-01 19:08 ` Marcelo Ricardo Leitner
2016-11-28 18:26 ` net/sctp: vmalloc allocation failure in sctp_setsockopt/xt_alloc_table_info Eric Dumazet
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=20161128151312.GA13172@localhost.localdomain \
--to=marcelo.leitner@gmail.com \
--cc=andreyknvl@google.com \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=dvyukov@google.com \
--cc=edumazet@google.com \
--cc=kaber@trash.net \
--cc=kadlec@blackhole.kfki.hu \
--cc=kcc@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sctp@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=pablo@netfilter.org \
--cc=syzkaller@googlegroups.com \
--cc=vyasevich@gmail.com \
/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.