linux-kernel - Re: [Xen-devel] Re: [PATCH 3/3] xen-blkfront: If no barrier or flush is supported, use invalid operation.

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

Date:	Mon, 19 Sep 2011 10:35:32 +0100
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>
Cc:	<jeremy.fitzhardinge@...rix.com>, <axboe@...nel.dk>,
	<stable@...nel.org>, <xen-devel@...ts.xensource.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] Re: [PATCH 3/3] xen-blkfront: If no barrier or
	 flush is supported, use invalid operation.

>>> On 16.09.11 at 21:15, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:
> On Mon, Sep 12, 2011 at 09:01:25AM +0100, Jan Beulich wrote:
>> >>> On 09.09.11 at 20:31, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:
>> > By default we would set the info->flush_op=0, and zero maps
>> > to BLKIF_OP_READ request code. So if the backend did not support
>> > either barrier ('feature-barrier') or flush ('feature-flush-cache')
>> > we would end up using that opcode for the flush/barrier request, meaning
>> > we actually do a READ request. Fortunatly for us, __generic_make_request
>> > checks q->flush_flags and realizes that we don't do FLUSH and removes
>> > the REQ_FLUSH | REQ_FUA so we never end up issuing a READ request
>> > for a flush request. However, other third party implementations of
>> > __make_request might not be so smart, so lets fix this up.
>> 
>> Wouldn't it be better to simply have blkif_queue_request() fail in that
>> case (and then it doesn't matter whether flush_op is set to 0 or -1)?
>> Not the least because older (forward-port) backends stall the incoming
>> queue and are possibly verbose for invalid requests seen.
> 
> So like this:

Yes, this looks small and neat.

Acked-by: Jan Beulich <jbeulich@...e.com>

> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 468bfec..e9d301c 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -380,7 +380,9 @@ static void do_blkif_request(struct request_queue *rq)
>  
>  		blk_start_request(req);
>  
> -		if (req->cmd_type != REQ_TYPE_FS) {
> +		if ((req->cmd_type != REQ_TYPE_FS) ||
> +		    ((req->cmd_flags & (REQ_FLUSH | REQ_FUA)) &&
> +		    !info->flush_op)) {
>  			__blk_end_request_all(req, -EIO);
>  			continue;
>  		}



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