On Tue 30-01-18 10:02:34, Dmitry Vyukov wrote:

On Tue, Jan 30, 2018 at 9:28 AM, Kirill A. Shutemov
[off-list ref] wrote:

quoted

On Tue, Jan 30, 2018 at 09:11:27AM +0100, Florian Westphal wrote:

quoted

Michal Hocko [off-list ref] wrote:

quoted

On Mon 29-01-18 23:35:22, Florian Westphal wrote:

quoted

Kirill A. Shutemov [off-list ref] wrote:

[...]

quoted

quoted

I hate what I'm saying, but I guess we need some tunable here.
Not sure what exactly.

Would memcg help?

That really depends. I would have to check whether vmalloc path obeys
__GFP_ACCOUNT (I suspect it does except for page tables allocations but
that shouldn't be a big deal). But then the other potential problem is
the life time of the xt_table_info (or other potentially large) data
structures. Are they bound to any process life time.

No.

Well, IIUC they bound to net namespace life time, so killing all
proccesses in the namespace would help to get memory back. :)

... unless the namespace is mounted into file system.

Let's start with NOWARN as that's what kernel generally uses for
allocations with user-controllable size. ENOMEM is roughly as
informative as the WARNING message in this case.

You want __GFP_NORETRY but that is not _fully_ supported by kvmalloc
right now. More specifically kvmalloc doesn't guanratee that the request
will not trigger the OOM killer (like regular __GFP_NORETRY). This is
because of internal vmalloc restrictions. If you are however OK to
simply bail out in most cases then __GFP_NORETRY should work reasonably
fine.

I think we also need to consider setting up memory cgroup for
syzkaller test processes (we do RLIMIT_AS, but that's weak).

Well, this is not about syzkaller, it merely pointed out a potential
DoS... And that has to be addressed somehow.

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>