Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 7 Dec 2000 10:27:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 7 Dec 2000 10:27:10 -0500 Received: from dfmail.f-secure.com ([194.252.6.39]:38409 "HELO dfmail.f-secure.com") by vger.kernel.org with SMTP id ; Thu, 7 Dec 2000 10:27:07 -0500 Date: Thu, 7 Dec 2000 17:09:12 +0200 (MET DST) From: Szabolcs Szakacsits To: Tigran Aivazian cc: Subject: Re: [PATCH] Broken NR_RESERVED_FILES In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 7 Dec 2000, Tigran Aivazian wrote: > On Thu, 7 Dec 2000, Szabolcs Szakacsits wrote: > > On Thu, 7 Dec 2000, Tigran Aivazian wrote: > > > On Thu, 7 Dec 2000, Szabolcs Szakacsits wrote: > > > > Reserved fd's for superuser doesn't work. > > > It does actually work, > > > > What do you mean under "work"? I meant user apps are able to > > exhaust fd's completely and none is left for superuser. > > really? how did you manage to do that? On a 2.4.0-test12-pre7 system I Just as you but I think you are testing on a margin condition [when all file structure were already allocated], just reboot and try it again. The failed logic is also clear from the kernel code [user happily allocates when freelist < NR_RESERVED_FILES]. Note, I tested only 2.2 but 2.4 apparently also has the same bad logic. Maybe with 2.4 you are also just lucky because of several other reasons [e.g. kernel tries harder to keep freelist high and you also have the fast enough box for it, etc]. > cannot reproduce the behaviour you describe. I.e. at least > NR_RESERVED_FILES (which I agree with you should be increased!) are left > to superuser processes whilst the user processes are denied. > > How exactly are you reproducing this? I wrote a simple while (1) > {open("/dev/null", 0); } program and run many instances of it as user. At > some stage user starts failing but superuser happily draws from the > freelist. Of course, the superuser cannot start complex programs which > require many descriptos but that is entirely the issues of Well, about maybe 'dmesg' will work, not others for the current default value (10). Note, the number of fd's aren't the *currently* used one but apparently about all of them - even if they were closed after the open - during the existence of the app [probably buffering and maybe this changed in 2.4]. > NR_RESERVED_FILES being too small on which I totally agree with you. Yep, with it's current value it's just a code decoration without any gains. Szaka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/