linux-kernel - Re: [RFC] cgroups: Resource controller for open files.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Wed, 2 Jul 2014 11:02:34 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Binder Makin <merimus@...gle.com>
Cc:	viro@...iv.linux.org.uk, linux-kernel@...r.kernel.org,
	Daniel Jacobowitz <dmj@...gle.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Michal Hocko <mhocko@...e.cz>, Li Zefan <lizefan@...wei.com>,
	cgroups@...r.kernel.org
Subject: Re: [RFC] cgroups: Resource controller for open files.

On Wed, Jul 02, 2014 at 10:55:01AM -0400, Binder Makin wrote:
> It does allow processes which are used to handling file handled to deal
> with the situation more cleanly.
> If you get the ENOMEM then you are out of memory and you kill the process,
> but if you are out of file handles we can clean up the open handles and
> continue.

I don't know.  If the program can manage fds dynamically, it may as
well police itself under a sensible limit.  I get that programs which
already work with EMFILE may benefit from this but this isn't adding
any essential feature and the same goal can be trivially achieved
without any help from kernel as the benefits from EMFILE handling
assumes the program is well-behaving.  I'm very doubtful that
custom-fitting kernel behavior to specific and rather peculiar program
behaviors is a healthy approach.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/