[RTEMS Project] #2384: [PATCH] [NFS client] Respect 2^32 - 1 B NFSv2 maximum file size

[RTEMS trac]

#2384: [PATCH] [NFS client] Respect 2^32 - 1 B NFSv2 maximum file size
--------------------------+--------------------
 Reporter:  nick.withers  |      Owner:
     Type:  defect        |     Status:  new
 Priority:  normal        |  Milestone:  4.11.1
Component:  filesystem    |    Version:  4.11
 Severity:  normal        |   Keywords:
--------------------------+--------------------
 The RTEMS NFS(v2) client in at least 4.11 and master does not range check
 ''off_t'' values before assigning them into NFSv2's on-the-wire 32-bit
 unsigned file offset field.

 Reads from and writes to an offset at or above 4 GiB will currently
 silently be remapped to the mod 2^32 location (on two's complement
 machines at least).

 The attached patch checks for negative offsets [1] and out of [0 -
 UINT32_MAX)-range access in nfs_file_read(), nfs_file_write() and
 nfs_file_ftruncate(). It doesn't touch the lseek() implementation, so an
 lseek() past NFSv2 range will still "succeed" - a subsequent read or write
 there won't. I think this is POSIX-compliant [2], however.

 [1] Perhaps unnecessary if it's impossible for a negative offset to be
 obtained without e.g., an application user twiddling things they
 shouldn't? lseek() at least does correctly error on obtaining negative
 offsets

 [2] e.g.,
 http://pubs.opengroup.org/onlinepubs/009695399/functions/lseek.html
 doesn't explicitly seem to require lseek() to fail for out-of range
 offsets that aren't negative, and it mustn't do a resize itself

--
Ticket URL: <http://devel.rtems.org/ticket/2384>
RTEMS Project <http://www.rtems.org/>
RTEMS Project