Message ID | f870c029-140d-3e77-dcd1-1890025b5795@kernel.dk (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [GIT,PULL] bdev size cleanups | expand |
On Sun, Oct 31, 2021 at 12:41 PM Jens Axboe <axboe@kernel.dk> wrote: > > On top of the core block branch, this topic branch cleans up the bdev > size handling. So on the whole this seems to be a good cleanup, but some of it worries me. For example, it seems to have lost the cast to "loff_t" when generating the byte size from a "sector_t". Ok, so these days those are both 64-bit, and it doesn't actually matter (the time when we had a 32-bit sector_t as an option are long gone), but I think that bdev_nr_bytes() helper really ends up being subtler than it looks. It very much depends on 'sector_t' and 'loff_t' being the same size (although sector_t is an u64, loff_t ends up being the signed version). I've pulled this, but I do think it might have been better with the type conversion being explicit. One of the reasons we had "sector_t" originally was that it ended up being configuration-dependent, and could be 32-bit. Those times may be gone, but it's still conceptually a very different type from "loff_t". Linus
The pull request you sent on Sun, 31 Oct 2021 13:41:51 -0600:
> git://git.kernel.dk/linux-block.git tags/for-5.16/bdev-size-2021-10-29
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3f01727f750eae3e61b738b57355b2538ab179f4
Thank you!
On 11/1/21 11:02 AM, Linus Torvalds wrote: > On Sun, Oct 31, 2021 at 12:41 PM Jens Axboe <axboe@kernel.dk> wrote: >> >> On top of the core block branch, this topic branch cleans up the bdev >> size handling. > > So on the whole this seems to be a good cleanup, but some of it worries me. > > For example, it seems to have lost the cast to "loff_t" when > generating the byte size from a "sector_t". > > Ok, so these days those are both 64-bit, and it doesn't actually > matter (the time when we had a 32-bit sector_t as an option are long > gone), but I think that bdev_nr_bytes() helper really ends up being > subtler than it looks. It very much depends on 'sector_t' and 'loff_t' > being the same size (although sector_t is an u64, loff_t ends up being > the signed version). > > I've pulled this, but I do think it might have been better with the > type conversion being explicit. One of the reasons we had "sector_t" > originally was that it ended up being configuration-dependent, and > could be 32-bit. Those times may be gone, but it's still conceptually > a very different type from "loff_t". Yes, probably safer just to make bdev_nr_bytes() return sector_t as well, even if loff_t isn't strictly wrong. Christoph, want to do a followup?
On Mon, Nov 1, 2021 at 4:20 PM Jens Axboe <axboe@kernel.dk> wrote: > > Yes, probably safer just to make bdev_nr_bytes() return sector_t as > well, even if loff_t isn't strictly wrong. Well, that would actually change the sign of some of the existing comparisons. Possibly changing their meaning entirely.. So having 'loff_t' being signed may be an odd choice for a byte size, but it is what it is. At least the current set of cleanups seemed to keep the type logic the same when it changed i_size_read() to be bdev_nr_bytes() instead. Changing it to 'sector_t' not only doesn't make conceptual sense when it's a byte count, it might also be dangerous. So my reaction was really that it wasn't obvious that bdev_nr_bytes() did the shift in the right type.. It does happen to do that, but historically sector_t was the smaller type. Linus
On Mon, Nov 01, 2021 at 05:19:58PM -0600, Jens Axboe wrote: > Yes, probably safer just to make bdev_nr_bytes() return sector_t as > well, even if loff_t isn't strictly wrong. Christoph, want to do a > followup? sector_t is wrong. I actually did that in the very first version accidentally and willy pointed out that this is wrong. If Linus really wants that we can add the cast.
On 11/1/21 5:50 PM, Linus Torvalds wrote: > On Mon, Nov 1, 2021 at 4:20 PM Jens Axboe <axboe@kernel.dk> wrote: >> >> Yes, probably safer just to make bdev_nr_bytes() return sector_t as >> well, even if loff_t isn't strictly wrong. > > Well, that would actually change the sign of some of the existing > comparisons. Possibly changing their meaning entirely.. > > So having 'loff_t' being signed may be an odd choice for a byte size, > but it is what it is. At least the current set of cleanups seemed to > keep the type logic the same when it changed i_size_read() to be > bdev_nr_bytes() instead. > > Changing it to 'sector_t' not only doesn't make conceptual sense when > it's a byte count, it might also be dangerous. > > So my reaction was really that it wasn't obvious that bdev_nr_bytes() > did the shift in the right type.. It does happen to do that, but > historically sector_t was the smaller type. OK, I misunderstood your original email, as per Christoph's email as well. May be worth adding loff_t cast, if for nothing else just to have it stick out to the next person touching it.