Date: Thu, 15 Apr 2004 16:54:30 -0300
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Manfred Spraul <manfred@colorfullife.com>, linux-kernel@vger.kernel.org,
       drepper@redhat.com
Subject: Re: message queue limits
Message-ID: <20040415195430.GB3568@logos.cnet>
References: <407A2DAC.3080802@redhat.com> <20040415145350.GF2085@logos.cnet> <20040415122411.0bcb9195.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040415122411.0bcb9195.akpm@osdl.org>
User-Agent: Mutt/1.5.5.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1364
Lines: 31

On Thu, Apr 15, 2004 at 12:24:11PM -0700, Andrew Morton wrote:
> Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
> >
> > On Sun, Apr 11, 2004 at 10:48:28PM -0700, Ulrich Drepper wrote:
> >  > Something has to change in the way message queues are created.
> >  > Currently it is possible for an unprivileged user to exhaust all mq
> >  > slots so that only root can create a few more.  Any other unprivileged
> >  > user has no change to create anything.
> >  > 
> >  > I think it is necessary to create a per-user limit instead of a
> >  > system-wide limit.
> > 
> >  Actually, there is no infrastructure to account for per-UID limits right now AFAICS 
> >  (please someone correct me) at ALL. We need to account and limit for per-user
> > 
> >  - pending signals
> >  - message queues
> 
> The stuff in kernel/user.c may be sufficient for this.

Oh, sweat! I'll try adding a "atomic_t signal_pending" to "user_struct" 
to be checked at send_signal(), and then go for message queue limiting.

Something which sucks is to add a atomic read/inc at each send signal operation.

Can we avoid the locking in some way?
-
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/