On Fri, Nov 09, 2018 at 09:58:01AM +0800, Ming Lei wrote: > On Thu, Nov 08, 2018 at 09:35:39AM -0800, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > > > This is a note to let you know that I've just added the patch titled > > > > block: don't deal with discard limit in blkdev_issue_discard() > > > > to the 4.18-stable tree which can be found at: > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > > > The filename of the patch is: > > block-don-t-deal-with-discard-limit-in-blkdev_issue_discard.patch > > and it can be found in the queue-4.18 subdirectory. > > > > If you, or anyone else, feels it should not be added to the stable tree, > > please let <stable@xxxxxxxxxxxxxxx> know about it. > > > > > > From 744889b7cbb56a64f957e65ade7cb65fe3f35714 Mon Sep 17 00:00:00 2001 > > From: Ming Lei <ming.lei@xxxxxxxxxx> > > Date: Fri, 12 Oct 2018 15:53:10 +0800 > > Subject: block: don't deal with discard limit in blkdev_issue_discard() > > > > From: Ming Lei <ming.lei@xxxxxxxxxx> > > > > commit 744889b7cbb56a64f957e65ade7cb65fe3f35714 upstream. > > > > blk_queue_split() does respect this limit via bio splitting, so no > > need to do that in blkdev_issue_discard(), then we can align to > > normal bio submit(bio_add_page() & submit_bio()). > > > > More importantly, this patch fixes one issue introduced in a22c4d7e34402cc > > ("block: re-add discard_granularity and alignment checks"), in which > > zero discard bio may be generated in case of zero alignment. > > > > Fixes: a22c4d7e34402ccdf3 ("block: re-add discard_granularity and alignment checks") > > Cc: stable@xxxxxxxxxxxxxxx > > Cc: Ming Lin <ming.l@xxxxxxxxxxxxxxx> > > Cc: Mike Snitzer <snitzer@xxxxxxxxxx> > > Cc: Christoph Hellwig <hch@xxxxxx> > > Cc: Xiao Ni <xni@xxxxxxxxxx> > > Tested-by: Mariusz Dabrowski <mariusz.dabrowski@xxxxxxxxx> > > Signed-off-by: Ming Lei <ming.lei@xxxxxxxxxx> > > Signed-off-by: Jens Axboe <axboe@xxxxxxxxx> > > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > > > --- > > block/blk-lib.c | 28 ++-------------------------- > > 1 file changed, 2 insertions(+), 26 deletions(-) > > > > --- a/block/blk-lib.c > > +++ b/block/blk-lib.c > > @@ -29,9 +29,7 @@ int __blkdev_issue_discard(struct block_ > > { > > struct request_queue *q = bdev_get_queue(bdev); > > struct bio *bio = *biop; > > - unsigned int granularity; > > unsigned int op; > > - int alignment; > > sector_t bs_mask; > > > > if (!q) > > @@ -54,38 +52,16 @@ int __blkdev_issue_discard(struct block_ > > if ((sector | nr_sects) & bs_mask) > > return -EINVAL; > > > > - /* Zero-sector (unknown) and one-sector granularities are the same. */ > > - granularity = max(q->limits.discard_granularity >> 9, 1U); > > - alignment = (bdev_discard_alignment(bdev) >> 9) % granularity; > > - > > while (nr_sects) { > > - unsigned int req_sects; > > - sector_t end_sect, tmp; > > + unsigned int req_sects = nr_sects; > > + sector_t end_sect; > > > > - /* > > - * Issue in chunks of the user defined max discard setting, > > - * ensuring that bi_size doesn't overflow > > - */ > > - req_sects = min_t(sector_t, nr_sects, > > - q->limits.max_discard_sectors); > > if (!req_sects) > > goto fail; > > if (req_sects > UINT_MAX >> 9) > > req_sects = UINT_MAX >> 9; > > > > - /* > > - * If splitting a request, and the next starting sector would be > > - * misaligned, stop the discard at the previous aligned sector. > > - */ > > end_sect = sector + req_sects; > > - tmp = end_sect; > > - if (req_sects < nr_sects && > > - sector_div(tmp, granularity) != alignment) { > > - end_sect = end_sect - alignment; > > - sector_div(end_sect, granularity); > > - end_sect = end_sect * granularity + alignment; > > - req_sects = end_sect - sector; > > - } > > > > bio = next_bio(bio, 0, gfp_mask); > > bio->bi_iter.bi_sector = sector; > > > > > > Patches currently in stable-queue which might be from ming.lei@xxxxxxxxxx are > > > > queue-4.18/block-don-t-deal-with-discard-limit-in-blkdev_issue_discard.patch > > BTW, > > This patch actually causes regression[1], however the fix[2] isn't merged > to linus tree yet. > > [1] https://marc.info/?l=linux-block&m=154048378809822&w=2 > [2] https://marc.info/?l=linux-block&m=154081786602515&w=2 Any reason why the fix did not have a cc: stable marking in it? :( When this hits Linus's tree, let me know what the git commit id is so that I can add it to the 4.18 and 4.19 releases. I'll go drop this from the 4.18.y queue right now. thanks, greg k-h
