Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp297885pxb; Wed, 20 Oct 2021 22:57:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy/8jpgHO6Ph+tIfVEklbrszGm2az0sTh+ZOhInUhjVOug5def34jMR12ZQQwc30OBDp56b X-Received: by 2002:a17:90b:1b42:: with SMTP id nv2mr4149323pjb.91.1634795834744; Wed, 20 Oct 2021 22:57:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634795834; cv=none; d=google.com; s=arc-20160816; b=gIKWwGW2jliLnembhfbYEMP6XZDEVNpZc1497bbMpRWonhI6sP0K99lkHTRvNEDOLE t4ABrnxTwI/zWmgK/ahHGgubWBj3u/wXwwJaRHxGE7V7KoyovyPvLUQMLFGCkyoI22vU DOp7T3vFsNpBbXEv10lKpZqIFbkUG92mxr6TzXcn2R7PB0I1eY8OLJmVg0VMHKMEZPhD V5DCM6g4sDyQEz8qhsulHBjku6d2wKWO1AwdoG2niWImcJ44al4WGW6l7wr6/OVn9871 wqnYAkitdxhzwfHZ9MVJBne7y36gKbCdjOByRiTITGDNQCvaxnc9RD3NPLKxEL1vq5p7 cdLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=MPMsfzrp3yhHHrEKGOJ9PXHajVcVgXnLQ+wrQS+Q/ns=; b=DBaBr5pOfatgmH1QHDxyld9W8WsqMluis4G4T26kjgu9ctzBK9MGl1MTssLkltlOQQ YuvF9ygQyCHq8dcaSAINeaY9SLys5qCPcrUAmQmu+qlMT4Kp9WiRxzDY0duPOV5VXz1E iTNthajhlHuw7B1cbYL906Nhjrj6gZRnYgwLVpgIAhpOC/esD3rlSb++5VlkdiJ+LMsC 7/kMGaESB0CL9rhx8Ah+s5qxh6fw42k6RYvRImWhPCVRaS/tnn+FOGZJFZ8OqZ680Gcm 4STS2TbozEx7N0qClGFYboC7W61RQ8rjO4u4aZuMTOibDOg1sYqX/Wl8BvZxPgXURcB6 gP1A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z130si5642672pgz.199.2021.10.20.22.57.00; Wed, 20 Oct 2021 22:57:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230426AbhJUF5t (ORCPT + 99 others); Thu, 21 Oct 2021 01:57:49 -0400 Received: from mga18.intel.com ([134.134.136.126]:50047 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229499AbhJUF5t (ORCPT ); Thu, 21 Oct 2021 01:57:49 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10143"; a="215871485" X-IronPort-AV: E=Sophos;i="5.87,168,1631602800"; d="scan'208";a="215871485" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Oct 2021 22:55:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,168,1631602800"; d="scan'208";a="444654055" Received: from unknown (HELO [10.239.154.68]) ([10.239.154.68]) by orsmga006.jf.intel.com with ESMTP; 20 Oct 2021 22:55:31 -0700 Subject: Re: [PATCH 2/2] i2c: virtio: fix completion handling To: Vincent Whitchurch , wsa@kernel.org, viresh.kumar@linaro.org Cc: virtualization@lists.linux-foundation.org, linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, kernel@axis.com References: <20211019074647.19061-1-vincent.whitchurch@axis.com> <20211019074647.19061-3-vincent.whitchurch@axis.com> From: Jie Deng Message-ID: Date: Thu, 21 Oct 2021 13:55:31 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211019074647.19061-3-vincent.whitchurch@axis.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/10/19 15:46, Vincent Whitchurch wrote: > The driver currently assumes that the notify callback is only received > when the device is done with all the queued buffers. > > However, this is not true, since the notify callback could be called > without any of the queued buffers being completed (for example, with > virtio-pci and shared interrupts) or with only some of the buffers being > completed (since the driver makes them available to the device in > multiple separate virtqueue_add_sgs() calls). Can the backend driver control the time point of interrupt injection ? I can't think of why the backend has to send an early interrupt. This operation should be avoided in the backend driver if possible. However, this change make sense if early interrupt can't be avoid. > > This can lead to incorrect data on the I2C bus or memory corruption in > the guest if the device operates on buffers which are have been freed by > the driver. (The WARN_ON in the driver is also triggered.) >