Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261199AbVA1Ief (ORCPT ); Fri, 28 Jan 2005 03:34:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261200AbVA1Ief (ORCPT ); Fri, 28 Jan 2005 03:34:35 -0500 Received: from mail.joq.us ([67.65.12.105]:58036 "EHLO sulphur.joq.us") by vger.kernel.org with ESMTP id S261199AbVA1Ied (ORCPT ); Fri, 28 Jan 2005 03:34:33 -0500 To: Ingo Molnar Cc: Nick Piggin , Paul Davis , Con Kolivas , linux , rlrevell@joe-job.com, CK Kernel , utz , Andrew Morton , alexn@dsv.su.se, Rui Nuno Capela , Chris Wright , Arjan van de Ven Subject: Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature References: <87wtu6fho8.fsf@sulphur.joq.us> <20050122165458.GA14426@elte.hu> <87hdl940ph.fsf@sulphur.joq.us> <20050124085902.GA8059@elte.hu> <20050124125814.GA31471@elte.hu> <20050125135613.GA18650@elte.hu> <87sm4opxto.fsf@sulphur.joq.us> <20050126070404.GA27280@elte.hu> <87fz0neshg.fsf@sulphur.joq.us> <1106782165.5158.15.camel@npiggin-nld.site> <20050128080802.GA2860@elte.hu> From: "Jack O'Quin" Date: Fri, 28 Jan 2005 02:35:30 -0600 In-Reply-To: <20050128080802.GA2860@elte.hu> (Ingo Molnar's message of "Fri, 28 Jan 2005 09:08:02 +0100") Message-ID: <871xc62bot.fsf@sulphur.joq.us> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Corporate Culture, linux) 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 Content-Length: 1381 Lines: 32 Ingo Molnar writes: > * Nick Piggin wrote: > >> And finally, with rlimit support, is there any reason why lockup >> detection and correction can't go into userspace? Even RT throttling >> could probably be done in a userspace daemon. > > that is correct. Jackd already has a watchdog thread, against lockups. > > i'm wondering, couldnt Jackd solve this whole issue completely in > user-space, via a simple setuid-root wrapper app that does nothing else > but validates whether the user is in the 'jackd' group and then keeps a > pipe open to to the real jackd process which it forks off, deprivileges > and exec()s? Then unprivileged jackd could request RT-priority changes > via that pipe in a straightforward way. Jack normally gets installed as > root/admin anyway, so it's not like this couldnt be done. Perhaps. Until recently, that didn't work because of the longstanding rlimits bug in mlockall(). For scheduling only, it might be possible. Of course, this violates your requirement that the user not be able to lock up the CPU for DoS. The jackd watchdog is not perfect. -- joq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/