Date: Tue, 20 Apr 2004 13:04:39 -0700
From: Andrew Morton <akpm@osdl.org>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: jakub@redhat.com, drepper@redhat.com, manfred@colorfullife.com,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] per-user signal pending and message queue limits
Message-Id: <20040420130439.23fae566.akpm@osdl.org>
In-Reply-To: <20040420141319.GB13259@logos.cnet>
References: <20040419212810.GB10956@logos.cnet>
	<20040419224940.GY31589@devserv.devel.redhat.com>
	<20040420141319.GB13259@logos.cnet>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1295
Lines: 30

Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
>
>  I wonder if it is a good idea to base mqueue limitation on the number of
> > message queues and not take into account how big they are.
> > 64 message queues with 1 byte msgsize and 1 maxmsg is certainly quite
> > harmless and the system could have even more queues for such a user,
> > while 64 message queues with 16K msgsize (current default) and 40 maxmsg
> > (also default) eats ~ 40M of kernel memory.
> 
> Indeed, it seems more correct to account for something else than "nr of message queues".
> 
> Memory occupied sounds better, yeap?
> 
> I'm sending the patch anyway, we can use the same RLIMIT_MSGQUEUE and user->msg_queues later 
> on with another meaning. 
> 
> Here it goes the update version, Andrew:

But we still have the global mq and signal limits?  These permit local
denials of service attacks.  See
http://seclists.org/lists/linux-kernel/2004/Apr/2065.html

The major advantage of your work is that we can now remove those limits. 
You'll be needing a 2.4 backport ;)

-
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/