Unix CM: Fix negative file length case, again
authorSimon Wilkinson <sxw@inf.ed.ac.uk>
Sat, 16 Jan 2010 02:09:34 +0000 (02:09 +0000)
committerDerrick Brashear <shadow|account-1000005@unknown>
Sat, 16 Jan 2010 15:00:34 +0000 (07:00 -0800)
As originally noted in f6f9ee5402f1718f330a00ec89fb34b05c3cd360
some fileservers return a negative length, typically when a client
is attempting to fetch data that is past the extents of the file,
the CM needs to retain this negative length, and handle it correctly.

c7b92a3018044f7aca4d9a77644e5c06ef64d1e9 added safety checks for
the fileserver returning a length larger than that asked for by
the client. Sadly, this check does a comparison between a
signed, and an unsigned, variable. This leads to it incorrectly
classifying negative responses as being too large.

Add a cast, and a comment, to fix this.

Change-Id: I2ca67f55204c565667d5cd91cde3d520f8d9b10c
Reviewed-on: http://gerrit.openafs.org/1109
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Derrick Brashear <shadow@dementia.org>

src/afs/afs_fetchstore.c

index 5ddd586..771ce0b 100644 (file)
@@ -989,7 +989,10 @@ rxfs_fetchInit(struct afs_conn *tc, struct vcache *avc, afs_offs_t base,
     } else
        code = -1;
 
-    if (*alength > size) {
+    /* We need to cast here, in order to avoid issues if *alength is
+     * negative. Some, older, fileservers can return a negative length,
+     * which the rest of the code deals correctly with. */
+    if (*alength > (afs_int32) size) {
        /* The fileserver told us it is going to send more data than we
         * requested. It shouldn't do that, and accepting that much data
         * can make us take up more cache space than we're supposed to,