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: <CACVXFVPLXfWKcQGcmX8H6Um+4P0XFpKC0DWC4-JXy94st=QL7Q@mail.gmail.com>
Date:   Thu, 16 Feb 2017 21:59:22 +0800
From:   Ming Lei <tom.leiming@...il.com>
To:     Johannes Thumshirn <jthumshirn@...e.de>
Cc:     Shaohua Li <shli@...nel.org>, Jens Axboe <axboe@...com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:SOFTWARE RAID (Multiple Disks) SUPPORT" 
        <linux-raid@...r.kernel.org>,
        linux-block <linux-block@...r.kernel.org>,
        Christoph Hellwig <hch@...radead.org>,
        NeilBrown <neilb@...e.com>
Subject: Re: [PATCH 02/17] block: introduce bio_remove_last_page()

On Thu, Feb 16, 2017 at 9:40 PM, Johannes Thumshirn <jthumshirn@...e.de> wrote:
> On 02/16/2017 02:30 PM, Ming Lei wrote:
>> On Thu, Feb 16, 2017 at 8:08 PM, Johannes Thumshirn <jthumshirn@...e.de> wrote:
>>> On 02/16/2017 12:45 PM, Ming Lei wrote:
>>>> MD need this helper to remove the last added page, so introduce
>>>> it.
>>>>
>>>> Signed-off-by: Ming Lei <tom.leiming@...il.com>
>>>> ---
>>>>  block/bio.c         | 23 +++++++++++++++++++++++
>>>>  include/linux/bio.h |  1 +
>>>>  2 files changed, 24 insertions(+)
>>>>
>>>> diff --git a/block/bio.c b/block/bio.c
>>>> index 5eec5e08417f..0ce7ffcd7939 100644
>>>> --- a/block/bio.c
>>>> +++ b/block/bio.c
>>>> @@ -837,6 +837,29 @@ int bio_add_pc_page(struct request_queue *q, struct bio *bio, struct page
>>>>  EXPORT_SYMBOL(bio_add_pc_page);
>>>>
>>>>  /**
>>>> + *   bio_remove_last_page    -       remove the last added page
>>>> + *   @bio: destination bio
>>>> + *
>>>> + *   Attempt to remove the last added page from the bio_vec maplist.
>>>> + */
>>>> +void bio_remove_last_page(struct bio *bio)
>>>> +{
>>>> +     /*
>>>> +      * cloned bio must not modify vec list
>>>> +      */
>>>> +     if (WARN_ON_ONCE(bio_flagged(bio, BIO_CLONED)))
>>>> +             return;
>>>> +
>>>> +     if (bio->bi_vcnt > 0) {
>>>
>>> In patch 1 you introduce bio_segments_all() with the log message 'So
>>> that we can replace the direct access to .bi_vcnt.' Here you introduce a
>>> new direct access to it (plus the duplicated WARN_ON_ONCE()).
>>>
>>> Maybe use the helper directly here (I admit I haven't gone through the
>>> whole series yet, so I can't see if the change is made later).
>>
>> Firstly MD does need one helper to remove the last added page, as you
>> can see there are three such uses in patch3.
>>
>> Secondly both the two helpers will be changed once multipage bvec
>> is supported, that means we have to change MD too after multipage bvec
>> if just using bio_segments_all() to replace .bi_vcnt for removing
>> the last added page.
>
> I'm not sure if we're talking past each other here, I assumed you'd do
> something like:
>
> void bio_remove_last_page(struct bio *bio)
> {
>         int vcnt = bio_segments_all(bio);
>
>         if (bio_flagged(bio, BIO_CLONED))
>                 return;
>
>         if (vcnt > 0) {
>                 struct bio_vec *bv = &bio->bi_io_vec[vcnt - 1];
>
>                 bio->bi_iter.bi_size -= bv->bv_len;
>                 bio->bi_vcnt--;
>         }
> }

What we are doing is to remove the external direct access to bvec
table in drivers or filesystems because they may misuse that, for
example, drivers often use .bi_vcnt to get the page count in the bio,
but the actual meaning is just bvec's count.

And the implementation in block layer still need to play the table directly,
especially for sake of efficiency, cause we understand the details and won't
misuse that.


Thanks,
Ming Lei

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ