All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [GIT PULL] bdev size cleanups
Date: Mon, 1 Nov 2021 17:19:58 -0600	[thread overview]
Message-ID: <71c40f9b-7f83-be81-18cf-297077db005c@kernel.dk> (raw)
In-Reply-To: <CAHk-=wii3c_VebHJxEyqU5P6FKjOLirYHQm+0=oaL59DNi-t1A@mail.gmail.com>

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?

-- 
Jens Axboe


  reply	other threads:[~2021-11-01 23:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-31 19:41 [GIT PULL] bdev size cleanups Jens Axboe
2021-11-01 17:02 ` Linus Torvalds
2021-11-01 23:19   ` Jens Axboe [this message]
2021-11-01 23:50     ` Linus Torvalds
2021-11-02 15:28       ` Jens Axboe
2021-11-02  6:10     ` Christoph Hellwig
2021-11-01 17:28 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=71c40f9b-7f83-be81-18cf-297077db005c@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.