wonderffffffffull ac filemap patch

wonderffffffffull ac filemap patch

[Hugh Dickins]

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?

Hugh

--- 2.5.66-mm1/mm/filemap.c	Wed Mar 26 11:50:36 2003
+++ linux/mm/filemap.c	Thu Mar 27 16:53:46 2003
@@ -1509,7 +1509,10 @@
 				send_sig(SIGXFSZ, current, 0);
 				return -EFBIG;
 			}
-			if (*pos > 0xFFFFFFFFULL || *count > limit-(u32)*pos) {
+			/* Fix this up when we got to rlimit64 */
+			if (*pos > 0xFFFFFFFFULL)
+				*count = 0;
+			else if (*count > limit - (u32)*pos) {
 				/* send_sig(SIGXFSZ, current, 0); */
 				*count = limit - (u32)*pos;
 			}

Re: wonderffffffffull ac filemap patch

[Alan Cox]

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)

Re: wonderffffffffull ac filemap patch

[Hugh Dickins]

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

Re: wonderffffffffull ac filemap patch

[Alan Cox]

On Thu, 2003-03-27 at 17:59, Hugh Dickins wrote:
> > 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?

Infallibility is only available by special request. I'd have to read the
code and specs again but what you say sounds quite reasonable since off_t
would be 64bit, and rlimit types likewise