Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp102743imu; Mon, 10 Dec 2018 17:07:27 -0800 (PST) X-Google-Smtp-Source: AFSGD/WOiua68ouZSmMKZuNX+Os/d6fcgQHzW43/deKshL1dJCq/jgOWB6TfiXdidhgj3aEuj9gl X-Received: by 2002:a63:790e:: with SMTP id u14mr12784448pgc.452.1544490447646; Mon, 10 Dec 2018 17:07:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544490447; cv=none; d=google.com; s=arc-20160816; b=tKFz7sxiyCU+mKwmezRfFk3dwwlAV2BhAVatIph2FLOPYn9lv0qYnoVM8XpJdXz93m 2DnMo6l4tfMzQfF4/BWTOXQpBp1moaH5P7CldDEXNH6PDmkvPjV97ml6Uu/MId5Y+yuj yOLQCyJ21xL3QpGhTEv9YQh93B+MSBHT7E+I35M4ICG9nc3hDUgjXYTtTT8qx2A3OmvL 4Rz6z/+G6JHNVr3K4aP2pjqsPCuXp8Iksg+6zrfOBxWPwMq/sPkIYG3QLuwqWeew9Vui FJumaoehctTUxlSGp6fxM1Z1n32oQPCRLrObUjKZMnoL77SR7BEqIt3s+NQ4aq1RdGlE gaeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=yi1VF96O/q8BCikgm25lag/fmoX6JrFGqfib6kD7cMo=; b=WMIBSdvy/cLIQVC5vOhSg5Hm7UNWafMJydRFcIEbf9dDp8wygq4v5rYCKA2zYqMhXS zx4G4KsR82u87UErFBEcl8dpC2A/M0ncnKZHjw83NVfCEDw+di9zsdjeZiiSKl8X58nM IyD1Az25UGtLUAOPnMgd4c7SUtIef5ABQ9SBR7MOt7PZel/UaGLpBQqr3Da46Hu3yjNI ERWeKatoR5bht8+qYzrXltibeJInSasKLVslYnyor4+Mvn06uLsnVzBA9wSVGk4RR7Xm 1o2Z2t7OFFeGJQB8s3cJahrHyYB5ZJPiDejdjrGzhE10aIxpLabLiPvb31ZbpdJ0wNKw Pa5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=SMwiI9t1; 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 y2si11235198pli.266.2018.12.10.17.07.12; Mon, 10 Dec 2018 17:07:27 -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=SMwiI9t1; 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 S1728689AbeLKAKo (ORCPT + 99 others); Mon, 10 Dec 2018 19:10:44 -0500 Received: from mail-oi1-f194.google.com ([209.85.167.194]:38672 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726720AbeLKAKo (ORCPT ); Mon, 10 Dec 2018 19:10:44 -0500 Received: by mail-oi1-f194.google.com with SMTP id a77so10583255oii.5 for ; Mon, 10 Dec 2018 16:10:43 -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; bh=yi1VF96O/q8BCikgm25lag/fmoX6JrFGqfib6kD7cMo=; b=SMwiI9t1szhtExZ4zKZzTD2Xqq8bjMi8Ht4SZDzQC8L17IrgIDSRQWAZn4Maf+5D3e AmS8nDPTGpBoEyA5uyzbGgQGarVOGRzxMAi8nJKO56Yno1mx6JHll3xtNDZ8NDMz+gZe 8A5lZ9WXfvbykOp2DCHCEseD2lKFgw7FLXEIekcSXqEgmMTpWgstajDqicyhpdL3/lBr MofVO/cz1rbKVoIjkftwOfM5ptIW17YX+IbPKJxmfYUTNjOuUV5yyF1UC88sWzdHYIlC REuV+/iI75QL0Ml08Nk+TFtIstSE9tGdrP3D2BYzbadhzxSi2yzivL3oDXb73pwDbJ9R oEpw== 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; bh=yi1VF96O/q8BCikgm25lag/fmoX6JrFGqfib6kD7cMo=; b=b2/9mN9sV/WU5dkL1SMI8ik4xWZG1K/MIPJeGmksfgJ9+51H0irhCVfsnn6ttm6eC3 Mjk//Ae34nlXB51SB9I7g+5ZUCXyTQtBJPwR8Qu4sh63BhXCCPDkimZoXBsvp7ah+R// XkWMbfrpsNChO1yKOpxIIGMqZrUPkWzQEyqmM7XubOOQ4oqT5X1ASsruS2z5rsSjJl1o +k9ajXYVs4l7Vsrrj0l933VQnWaTOp8snSoGSlJQ4XGMC4pzhqHZK2tm2ACVA99TLHsq 8MqN//V3NQvuea+b48bzlEGB2hGrIPBMmUkwHqkBHa7B/E6jdauyPyR8q4l0tOJMgKE4 UbGA== X-Gm-Message-State: AA+aEWa8yWeUeQ0yBodCqf9ou3mO3rT1GbbywDQTlcg7JW6RG7DOyLfD nd1xbw0dxy2qgUufHqxZktH2gNbu+Ob93vSoYh/ImA== X-Received: by 2002:aca:d905:: with SMTP id q5mr119976oig.0.1544487043418; Mon, 10 Dec 2018 16:10:43 -0800 (PST) MIME-Version: 1.0 References: <46441800c43f029757c70d8386e3112701081503.1534160958.git.yi.z.zhang@linux.intel.com> <1534787638.13739.52.camel@intel.com> <89e7bd54-4afa-614d-ec54-49af7928d6c7@intel.com> <20180821161657.GA22028@tiger-server> In-Reply-To: <20180821161657.GA22028@tiger-server> From: Dan Williams Date: Mon, 10 Dec 2018 16:10:31 -0800 Message-ID: Subject: Re: [PATCH V2 1/1] device-dax: check for vma range while dax_mmap. To: Dave Jiang , Vishal L Verma , "Zhang, Yu C" , Linux Kernel Mailing List , linux-nvdimm , zwisler@kernel.org, Jan Kara , "Zhang, Yi Z" 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 Tue, Aug 21, 2018 at 12:38 AM Yi Zhang wrote: > > On 2018-08-20 at 12:50:31 -0700, Dave Jiang wrote: > > > > > > On 08/20/2018 10:53 AM, Verma, Vishal L wrote: > > > > > > On Mon, 2018-08-13 at 20:02 +0800, Zhang Yi wrote: > > >> This patch prevents a user mapping an illegal vma range that is larger > > >> than a dax device physical resource. > > >> > > >> When qemu maps the dax device for virtual nvdimm's backend device, the > > >> v-nvdimm label area is defined at the end of mapped range. By using an > > >> illegal size that exceeds the range of the device dax, it will trigger a > > >> fault with qemu. > > >> > > >> Signed-off-by: Zhang Yi > > >> --- > > >> drivers/dax/device.c | 29 +++++++++++++++++++++++++++++ > > >> 1 file changed, 29 insertions(+) > > >> > > > > > > Looks good to me: > > > Reviewed-by: Vishal Verma > > > > Applied. > Thanks Dava and Vishal's kindly review. Thank you. So, it turns out this patch did not get merged for 4.20. I fumbled it when returning from vacation. However, I'm not sure it is needed. As long as attempts to access the out-of-range capacity results in SIGBUS then the implementation is correct. This is similar to the case where a file is truncated after the vma is established. That size is validated at fault time. Could you be clearer about why this is a problem? The fault sounds like the correct result.