From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 62FE731B833 for ; Tue, 3 Feb 2026 17:05:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770138319; cv=none; b=I2q+S/8dbq/2EAYvTsW54zFGupp+0TmlEHIS/xcbPLkMI0Rra3HwgxxMkWtc76JnTdCxFvve2OK6BvYW9iHTjsGiIDppdaxueMmpp5mWSDgVzDX03R7pykf8/5qt+8XiksYXc37TfAxHT4xHudt1gQV29kzHnuRtEuqAC4DWJXo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770138319; c=relaxed/simple; bh=ANgf7erO45M6z8OJhY8t3iY3rCsUya439h+4UicQju0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ehNH2tCvB0+n4S3KRWOmmOKArQxhFUuX/Baf2QX8uM6EeyeQwXQFXpbZQTd+uP+PAVQDsvhMALr7/D3BJOjcCqmQeIC+Zprupe1ttoAVJcIDOugBsk0HRBWDw7kbeKn/FTyeYXwH19qPQbHl/TFm/84NL23DX5Xx/7xuqh3p5YI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=fSfNZfgO; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fSfNZfgO" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-48069a48629so60897655e9.0 for ; Tue, 03 Feb 2026 09:05:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770138317; x=1770743117; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=E5tYYcTG2h6gNGfOyutvveFDKr0sO2maCZCmLPcxWJU=; b=fSfNZfgO00L76kmAJEiElypbfAQyCSS2gxAw/L1ZyIG08Ua1CFPxz7osxDT7PhsSaj b4W1n0+I/PVdNbWsRaSGiQe+0fVaU++/FWjN4BoSKGV9srJusgGdIDLNXd8V+Ark3ePS FuNXaaTP29oNaeiIlbkhjqD4sqIqKXkL15Ah5URK4LoBQ1DjfnTnV9wzg4hpUlk+npca UguDd8lEDixWV6FVzlfQcTHVDG52iwoK0lz2uKLSYZLqLTC2obCyCt9fEOMA0aZNR8sP DDBMAWjtPzkzFQ0Kz2NWegoOBO4SoWASz2lWflZSCW8uhzvIPd7+eMZXXGE0zcigAjyY GBJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770138317; x=1770743117; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=E5tYYcTG2h6gNGfOyutvveFDKr0sO2maCZCmLPcxWJU=; b=paKrjmCDSggsQpwD/k56FLg6RQO77MjQygu3BdawF3CeF/UMVZ8u6JeWy372t3OPrb iS8XGDjGUsyS/GNGPhUyqbylxG2z8VlfDCXTQ2G9vCvy7EYt6MGTIeD67J+MLOXHuqHc inOB8pL8mTbCNbyg6s5IEwD70wqTFEralSCPBuoQZzbu6la1txGPcnFWzD94NArrC+bb XUPiQeKD0nAY5HLOo679IzZTwjysUdvNnJsXSgpRuoEIT70v0/qBTRSCvlsgxTap24AR Kx4moq3o+TZybX4UFaFr3D65uw9gyD8c0nJYmmQ7BiaHjVupNAHv+3FTGx+DN90as3dn rcug== X-Forwarded-Encrypted: i=1; AJvYcCVpBMCb4KmwZFAdoQqLKi28qv7mQPwK6S1UhELg8IHIPd9MhUHdpTzU8w1+Ogbt6CyFeT/gcMJBCF0yJw0=@vger.kernel.org X-Gm-Message-State: AOJu0YwLAD4Cv2SCtHouZrABenNp0tI64mdYOzJHChPphBtuuIHkPmM6 TQutefAVIVetZ77n3ZylaSRv4PSpLg+DC0wRrrTvFrVuN+54muY5lXAD X-Gm-Gg: AZuq6aJt9Z/hEsxq7oafcDL1b41mBad4mZXZEmXrY+vTCSLTl5YKLLcndQdhgxrfSCX /X+RCJofJn0SI5ZYjCCUiD5Ief4RtghR5q2/D8w/1SC9waJLTkj+LHdPXjW+Psjyb+vNl2ZFc03 xSo9ckZUJT7p5B/LFS7NVKGtb/Tzd6cuMqXv6IWfWEZmkA0q6dgPPbzysMjL2n0G3S2dxkNJIqT W1ySYnPBEt9abNEb0psZ3qslh21xmCJ/WnAhjNLAZltFFaUCgAXiKNp5IG5/O//YgGD0HMCHADh S5O8iU72RTG8wTmRvy7agwFfVEfUGm1ida2sKfGG64nFIVht5XG3aFyxbJpcaTtX/O0Gb01qNhE O5zzk+TNnjCt7MdQ+MhClL3K2Aeme7iEY6dFpdg9XENaO2LXjLXzPJdOii5tmAdQkqvSYt9Ue3h LF0ZjXutQ0rUJIrV021YgkwX2sNFINvAu//ezudpT6PQ5ZE4hoo+Sc X-Received: by 2002:a05:600c:8b0f:b0:471:1717:411 with SMTP id 5b1f17b1804b1-4830e97b082mr4293425e9.24.1770138316601; Tue, 03 Feb 2026 09:05:16 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4830ead1973sm2440295e9.5.2026.02.03.09.05.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Feb 2026 09:05:16 -0800 (PST) Date: Tue, 3 Feb 2026 17:05:14 +0000 From: David Laight To: "Michael S. Tsirkin" Cc: Xuan Zhuo , Johannes Thumshirn , Alexander Graf , Jason Wang , Eugenio =?UTF-8?B?UMOpcmV6?= , "open list:VIRTIO CORE" , open list Subject: Re: [PATCH v3] virtio_ring: Add READ_ONCE annotations for device-writable fields Message-ID: <20260203170514.4cce4498@pumpkin> In-Reply-To: <20260203065312-mutt-send-email-mst@kernel.org> References: <20260131102810.1254845-1-johannes.thumshirn@wdc.com> <1770107244.8746088-1-xuanzhuo@linux.alibaba.com> <20260203065312-mutt-send-email-mst@kernel.org> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 3 Feb 2026 07:02:23 -0500 "Michael S. Tsirkin" wrote: ... > > > +/* > > > + * Accessors for device-writable fields in virtio rings. > > > + * These fields are concurrently written by the device and read by the driver. > > > + * Use READ_ONCE() to prevent compiler optimizations, document the > > > + * intentional data race and prevent KCSAN warnings. > > > + */ > > > +static inline u16 vring_read_split_used_idx(const struct vring_virtqueue *vq) > > > > "inline" is not recommended in *.c files. > > why would it be? it's a compiler hint. given this is the hottest path, > it makes sense. The compiler will almost always inline trivial functions regardless of whether are marked inline or not. So it is unlikely that adding 'inline' to any of this block of functions makes any difference at all. Adding inline to the wrong functions just bloats the code and can make the code run slower if there are two calls near enough to each other that the code would still be in the i-cache [1]. There are cases where the code would be smaller and faster if a function is inlined - but the compiler chooses not to. Those need always_inline. Apart from some quite bug functions that shouldn't be marked inline at all it would actually make sense to #define inline always_inline since that is what most kernel code actually wants to do. But a lot of the time the compiler gets it right - which is where the guidance comes from. [1] gcc has another way of breaking this by generating multiple copies of a function for different constant parameters. Sometimes that can make a big difference to the amount of code - then it can make sense, but sometimes it just means you have two almost identical copies to fill memory and the i-cache. David