Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1068069ybn; Wed, 2 Oct 2019 10:20:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqxcnMBhM1w6oFUpGwc/QxYc7MVw6pCcIaRTQ4H7Pogwu79rFgURYluxUHPGB61yw/NCBRSH X-Received: by 2002:aa7:dd8e:: with SMTP id g14mr4986178edv.233.1570036823859; Wed, 02 Oct 2019 10:20:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570036823; cv=none; d=google.com; s=arc-20160816; b=o9b+W4kWdVBXTeZryTHPtUzGQqhk7CXDvDVqxqcYPZXzqlMRgJN4bLOdpkG3XLkw5a qZDIamztKVYDQR/AtPL5i6ukTTAZFpTwVylw19gBTkWvRRNGjZdK+upVPfGvwB+nErB/ Zg7xzrmy+4tyiq6F+r6I07cVGEVxSNH5r09HcR9SaufOoINK6hrlvTW7VY623wglRUqy N2y/EKLQbmH5ezI7OB1GoYCpvVRULh8wHZp8VYB7Hn8/AtUBewvmWNczWatpaZgJr14U VUUh10nNBgd48MaJqgNnyHhGo+X9e4u8d+vVUbV9tHptXFGGxzTwhkoJ/xhf1Uqi3ppB 7Osw== 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=FGy1yj2Nkd4I3o1PANIl4doU/LIuczpCSjwOaFwpFtM=; b=hecEb+QrQI4XWkNVO9WmYq4pVY+Lk7yxpm35/rG1JD+bPHZpMI+T4607f33sg/NYl8 joVjoXaxO/xoM3NO0QIpzMuBKGTN+FMnvlIslttJvaOOmEOoqz9BC388TRzbVTh/QWRs k8z467bw3FarEG5Il2laXKc69SudIQ6ajulr4FbsuxE4ZxwfugnqS2zc9CiMRtikCLT9 hA7zPX1CmW9vxLFutdvulLF9nNZGQKXeoYSyD4uhtqJC9ZSdRwTKUaPsRRrCC59LYEQe i4/z0hlXjGLppk9h2rsg0Y50DjgLke6FABdpsqv3PFRB4YZ6jNp7n2RunSxIeAwQccty 0T0A== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d14si11022212ejr.358.2019.10.02.10.19.59; Wed, 02 Oct 2019 10:20:23 -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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728476AbfJBRQg (ORCPT + 99 others); Wed, 2 Oct 2019 13:16:36 -0400 Received: from mga07.intel.com ([134.134.136.100]:52280 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727910AbfJBRQg (ORCPT ); Wed, 2 Oct 2019 13:16:36 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2019 10:16:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,249,1566889200"; d="scan'208";a="343390102" Received: from jacob-builder.jf.intel.com (HELO jacob-builder) ([10.7.199.155]) by orsmga004.jf.intel.com with ESMTP; 02 Oct 2019 10:16:35 -0700 Date: Wed, 2 Oct 2019 10:20:44 -0700 From: Jacob Pan To: Jean-Philippe Brucker Cc: iommu@lists.linux-foundation.org, LKML , Joerg Roedel , David Woodhouse , Alex Williamson , Jean-Philippe Brucker , Yi Liu , "Tian, Kevin" , Raj Ashok , Christoph Hellwig , Lu Baolu , Jonathan Cameron , Eric Auger , jacob.jun.pan@linux.intel.com Subject: Re: [PATCH v2 3/4] iommu/ioasid: Add custom allocators Message-ID: <20191002102044.6ed3ad56@jacob-builder> In-Reply-To: <20191002161825.GA626133@lophozonia> References: <1569110870-12603-1-git-send-email-jacob.jun.pan@linux.intel.com> <1569110870-12603-4-git-send-email-jacob.jun.pan@linux.intel.com> <20191002161825.GA626133@lophozonia> Organization: OTC X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2 Oct 2019 18:18:25 +0200 Jean-Philippe Brucker wrote: > Hi Jacob, > > I have four tiny comments below but the patch looks great otherwise, > no major concern from me. > > On Sat, Sep 21, 2019 at 05:07:49PM -0700, Jacob Pan wrote: > > +/* > > + * struct ioasid_allocator_data - Internal data structure to hold > > information > > + * about an allocator. There are two types of allocators: > > + * > > + * - Default allocator always has its own XArray to track the > > IOASIDs allocated. > > + * - Custom allocators may share allocation helpers with different > > private data. > > + * Custom allocators that share the same helper functions also > > share the same > > + * XArray. > > + * Rules: > > + * 1. Default allocator is always available, not dynamically > > registered. This is > > + * to prevent race conditions with early boot code that want to > > register > > + * custom allocators or allocate IOASIDs. > > + * 2. Custom allocators take precedence over the default allocator. > > + * 3. When all custom allocators sharing the same helper functions > > are > > + * unregistered (e.g. due to hotplug), all outstanding IOASIDs > > must be > > + * freed. Otherwise, outstand IOASIDs will be lost and > > orphaned. > > outstanding > > [...] > > ioasid_t ioasid_alloc(struct ioasid_set *set, ioasid_t min, > > ioasid_t max, void *private) > > { > > - ioasid_t id; > > struct ioasid_data *data; > > + void *adata; > > + ioasid_t id; > > nit: changing the location of id could be in patch 2/4. > will do. > > - data = kzalloc(sizeof(*data), GFP_KERNEL); > > + data = kzalloc(sizeof(*data), GFP_ATOMIC); > > I don't think that one needs to be GFP_ATOMIC. Otherwise it should > probably be done from the start, by patch 2/4. > I was thinking since we are making this API usable in atomic context, we need to use GFP_ATOMIC and spinlock throughout the code. I agree it should be moved to 2/4. > > if (!data) > > return INVALID_IOASID; > > > > data->set = set; > > data->private = private; > > > > - if (xa_alloc(&ioasid_xa, &id, data, XA_LIMIT(min, max), > > GFP_KERNEL)) { > > - pr_err("Failed to alloc ioasid from %d to %d\n", > > min, max); > > + /* > > + * Custom allocator needs allocator data to perform > > platform specific > > + * operations. > > + */ > > + spin_lock(&ioasid_allocator_lock); > > + adata = active_allocator->flags & > > IOASID_ALLOCATOR_CUSTOM ? active_allocator->ops->pdata : data; > > + id = active_allocator->ops->alloc(min, max, adata); > > + if (id == INVALID_IOASID) { > > + pr_err("Failed ASID allocation %lu\n", > > active_allocator->flags); > > + goto exit_free; > > + } > > + > > + if ((active_allocator->flags & IOASID_ALLOCATOR_CUSTOM) && > > + xa_alloc(&active_allocator->xa, &id, data, > > XA_LIMIT(id, id), GFP_ATOMIC)) { > > nit: aligning at the "if (" would make this block more readable. > sounds good. I need to change my editor :) > > + /* Custom allocator needs framework to store and > > track allocation results */ > > + pr_err("Failed to alloc ioasid from %d\n", id); > > + active_allocator->ops->free(id, > > active_allocator->ops->pdata); goto exit_free; > > } > > Thanks, > Jean [Jacob Pan]