Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Mar 2012 03:11:43 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Djalal Harouni <tixxdz@...ndz.org>
Cc: Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org, 
	kernel-hardening@...ts.openwall.com, 
	Andrew Morton <akpm@...ux-foundation.org>, Al Viro <viro@...iv.linux.org.uk>, 
	Alexey Dobriyan <adobriyan@...il.com>, "Eric W. Biederman" <ebiederm@...ssion.com>, 
	Vasiliy Kulikov <segoon@...nwall.com>, Kees Cook <keescook@...omium.org>, 
	Solar Designer <solar@...nwall.com>, WANG Cong <xiyou.wangcong@...il.com>, 
	James Morris <james.l.morris@...cle.com>, linux-security-module@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>, 
	Greg KH <gregkh@...uxfoundation.org>, Ingo Molnar <mingo@...e.hu>, 
	Stephen Wilson <wilsons@...rt.ca>, "Jason A. Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH 1/9] exec: add a global execve counter

On Sun, Mar 11, 2012 at 5:25 PM, Djalal Harouni <tixxdz@...ndz.org> wrote:
> On Sun, Mar 11, 2012 at 04:42:37PM -0700, Linus Torvalds wrote:
>> That's the point. I made the mistake of using mm_users initially, but
>> ysing mm_count - which is what I said to use (and what Oleg fixed
>> things to in commit 6d08f2c71397) should *not* have that problem. It
>> just keeps the 'struct mm_struct' itself around.
> And that mm_struct will explode and only the VFS will catch it.
>
> Given  1024 processes * (RLIMIT_NOFILE 1024 - 3) == ~1020000
>
> more than 1020000 mm structs (all of dead processes ?)
>
> A quick test on a default ubuntu:
> cat /proc/sys/fs/file-max
> 388411
>
> So we are able to keep around 388411 dead mm_struct in memory, just try it.

Umm.

I think your argument is totally braindead and wrong.

My counter-argument is very simple: "So what?"

Those mm_structs are small. They are something like a couple of
hundred bytes. If you really worry about open files, you should worry
about the size of the inode, and people using the "pipe()" system
call. Then you have those open files with an inode, *and* several kB
of data that can be trivially filled by the user with a simple
"write()" that they never need read.

So "struct mm_struct" is totally irrelevant, and not in any way a
special thing. It's not the biggest, it's not the most interesting,
and it's simply not interesting. You're barking up the wrong tree.

> Our embedded devices will suffer, serial login will be killed, getty, ...
> ssh root owned ... I've experienced this.

None of it has anything to do with 'struct mm_struct', though, has it?

I suspect the real thing to do is to just make the OOM killer look at
how many files are open too. Make each open file count as 4kB (or
more), and use it when deciding what to kill. Fix the actual real
problem instead of trying to fix one small detail - and one that isn't
even the right small detail.

                   Linus

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.