Message-ID: <4085667C.5080001@colorfullife.com>
Date: Tue, 20 Apr 2004 20:05:48 +0200
From: Manfred Spraul <manfred@colorfullife.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.4.1) Gecko/20031114
MIME-Version: 1.0
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
CC: Jakub Jelinek <jakub@redhat.com>, akpm@osdl.org, drepper@redhat.com,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] per-user signal pending and message queue limits
References: <20040419212810.GB10956@logos.cnet> <20040419224940.GY31589@devserv.devel.redhat.com> <20040420141319.GB13259@logos.cnet>
In-Reply-To: <20040420141319.GB13259@logos.cnet>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 866
Lines: 24

Marcelo Tosatti wrote:

>Indeed, it seems more correct to account for something else than "nr of message queues".
>
>Memory occupied sounds better, yeap?
>  
>
I agree, but note that there is one hidden problem:
There can be one notification for each registered message queue. If 
there are more than ~560 queues and one process wants to install 
SIGEV_THREAD notification handlers for all of them, then the netfilter 
code will run against the socket rmem limit and mq_notify will block.
_If_ there are users that do that we'll have to bypass the normal 
sk_rmem_alloc and add an mqueue specific limit.

--
    Manfred


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