Re: [git pull] pull request for writable limits for 2.6.34-rc0

[Jiri Slaby <jirislaby@gmail.com>]

Hi.

On 03/21/2010 07:38 PM, Linus Torvalds wrote:
> Yeah, the infinity setting should be cleaned up. I also wonder if we 
> should clean up the odd file limit rules, and make them all be about 
> bytes. Correct me if I'm wrong, but don't we do that whole file size thing 
> in kilobytes right now?

Nope, it's just ulimit in bash who takes "blocks" and calls setrlimit
with 1024*value for core and file size limits.

> I do also agree that maybe we could/should skip the whole "writable /proc" 
> thing.

I agree too, why I had to implement is that we cannot assign syscall
numbers before merging upstream (for obvious reasons of not destroying
userspace interface where programs won't work on our distro) and we
needed the writable-limits feature.

> Or even just _one_ system call that takes two pointers, and can do an 
> atomic replace-and-return-the-old-value, like 'sigaction()' does, ie 
> something like
> 
> 	int prlimit64(pid, limit, const struct rlimit64 *new, struct rlimit64 *old);
> 
> wouldn't that be a nice generic interface?

Seconded. But should the limits be by default 64-bit even on 32-bit? I
mean: switch 'struct limit' in signal_struct to 'struct rlimit64'? This
would make the limits non-atomic on 32-bit. Oh, they are not already if
reader wants both cur and max without any locks, but I'm not sure now
what implications this will have (I haven't checked compilers, but I
think a store of 00000001 0000000 in place of 00000000 ffffffff may
result in a read of 00000001 ffffffff or alike). Or did I misunderstand you?

thanks,
-- 
js