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

From: Marcelo Tosatti
Date: Wed Apr 21 2004 - 15:54:56 EST

On Tue, Apr 20, 2004 at 04:34:43PM -0700, Andrew Morton wrote:
> Marcelo Tosatti <marcelo.tosatti@xxxxxxxxxxxx> 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?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at