Re: [PATCH v3 2/3] block: verify data when endio

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/29/19 8:40 AM, Bob Liu wrote:
> On 3/29/19 10:28 PM, Jens Axboe wrote:
>> On 3/29/19 8:23 AM, Bob Liu wrote:
>>> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
>>> index d66bf5f32610..e9f25f162138 100644
>>> --- a/include/linux/blk_types.h
>>> +++ b/include/linux/blk_types.h
>>> @@ -18,6 +18,7 @@ struct block_device;
>>>  struct io_context;
>>>  struct cgroup_subsys_state;
>>>  typedef void (bio_end_io_t) (struct bio *);
>>> +typedef int (bio_verifier_t) (struct bio *);
>>>  
>>>  /*
>>>   * Block error status values.  See block/blk-core:blk_errors for the details.
>>> @@ -187,6 +188,8 @@ struct bio {
>>>  		struct bio_integrity_payload *bi_integrity; /* data integrity */
>>>  #endif
>>>  	};
>>> +	bio_verifier_t		*bi_verifier;	/* verify callback when endio */
>>> +	struct work_struct      bi_work;	/* I/O completion */
>>>  
>>>  	unsigned short		bi_vcnt;	/* how many bio_vec's */
>>
>> I told you this for the initial posting, and the objection still stands.
>> Adding 40 bytes to struct bio is a no-go.
>>
> 
> Yes, I know that.
> Already list in Todo:
> - union with "struct bio_integrity_payload *bi_integrity" to save bio space.

As written in the other email, that solves _nothing_. So in terms of RFC, I'm
letting you know that adding anything to the bio for this issue is going to
be a non-starter.

> This is only a rfc patch, because not sure any other objection of this
> passdown-verify solution..  Will consider more about the bio space if
> there is agreement of the passdown-verify way.

OK, also see other mail on a potential route for the bio space that
doesn't increase the size for the bio at all.

You and Martin keep claiming this isn't an issue, but it is. Hence I'm
just making it as clear as I can that bumping the bio size for this
isn't going to fly.

-- 
Jens Axboe




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux