On Tue 07-08-18 20:23:55, Florian Westphal wrote:
> Michal Hocko wrote:
> > Subject: [PATCH] netfilter/x_tables: do not fail xt_alloc_table_info too
> > easilly
>
> [..]
>
> > - /* __GFP_NORETRY is not fully supported by kvmalloc but it should
> > -
On Tue 07-08-18 13:30:13, Florian Westphal wrote:
> Michal Hocko wrote:
> > On Tue 07-08-18 13:19:26, Florian Westphal wrote:
> > > Michal Hocko wrote:
> > > > > I can't reproduce it anymore.
> > > > > If i understand correctly this way memo
On Tue 07-08-18 13:29:15, Vlastimil Babka wrote:
> On 08/02/2018 10:50 AM, Michal Hocko wrote:
> > On Wed 01-08-18 19:03:03, Georgi Nikolov wrote:
> >>
> >> *Georgi Nikolov*
> >> System Administrator
> >> www.icdsoft.com <http://www.icdsoft.com>
&
On Tue 07-08-18 13:19:26, Florian Westphal wrote:
> Michal Hocko wrote:
> > > I can't reproduce it anymore.
> > > If i understand correctly this way memory allocated will be
> > > accounted to kmem of this cgroup (if inside cgroup).
> >
> > s@this
On Tue 07-08-18 14:02:00, Georgi Nikolov wrote:
> On 08/06/2018 11:42 AM, Georgi Nikolov wrote:
> > On 08/02/2018 11:50 AM, Michal Hocko wrote:
> >> In other words, why don't we simply do the following? Note that this is
> >> not tested. I have also no idea what is the
On Thu 02-08-18 11:25:49, Pablo Neira Ayuso wrote:
> On Thu, Aug 02, 2018 at 10:50:43AM +0200, Michal Hocko wrote:
[...]
> > diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> > index d0d8397c9588..b769408e04ab 100644
> > --- a/net/netfilter/x_tables.c
&g
On Wed 01-08-18 19:03:03, Georgi Nikolov wrote:
>
> *Georgi Nikolov*
> System Administrator
> www.icdsoft.com <http://www.icdsoft.com>
>
> On 08/01/2018 11:33 AM, Michal Hocko wrote:
> > On Wed 01-08-18 09:34:23, Vlastimil Babka wrote:
> >> On 07/3
s
higher privileges then I fail to see where the distrust comes from. If
this is really about untrusted root in a namespace then the proper way
is to use __GFP_ACCOUNT and limit that via kmemc.
__GFP_NORETRY can fail really easily if the kswapd doesn't keep the pace
with the allocations which migh
trigger the oom killer but in rare cases this might happen
(e.g. when page tables are allocated because those are hardcoded GFP_KERNEL).
That being said, I have no objection to use GFP_KERNEL if it helps real
workloads but we probably need some cap...
--
Michal Hocko
SUSE Labs
--
To unsubscribe from
ess 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).
On Thu 26-07-18 09:50:45, Vlastimil Babka wrote:
> On 07/26/2018 09:42 AM, Michal Hocko wrote:
> > On Thu 26-07-18 09:34:58, Vlastimil Babka wrote:
> >> On 07/26/2018 09:26 AM, Michal Hocko wrote:
> >>> On Thu 26-07-18 09:18:57, Vlastimil Babka wrote:
> >>&
On Thu 26-07-18 09:34:58, Vlastimil Babka wrote:
> On 07/26/2018 09:26 AM, Michal Hocko wrote:
> > On Thu 26-07-18 09:18:57, Vlastimil Babka wrote:
> >> On 07/25/2018 09:52 PM, Andrew Morton wrote:
> >>> (switched to email. Please respond via emailed reply-to-all,
t
> >> ./test
> >> i=0;while sleep 0 ; do iptables-restore < iptables.save ; i=$(($i+1));
> >> echo $i;
> >> done
> >>
> >> Here is the source of "test" program and attached iptables.save. It happens
> >> also with smaller iptables.save file.
ps created.
It seems somebody is depleting the vmalloc space. Feel free to CC me on
that report. I am definitely interested.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.o
ack for all but order-0 sizes and it dropped
__GFP_NOWARN from the vmalloc call.
The later would allow to print the error message. Just to make it clear,
the regression you are seeing is not just the error message. It is
iptables-restore that fails and hasn't before, right?
--
Michal Hocko
SUSE L
the above patch could have made any difference.
I am even not sure what the actual bug is, to be honest.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue 30-01-18 11:27:45, Andrew Morton wrote:
> On Tue, 30 Jan 2018 15:01:04 +0100 Michal Hocko <mho...@kernel.org> wrote:
>
> > > Well, this is not about syzkaller, it merely pointed out a potential
> > > DoS... And that has to be addressed somehow.
> >
>
ETRY has been used for both kmalloc and vmalloc paths.
So it is more a quick band aid than a longterm solution.
[1] http://lkml.kernel.org/r/20180129165722.gf5...@breakpoint.cc
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the b
On Tue 30-01-18 15:01:11, Florian Westphal wrote:
> > From d48e950f1b04f234b57b9e34c363bdcfec10aeee Mon Sep 17 00:00:00 2001
> > From: Michal Hocko <mho...@suse.com>
> > Date: Tue, 30 Jan 2018 14:51:07 +0100
> > Subject: [PATCH] net/netfilter/x_tables.c: make allocat
On Tue 30-01-18 10:57:39, Michal Hocko wrote:
> On Tue 30-01-18 10:02:34, Dmitry Vyukov wrote:
> > On Tue, Jan 30, 2018 at 9:28 AM, Kirill A. Shutemov
> > <kir...@shutemov.name> wrote:
> > > On Tue, Jan 30, 2018 at 09:11:27AM +0100, Florian Westphal wrote:
> >
On Tue 30-01-18 10:02:34, Dmitry Vyukov wrote:
> On Tue, Jan 30, 2018 at 9:28 AM, Kirill A. Shutemov
> <kir...@shutemov.name> wrote:
> > On Tue, Jan 30, 2018 at 09:11:27AM +0100, Florian Westphal wrote:
> >> Michal Hocko <mho...@kernel.org> wrote:
> >> &g
On Tue 30-01-18 09:11:27, Florian Westphal wrote:
> Michal Hocko <mho...@kernel.org> wrote:
> > On Mon 29-01-18 23:35:22, Florian Westphal wrote:
> > > Kirill A. Shutemov <kir...@shutemov.name> wrote:
> > [...]
> > > > I hate what I'm saying, but I g
t wouldn't resolve it other than kill all tasks in the affected
memcg/container. Whether this is sufficient or not, I dunno. It sounds
quite suboptimal to me. But it is true this would be less tricky then
adding a global knob...
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the
t; >
> > Just supressing OOM kill is a bad idea. We still leave a way to allocate
> > arbitrary large buffer in kernel.
>
> Isn't that what we do everywhere in network stack?
>
> I think we should try to allocate whatever amount of memory is needed
>
; unsigned int *xt_alloc_entry_offsets(unsigned int size)
> {
> if (size < (SIZE_MAX / sizeof(unsigned int)))
> - return kvmalloc(size * sizeof(unsigned int), GFP_KERNEL);;
> + return kvmalloc(size * sizeof(unsigned int), GFP_KERNEL);
>
> return NULL;
&
25 matches
Mail list logo
