linux-kernel - Re: [PATCH 11/14] block: implement and use [__]blk_end_request

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: <49BB0ECB.6090003@kernel.org>
Date:	Sat, 14 Mar 2009 10:56:27 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
CC:	axboe@...nel.dk, linux-kernel@...r.kernel.org,
	Russell King <rmk@....linux.org.uk>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Mike Miller <mike.miller@...com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Jeff Garzik <jgarzik@...ox.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jeremy Fitzhardinge <jeremy@...source.com>,
	Alex Dubov <oakad@...oo.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>
Subject: Re: [PATCH 11/14] block: implement and use [__]blk_end_request_all()

Hello, Bartlomiej.  :-)

Bartlomiej Zolnierkiewicz wrote:
>>  end_request:
>>  	if (blk_pc_request(rq)) {
>> -		unsigned int dlen = rq->data_len;
>> -
>>  		if (dma)
>>  			rq->data_len = 0;
> 
> Since rq->data_len is modified here...
> 
>> -
>> -		if (blk_end_request(rq, 0, dlen))
>> -			BUG();
>> -
>> +		blk_end_request_all(rq, 0);
> 
> ...this won't fly.
> 
> [ IIRC ->data_len modification is needed for SG_IO ]

Thanks for catching this.  I'll take further look into this.

>> @@ -190,9 +190,7 @@ void ide_end_drive_cmd (ide_drive_t *drive, u8 stat, u8 err)
>>  
>>  	rq->errors = err;
>>  
>> -	if (unlikely(blk_end_request(rq, (rq->errors ? -EIO : 0),
>> -				     blk_rq_bytes(rq))))
>> -		BUG();
>> +	blk_end_request_all(rq, (rq->errors ? -EIO : 0));
> 
> How's about dropping needless parentheses while at it?

Sure.

>> diff --git a/drivers/ide/ide-pm.c b/drivers/ide/ide-pm.c
>> index 60538d9..d3d2d29 100644
>> --- a/drivers/ide/ide-pm.c
>> +++ b/drivers/ide/ide-pm.c
>> @@ -194,8 +194,7 @@ void ide_complete_pm_request(ide_drive_t *drive, struct request *rq)
>>  
>>  	drive->hwif->rq = NULL;
>>  
>> -	if (blk_end_request(rq, 0, 0))
>> -		BUG();
>> +	blk_end_request_all(rq, 0);
> 
> 0 => ide_rq_bytes() _not_ blk_rq_bytes()

Can you elaborate a bit?  Isn't the request supposed to always
completely finish here?  If the request isn't zero-length, completion
with 0 byte length doesn't make any sense.

> Please convert ide_complete_pm_request() to use blk_rq_bytes() in
> the separate pre-patch first.

Alright, will do.

> More generic comment follows -> this patch is guaranteed to clash
> with at least linux-next/pata-2.6 tree so why not introduce block
> layer helpers now, then push all driver updates through respective
> driver maintainers and deal with end_request() later (after all
> driver updates are in-tree)?

Most of the lld changes being trivial, I was hoping to push things
through blk tree, but IDE seems to be the most intertwined with the
block layer and it's likely to see quite some amount of not-so-trivial
changes to subtle paths.  How about pushing !IDE parts into blk tree
and pulling blk into pata-2.6, make IDE related changes there and
pulling back into blk tree so that further progresses can be made?

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/