Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp778762ybl; Fri, 30 Aug 2019 07:05:46 -0700 (PDT) X-Google-Smtp-Source: APXvYqycMux91HP3OHLHNlV+NRLCBvqdwFHU8M1vLRDq67zQVU2fV+6mxCC9PPn4kJJGnZHhoQ5B X-Received: by 2002:aa7:87d5:: with SMTP id i21mr18340089pfo.70.1567173945944; Fri, 30 Aug 2019 07:05:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567173945; cv=none; d=google.com; s=arc-20160816; b=BvQL6wHOnWBs1X4GwNHznjG3AVrdQ9+u/9wuCpZgCEpqeVRIloOo/81C6Gt189lRRu gJOTfSu0ECQuTnnNQUorj1XjFPFK6ZcC4h5O3bjKLxcMFEfD3r4RGtndgfJGPC/TBgEv UXck29NlrH6MBJgR2JEMyWPTH+90qAM+mxX9gP5+w4pv78xMrhssMTPD5tFV+3qoyvG0 8xH65v2r078pBpyjtu7HK0ps8uZni9wKKcmBt3vXw1dThXsqizt15nbiE0kkCty0rde4 fhD6U8g9sWvfPtRF4HCGcGhW5oITAD/4vcqAniUP2ieaFzROaq3AWj1PkEuFNFK8Dw/c BsSg== 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:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=GN/wAXCMSe31JBCRc8sYiyJzp5uNKoiJ+hDocvpzDvU=; b=kIon32V7M2qwjy+vZHj/OsQLNUv9egrkjWTKhV0qJ8uybTseMebPeyUqIJZIHrAE4l 1fy0FsqSfMogimopIREatIemc8IHhStgpWvSXYchU4N4sY4LJ6QdenmkIrT7/Ot+0vYL UfGhPiuPekbAA1nKt0SAxQuT1upKe5Qb/N/2ixY1+uDYQao8suxfvR/EdBmkqgWmPulP jITbAjkrR6NQpxpWwJX0MxwH+rhZQ41pvdwWqGRsGQWX/AULbfu/Hnp07RaEOagXVTT1 3IfYZ9OFOAL5yGdGljy71DvoMRWii9aD/LmwRyxiyCTeqeak0EoXGfYswNBAai5RKGNS wPOg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (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 v186si4415758pgd.358.2019.08.30.07.05.26; Fri, 30 Aug 2019 07:05:45 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728129AbfH3OCb (ORCPT + 99 others); Fri, 30 Aug 2019 10:02:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19836 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727135AbfH3OCa (ORCPT ); Fri, 30 Aug 2019 10:02:30 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 62C7FC075BD2; Fri, 30 Aug 2019 14:02:30 +0000 (UTC) Received: from gondolin (dhcp-192-222.str.redhat.com [10.33.192.222]) by smtp.corp.redhat.com (Postfix) with ESMTP id 35E8D3DE1; Fri, 30 Aug 2019 14:02:26 +0000 (UTC) Date: Fri, 30 Aug 2019 16:02:23 +0200 From: Cornelia Huck To: Parav Pandit Cc: "alex.williamson@redhat.com" , Jiri Pirko , "kwankhede@nvidia.com" , "davem@davemloft.net" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" Subject: Re: [PATCH v2 1/6] mdev: Introduce sha1 based mdev alias Message-ID: <20190830160223.332fd81f.cohuck@redhat.com> In-Reply-To: References: <20190826204119.54386-1-parav@mellanox.com> <20190829111904.16042-1-parav@mellanox.com> <20190829111904.16042-2-parav@mellanox.com> <20190830111720.04aa54e9.cohuck@redhat.com> <20190830143927.163d13a7.cohuck@redhat.com> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 30 Aug 2019 14:02:30 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 30 Aug 2019 12:58:04 +0000 Parav Pandit wrote: > > -----Original Message----- > > From: Cornelia Huck > > Sent: Friday, August 30, 2019 6:09 PM > > To: Parav Pandit > > Cc: alex.williamson@redhat.com; Jiri Pirko ; > > kwankhede@nvidia.com; davem@davemloft.net; kvm@vger.kernel.org; linux- > > kernel@vger.kernel.org; netdev@vger.kernel.org > > Subject: Re: [PATCH v2 1/6] mdev: Introduce sha1 based mdev alias > > > > On Fri, 30 Aug 2019 12:33:22 +0000 > > Parav Pandit wrote: > > > > > > -----Original Message----- > > > > From: Cornelia Huck > > > > Sent: Friday, August 30, 2019 2:47 PM > > > > To: Parav Pandit > > > > Cc: alex.williamson@redhat.com; Jiri Pirko ; > > > > kwankhede@nvidia.com; davem@davemloft.net; kvm@vger.kernel.org; > > > > linux- kernel@vger.kernel.org; netdev@vger.kernel.org > > > > Subject: Re: [PATCH v2 1/6] mdev: Introduce sha1 based mdev alias > > > > > > > > On Thu, 29 Aug 2019 06:18:59 -0500 > > > > Parav Pandit wrote: > > > > > > > > > Some vendor drivers want an identifier for an mdev device that is > > > > > shorter than the UUID, due to length restrictions in the consumers > > > > > of that identifier. > > > > > > > > > > Add a callback that allows a vendor driver to request an alias of > > > > > a specified length to be generated for an mdev device. If > > > > > generated, that alias is checked for collisions. > > > > > > > > > > It is an optional attribute. > > > > > mdev alias is generated using sha1 from the mdev name. > > > > > > > > > > Signed-off-by: Parav Pandit > > > > > > > > > > --- > > > > > Changelog: > > > > > v1->v2: > > > > > - Kept mdev_device naturally aligned > > > > > - Added error checking for crypt_*() calls > > > > > - Corrected a typo from 'and' to 'an' > > > > > - Changed return type of generate_alias() from int to char* > > > > > v0->v1: > > > > > - Moved alias length check outside of the parent lock > > > > > - Moved alias and digest allocation from kvzalloc to kzalloc > > > > > - &alias[0] changed to alias > > > > > - alias_length check is nested under get_alias_length callback > > > > > check > > > > > - Changed comments to start with an empty line > > > > > - Fixed cleaunup of hash if mdev_bus_register() fails > > > > > - Added comment where alias memory ownership is handed over to > > > > > mdev device > > > > > - Updated commit log to indicate motivation for this feature > > > > > --- > > > > > drivers/vfio/mdev/mdev_core.c | 123 > > > > ++++++++++++++++++++++++++++++- > > > > > drivers/vfio/mdev/mdev_private.h | 5 +- > > > > > drivers/vfio/mdev/mdev_sysfs.c | 13 ++-- > > > > > include/linux/mdev.h | 4 + > > > > > 4 files changed, 135 insertions(+), 10 deletions(-) > > > > > > ...and detached from the local variable here. Who is freeing it? The > > > > comment states that it is done by the mdev, but I don't see it? > > > > > > > mdev_device_free() frees it. > > > > Ah yes, I overlooked the kfree(). > > > > > once its assigned to mdev, mdev is the owner of it. > > > > > > > This detour via the local variable looks weird to me. Can you either > > > > create the alias directly in the mdev (would need to happen later in > > > > the function, but I'm not sure why you generate the alias before > > > > checking for duplicates anyway), or do an explicit copy? > > > Alias duplicate check is done after generating it, because duplicate alias are > > not allowed. > > > The probability of collision is rare. > > > So it is speculatively generated without hold the lock, because there is no > > need to hold the lock. > > > It is compared along with guid while mutex lock is held in single loop. > > > And if it is duplicate, there is no need to allocate mdev. > > > > > > It will be sub optimal to run through the mdev list 2nd time after mdev > > creation and after generating alias for duplicate check. > > > > Ok, but what about copying it? I find this "set local variable to NULL after > > ownership is transferred" pattern a bit unintuitive. Copying it to the mdev (and > > then unconditionally freeing it) looks more obvious to me. > Its not unconditionally freed. That's not what I have been saying :( > Its freed in the error unwinding path. > I think its ok along with the comment that describes this error path area. It is not wrong, but I'm not sure I like it.