On 12/17/19 1:26 PM, Linus Torvalds wrote: > On Tue, Dec 17, 2019 at 11:39 AM Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> 'loff_t length' is not right. > > Looking around, it does seem to get used that way. Too much, though. > >>> + loff_t pos = data->pos; >>> + loff_t length = pos + data->len; >> >> And WTH is that? "pos + data->len" is not "length", that's end. And this: >> >>> loff_t end = pos + length, done = 0; >> >> What? Now 'end' is 'pos+length', which is 'pos+pos+data->len'. > > But this is unrelated to the crazy types. That just can't bve right. Yeah, I fixed that one up, that was my error. >> Is there some reason for this horrible case of "let's allow 64-bit sizes?" >> >> Because even if there is, it shouldn't be "loff_t". That's an >> _offset_. Not a length. > > We do seem to have a lot of these across filesystems. And a lot of > confusion. Most of the IO reoutines clearly take or return a size_t > (returning ssize_t) as the IO size. And then you have the > zeroing/truncation stuff that tends to take loff_t. Which still smells > wrong, and s64 would look like a better case, but whatever. > > The "iomap_zero_range() for truncate" case really does seem to need a > 64-bit value, because people do the difference of two loff_t's for it. > In fact, it almost looks like that function should take a "start , > end" pair, which would make loff_t be the _right_ thing. > > Because "length" really is just (a positive) size_t normally. Honestly, I'd much rather leave the loff_t -> size_t/ssize_t to Darrick/Dave, it's really outside the scope of this patch, and I'd prefer not to have to muck with it. They probably feel the same way! -- Jens Axboe
