linux-kernel - Re: [PATCH 07/10] block: drop request->hard_* and *nr

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] [day] [month] [year] [list]

Message-ID: <49FE77D5.9040909@kernel.org>
Date:	Mon, 04 May 2009 14:06:29 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Boaz Harrosh <bharrosh@...asas.com>
CC:	axboe@...nel.dk, linux-kernel@...r.kernel.org, jeff@...zik.org,
	linux-ide@...r.kernel.org, James.Bottomley@...senPartnership.com,
	linux-scsi@...r.kernel.org, bzolnier@...il.com,
	petkovbb@...glemail.com, sshtylyov@...mvista.com,
	mike.miller@...com, chirag.kantharia@...com, Eric.Moore@....com,
	stern@...land.harvard.edu, fujita.tomonori@....ntt.co.jp,
	zaitcev@...hat.com, Geert.Uytterhoeven@...ycom.com,
	sfr@...b.auug.org.au, grant.likely@...retlab.ca,
	paul.clements@...eleye.com, jesper.juhl@...il.com,
	tim@...erelk.net, jeremy@...source.com, adrian@...en.demon.co.uk,
	oakad@...oo.com, dwmw2@...radead.org, schwidefsky@...ibm.com,
	ballabio_dario@....com, davem@...emloft.net, rusty@...tcorp.com.au,
	Markus.Lidel@...dowconnect.com
Subject: Re: [PATCH 07/10] block: drop request->hard_* and *nr_sectors

Hello, Boaz.

Boaz Harrosh wrote:
>> @@ -1926,8 +1892,25 @@ bool blk_update_request(struct request *req, int error, unsigned int nr_bytes)
>>  		bio_iovec(bio)->bv_len -= nr_bytes;
>>  	}
>>  
>> -	blk_recalc_rq_sectors(req, total_bytes >> 9);
>> +	req->data_len -= total_bytes;
>> +	req->buffer = bio_data(req->bio);
>> +
>> +	/* update sector only for requests with clear definition of sector */
>> +	if (blk_fs_request(req) || blk_discard_rq(req))
>> +		req->sector += total_bytes >> 9;
>> +
>> +	/*
>> +	 * If total number of sectors is less than the first segment
>> +	 * size, something has gone terribly wrong.
>> +	 */
>> +	if (blk_rq_bytes(req) < blk_rq_cur_bytes(req)) {
>> +		printk(KERN_ERR "blk: request botched\n");
>> +		req->data_len = blk_rq_cur_bytes(req);
>> +	}
> 
> What happens in the last bio/segment?

Can you please elaborate a bit?  Nothing really changes for the last
bio/segment.

> Is it not allowed with block_pc commands that blk_rq_bytes(req) (was
> data_len) be smaller then sum_bytes(bio-chain)?

Well, before, it wasn't well defined.  For PC requests w/o bio, any
completion was full completion which isn't exactly data_len being
allowed to be shorter than actual data length but more like data_len
being completely ignored.  If a PC request has bio, the request should
be completed with full bio data length.  After recent changes, all PC
requests use bio and thus should fully complete the PC requests and
this patch doesn't change anything about that.

> Also I never understood the drain is it not appended to the last
> bio? I thought it is costumery in the Kernel to allow mapping longer
> then actual length?

drain is implemented in slightly hacky way.  All that's guaranteed is
extra room in the mapped sgl.  bio never sees it.

> Maybe you would want blk_rq_cur_bytes(req) to return the minimum of
> the two, and let bio's be longer then bytes requested. (ie. reverse
> above logic)

No, blk_rq_bytes() == sum of bio_rq_cur_bytes() of all bios in the
request and must NEVER be shorter than bio_rq_cur_bytes() by
definition.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/