Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp899644ybb; Wed, 1 Apr 2020 11:42:12 -0700 (PDT) X-Google-Smtp-Source: ADFU+vubFrhfpx+UWJ4JqxOKH38R4GFjyfz56ncJeZPiYWLYtAJaP+vkYgvBWX6Gn5WIwY+s9tjY X-Received: by 2002:a9d:12ce:: with SMTP id g72mr18035352otg.350.1585766532027; Wed, 01 Apr 2020 11:42:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585766532; cv=none; d=google.com; s=arc-20160816; b=uxWajyBRLGY+kT8yLOHlvdBrc6kxtYK4wm/cwqQqNxJG8/g7UFHJ0hogZwEFwL9ZOS CFXzGh8h3i2DwXESDC72c4RyYHuxyHNEbr5mUSOzopNwdbgsLiQqH/C1m00VaLIi6lmW 1hxH/dCFhrD+AeLV9JHMe0qtBxi3tXRxaNHpDcKE2EX9WQ/NDN50AiIZDyzzEVRbz69/ pZCyyJ3Iu0k3UAMK0Y3fKAjw6ZOs/aRQZ5H69oZYGLmWZYMhz6yRIN7Gad923mH+mea0 Mq7Tk6klLvxh4OfQApPC0VKO+9w1n3CyUC1qxmfl58bM4svErZx2AeU06pfB8q6ZSBDx l6nQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=pzTGLslFpdHXx/n6KMH3BGb7tsrM58pPmhp9HcVvhO8=; b=ZniTe0JVfIadn/+ysCpY2OL77HfixCYg6bD2LSRAMoHy95N6EIFStH4wo1TTKOe8LM 1kVfqzCs1IV6H/cCT8b+jNTD0WXPlcUCvV0r7RJN772s7gX3k3HklIwWY03aL1DoJbPf n76j9tnOE4g23p3r/Z1XrJqqcKchvh9HfL6uucjma3koobagndsZcW1wlnCVTeuJ9utG p2TxskDVGLHQ/7nIIINpYiXRAawNfi660kCb/tO8z5FTb9W3pK0rXYAPLBN+c9b0o7Qr AaWPtw88/r0SoNw8lQf7XkcFJJ7VopGsmUuaDnlx2M3lfjpB/Zps1gvzh5DpsczJTJeD KvsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=V3CmirXd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s200si1165839oie.188.2020.04.01.11.41.59; Wed, 01 Apr 2020 11:42:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=V3CmirXd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732337AbgDASlG (ORCPT + 99 others); Wed, 1 Apr 2020 14:41:06 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:44254 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1732256AbgDASlG (ORCPT ); Wed, 1 Apr 2020 14:41:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585766465; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pzTGLslFpdHXx/n6KMH3BGb7tsrM58pPmhp9HcVvhO8=; b=V3CmirXdWYh+cAhn1BJCb24bHJW1IUH6iMbwQBbw+gXQ94Zkzh3FluQU+8o3g3+GzaasHQ 3P7V126pd+nr2uDLNjaL9yhz10nkzCw7JaEGKPbPtOYmW6iuS0m2HQMAX9q6QVs3P7PZd9 qfkLHrlkuOqh33HPH3mg/ZEdo2Qm04Y= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-491-u7xh2wSMP9Gf1PUHjwFK1g-1; Wed, 01 Apr 2020 14:41:03 -0400 X-MC-Unique: u7xh2wSMP9Gf1PUHjwFK1g-1 Received: by mail-qv1-f72.google.com with SMTP id dh19so353678qvb.23 for ; Wed, 01 Apr 2020 11:41:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pzTGLslFpdHXx/n6KMH3BGb7tsrM58pPmhp9HcVvhO8=; b=KOdrB1OYOhGH3cNBvoeSw6XjV2eBe2b67h9Q+Al2fNLVExtD/JOWZ59RuArt/kwp8n AMiBZaf7q1ZXRJpIE7Wh6jViqeFhnwIxJ4PA6cyyzRgbNHgisGQUnL+1i77s/Mzar9jA CyweQnuVGhR+tTVsxPtgD/ISqcdbo1jn6VDnrt3vZ48bJEuJNzhCgcCf4ueKYN9iDf9J py5RAbhfaBF9wmnWgFvO5sOcucTHj8Sfq56vbMsp/FlBljw7d0s0lnA5jVaETFS60+V5 eNoDIM/RcfnUHzK4/dcZ03lfTVVNgtFGwHsZxhfL9FyZY66LSucJdAKuR+AeWaxWdd+r HgxA== X-Gm-Message-State: AGi0PuY/NRQMSSoNv5FI2CTcLdw1leFBF5TZhIbuDUARktY0DuOjqOdi r86ncLSpsI8eUE2bfGUBCHUdBJqwrK3m4OZkGgu/GGDCfCahBHFwdcTY5+e599/6IpMYI7u7aEb 6NJZPnQ52fhSieU8G5R8jKULe3UjSsJTGGl/5ZPJD X-Received: by 2002:a37:648:: with SMTP id 69mr3518438qkg.353.1585766461857; Wed, 01 Apr 2020 11:41:01 -0700 (PDT) X-Received: by 2002:a37:648:: with SMTP id 69mr3518405qkg.353.1585766461586; Wed, 01 Apr 2020 11:41:01 -0700 (PDT) MIME-Version: 1.0 References: <20200331192804.6019-1-eperezma@redhat.com> In-Reply-To: From: Eugenio Perez Martin Date: Wed, 1 Apr 2020 20:40:25 +0200 Message-ID: Subject: Re: [PATCH v3 0/8] vhost: Reset batched descriptors on SET_VRING_BASE call To: Christian Borntraeger Cc: "Michael S. Tsirkin" , "linux-kernel@vger.kernel.org" , Stephen Rothwell , kvm list , Linux Next Mailing List , "virtualization@lists.linux-foundation.org" , Halil Pasic , Cornelia Huck Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 1, 2020 at 9:19 AM Christian Borntraeger wrote: > > On 31.03.20 21:27, Eugenio P=C3=A9rez wrote: > > Vhost did not reset properly the batched descriptors on SET_VRING_BASE > > event. Because of that, is possible to return an invalid descriptor to > > the guest. > > > > This series ammend this, resetting them every time backend changes, and > > creates a test to assert correct behavior. To do that, they need to > > expose a new function in virtio_ring, virtqueue_reset_free_head, only > > on test code. > > > > Another useful thing would be to check if mutex is properly get in > > vq private_data accessors. Not sure if mutex debug code allow that, > > similar to C++ unique lock::owns_lock. Not acquiring in the function > > because caller code holds the mutex in order to perform more actions. > > > > > > > v3: > > * Rename accesors functions. > > * Make scsi and test use the accesors too. > > > > v2: > > * Squashed commits. > > * Create vq private_data accesors (mst). > > > > This is meant to be applied on top of > > c4f1c41a6094582903c75c0dcfacb453c959d457 in > > git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git. > > > A quick test on s390 looks good. > Really good to know :). Would it be possible to investigate when qemu launches the offending ioctls= ? Thanks!