Messages in this thread | | | Date | Wed, 21 Apr 2004 17:34:56 -0300 | From | Marcelo Tosatti <> | Subject | Re: [PATCH] per-user signal pending and message queue limits |
| |
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
- 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/
| |