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 ws5-mx01.kavi.com (ws5-mx01.kavi.com [34.193.7.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7F4D3C46CA1 for ; Mon, 18 Sep 2023 14:05:34 +0000 (UTC) Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by ws5-mx01.kavi.com (Postfix) with ESMTP id 7B1691318FD for ; Mon, 18 Sep 2023 14:05:33 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 66ED69864D1 for ; Mon, 18 Sep 2023 14:05:33 +0000 (UTC) Received: from host09.ws5.connectedcommunity.org (host09.ws5.connectedcommunity.org [10.110.1.97]) by lists.oasis-open.org (Postfix) with QMQP id 560839863AD; Mon, 18 Sep 2023 14:05:33 +0000 (UTC) Mailing-List: contact virtio-dev-help@lists.oasis-open.org; run by ezmlm List-ID: Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 452F09863D8 for ; Mon, 18 Sep 2023 14:05:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-MC-Unique: 5VjUGSnRMeSYamHZJv2ufw-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695045926; x=1695650726; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aBaH0w7I2soY0dkzOxGiZAhm9GFoon2ZK3bUZWRDZAI=; b=MwGVKAXJgJArof6CMe3vX9XrlHZsw4vBTUgYE/+UlbFlQUTbARYLtPn4kRBzVsELKB 1Xe76ezdEFnSRM5MV8vBlINoLrZr04xPaq2fXoVP6trKsCXTSIAnylX6E4auPM2ZABJh u7s50+MyO0trfJQNs1uDOFyzmlT8uA40+2GBMSMIpLKOYIMcD5rXb92Jb1rFptyqX9X8 5RaTjEbHHjcB5y4EOoEPIFS2lFtmDBh5gutZli9spcurcDvnk5Dyc3VJhNicGYDESXlM 2ixxnEkDWeR+eRVyl+iD8xSE4mDacFoz3qRL7yWrKINOPo+5e94PMEUJRT2Quw4pUMbO q4ew== X-Gm-Message-State: AOJu0YxPbeUf1v1wKFGAc/cHKeHfvoMkZkqQPIijqqYngwouyKcE/it8 IHvTvKIGK82sufOCLlPnWWIvTYYCP4RM4vc8Txb4m06Lmq+hdtqWdf+YOfoxFyXz7pCniyy8ukZ cZ0h/fgk9epM6PlC3IOboX/l5lAAW X-Received: by 2002:a05:6402:320b:b0:530:d6c5:7e79 with SMTP id g11-20020a056402320b00b00530d6c57e79mr5639331eda.32.1695045925842; Mon, 18 Sep 2023 07:05:25 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE7nthvLQULQLpTDAJgK+3lUfEfesVF+IS0LX8MUzxYl5HeOR6sRpVtBkahoOq0Hr0mHiVOLA== X-Received: by 2002:a05:6402:320b:b0:530:d6c5:7e79 with SMTP id g11-20020a056402320b00b00530d6c57e79mr5639308eda.32.1695045925509; Mon, 18 Sep 2023 07:05:25 -0700 (PDT) Date: Mon, 18 Sep 2023 10:05:21 -0400 From: "Michael S. Tsirkin" To: Babis Chalios Cc: virtio-comment@lists.oasis-open.org, virtio-dev@lists.oasis-open.org, "Cali, Marco" , "Graf (AWS), Alexander" , "Jason A. Donenfeld" , aams@amazon.de Message-ID: <20230918100355-mutt-send-email-mst@kernel.org> References: <20221121162756.350032-4-mst@redhat.com> <0abb7518-16e0-4227-bfe1-a29bd27124e8@amazon.es> <20230912170032-mutt-send-email-mst@kernel.org> <20230913053707-mutt-send-email-mst@kernel.org> <20230918083722-mutt-send-email-mst@kernel.org> <20230918091506-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: [virtio-dev] [PATCH RFC 3/3] rng: leak detection support On Mon, Sep 18, 2023 at 04:02:54PM +0200, Babis Chalios wrote: > On 18/9/23 15:58, Michael S. Tsirkin wrote: > > On Mon, Sep 18, 2023 at 03:00:43PM +0200, Babis Chalios wrote: > > > > > Right, so I think that there is a race condition between the time the driver > > > > > sees the used buffers of the first > > > > > batch and until it adds the second batch on the next leak queue. > > > > > > > > > > 1. driver adds batch 1 > > > > > 2. leak event > > > > > 3. device uses batch 1 > > > > > 4. driver sees the used buffers and > > > > > a. switches leak queues > > > > > b. adds batch 2. > > > > > 5. devices finds initial leak queue empty and sees buffers in second leak > > > > > queue. > > > > > > > > > > If a second leak event happens after step 3 above and before all of steps 4 > > > > > complete then batch 2 will not > > > > > be processed as part of the second leak event. > > > > driver can just pre-add buffers in the second queue. > > > > > > > > 1. available buffers to queue 1-X > > > > 2. available buffers to queue X > > > > > > > > > > > > 3. poll queue X > > > > 4. used buffers in queue X > > > > 5. avail buffers in queue X > > > > 6. poll queue 1-X > > > > 7. used buffers in queue X > > > > 8. avail buffers in queue X > > > > 9. goto 3 > > > > > > > Yes, that's what the driver does now in the RFC patch. However, this just > > > decreases > > > the race window, it doesn't eliminate it. If a third leak event happens it > > > might not > > > find any buffers to use: > > > > > > 1. available buffers to queue 1-X > > > 2. available buffers to queue X > > > > > > > > > 3. poll queue X > > > 4. used buffers in queue X <- leak event 1 will use buffers in X > > > 5. avail buffers in queue X > > > 6. poll queue 1-X <- leak event 2 will use buffers in 1-X > > > 7. used buffers in queue 1-X > > > 8. avail buffers in queue 1-X > > > <- leak event 3 (it needs buffers in X, race with step 5) > > > 9. goto 3 > > > > I don't get it. we added buffers in step 5. > > What if the leak event 3 arrives before step 5 had time to actually add the > buffers in X and make > them visible to the device? Then it will see a single event in 1-X instead of two events. A leak is a leak though, I don't see does it matter how many triggered. > > > > > > > > > If, instead, we define a single leak queue and require that VMM should refuse to take a snapshot > > > if that queue is empty, we avoid the race condition in all cases and IMHO the protocol becomes > > > much simpler. > > > > > > > > > Cheers, > > > Babis > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org