From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755628AbcHXLYd (ORCPT ); Wed, 24 Aug 2016 07:24:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34978 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751025AbcHXLYb (ORCPT ); Wed, 24 Aug 2016 07:24:31 -0400 Date: Wed, 24 Aug 2016 13:24:28 +0200 From: Jiri Olsa To: Yauheni Kaliuta Cc: linux-kernel@vger.kernel.org, Aristeu Rozanski , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Alexander Shishkin , Steven Rostedt Subject: Re: [RFC] rlimit exceed notification events Message-ID: <20160824112428.GA15743@krava> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.0 (2016-08-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 24 Aug 2016 11:24:31 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 19, 2016 at 05:41:20PM +0300, Yauheni Kaliuta wrote: > Hi! > > At the moment there is no clear indication if a process exceeds resource > limit. In some cases the problematic syscall can return a error, in some cases > the process can be just killed. > > I'm trying to implement some sort of monitoring of such events and have a > question, what way would be acceptable. > > 1) The straight forward solution would be to instrument every such a place with > a printk (something related implemented, for example, by > d977d56ce5b3e8842236f2f9e7483d4914c9592e). > > It has some concerns about reliablity and performance (giving a way to flood > printk buffer because of bad application, for example). > > 2) Using tracepoints. I've used a simple program, which dup()s until gets the > error 3 times: just to start up the discussion.. ;-) I'd think this one (2) is the proper way, but generaly you need to come with good justification/usecase to add new tracepoint also rlimit seems to be difficult to add tracepoints to, because the checks are spread all over the code.. can't think of a good solution ATM > $ sudo ./perf record -e rlimit:rlimit_exceeded ./a.out > Couldn't dup file: Too many open files, iteration 1020 > Couldn't dup file: Too many open files, iteration 1021 > Couldn't dup file: Too many open files, iteration 1022 > [ perf record: Woken up 1 times to write data ] > [ perf record: Captured and wrote 0.010 MB perf.data (3 samples) ] > > $ sudo ./perf report > # To display the perf.data header info, please use --header/--header-only options. > # > # > # Total Lost Samples: 0 > # > # Samples: 3 of event 'rlimit:rlimit_exceeded' > # Event count (approx.): 3 > # > # Overhead Trace output > # ........ ........................................................ > # > 100.00% RLIMIT NOFILE violation. Current 1024, requested Unknown > > The code to demonstrate the idea below: > > diff --git a/fs/file.c b/fs/file.c > index 6b1acdfe59da..a358de041ac4 100644 > --- a/fs/file.c > +++ b/fs/file.c > @@ -947,6 +947,9 @@ SYSCALL_DEFINE1(dup, unsigned int, fildes) > else > fput(file); > } > + if (ret == -EMFILE) > + rlimit_exceeded(RLIMIT_NOFILE, > + rlimit(RLIMIT_NOFILE), (u64)-1); > return ret; how about other places? alloc_fd/get_unused_fd_flags/replace_fd.. jirka