Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp317911imj; Wed, 13 Feb 2019 08:50:46 -0800 (PST) X-Google-Smtp-Source: AHgI3IakUoYuUhnxPYhSAyx2ebyYigEXbagHy0AqrxUFTNMYZOAJfeENIJqN22CNMCMo1uZMZOjB X-Received: by 2002:a65:500c:: with SMTP id f12mr1278836pgo.226.1550076646918; Wed, 13 Feb 2019 08:50:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550076646; cv=none; d=google.com; s=arc-20160816; b=09dQWN2atPKVxRXiNIswUls++7SYRO2JFp2isB38c0MBlScpEZoi9JffgNP9rplgIP 4XZwvysyKce1fhdZhJeNuLaDm0fk6Mvbqk6Go53Wc8S1H63Q239mcA4GmHbumVgfyULQ wyvo962PMAxw++1e4YCLl600XH/1aNfxrqwvqdlA7V6kfO24kaZSuAX/cMKEGNU4LSwJ 9pxoRbK78XXAoyD9rK7uqUwArOlIPuQasKDwnBrIFFyge+LpwUmdMT67sDZnHkiA7vHr uvW6hMEsrhzE20p6aJi4f79E0tuhJql0nusYo2sOafHW0hxh/63FrEchgwMS/SvAC6IP zenw== 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=XtYAbd61b340Vd3goSh2N2gZ0biExBnNhPdti+q3fWM=; b=GfZab8VgjDkzWUMqx0H4DQ9kh0fo/GIaZnUyk/jKYr6WPjxQZYN3sR5KfdTl40eEpM 6/jCVLAycQ19ZyVdhpiGcsxZnUvdl3MGOOPhrlhmbZRxCfha7XtCWh86RlR3wsipDCmU iaj6XLLCmk9C8JyBKfQUviohSMKK76zHCYp1E5W5sc75UN+EmyTwD1FWobHcXrfRlsEW vLUAeaIdOEszpGYKRrXtJ/Xvq8wcUMCQ2Suew8xbu1gW/5Rg19tFM4YQYuYRD22aR3jg 6FqK/4/T2XlVbTQJvHcahhaomdrZJw6L0tDDswvfXmRzSlIzegfI3YBIPh8d5QuRaA4K fTrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=vq6KrWoR; 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 z25si14954686pgu.560.2019.02.13.08.50.30; Wed, 13 Feb 2019 08:50:46 -0800 (PST) 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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=vq6KrWoR; 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 S2392686AbfBMQuB (ORCPT + 99 others); Wed, 13 Feb 2019 11:50:01 -0500 Received: from mail-ot1-f66.google.com ([209.85.210.66]:46109 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388561AbfBMQuA (ORCPT ); Wed, 13 Feb 2019 11:50:00 -0500 Received: by mail-ot1-f66.google.com with SMTP id w25so5315263otm.13 for ; Wed, 13 Feb 2019 08:50:00 -0800 (PST) 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=XtYAbd61b340Vd3goSh2N2gZ0biExBnNhPdti+q3fWM=; b=vq6KrWoRpJa7Efj9KN5Rx9KajsCeZCXqEFYqOZEKwKqpVb0f2e9tb95B49AOibTbEq LZXHlLJHGxc7fdixDC3Y9zWBuiC+AMyP+AxiFG5U+D8vAlz3kFUYQr9aYHHLDniugXj8 WWuICq9NJwnwc3gzVZF5/8t5GxRY7+LcbuNCQoBzjQVc222d7pyrlJn291tFup8Wcf7Z MhFGMcua74XKheGnIy642YVsyNQ1cJ9vd63NC1wVFogKV95KCSWLVxU6edqmofmWeyTj b3pHtHFLLxG+XPw9+ULrktNH8eBG1G8muF7N5H+/SQco+9N9cZ34MiU5vxD0joUquTK0 UzfA== 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=XtYAbd61b340Vd3goSh2N2gZ0biExBnNhPdti+q3fWM=; b=skpSSO/Df/P0BC0osjXcaArtFlnokgqCFIvvZ9Xq+p2nFVYAC8TTZ/CxMLN9nP1vwf +uk4M1Gs3OuUnK1oqgS0NF/S/ECLFhGMIXw8J9mmi0GjgOIva2w5mXVY2+GK3fzukKjm xEZKkYGNXVLqSpbSQI+QvWl/wEPwz317xfAH2FXBY1CSQeScZ74pnxX/vvc/HnaGYiBB 7E1HjLf2nTUZMlZ+DiQNqDf6lDJisrjpT5+xNqM2UldB+xyH0jFgDVvdakp1blM1K/hy FS0x0Z7JXgqBUFxRdM/hMIJvPZ8MgLJc8Qk+m46OXJX8gx5TxQELSdjK79MdpgXOYlVL 8IVA== X-Gm-Message-State: AHQUAuZ6ZJvNgSCeIV/FZbxe2hH71l2jXSqcokJ6OUASplTmJFheB85A 4ZST6WrnsEhdmElONVUaS9aqDnwgO6UyGduFFF0uE64q X-Received: by 2002:a05:6808:344:: with SMTP id j4mr770099oie.149.1550076599649; Wed, 13 Feb 2019 08:49:59 -0800 (PST) MIME-Version: 1.0 References: <155000668075.348031.9371497273408112600.stgit@dwillia2-desk3.amr.corp.intel.com> <155000669646.348031.16690970886357498896.stgit@dwillia2-desk3.amr.corp.intel.com> <20190213102202.GA13313@quack2.suse.cz> In-Reply-To: <20190213102202.GA13313@quack2.suse.cz> From: Dan Williams Date: Wed, 13 Feb 2019 08:49:47 -0800 Message-ID: Subject: Re: [PATCH 3/7] dax: Check the end of the block-device capacity with dax_direct_access() To: Jan Kara Cc: linux-nvdimm , "Darrick J. Wong" , Linux Kernel Mailing List , Vishal L Verma , linux-fsdevel 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 Wed, Feb 13, 2019 at 2:22 AM Jan Kara wrote: > > On Tue 12-02-19 13:24:56, Dan Williams wrote: > > The checks in __bdev_dax_supported() helped mitigate a potential data > > corruption bug in the pmem driver's handling of section alignment > > padding. Strengthen the checks, including checking the end of the range, > > to validate the dev_pagemap, Xarray entries, and sector-to-pfn > > translation established for pmem namespaces. > > > > Cc: Jan Kara > > Cc: "Darrick J. Wong" > > Signed-off-by: Dan Williams > > --- > > drivers/dax/super.c | 39 +++++++++++++++++++++++++++++---------- > > 1 file changed, 29 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c > > index 6e928f37d084..a27395cfcec6 100644 > > --- a/drivers/dax/super.c > > +++ b/drivers/dax/super.c > > @@ -86,12 +86,14 @@ bool __bdev_dax_supported(struct block_device *bdev, int blocksize) > > { > > struct dax_device *dax_dev; > > bool dax_enabled = false; > > + pgoff_t pgoff, pgoff_end; > > struct request_queue *q; > > - pgoff_t pgoff; > > - int err, id; > > - pfn_t pfn; > > - long len; > > char buf[BDEVNAME_SIZE]; > > + void *kaddr, *end_kaddr; > > + pfn_t pfn, end_pfn; > > + sector_t last_page; > > + long len, len2; > > + int err, id; > > > > if (blocksize != PAGE_SIZE) { > > pr_debug("%s: error: unsupported blocksize for dax\n", > > @@ -113,6 +115,15 @@ bool __bdev_dax_supported(struct block_device *bdev, int blocksize) > > return false; > > } > > > > + last_page = ALIGN_DOWN(part_nr_sects_read(bdev->bd_part) > > + - PAGE_SIZE / 512, PAGE_SIZE / 512); > > Why not just (i_size_read(bdev->bd_inode) - 1) >> PAGE_SHIFT? Because that would be too elegant and straightforward? > Otherwise the patch looks good to me. Thanks, I'll fix up the last page calculation.