On Wed, 5 May 2010, Jiri Slaby wrote:
quoted text
> 
> So I ended up with thinking about these possibilities:
> 
> 1) internal representation of limits will stay as is in signal_struct,
> i.e. long limits with infinity being ~0ul. This is the least intrusive
> solution. The new prlimit64 will convert rlimit64 to rlimit and pass
> down to do_prlimit. With setrlimit and getrilimit just as wrappers it
> will look like:
> prlimit64(pid, resource, new64, old64) ->
>     new = convert_to_rlim(new64)
>     tsk = find_task(pid)
>     do_prlimit(tsk, resource, new, old)
>     old64 = convert_to_rlim64(old)
> setrlimit(resource, rlim) ->
>     do_prlimit(current, resource, rlim, NULL)
> getrlimit(resource, rlim) ->
>     do_prlimit(current, resource, NULL, rlim)
> with appropriate copy_{from,to}_user. (And setrlimit+getrlimit will be
> scheduled for removal with all the compat crap around them.)

Yes, this sounds much better to me.

quoted text
> It may also be that rlimit64 will contain flags like:
> #define RLIM64_CUR_INFINITY     0x00000001
> #define RLIM64_MAX_INFINITY     0x00000002
> struct rlimit64 {
>         __u64 rlim_cur;
>         __u64 rlim_max;
>         __u32 flags;
> };
> if I understood Alexey correctly to separate limits values from
> infinity? flags then will be converted to ~0ul when converting from
> rlimit64 to rlimit above too.

Ok, I'm not entirely sure we need to care specially about INFINITY, 
_especially_ since INF is really rather big in 64 bits. So to some degree, 
making things 64-bit is _less_ likely to make INFINITIES a problem.

It's also impossible to convert back and forth reliably unless you were to 
add this bit to the internal rlimit structure too. It sounds like a bad 
design to have

	prlimit64(-1, limit, &new, NULL);
	prlimit64(-1, limit, NULL, &old);

result in "old" containing something different than "new".

Of course, if there are 32-bit/64-bit issues, the above can _never_ give 
the same results for >= (1<<32) values, but that's a somewhat separate 
issue, and is directly tied to the word-size, not some new internal flag.

quoted text
> The drawback is when a 32-bit user passes down a value >= (1 << 32),
> EINVAL shall occur.

I'd almost prefer to just turn them into RLIMIT_MAX. If somebody asks for 
a really huge limit that is bigger than the max we already have, doesn't 
RLIMIT_MAX sound like the right thing?

quoted text
> 2) Introduce an rlimit lock and move every user to the rlimit helpers
> which appropriately lock the accesses. And making locking a nop when
> BITS_PER_LONG == 64. Then we can have rlimit64 in signal_struct and
> everything will happen on 64-bit limit values.

I think long-term we might want to do this, but not as a first stage. And 
if the 'infinity' flag makes sense, _and_ we decide that long-term we want 
to do this, then I'm not objecting to adding it now.

quoted text
> Just a side note, we cannot use the rlimit64 name which is already
> reserved in glibc headers for limits handling.

What does the glibc 'struct rlimit64' look like? It's the structure name 
that matters, since the system call name would presumably be 'prlimit64()' 
due to the pid thing.

And if the glibc rlimit64 matches what we would use, I think we can decide 
to just re-use it.

		Linus
--
unsubscribe notice
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/