All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: snitzer@redhat.com, hch@lst.de, axboe@kernel.dk,
	dm-devel@redhat.com, James.Bottomley@suse.de,
	linux-kernel@vger.kernel.org, martin.petersen@oracle.com,
	akpm@linux-foundation.org
Subject: Re: [PATCH 1/2] block: fix leaks associated with discard request payload
Date: Sun, 27 Jun 2010 11:26:52 +0200	[thread overview]
Message-ID: <20100627092652.GA11625@lst.de> (raw)
In-Reply-To: <20100627174721D.fujita.tomonori@lab.ntt.co.jp>

On Sun, Jun 27, 2010 at 05:49:29PM +0900, FUJITA Tomonori wrote:
> On Sat, 26 Jun 2010 15:56:50 -0400
> Mike Snitzer <snitzer@redhat.com> wrote:
> 
> > Fix leaks introduced via "block: don't allocate a payload for discard
> > request" commit a1d949f5f44.
> > 
> > sd_done() is not called for REQ_TYPE_BLOCK_PC commands so cleanup
> > discard request's payload directly in scsi_finish_command().
> 
> Instead of adding another discard hack to scsi_finish_command(), how
> about converting discard to REQ_TYPE_FS request? discard is FS request
> from the perspective of the block layer. It also fixes a problem that
> discard isn't retried in the case of UNIT ATTENTION.
>
> I think that we can get more cleaner code if we handle discard as
> normal (fs) request in the block layer (and scsi-ml). We need more
> changes but this patch is the first step.

Making discard a REQ_TYPE_FS inside scsi (it already is before entering
sd_prep_fn) means we'll need to special case it all over the I/O
submission and completion path.  Having the payload length not matching
the transfer length is something we don't expect for FS requests.

> index e16185b..9e15c46 100644
> --- a/block/blk-lib.c
> +++ b/block/blk-lib.c
> @@ -20,6 +20,10 @@ static void blkdev_discard_end_io(struct bio *bio, int err)
>  	if (bio->bi_private)
>  		complete(bio->bi_private);
>  
> +	/* free the page that the lower layer allocated */
> +	if (bio_page(bio))
> +		__free_page(bio_page(bio));
> +

This is exactly what this patchkit gets rid off.  Having a payload
page that the caller tracks (previously fully, with this patch only for
freeing) makes DM's life a lot harder.  Remember we don't actually store
any payload in there before entering sd_prep_fn - it's just that the
scsi commands implementing discards need some payload - either a sector
sizes zero filled buffer for WRITE SAME, or an LBA/len encoding inside
the payload for UNMAP.


> -	rq->cmd_type = REQ_TYPE_BLOCK_PC;
> +	rq->cmd_type = REQ_TYPE_FS;

No need to set REQ_TYPE_FS here, it's already set up that way.



  reply	other threads:[~2010-06-27  9:27 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-18 14:59 [PATCH, RFC] block: don't allocate a payload for discard request Christoph Hellwig
2010-06-19  4:25 ` Mike Snitzer
2010-06-22 18:00   ` Mike Snitzer
2010-06-26 19:56     ` [PATCH 1/2] block: fix leaks associated with discard request payload Mike Snitzer
2010-06-27  8:49       ` FUJITA Tomonori
2010-06-27  9:26         ` Christoph Hellwig [this message]
2010-06-27 10:01           ` FUJITA Tomonori
2010-06-27 10:35             ` FUJITA Tomonori
2010-06-27 11:07               ` Christoph Hellwig
2010-06-27 12:32                 ` FUJITA Tomonori
2010-06-27 14:16                   ` Mike Snitzer
2010-06-27 15:35                     ` Christoph Hellwig
2010-06-27 16:23                       ` FUJITA Tomonori
2010-06-27 15:33                   ` Christoph Hellwig
2010-06-28  7:57                   ` Christoph Hellwig
2010-06-28  8:14                     ` FUJITA Tomonori
2010-06-28  8:18                       ` Jens Axboe
2010-06-28  8:45                         ` FUJITA Tomonori
2010-06-28  8:45                           ` FUJITA Tomonori
2010-06-28 15:25                       ` Christoph Hellwig
2010-06-30 11:55                         ` FUJITA Tomonori
2010-07-01  4:21                           ` FUJITA Tomonori
2010-06-27  9:38       ` Christoph Hellwig
2010-06-27 15:29       ` James Bottomley
2010-06-28 17:16         ` Martin K. Petersen
2010-06-29  8:00           ` Boaz Harrosh
2010-06-29 22:28         ` [dm-devel] " Mikulas Patocka
2010-06-29 23:03           ` James Bottomley
2010-06-29 23:51             ` Mike Snitzer
2010-06-29 23:51               ` Mike Snitzer
2010-06-30  0:11             ` [dm-devel] " Mikulas Patocka
2010-06-30 14:22               ` James Bottomley
2010-06-30 15:36                 ` Mike Snitzer
2010-06-30 16:26                   ` James Bottomley
2010-07-01 12:28                 ` [dm-devel] " Mikulas Patocka
2010-07-01 12:46                   ` Mike Snitzer
2010-07-01 14:03                     ` Mikulas Patocka
2010-07-01 14:03                       ` Mikulas Patocka
2010-07-01 12:49                   ` [dm-devel] " Alasdair G Kergon
2010-06-30  8:32         ` Boaz Harrosh
2010-06-30  8:42           ` Christoph Hellwig
2010-06-30 10:25             ` Boaz Harrosh
2010-06-30 10:41               ` Christoph Hellwig
2010-06-30 10:57                 ` Boaz Harrosh
2010-06-30 12:18                   ` Mike Snitzer
2010-06-26 19:56     ` [PATCH 2/2] block: defer the use of inline biovecs for discard requests Mike Snitzer
2010-06-27  9:39       ` Christoph Hellwig
2010-06-27 14:00         ` Mike Snitzer
2010-06-27 14:55       ` [PATCH 2/2 v2] " Mike Snitzer
2010-06-27 15:33         ` Christoph Hellwig
2010-06-28 10:33       ` [PATCH 2/2] " FUJITA Tomonori
2010-06-28 12:29         ` Mike Snitzer
2010-06-28 15:15           ` FUJITA Tomonori
2010-06-28 15:31             ` Mike Snitzer
2010-06-28 12:34       ` Jens Axboe
2010-06-28 12:37         ` Mike Snitzer
2010-06-28 12:41           ` Jens Axboe
2010-06-28 12:44             ` Christoph Hellwig
2010-06-28 12:49               ` Jens Axboe
2010-06-28 12:45             ` Mike Snitzer

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=20100627092652.GA11625@lst.de \
    --to=hch@lst.de \
    --cc=James.Bottomley@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=snitzer@redhat.com \
    /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.