linux-kernel - Re: [Xen-devel] [PATCH 2/2] block/xen-blkfront: Handle non-indirect grant with 64KB pages

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: <56139D0D.4020409@citrix.com>
Date:	Tue, 6 Oct 2015 12:06:05 +0200
From:	Roger Pau Monné <roger.pau@...rix.com>
To:	Julien Grall <julien.grall@...rix.com>,
	<xen-devel@...ts.xenproject.org>
CC:	<ian.campbell@...rix.com>, <stefano.stabellini@...citrix.com>,
	<linux-kernel@...r.kernel.org>,
	David Vrabel <david.vrabel@...rix.com>,
	"Boris Ostrovsky" <boris.ostrovsky@...cle.com>
Subject: Re: [Xen-devel] [PATCH 2/2] block/xen-blkfront: Handle non-indirect
 grant with 64KB pages

El 06/10/15 a les 11.58, Julien Grall ha escrit:
> Hi Roger,
> 
> On 06/10/2015 10:39, Roger Pau Monné wrote:
>> El 05/10/15 a les 19.05, Julien Grall ha escrit:
>>> On 05/10/15 17:01, Roger Pau Monné wrote:
>>>> El 11/09/15 a les 21.32, Julien Grall ha escrit:
>>>>>           ring_req->u.rw.nr_segments = num_grant;
>>>>> +        if (unlikely(require_extra_req)) {
>>>>> +            id2 = blkif_ring_get_request(info, req, &ring_req2);
>>>>
>>>> How can you guarantee that there's always going to be another free
>>>> request? AFAICT blkif_queue_rq checks for RING_FULL, but you don't
>>>> actually know if there's only one slot or more than one available.
>>>
>>> Because the depth of the queue is divided by 2 when the extra request is
>>> used (see xlvbd_init_blk_queue).
> 
> I just noticed that I didn't mention this restriction in the commit
> message. I will do it in the next revision.
> 
>> I see, that's quite restrictive but I guess it's better than introducing
>> a new ring macro in order to figure out if there are at least two free
>> slots.
> 
> I actually didn't think about your suggestion. I choose to divide by two
> based on the assumption that the block framework will always try to send
> a request with the maximum data possible.

AFAIK that depends on the request itself, the block layer will try to
merge requests if possible, but you can also expect that there are going
to be requests that will just contain a single block.

> I don't know if this assumption is correct as I'm not fully aware how
> the block framework is working.
> 
> If it's valid, in the case of 64KB guest, the maximum size of a request
> would be 64KB when indirect segment is not supported. So we would end up
> with a lot of 64KB request which will require 2 ring request.

I guess you could add a counter in order to see how many requests were
split vs total number of requests.

Roger.

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