Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp122238pxa; Fri, 31 Jul 2020 07:55:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyPpWTh6Mi33RSKSwiaFaMLEPAkm5R/ctgM8rHsAcA7Mw9okKL7taykYp1N5amM4zSBHg1d X-Received: by 2002:a17:906:698:: with SMTP id u24mr4323537ejb.57.1596207300617; Fri, 31 Jul 2020 07:55:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596207300; cv=none; d=google.com; s=arc-20160816; b=t+GnuQ5lpEpESybaQvjlguXO+qFFbW8M18p+bQtnFG3WMrpT0S8G9phVDEvQ47Qzf3 nDAto9Y4h76o/uBuNTQ6ti0w1XZ+BLmStpZgm7elTmoaEvzLEbKAAJ3otFBxy5pGVIox eVw1hAW0rCueS3zTbwTt8K+lng4gOFO5sJG1RklM+Z8tsVt+9qHX+9vFzb+6zm9BMKAP 4CbjUsQgaA+LiOa0mMsJnzJDl4Z0EXrrOoGJb3I3UP+JDb/qKrfOHzgVXY4RK6mK4bJL jpZtbluB05S1uTRyK2psJju6CQNJ1wTY5MLxfv6VK1sbpwYKbeM/O3h29FG/Mk4SJJL5 7grg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=7xbkWYnKB5bD8Dx+A3hqQvuyFQl9+LQz6yTL7Vvq6w0=; b=TQFPuPrpMKqk7U4UdyITkqysSQf9gfUPdgTeqvs+BUZnAGj5c8Vj8cRSntaiU0l9FL 7xmtzF+bZ6gsecr/e3iB9wnfUBM0ybzjziEJT9FbU292092Y0hZsL7tpwSpJY63E/6W1 hhw16V4k4lB1JcQM8JM7mCCdqscpFiNFGpC05GArowdtZtenebHLxURk9cIQc80VAixn yo+FnS3bbzbnc8j1ZCng0GJZ3GotYAQofPkXDWKJDhKhj3hLHiMEMgOof+2VUB7RnBs7 TtX8Y8h2/lFBPvyLWG25FCHwG4XrWkLu1GUhr5UlKURUP0HhmhatU1VsCodwGU1V2beF 4OqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=s7e5W0fX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id t15si5120772eje.543.2020.07.31.07.54.20; Fri, 31 Jul 2020 07:55:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=s7e5W0fX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1728713AbgGaOwt (ORCPT + 99 others); Fri, 31 Jul 2020 10:52:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726925AbgGaOwt (ORCPT ); Fri, 31 Jul 2020 10:52:49 -0400 Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A5123C061574 for ; Fri, 31 Jul 2020 07:52:48 -0700 (PDT) Received: by mail-ed1-x543.google.com with SMTP id di22so15375170edb.12 for ; Fri, 31 Jul 2020 07:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7xbkWYnKB5bD8Dx+A3hqQvuyFQl9+LQz6yTL7Vvq6w0=; b=s7e5W0fXDILLB6ZWbNuQf571n49wktNjevDIf5ymOQ4TmVGXG/ZXEhdZ5d2V2CSlGz SQFONr4GotVUcj7ixDNsa/uashyzLwpPDHZD254BElUXOnbseZXkDpKdmlzJHzGcW5lN HvkEPK1kV8BwVkzcYf2T62N3V+yUFc1TSsAWKyqD7cET6pOYxMk/unAf2w3OhIWXlwJC iQPf5U3ideRZ3LCcsaE5QbRva7XwFMZadtyqvvng1ODDFENc/f5u3wI+RXzsiF+dYn32 5YUMF86zfXDGdwXniwrzfwZf3DBgyBPfFya+TKVIhW0JLlMZ2fz/t76egk/7KVNrEX59 7bUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7xbkWYnKB5bD8Dx+A3hqQvuyFQl9+LQz6yTL7Vvq6w0=; b=n9dTe1YiEaRYaJThKRPnzVVFyc2FFGt93eHunseyKq1A1dkA4NIVRYU0srGO45GSpJ suDiSRSl9VyExnxLyqXIRFoSPigH156oWWaqBsBuymAsMOHf1OjpxpOxoETCfY9eY3lv Ec86Hzb4zmkUwVdWs/mZw+ji3gHVt09rZVgnYLZLLdDjLzEyt716dmTcXacK/3zX1UML 6dtRMs6yHNuCO7D0XoNleNRJk83eRGP6WEX0C7noOKG5idcF+oQYfIT4iKzqFJIlrodo O7V5gehSWwt9zBbKAU2saY/WDQrGPjG4ty1K6obbyOdgTv5lAxXA+zarCJj2cM6XKa8k akEg== X-Gm-Message-State: AOAM532osxzCK/ehiVw6WaVTjQ9qKC67zHmtLQFsdcFdYBxfW0FKDW7e 4CUWc+WQHM5aljMygbXOkIjw6YlLqbKPFzaV7VrLzQ== X-Received: by 2002:a50:fb06:: with SMTP id d6mr4114200edq.165.1596207167258; Fri, 31 Jul 2020 07:52:47 -0700 (PDT) MIME-Version: 1.0 References: <20200716172913.19658-1-joao.m.martins@oracle.com> <20200716172913.19658-3-joao.m.martins@oracle.com> In-Reply-To: <20200716172913.19658-3-joao.m.martins@oracle.com> From: Dan Williams Date: Fri, 31 Jul 2020 07:52:36 -0700 Message-ID: Subject: Re: [PATCH v1 2/4] device-dax: Add an 'align' attribute To: Joao Martins Cc: linux-nvdimm , Vishal Verma , Dave Jiang , Linux Kernel Mailing List , Linux MM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 16, 2020 at 10:31 AM Joao Martins wrote: > > Introduce a device align attribute. While doing so, > rename the region align attribute to be more explicitly > named as so, but keep it named as @align to retain the API > for tools like daxctl. > > Changes on align may not always be valid, when say certain > mappings were created with 2M and then we switch to 1G. So, we > validate all ranges against the new value being attempted, > post resizing. > > Signed-off-by: Joao Martins > --- > drivers/dax/bus.c | 101 +++++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 92 insertions(+), 9 deletions(-) > > diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c > index 2578651c596e..eb384dd6a376 100644 > --- a/drivers/dax/bus.c > +++ b/drivers/dax/bus.c > @@ -230,14 +230,15 @@ static ssize_t region_size_show(struct device *dev, > static struct device_attribute dev_attr_region_size = __ATTR(size, 0444, > region_size_show, NULL); > > -static ssize_t align_show(struct device *dev, > +static ssize_t region_align_show(struct device *dev, > struct device_attribute *attr, char *buf) > { > struct dax_region *dax_region = dev_get_drvdata(dev); > > return sprintf(buf, "%u\n", dax_region->align); > } > -static DEVICE_ATTR_RO(align); > +static struct device_attribute dev_attr_region_align = > + __ATTR(align, 0400, region_align_show, NULL); > > #define for_each_dax_region_resource(dax_region, res) \ > for (res = (dax_region)->res.child; res; res = res->sibling) > @@ -488,7 +489,7 @@ static umode_t dax_region_visible(struct kobject *kobj, struct attribute *a, > static struct attribute *dax_region_attributes[] = { > &dev_attr_available_size.attr, > &dev_attr_region_size.attr, > - &dev_attr_align.attr, > + &dev_attr_region_align.attr, > &dev_attr_create.attr, > &dev_attr_seed.attr, > &dev_attr_delete.attr, > @@ -855,14 +856,13 @@ static ssize_t size_show(struct device *dev, > return sprintf(buf, "%llu\n", size); > } > > -static bool alloc_is_aligned(struct dax_region *dax_region, > - resource_size_t size) > +static bool alloc_is_aligned(resource_size_t size, unsigned long align) For type safety, let's make this take @dev_dax as a parameter. For the dev_dax_set_align() case I think it is ok to provisionally adjust dev_dax->align under the lock before entry and revert to the old alignment on failure. I can fix that up locally on applying.