linux-kernel - Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

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: <1d3d7e32-22d1-83aa-af0a-7ed6e628f5e5@kernel.dk>
Date:   Thu, 27 Sep 2018 15:37:51 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Sander Eikelenboom <linux@...elenboom.it>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Juergen Gross <jgross@...e.com>, konrad.wilk@...cle.com,
        roger.pau@...rix.com
Cc:     xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants,
 keep them in the buffer

On 9/27/18 2:33 PM, Sander Eikelenboom wrote:
> On 27/09/18 21:06, Boris Ostrovsky wrote:
>> On 9/27/18 2:56 PM, Jens Axboe wrote:
>>> On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
>>>> On 27/09/18 16:26, Jens Axboe wrote:
>>>>> On 9/27/18 1:12 AM, Juergen Gross wrote:
>>>>>> On 22/09/18 21:55, Boris Ostrovsky wrote:
>>>>>>> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>>>>>>> added support for purging persistent grants when they are not in use. As
>>>>>>> part of the purge, the grants were removed from the grant buffer, This
>>>>>>> eventually causes the buffer to become empty, with BUG_ON triggered in
>>>>>>> get_free_grant(). This can be observed even on an idle system, within
>>>>>>> 20-30 minutes.
>>>>>>>
>>>>>>> We should keep the grants in the buffer when purging, and only free the
>>>>>>> grant ref.
>>>>>>>
>>>>>>> Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>>>>>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@...cle.com>
>>>>>> Reviewed-by: Juergen Gross <jgross@...e.com>
>>>>> Since Konrad is out, I'm going to queue this up for 4.19.
>>>>>
>>>> Hi Boris/Juergen.
>>>>
>>>> Last week i tested a linux-4.19-rc4 kernel with xen-next and this patch from Boris pulled on top. 
>>>> Unfortunately it made a VM hang (probably because it's rootFS is shuffled from under it's feet 
>>
>> What do you mean by "rootFS is shuffled from under it's feet " ?
> 
> Assumption that block-front getting borked and either a kernel crash or rootfs becoming mounted readonly. Didn't (try) to check though.
> 
>>>> and it gave these in dom0 dmesg:
>>>>
>>>> [ 9251.696090] xen-blkback: requesting a grant already in use
>>>> [ 9251.705861] xen-blkback: trying to add a gref that's already in the tree
>>>> [ 9251.715781] xen-blkback: requesting a grant already in use
>>>> [ 9251.725756] xen-blkback: trying to add a gref that's already in the tree
>>>> [ 9251.735698] xen-blkback: requesting a grant already in use
>>>> [ 9251.745573] xen-blkback: trying to add a gref that's already in the tree
>>>>
>>>> The VM was a HVM with 4 vcpu's and 2 phy disks:
>>>> xen-blkback: backend/vbd/14/768: using 4 queues, protocol 1 (x86_64-abi) persistent grants
>>>> xen-blkback: backend/vbd/14/832: using 4 queues, protocol 1 (x86_64-abi) persistent grants
>>>>
>>>>
>>>> Currently i have been running 4.19-rc5 with xen-next on top and commit
>>>> a46b53672b2c reverted, for a couple of days. That seems to run stable
>>>> for me (since it's a small box so i'm not hit by what a46b53672b2c
>>>> tried to fix.
>>>>
>>>> If you can come up with a debug patch i can give that a spin tomorrow
>>>> evening or in the weekend, so we are hopefully still in time for the
>>>> 4.19 release.
>>> At this late in the game, might make more sense to simply revert the
>>> buggy commit.  Especially since what is currently out there doesn't fix
>>> the issue for you.
>
> Don't know if Boris or Juergen have a hunch about the issue, if not
> perhaps a revert is the best.

Anyone? Unless I hear otherwise, I'll revert the series tomorrow.

-- 
Jens Axboe