From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751698AbcFNPVq (ORCPT ); Tue, 14 Jun 2016 11:21:46 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:36524 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750977AbcFNPVn (ORCPT ); Tue, 14 Jun 2016 11:21:43 -0400 Subject: Re: [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max To: Andy Lutomirski References: <1465847065-3577-1-git-send-email-toiwoton@gmail.com> <1465847065-3577-6-git-send-email-toiwoton@gmail.com> <887b928a-87f3-46aa-cfd3-d962fe40b85f@kernel.org> Cc: Andy Lutomirski , "linux-kernel@vger.kernel.org" , Alexander Viro , Ingo Molnar , Peter Zijlstra , Andrew Morton , Kees Cook , Cyrill Gorcunov , Alexey Dobriyan , John Stultz , Janis Danisevskis , Calvin Owens , Jann Horn , "open list:FILESYSTEMS (VFS and infrastructure)" From: Topi Miettinen Openpgp: id=A0F2EB0D8452DA908BEC8E911CF9ADDBD610E936 Message-ID: <0fefc5df-35c3-c144-74ea-940195384542@gmail.com> Date: Tue, 14 Jun 2016 15:21:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/13/16 21:16, Andy Lutomirski wrote: > On Mon, Jun 13, 2016 at 2:13 PM, Topi Miettinen wrote: >> On 06/13/16 20:40, Andy Lutomirski wrote: >>> On 06/13/2016 12:44 PM, Topi Miettinen wrote: >>>> Track maximum number of files for the process, present current maximum >>>> in /proc/self/limits. >>> >>> The core part should be its own patch. >>> >>> Also, you have this weirdly named (and racy!) function bump_rlimit. >> >> I can change the name if you have better suggestions. rlimit_track_max? >> >> The max value is written often but read seldom, if ever. What kind of >> locking should I use then? > > Possibly none, but WRITE_ONCE would be good as would a comment > indicating that your code in intentionally racy. Or you could use > atomic_cmpxchg if that won't kill performance. > > rlimit_track_max sounds like a better name to me. > >> >>> Wouldn't this be nicer if you taught the rlimit code to track the >>> *current* usage generically and to derive the max usage from that? >> >> Current rlimit code performs checks against current limits. These are >> typically done early in the calling function and further checks could >> also fail. Thus max should not be updated until much later. Maybe these >> could be combined, but not easily if at all. > > I mean: why not actually show the current value in /proc/pid/limits > and track the max via whatever teaches proc about the current value? > That could be interesting data too. In other comments, a new file was proposed and then your model would be good choice. >> >>> >>>> diff --git a/fs/proc/base.c b/fs/proc/base.c >>>> index a11eb71..227997b 100644 >>>> --- a/fs/proc/base.c >>>> +++ b/fs/proc/base.c >>>> @@ -630,8 +630,8 @@ static int proc_pid_limits(struct seq_file *m, >>>> struct pid_namespace *ns, >>>> /* >>>> * print the file header >>>> */ >>>> - seq_printf(m, "%-25s %-20s %-20s %-10s\n", >>>> - "Limit", "Soft Limit", "Hard Limit", "Units"); >>>> + seq_printf(m, "%-25s %-20s %-20s %-10s %-20s\n", >>>> + "Limit", "Soft Limit", "Hard Limit", "Units", "Max"); >>> >>> What existing programs, if any, does this break? >> >> Using Debian codesearch for /limits" string, I'd check pam_limits and >> rtkit. The max values could be put into a new file if you prefer. > > If it actually breaks them, then you need to change the patch so you > don't break them. >