Messages in this thread |  | | From | David Laight <> | Subject | RE: [PATCH v3] qnx4: qnx4_block_map error handling | Date | Tue, 3 Nov 2020 21:57:32 +0000 |
| |
From: Tong Zhang > Sent: 03 November 2020 13:53 ... > > Also 'blknum' is only 'unsigned long' so ~0ull is wrong. > > It can be worth injecting an error and checking the error > > propagation works. > > > > What is the actual maximum file size?
> The maximum file size is 2GB-1, but from my understanding > qnx4_block_map() returns a physical block number. > The max disk size supported is 2**64 bytes, however > it is limited to unsigned long (2**32) > -- so I am actually very hesitant to encode an error code in the return value > without changing the function return type, which will introduce more > changes I don't like. > The original -EIO in qnx4_block_map() is also dodgy btw.
You've put your hand into a bag of worms...
Looks like a load of the 'long' need to be 64bit.
I'm actually surprised how often 'long' appears in the linux kernel. I don't believe there was ever a 16bit version (eg 286) where 'long' was 32bit.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
|  |