public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
To: Greg KH <greg@kroah.com>, Stable <stable@vger.kernel.org>
Cc: linux-block <linux-block@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>, Dave Chinner <dchinner@redhat.com>,
	Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>,
	Ming Lei <ming.lei@redhat.com>
Subject: [PATCH v4.19 2/2] block: fix 32 bit overflow in __blkdev_issue_discard()
Date: Thu, 30 Jan 2020 17:53:22 +0300	[thread overview]
Message-ID: <158039600260.4465.8760113992408208442.stgit@buzz> (raw)
In-Reply-To: <158039599680.4465.7011319825891038466.stgit@buzz>

From: Dave Chinner <dchinner@redhat.com>

Commit 4800bf7bc8c725e955fcbc6191cc872f43f506d3 upstream.

-- snip --

Overflow in __blkdev_issue_discard() actually exists since 4.18
commit af097f5d199e2aa3ab3ef777f0716e487b8f7b08 ("block: break discard
submissions into the user defined size"):

- req_sects = min_t(sector_t, nr_sects, UINT_MAX >> 9);
+ req_sects = min_t(sector_t, nr_sects, q->limits.max_discard_sectors)

Default max_discard_sectors could be bigger than UINT_MAX.

And finally 4.19 commit 744889b7cbb56a64f957e65ade7cb65fe3f35714
("block: don't deal with discard limit in blkdev_issue_discard()")
made problem worse:

- req_sects = min_t(sector_t, nr_sects, q->limits.max_discard_sectors);
+ req_sects = nr_sects;

Now BLKDISCARD ioctl fails unexpectedly if lower word of length is zero:
ioctl(3, BLKDISCARD, [0, 0x20000000000])  = -1 EOPNOTSUPP (Operation not supported)

-- snip --

A discard cleanup merged into 4.20-rc2 causes fstests xfs/259 to
fall into an endless loop in the discard code. The test is creating
a device that is exactly 2^32 sectors in size to test mkfs boundary
conditions around the 32 bit sector overflow region.

mkfs issues a discard for the entire device size by default, and
hence this throws a sector count of 2^32 into
blkdev_issue_discard(). It takes the number of sectors to discard as
a sector_t - a 64 bit value.

The commit ba5d73851e71 ("block: cleanup __blkdev_issue_discard")
takes this sector count and casts it to a 32 bit value before
comapring it against the maximum allowed discard size the device
has. This truncates away the upper 32 bits, and so if the lower 32
bits of the sector count is zero, it starts issuing discards of
length 0. This causes the code to fall into an endless loop, issuing
a zero length discards over and over again on the same sector.

Fixes: ba5d73851e71 ("block: cleanup __blkdev_issue_discard")
Tested-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>

Killed pointless WARN_ON().

Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
---
 block/blk-lib.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/block/blk-lib.c b/block/blk-lib.c
index 41088d5466c1..0dbc9e2ab9a3 100644
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@ -56,9 +56,11 @@ int __blkdev_issue_discard(struct block_device *bdev, sector_t sector,
 		return -EINVAL;
 
 	while (nr_sects) {
-		unsigned int req_sects = min_t(unsigned int, nr_sects,
+		sector_t req_sects = min_t(sector_t, nr_sects,
 				bio_allowed_max_sectors(q));
 
+		WARN_ON_ONCE((req_sects << 9) > UINT_MAX);
+
 		bio = next_bio(bio, 0, gfp_mask);
 		bio->bi_iter.bi_sector = sector;
 		bio_set_dev(bio, bdev);


      reply	other threads:[~2020-01-30 14:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-30 14:53 [PATCH v4.19 1/2] block: cleanup __blkdev_issue_discard() Konstantin Khlebnikov
2020-01-30 14:53 ` Konstantin Khlebnikov [this message]

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=158039600260.4465.8760113992408208442.stgit@buzz \
    --to=khlebnikov@yandex-team.ru \
    --cc=axboe@kernel.dk \
    --cc=dchinner@redhat.com \
    --cc=dmtrmonakhov@yandex-team.ru \
    --cc=greg@kroah.com \
    --cc=linux-block@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=stable@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox