Re: [PATCH] per-user signal pending and message queue limits

[Marcelo Tosatti <marcelo.tosatti@cyclades.com>]

On Tue, Apr 20, 2004 at 04:34:43PM -0700, Andrew Morton wrote:
> Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
> >
> > > The major advantage of your work is that we can now remove those limits. 
> > > You'll be needing a 2.4 backport ;)
> > 
> > Yeap. :) 
> > 
> > And we also need to do the userspace part. ulimit is part of bash, so 
> > probably all shell's should be awared of this? I never looked
> > how "ulimit" utility works.
> 
> yup, the shells need to be changed, which is really awkward.  I was wrong
> about how bash and zsh handle `ulimit 4 1024'.
> 
> Really the shells _should_ permit ulimit-by-number for this very reason.
> 
> Adding new ulimits is nice - it's a shame that the shells make it hard to
> use.

I'm thinking about how to do the mqueue "kernel allocated memory" accounting, 
and I have a problem. A user can create an mqueue of given size via sys_mq_open()
using "msg_attr" structure (will be created in do_create). I can account for how much 
memory has been allocated, but I can't at "deaccount" at kfree() time (this memory 
is stored in inode->(mqueue_inode_info *)info->messages), because I dont know how big
it is (its user selectable via "msg_attr" structure). 

What can be done about this?

Creating a data structure to account for "allocation->allocation size" 
sounds overly complicated at first, but might be necessary if correct
accounting is necessary?

Gracias