linux-kernel - Re: [PATCH 10/18] lightnvm: pblk: use bio_copy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <EE4FE7F3-88CF-42DD-B18F-B0AC2CB5EB2C@lightnvm.io>
Date:   Wed, 6 Sep 2017 16:00:56 +0200
From:   Javier González <jg@...htnvm.io>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Matias Bjørling <mb@...htnvm.io>,
        Jens Axboe <axboe@...com>, linux-block@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Matias Bjørling <matias@...xlabs.com>
Subject: Re: [PATCH 10/18] lightnvm: pblk: use bio_copy_kern when possible

> On 6 Sep 2017, at 15.47, Christoph Hellwig <hch@...radead.org> wrote:
> 
> On Wed, Sep 06, 2017 at 12:51:03PM +0200, Javier González wrote:
>> In pblk, buffers forming bios can be allocated on physically contiguous
>> or virtually contiguous memory. For physically contiguous memory, we
>> already use the bio_map_kern helper funciton, however, for virtually
>> contiguous memory, we from the bio manually. This makes the code more
>> complex, specially on the completion path, where mapped pages need to be
>> freed.
>> 
>> Instead, use bio_copy_kern, which does the same and at the same time
>> simplifies the completion path.
> 
> Nope.  You want to loop over vmalloc_to_page and call bio_add_page
> for each page,

Yes. This is basically what I did before.

> after taking care of virtually tagged caches instead
> of this bounce buffering.

And thus I considered bio_copy_kern to be a better solution, since it
will through time take care of doing the vmalloc_to_page correctly for
all cases.

> 
> And you really want to allocate the request first and only then map
> the data to the request, as said before.

Ok. So this would mean that targets (e.g., pblk) deal with struct
request instead of only dealing with bios and then letting the LightNVM
core transforming bios to requests. This way we can directly map to the
request. Is this what you mean?

Just out of curiosity, why is forming the bio trough bio_copy_kern (or
manually doing the same) and then transforming to a request incorrect /
worse?

Javier

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)