From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752807AbdCHMHv (ORCPT ); Wed, 8 Mar 2017 07:07:51 -0500 Received: from mailout4.samsung.com ([203.254.224.34]:37739 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750763AbdCHMHa (ORCPT ); Wed, 8 Mar 2017 07:07:30 -0500 X-AuditID: b6c32a38-f79f06d000001a72-b3-58bfd46c14f7 Subject: Re: counting file descriptors with a cgroup controller To: Tejun Heo Cc: lizefan@huawei.com, hannes@cmpxchg.org, =?UTF-8?Q?=c5=81ukasz_Stelmach?= , linux-kernel@vger.kernel.org, Karol Lewandowski , cgroups@vger.kernel.org From: Krzysztof Opasiak Message-id: <50e07c29-295a-62fd-e0ad-7e52d5b55c7d@samsung.com> Date: Wed, 08 Mar 2017 10:52:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-version: 1.0 In-reply-to: <20170307204825.GH31179@htj.duckdns.org> Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsWy7bCmvm7Olf0RBk2LpSxuLJ/BYrF6k69F 46e5zBY3D61gtLi8aw6bxaSOXnaLX8uPMjqwexx+857Zo+XIW1aPTas62Tz6tqxi9Pi8SS6A NYrLJiU1J7MstUjfLoEro3HGH5aCNQIVm9asY2tg/MvTxcjJISFgInGrYy8jhC0mceHeerYu Ri4OIYEdjBI9n+cwQzjtTBLdu24AORxgHV+3BkHE5zBKTFmwhAnCuc8ocfjZUnaQUcIC9hLn zx1kAbFFBGQlrkx7yAhSxCxwjlFi7b9V7CCT2AT0JebtEgWp4RWwk3j79xgriM0ioCqx+Mlb sBJRgQiJ/jPqECWCEj8m3wMbySlgKrHr2yOwVcwCjhIPFu1khbDlJTaveQt2tITAOnaJ3mkr 2CGOlpXYdIAZ4ksXiQn/FrNC2MISr45vYYewpSVW/bvFBNHbzCjRsecZC4QzgVFi27pDUFXW En9WTWSD2MYn8e5rDyvEAl6JjjYhiBIPicsTNrNA2I4Sq//NYYEE0HJmiV2f57FMYJSfheSh WUiemIXkiQWMzKsYxVILinPTU4sNC0z0ihNzi0vz0vWS83M3MYJTipbFDsY953wOMQpwMCrx 8Hqc3RchxJpYVlyZe4hRgoNZSYT3wcX9EUK8KYmVValF+fFFpTmpxYcYpTlYlMR5WQ0mRggJ pCeWpGanphakFsFkmTg4pRoYfd5P/Zf56vS3+bM+fJj5/MXe3w68wl+8o81dZ6U7MPqsmbBk l2486/1q/qAy7Yvsl7Z09W3aZ5zRnv2n5fSR0NqcHzK1Sp22VbeO31dU0GK5Y1RlIHnRYMPp OI8/5QLz//705hFnWxD3Ppczf0r2xplct87zrFX6r+cU+ZvPzOvpvqL0m9FmSizFGYmGWsxF xYkAOs/fGiUDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsVy+t9jQd2cK/sjDI4+4rW4sXwGi8XqTb4W jZ/mMlvcPLSC0eLyrjlsFpM6etktfi0/yujA7nH4zXtmj5Yjb1k9Nq3qZPPo27KK0ePzJrkA 1ig3m4zUxJTUIoXUvOT8lMy8dFul0BA3XQslhbzE3FRbpQhd35AgJYWyxJxSIM/IAA04OAe4 Byvp2yW4ZTTO+MNSsEagYtOadWwNjH95uhg5OCQETCS+bg3qYuQEMsUkLtxbz9bFyMUhJDCL UWLu2hZmCOcho8SeTy+ZQKqEBewlzp87yAJiiwjISlyZ9pARomgls8T0+9/A2pkFLjBK7Py/ lBlkBZuAvsS8XaIgDbwCdhJv/x5jBbFZBFQlFj95yw5iiwpESNx62MECUSMo8WPyPTCbU8BU Yte3R2A1zAK2Egver2OBsOUlNq95yzyBEehOhJZZSMpmISlbwMi8ilEitSC5oDgpPdcwL7Vc rzgxt7g0L10vOT93EyM4xp5J7WA8uMv9EKMAB6MSD++HU/sihFgTy4orcw8xSnAwK4nwPri4 P0KINyWxsiq1KD++qDQntfgQoynQIxOZpUST84Hxn1cSb2hibmJubGBhbmlpYqQkzts4+1m4 kEB6YklqdmpqQWoRTB8TB6dUA6No+As1Bq7prffulEic2iChylHRPKNX/ErzBsvfF5XePt7G LHY/pf2aWf+Kuev3exZsfpvwY4Pxb/Xu2gwRScvDC4pMN2i2/yhrTpKyYghNK53q/9Y98eum 7d0BjR8efjq0PnLxgYqene3LbxT2lZRJHdxwVvFXqd41lfJLU671hvuo2CpKbFZiKc5INNRi LipOBACXMXHSxwIAAA== X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170308095244epcas1p2054aff5475c315192ddf60379f1bb660 X-Msg-Generator: CA X-Sender-IP: 203.254.230.26 X-Local-Sender: =?UTF-8?B?S3J6eXN6dG9mIE9wYXNpYWsbU1JQT0wtU3lzdGVtIChUUCkb?= =?UTF-8?B?7IK87ISx7KCE7J6QG1NvZnR3YXJlIEVuZ2luZWVy?= X-Global-Sender: =?UTF-8?B?S3J6eXN6dG9mIE9wYXNpYWsbU1JQT0wtU3lzdGVtIChUUCkb?= =?UTF-8?B?U2Ftc3VuZ8KgRWxlY3Ryb25pY3MbU29mdHdhcmUgRW5naW5lZXI=?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjczOTY=?= CMS-TYPE: 101P X-HopCount: 7 X-CMS-RootMailID: 20170217093725eucas1p12478baf297d25303f3020f4973fbf3b0 X-RootMTR: 20170217093725eucas1p12478baf297d25303f3020f4973fbf3b0 References: <87poihtaya.fsf%l.stelmach@samsung.com> <9a57890c-d9e9-5719-e155-ce1161795a02@samsung.com> <20170306185820.GA19696@htj.duckdns.org> <7fbd9c4c-76ca-4073-9afa-1ab54364ec79@samsung.com> <20170307194134.GE31179@htj.duckdns.org> <9ee62e45-6645-454b-11b5-85be746bc81a@samsung.com> <20170307204825.GH31179@htj.duckdns.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/07/2017 09:48 PM, Tejun Heo 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. >> >> 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? > Well detecting failures of open is not enough and it has couple of problems: 1) open(2) is not the only syscall which creates fd. In addition to other syscalls like socket(2), dup(2), some ioctl() on drivers (for example video) also creates fds. I'm not sure if we have any other mechanism than grep through kernel source to find out which ioctl() creates fd or and which not. 2) As far as I know (I'm not a bpf specialist so please correct me if I'm wrong), with bpf we are able only to detect such events but we are unable to prevent them from getting to caller. It means that service will know that it run out of fds and will need to handle this properly. If there is a bug in this error path service may crash. What we would like to get is just a notification to external process that some limit has been reached without returning error to service itself. 3) Theoretically we could do this using bpf or syscall auditing and count fds for each userspace process or check /proc/ after each notification but it's getting very heavy for production environment. Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics