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
| ||
|
Date: Tue, 7 Mar 2017 20:59:39 -0600 From: Parav Pandit <pandit.parav@...il.com> To: Tejun Heo <tj@...nel.org> Cc: Krzysztof Opasiak <k.opasiak@...sung.com>, Li Zefan <lizefan@...wei.com>, Johannes Weiner <hannes@...xchg.org>, Ćukasz Stelmach <l.stelmach@...sung.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Karol Lewandowski <k.lewandowsk@...sung.com>, cgroups@...r.kernel.org Subject: Re: counting file descriptors with a cgroup controller Hi, On Tue, Mar 7, 2017 at 2:48 PM, Tejun Heo <tj@...nel.org> wrote: > > Hello, > > On Tue, Mar 07, 2017 at 09:06:49PM +0100, Krzysztof Opasiak wrote: > > Personally, I don't want to use rlimit for this as it ends up returning > > error code from for example open() when we hit the limit. This may lead to > > some unpredictable crashes in services (esp. those poor proprietary binary > > blobs). Instead of injecting errors to service we would like to just get > > notification that this service has more opened fds than it should and ask it > > to restart in a polite way. > > How does those poor proprietary binary blobs remain polite after restart? Do you mean you want to keep restarting them when it reaches the limit? > > For memory seems to be quite easy to achieve as we can just get eventfd > > notification when application passes given memory usage using memory cgroup > > controller. Maybe you know some efficient method to do the same for fds? > > So, if all you wanna do is reliably detecting open(2) failures, can't > you do that with bpf tracing? > > Thanks. > > -- > tejun > -- > To unsubscribe from this list: send the line "unsubscribe cgroups" in > the body of a message to majordomo@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists