]> git.neil.brown.name Git - history.git/commit
[PATCH] file limit checking simplification
authorAndrew Morton <akpm@digeo.com>
Thu, 3 Apr 2003 00:26:51 +0000 (16:26 -0800)
committerLinus Torvalds <torvalds@home.transmeta.com>
Thu, 3 Apr 2003 00:26:51 +0000 (16:26 -0800)
commitd80bbda59ff794db16efa0bf7a4889b8096b0e54
tree8f515a84c0e100149cff1dc35072c1c09e7d2ee7
parent240d3e2d1f4dad9d40ad101352538d75e8c37c98
[PATCH] file limit checking simplification

From: Hugh Dickins <hugh@veritas.com>

When handling rlimit != RLIM_INFINITY, generic_write_checks tests file
position against 0xFFFFFFFFULL, and casts it to a u32.  This code is
carried forward from 2.4.4, and the 2.4-ac tree contains an apparently
obvious fix to one part of it (should set count to 0 not to a negative).
But when you think it through, it all turns out to be bogus.

On a 32-bit architecture: limit is a 32-bit unsigned long, we've
already handled *pos < 0 and *pos >= limit, so *pos here has no way
of being > 0xFFFFFFFFULL, and thus casting it to u32 won't truncate it.
And on a 64-bit architecture: limit is a 64-bit unsigned long, but this
code is disallowing file position beyond the 32 bits; or if there's some
userspace compatibility issue, with limit having to fit into 32 bits,
the 32-bit architecture argument applies and they're still irrelevant.

So just remove the 0xFFFFFFFFULL test; and in place of the u32, cast to
typeof(limit) so it's right even if rlimits get wider.  And there's no
way we'd want to send SIGXFSZ below the limit: remove send_sig comment.

There's a similarly suspicious u32 cast a little further down, when
checking MAX_NON_LFS.  Given its definition, that does no harm on any
arch: but it's better changed to unsigned long, the type of MAX_NON_LFS.
mm/filemap.c