From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91896C433FE for ; Wed, 2 Mar 2022 14:46:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243209AbiCBOrH (ORCPT ); Wed, 2 Mar 2022 09:47:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243136AbiCBOrH (ORCPT ); Wed, 2 Mar 2022 09:47:07 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C15F3C793C for ; Wed, 2 Mar 2022 06:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646232383; 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: in-reply-to:in-reply-to:references:references; bh=w205eOqOdxeAZdCILUJdCHi/CnhyFtZESdwZqehxcdc=; b=GZYZDlyesE/pp8ODtAnWwaaMpSkl4SvEc6dt0M86vxmzS1/uc47uZlz4cbmfgdl3u9lwNh x+P1Ha9uRcrDyYOVF3mtB1owRJLN1rofnHhn6iiJvwDmyld8JuZMUrIGYXEcPzzs6bPyI0 FA+GTAJrcZ/nryT2VGbhRpqlZbeUuCQ= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-573-Puv2HWkdNGCxhUiJQ7o98w-1; Wed, 02 Mar 2022 09:46:21 -0500 X-MC-Unique: Puv2HWkdNGCxhUiJQ7o98w-1 Received: by mail-wm1-f70.google.com with SMTP id 10-20020a1c020a000000b0037fae68fcc2so1990704wmc.8 for ; Wed, 02 Mar 2022 06:46:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=w205eOqOdxeAZdCILUJdCHi/CnhyFtZESdwZqehxcdc=; b=nVVGoQ/3ZeoNWPvwPatr03ZHgSRGHdHtBocMzhWRLpjsViHl57UBUtpVPrWMt0UGn3 pE18HP8r6az9XOXWf/uv3rGoZVI3qvHQ6XLH7tufyKP9Yf6uLMnPSVo3cIetk+i5GyRO Ls9oxbIeRV7Vn2SvEX0YhWXmk4974vPAhh195FgHDhz/rdFaNmUyVjYEy/3fdikCC84z n9ePypt7VUcpCJj+F1gTLjiR2BCKrcvzYsFuSznq0n0A8cuhR88Wsiz2cZjn+2bXspQ2 4ZkzFqEojkGZiuwzGndexighW4qDHDb1NM4Jd9Oh7Pp2IqkLT68noLyf14SPZZoh8nTx c67g== X-Gm-Message-State: AOAM530E4iCxkshxx3QVJJRjxYOfrgxSjaE4Ar1kTPJGR2myfoqadwGe Aiu3R6rDT0q0JiQP1a4uDz/t3L7RdWWqMl6ON0yHXtGBc66cUkRGpOTBbbgxMyc8YS7Vt65Ap3T tWIVOmOzX2zq8wQnE0zw= X-Received: by 2002:adf:eb45:0:b0:1ef:6070:7641 with SMTP id u5-20020adfeb45000000b001ef60707641mr20390140wrn.301.1646232380697; Wed, 02 Mar 2022 06:46:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJza4Ib8iRQhbK5h23mGl00nx8utPjoauWdru+z6xmj8vBVgS9w4ICFHCPrxOEOgLj/22uh95g== X-Received: by 2002:adf:eb45:0:b0:1ef:6070:7641 with SMTP id u5-20020adfeb45000000b001ef60707641mr20390128wrn.301.1646232380470; Wed, 02 Mar 2022 06:46:20 -0800 (PST) Received: from redhat.com ([2a10:8006:355c:0:48d6:b937:2fb9:b7de]) by smtp.gmail.com with ESMTPSA id z16-20020a7bc7d0000000b00381004c643asm5677773wmk.30.2022.03.02.06.46.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Mar 2022 06:46:19 -0800 (PST) Date: Wed, 2 Mar 2022 09:46:16 -0500 From: "Michael S. Tsirkin" To: "Jason A. Donenfeld" Cc: Laszlo Ersek , LKML , KVM list , QEMU Developers , linux-hyperv@vger.kernel.org, Linux Crypto Mailing List , Alexander Graf , "Michael Kelley (LINUX)" , Greg Kroah-Hartman , adrian@parity.io, Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , Dominik Brodowski , Jann Horn , "Rafael J. Wysocki" , "Brown, Len" , Pavel Machek , Linux PM , Colm MacCarthaigh , Theodore Ts'o , Arnd Bergmann Subject: Re: propagating vmgenid outward and upward Message-ID: <20220302092149-mutt-send-email-mst@kernel.org> References: <223f858c-34c5-3ccd-b9e8-7585a976364d@redhat.com> <20220301121419-mutt-send-email-mst@kernel.org> <20220302031738-mutt-send-email-mst@kernel.org> <20220302074503-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Wed, Mar 02, 2022 at 02:55:29PM +0100, Jason A. Donenfeld wrote: > Hi Michael, > > On Wed, Mar 02, 2022 at 07:58:33AM -0500, Michael S. Tsirkin wrote: > > > There's also the atomicity aspect, which I think makes your benchmark > > > not quite accurate. Those 16 bytes could change between the first and > > > second word (or between the Nth and N+1th word for N<=3 on 32-bit). > > > What if in that case the word you read second doesn't change, but the > > > word you read first did? So then you find yourself having to do a > > > hi-lo-hi dance. > > > And then consider the 32-bit case, where that's even > > > more annoying. This is just one of those things that comes up when you > > > compare the semantics of a "large unique ID" and "word-sized counter", > > > as general topics. (My suggestion is that vmgenid provide both.) > > > > I don't see how this matters for any applications at all. Feel free to > > present a case that would be race free with a word but not a 16 > > byte value, I could not imagine one. It's human to err of course. > > Word-size reads happen all at once on systems that Linux supports, > whereas this is not the case for 16 bytes (with a few niche exceptions > like cmpxchg16b and such). If you read the counter atomically, you can > check to see whether it's changed just after encrypting but before > transmitting and not transmit if it has changed, and voila, no race. > With 16 bytes, synchronization of that read is pretty tricky (though > maybe not all together impossible), because, as I mentioned, the first > word might have changed by the time you read a matching second word. I'm > sure you're familiar with the use of seqlocks in the kernel for solving > a somewhat related problem. > > Jason I just don't see how "value changed while it was read" is so different from "value changed one clock after it was read". Since we don't detect the latter I don't see why we should worry about the former. What I don't have here is how would a code reading the value look. It might help to write some pseudo code to show that, but I'd say it makes more sense to just code the read up even just so the overhead of the current interface can be roughtly measured. -- MST