From: Matthew Wilcox <willy@linux.intel.com>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
jgarzik@redhat.com, Matthew Wilcox <matthew@wil.cx>
Subject: Re: [PATCH 1/5] Block: Discard may need to allocate pages
Date: Sat, 2 May 2009 23:11:50 -0700 [thread overview]
Message-ID: <20090503061150.GF10704@linux.intel.com> (raw)
In-Reply-To: <49D8A3D7.5070507@panasas.com>
[I thought I replied to this, but I don't see an indication that I did]
On Sun, Apr 05, 2009 at 03:28:07PM +0300, Boaz Harrosh wrote:
> > +++ b/block/blk-barrier.c
> > @@ -356,6 +356,8 @@ static void blkdev_discard_end_io(struct bio *bio, int err)
> > clear_bit(BIO_UPTODATE, &bio->bi_flags);
> > }
> >
> > + if (bio_has_data(bio))
> > + __free_page(bio_page(bio));
>
> Page freed which was allocated by the LLD
It wasn't allocated by the LLD. It was allocated by the ULD.
> > bio_put(bio);
>
> OK bio was allocated by user code but shouldn't
? Are you saying the bio should be allocated by each driver
implementing a discard operation?
> > while (nr_sects && !ret) {
> > - bio = bio_alloc(gfp_mask, 0);
> > + bio = bio_alloc(gfp_mask, 1);
>
> blkdev_issue_discard() and blk_ioctl_discard() has half a page
> of common (and changing) code, could be done to use a common
> helper that sets policy about bio allocation sizes and such.
>
> Just my $0.017
Yes, that works nicely. Thanks for the suggestion.
> > @@ -1118,7 +1120,7 @@ void init_request_from_bio(struct request *req, struct bio *bio)
> > req->cmd_flags |= REQ_DISCARD;
> > if (bio_barrier(bio))
> > req->cmd_flags |= REQ_SOFTBARRIER;
> > - req->q->prepare_discard_fn(req->q, req);
> > + req->q->prepare_discard_fn(req->q, req, bio);
>
> Allocation of bio page could be done commonly here.
> The prepare_discard_fn() is made to return the needed size. It is not as if we actually
> give the driver a choice about the allocation.
Not all drivers need to allocate a page. Some drivers may need
to allocate more than one page, depending on how large the range is.
And the driver can't just return the page size it needs here -- it needs
to fill in the contents of the page too.
I suppose we could do something fairly disgusting like:
for (;;) {
struct page *page;
needed = req->q->prepare_discard_fn(req->q, req, bio);
if (!needed)
break;
page = alloc_page(GFP_KERNEL);
if (bio_add_pc_page(q, bio, page, PAGE_SIZE, 0) < PAGE_SIZE)
goto fail;
}
Then the driver can return 0 => success, anything else => allocate more
ram, try again.
> I have one question:
>
> At [PATCH 4/5] and [PATCH 4/5] you do:
> + struct page *page = alloc_page(GFP_KERNEL);
>
> does that zero the alloced page? since if I understand correctly this page
> will go on the wire, a SW target on the other size could snoop random Kernel
> memory, is that allowed? OK I might be totally clueless here.
alloc_page doesn't zero the page.
scsi only sends out 24 bytes of that page on the wire, and it initialises
all 24 bytes. ide/ata send multiples of 512 bytes on the wire, and
they're careful to zero any of the space they're not using.
next prev parent reply other threads:[~2009-05-03 6:11 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-02 14:37 [PATCH 1/5] Block: Discard may need to allocate pages Matthew Wilcox
2009-04-02 14:37 ` [PATCH 2/5] Make DISCARD_BARRIER and DISCARD_NOBARRIER writes instead of reads Matthew Wilcox
2009-04-02 14:37 ` [PATCH 3/5] ata: Add TRIM infrastructure Matthew Wilcox
2009-04-02 14:37 ` [PATCH 4/5] ide: Add support for TRIM Matthew Wilcox
2009-04-02 14:37 ` [PATCH 5/5] libata: " Matthew Wilcox
2009-04-02 17:20 ` Mark Lord
2009-04-02 17:55 ` Matthew Wilcox
2009-04-16 20:25 ` Mark Lord
2009-04-17 19:44 ` Mark Lord
2009-04-02 15:58 ` [PATCH 4/5] ide: " Sergei Shtylyov
2009-04-02 16:28 ` Matthew Wilcox
2009-04-02 16:38 ` Sergei Shtylyov
2009-04-02 16:51 ` Matthew Wilcox
2009-04-02 19:37 ` Bartlomiej Zolnierkiewicz
2009-04-07 21:38 ` Bartlomiej Zolnierkiewicz
2009-04-07 22:15 ` Matthew Wilcox
2009-04-07 22:26 ` Jeff Garzik
2009-04-07 22:35 ` Bartlomiej Zolnierkiewicz
2009-04-07 17:20 ` Jeff Garzik
2009-04-07 17:57 ` Mark Lord
2009-04-07 18:10 ` Markus Trippelsdorf
2009-04-07 19:58 ` Mark Lord
2009-04-08 7:14 ` Markus Trippelsdorf
2009-04-08 14:25 ` Mark Lord
2009-04-08 14:33 ` Mark Lord
2009-04-08 14:44 ` Dongjun Shin
2009-04-08 14:59 ` Jeff Garzik
2009-04-08 15:50 ` Mark Lord
2009-04-02 15:55 ` [PATCH 3/5] ata: Add TRIM infrastructure Sergei Shtylyov
2009-04-02 16:18 ` Matthew Wilcox
2009-04-02 16:32 ` Sergei Shtylyov
2009-04-02 16:47 ` Matthew Wilcox
2009-04-07 0:02 ` Jeff Garzik
2009-04-05 12:28 ` [PATCH 1/5] Block: Discard may need to allocate pages Boaz Harrosh
2009-04-06 20:34 ` Matthew Wilcox
2009-05-03 6:11 ` Matthew Wilcox [this message]
2009-05-03 7:16 ` New TRIM/UNMAP tree published (2009-05-02) Matthew Wilcox
2009-05-03 13:07 ` Hugh Dickins
2009-05-03 14:48 ` Matthew Wilcox
2009-05-03 15:02 ` Boaz Harrosh
2009-05-03 15:42 ` Matthew Wilcox
2009-05-03 16:34 ` Boaz Harrosh
2009-05-03 18:34 ` Jeff Garzik
2009-05-03 18:40 ` Jeff Garzik
2009-05-03 19:04 ` James Bottomley
2009-05-03 19:20 ` Jeff Garzik
2009-05-03 19:37 ` James Bottomley
2009-05-04 14:03 ` Douglas Gilbert
2009-05-04 14:40 ` James Bottomley
2009-05-04 15:11 ` Douglas Gilbert
2009-05-04 15:23 ` James Bottomley
2009-05-03 19:47 ` James Bottomley
2009-05-03 22:47 ` Jeff Garzik
2009-05-04 15:28 ` Boaz Harrosh
2009-05-03 21:48 ` Matthew Wilcox
2009-05-03 22:54 ` Jeff Garzik
2009-05-03 18:48 ` Bartlomiej Zolnierkiewicz
2009-05-03 15:05 ` Hugh Dickins
2009-04-17 21:23 ` [PATCH 1/5] Block: Discard may need to allocate pages Mark Lord
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=20090503061150.GF10704@linux.intel.com \
--to=willy@linux.intel.com \
--cc=bharrosh@panasas.com \
--cc=jgarzik@redhat.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
/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;
as well as URLs for NNTP newsgroup(s).