On 27 Mar 2003, Alan Cox wrote:
> On Thu, 2003-03-27 at 17:33, Hugh Dickins wrote:
> > Here's a patch I've stolen from 2.4-ac, which is clearly correct so
> > far as it goes. I keep wanting to get this integrated into 2.4 and
> > 2.5, then bring shmem.c into line (in 2.5 use generic_write_checks).
> >
> > But each time I approach it, I get stuck on trying to understand the
> > code it's a good patch to. I understand that there's a problem with
> > loff_t twice as wide as rlim, and that we need to trim count down near
> > the limit. But I don't understand why 0xFFFFFFFFULL and (u32) rather
> > than RLIM_INFINITY and (unsigned long): are we really trying to
> > cripple 64-bit arches here?
>
> For 2.4 I just wanted to handle what we had and fix up the spec violations.
> For 2.5.x rlimit64 is calling 8)
Fixing up a silly in what's there, that I understand; and adding rlimit64,
that too. But on 64-bit arches, isn't rlimit already rlimit64?
If the answer to that is Yes, then doesn't the 0xFFFFFFFFULL test cripple
them? If the answer to that is No, then how come we're trying to handle
a case in which limit has more than 32 bits?
Hugh
-
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/
This archive was generated by hypermail 2b29 : Mon Mar 31 2003 - 22:00:28 EST