linux-kernel - Re: [PATCH 08/10] block: cleanup rq->data

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 for Android: free password hash cracker in your pocket

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

Date:	Sun, 03 May 2009 16:51:32 +0300
From:	Boaz Harrosh <bharrosh@...asas.com>
To:	Tejun Heo <tj@...nel.org>
CC:	James Bottomley <James.Bottomley@...senPartnership.com>,
	axboe@...nel.dk, linux-kernel@...r.kernel.org, jeff@...zik.org,
	linux-ide@...r.kernel.org, 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,
	"Darrick J. Wong" <djwong@...ibm.com>
Subject: Re: [PATCH 08/10] block: cleanup rq->data_len usages

On 05/03/2009 04:32 AM, Tejun Heo wrote:
> James Bottomley wrote:
>> On Thu, 2009-04-30 at 16:47 +0300, Boaz Harrosh wrote:
>>>> @@ -966,7 +965,7 @@ static int scsi_init_sgtable(struct request
>>> *req, struct scsi_data_buffer *sdb,
>>>>       BUG_ON(count > sdb->table.nents);
>>>>       sdb->table.nents = count;
>>>>       if (blk_pc_request(req))
>>>> -             sdb->length = req->data_len;
>>>> +             sdb->length = blk_rq_bytes(req);
>>>>       else
>>>>               sdb->length = blk_rq_sectors(req) << 9;
>>> Is this true. I thought they must be the same now. I was actually
>>> anticipating this if() removed.
>> Me too ... there's one of these in scsi_lib.c as well.
> 
> Not until the next patch.  It's probably safe for scsi to make the
> switch here but I wanted to do the transition in two logical steps -
> 1. make all users use accessors in the defined manner without
> affecting anything else 2. knowing #1 is true for all low level
> drivers, unify implementation inside block layer.  I had a following
> patch which tried to do sweep conversion of all llds (which is
> guaranteed to be safe after #2 has happened) but it looked like more
> trouble than worth and seems like best left to each subsystem, so
> please go ahead and clean up subsystems on top of this patchset.  :-)
> 
>> The difference comes because filesystem requests are always in sectors,
>> but BLOCK_PC requests are always in bytes .... we should be able to wrap
>> the accessors so they do the correct conversions.
> 
> After this series is applied, blk_rq_bytes() >> 9 == blk_rq_sectors()
> is guaranteed (note that blk_rq_sectors() << 9 might not equal
> blk_rq_bytes() if the data transfer length isn't multiple of 512), so
> the above if can be removed.  I just didn't want to make the
> conversion (probably safe for scsi) before the actual unification.
> 
> Thanks.
> 

OK, NP. But in this case please note on the side all the places you think
might be suspect for blk_rq_bytes()/blk_rq_sectors() cosolidation and post the
list. Because it is now that you are going over the code and it is now that you
touch exactly all these places. 

You could even put a "TODO:" comments on all these places in this patch. So to draw
later patches that audit and remove the TODO:.

(Or in trivial places like above that are safe even before these patches, just
 convert them silently, in the sense of least traffic)

But sure I will see what I can help and send patches for. Tell me when you
think this is stable enough for me to add patches on top of.

Thanks
Boaz
--
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/