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: <200903132021.55921.bzolnier@gmail.com>
Date:	Fri, 13 Mar 2009 20:21:55 +0100
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Tejun Heo <tj@...nel.org>
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()

On Friday 13 March 2009, Tejun Heo wrote:
> Impact: cleanup
> 
> There are many [__]blk_end_request() call sites which call it with
> full request length and expect full completion.  Many of them ensure
> that the request actually completes by doing BUG_ON() the return
> value, which is awkward and error-prone.
> 
> This patch adds [__]blk_end_request_all() which takes @rq and @error
> and fully completes the request.  BUG_ON() is added to
> blk_update_request() to ensure that this actually happens.
> 
> Most conversions are simple but there are a few noteworthy ones.
> 
> * cdrom/viocd: viocd_end_request() replaced with direct calls to
>   __blk_end_request_all().
> 
> * s390/block/dasd: dasd_end_request() replaced with direct calls to
>   __blk_end_request_all().
> 
> * s390/char/tape_block: tapeblock_end_request() replaced with direct
>   calls to blk_end_request_all().
> 
> Signed-off-by: Tejun Heo <tj@...nel.org>
> Cc: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>

[...]

> diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
> index f825d50..8e6705a 100644
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c

[...]

> @@ -950,14 +947,9 @@ static ide_startstop_t cdrom_newpc_intr(ide_drive_t *drive)
>  
>  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 ]

>  		hwif->rq = NULL;
>  	} else {
>  		if (!uptodate)
> diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
> index a9a6c20..82f46dd 100644
> --- a/drivers/ide/ide-io.c
> +++ b/drivers/ide/ide-io.c
> @@ -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?

>  }
>  EXPORT_SYMBOL(ide_end_drive_cmd);
>  
> 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()

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

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)?

Thanks,
Bart
--
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/