From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B844C3B190 for ; Thu, 13 Feb 2020 22:43:43 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6143920873 for ; Thu, 13 Feb 2020 22:43:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="SmXDDB05" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6143920873 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id D76B410FC33FB; Thu, 13 Feb 2020 14:46:59 -0800 (PST) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::341; helo=mail-ot1-x341.google.com; envelope-from=dan.j.williams@intel.com; receiver= Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0A80310FC33F9 for ; Thu, 13 Feb 2020 14:46:57 -0800 (PST) Received: by mail-ot1-x341.google.com with SMTP id p8so7241531oth.10 for ; Thu, 13 Feb 2020 14:43:40 -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=hY6CV+ND7e1YGXWSjo+0nHc7akywE0TMpMRwKM18M98=; b=SmXDDB05FgkSDjl82jr0vRzKFNDC3TzgJv9zwXei/I8lhH2nzhediAtWrWFbK9wXps wqfiVO9vLKiQJNvx+mp9CQFnigfPh8wsRpGBXWaHzSNrFsKci0RSWKoq+fG8mOU1ja3K /NCtdPzVJL3iA8WlfgAGnEM6bun1wPKuHZEjQxtkZChKXjNflJXcfsnvL1rclMTMlK6x gJQBCVPju+i+TEYEemIW2T1wXWG0kEK3aCPIDm7r9cls3Ljs7SmIhsmz4tCY7Narvkw4 zbytoCGOxRXBfvQLCi0bOqRXCJxEiRUBxiMN+CtG/8LyrUCmJy9Hbtn4FVG7+NX2yDTj lGqA== 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=hY6CV+ND7e1YGXWSjo+0nHc7akywE0TMpMRwKM18M98=; b=bkc/PbQZsIVKytu2AZAmfnBjlL1UspWVwsHQI0HME+lXM47cL5HHdET5Bn5WitSXPP G7c3/iLydGz/pwRK6QVCbo5k+7EjvEmRZ2TlOTh4YmdHdZChNLn5rW7I55O+6wVReE9C vtkW3b/C+bmtsyV+XSIY6/3I1b56yeQ+AIfLz1ZVP1A7+A7nLyL+9eLOrebS4lPbntOq N01B1O1gfACI+HLzJ/75BER1DCuB88iU75UjOtTVnS7y9zruJ1Ci7dhzaHw7NzndIlm9 SLHTgx6Z6HKK4k/COkZ4NB7mAutzPRcLLI0xAqzsWyRA2xug1ZevMudZN+0CLNXwGefN 5b9Q== X-Gm-Message-State: APjAAAUVFYqAABHNrSV4f6y/nK+19Cu0mLDCm73RF+Mxd0BhJrPTHgCS FxZyeoeaCM4Q6i5Slkzn5XfVZGU7DWGYHiWioTfb+B+0ilo= X-Google-Smtp-Source: APXvYqwh0QpibBwkg8wqD1qCgWrU0VARu4V8rflQRY8+mOYx9YxokcdwDNt0F3KAuE2fZ50H4DcCVvTlaEy10NTp/PU= X-Received: by 2002:a9d:4e99:: with SMTP id v25mr15692065otk.363.1581633819941; Thu, 13 Feb 2020 14:43:39 -0800 (PST) MIME-Version: 1.0 References: <158155489850.3343782.2687127373754434980.stgit@dwillia2-desk3.amr.corp.intel.com> <158155490897.3343782.14216276134794923581.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: From: Dan Williams Date: Thu, 13 Feb 2020 14:43:28 -0800 Message-ID: Subject: Re: [PATCH v2 2/4] libnvdimm/namespace: Enforce memremap_compat_align() To: Jeff Moyer Message-ID-Hash: VDOVGL2S4JYILMAIEIDGPLDAGLXDHAHO X-Message-ID-Hash: VDOVGL2S4JYILMAIEIDGPLDAGLXDHAHO X-MailFrom: dan.j.williams@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: linux-nvdimm , "Aneesh Kumar K.V" , Linux Kernel Mailing List , linuxppc-dev X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Feb 13, 2020 at 1:55 PM Jeff Moyer wrote: > > Dan Williams writes: > > > The pmem driver on PowerPC crashes with the following signature when > > instantiating misaligned namespaces that map their capacity via > > memremap_pages(). > > > > BUG: Unable to handle kernel data access at 0xc001000406000000 > > Faulting instruction address: 0xc000000000090790 > > NIP [c000000000090790] arch_add_memory+0xc0/0x130 > > LR [c000000000090744] arch_add_memory+0x74/0x130 > > Call Trace: > > arch_add_memory+0x74/0x130 (unreliable) > > memremap_pages+0x74c/0xa30 > > devm_memremap_pages+0x3c/0xa0 > > pmem_attach_disk+0x188/0x770 > > nvdimm_bus_probe+0xd8/0x470 > > > > With the assumption that only memremap_pages() has alignment > > constraints, enforce memremap_compat_align() for > > pmem_should_map_pages(), nd_pfn, or nd_dax cases. > > > > Reported-by: Aneesh Kumar K.V > > Cc: Jeff Moyer > > Reviewed-by: Aneesh Kumar K.V > > Link: https://lore.kernel.org/r/158041477336.3889308.4581652885008605170.stgit@dwillia2-desk3.amr.corp.intel.com > > Signed-off-by: Dan Williams > > --- > > drivers/nvdimm/namespace_devs.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c > > index 032dc61725ff..aff1f32fdb4f 100644 > > --- a/drivers/nvdimm/namespace_devs.c > > +++ b/drivers/nvdimm/namespace_devs.c > > @@ -1739,6 +1739,16 @@ struct nd_namespace_common *nvdimm_namespace_common_probe(struct device *dev) > > return ERR_PTR(-ENODEV); > > } > > > > + if (pmem_should_map_pages(dev) || nd_pfn || nd_dax) { > > + struct nd_namespace_io *nsio = to_nd_namespace_io(&ndns->dev); > > + resource_size_t start = nsio->res.start; > > + > > + if (!IS_ALIGNED(start | size, memremap_compat_align())) { > > + dev_dbg(&ndns->dev, "misaligned, unable to map\n"); > > + return ERR_PTR(-EOPNOTSUPP); > > + } > > + } > > + > > if (is_namespace_pmem(&ndns->dev)) { > > struct nd_namespace_pmem *nspm; > > > > Actually, I take back my ack. :) This prevents a previously working > namespace from being successfully probed/setup. Do you have a test case handy? I can see a potential gap with a namespace that used internal padding to fix up the alignment. The goal of this check is to catch cases that are just going to fail devm_memremap_pages(), and the expectation is that it could not have worked before unless it was ported from another platform, or someone flipped the page-size switch on PowerPC. > I thought we were only > going to enforce the alignment for a newly created namespace? This should > only check whether the alignment works for the current platform. The model is a new default 16MB alignment is enforced at creation time, but if you need to support previously created namespaces then you can manually trim that alignment requirement to no less than memremap_compat_align() because that's the point at which devm_memremap_pages() will start failing or crashing. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15F4BC352A3 for ; Thu, 13 Feb 2020 22:43:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D56A420873 for ; Thu, 13 Feb 2020 22:43:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="SmXDDB05" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727931AbgBMWnl (ORCPT ); Thu, 13 Feb 2020 17:43:41 -0500 Received: from mail-ot1-f67.google.com ([209.85.210.67]:35736 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727347AbgBMWnk (ORCPT ); Thu, 13 Feb 2020 17:43:40 -0500 Received: by mail-ot1-f67.google.com with SMTP id r16so7305661otd.2 for ; Thu, 13 Feb 2020 14:43:40 -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=hY6CV+ND7e1YGXWSjo+0nHc7akywE0TMpMRwKM18M98=; b=SmXDDB05FgkSDjl82jr0vRzKFNDC3TzgJv9zwXei/I8lhH2nzhediAtWrWFbK9wXps wqfiVO9vLKiQJNvx+mp9CQFnigfPh8wsRpGBXWaHzSNrFsKci0RSWKoq+fG8mOU1ja3K /NCtdPzVJL3iA8WlfgAGnEM6bun1wPKuHZEjQxtkZChKXjNflJXcfsnvL1rclMTMlK6x gJQBCVPju+i+TEYEemIW2T1wXWG0kEK3aCPIDm7r9cls3Ljs7SmIhsmz4tCY7Narvkw4 zbytoCGOxRXBfvQLCi0bOqRXCJxEiRUBxiMN+CtG/8LyrUCmJy9Hbtn4FVG7+NX2yDTj lGqA== 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=hY6CV+ND7e1YGXWSjo+0nHc7akywE0TMpMRwKM18M98=; b=uhHChxGQtgi+deBFcUfy2zg/7Ufy5dnude3dWtwj/pSoxFMq1mNebLE1oVEYcvnDo1 6RnYHyz952k87JE1slxpQl+sxt6Kin/X+kkxVthT7ezGZ+tI5cajxh7N2FaKb6xLD6F5 Jo59j/adir1+H6ZzgIK25m3j504Y8UiedyxCIHOwRD3zciPb52vZr1ZWSjMrltZ6Z1SL 1QXs7qYWX7ZO70c0Fp/q2ngjRO/DRUsiLXbyuJuM6woAJ54MFTu96t4m0rUFyuH08cU2 oSH9bZeDJ77dKFNeKBIhXtHUEHDFqFcKI0Tq8ONSEiGf3f5PI37t0OqOjvoXRrhH+0Bz nw9Q== X-Gm-Message-State: APjAAAXeSlCEg9Lde854etLLuFhtgMlgDtP9rCQLrE8Hc80TfsJml1HW o5EnuOGmSKQ+lHODPDb4v/BQ+Iqo72TRcCkEMCSu+Q== X-Google-Smtp-Source: APXvYqwh0QpibBwkg8wqD1qCgWrU0VARu4V8rflQRY8+mOYx9YxokcdwDNt0F3KAuE2fZ50H4DcCVvTlaEy10NTp/PU= X-Received: by 2002:a9d:4e99:: with SMTP id v25mr15692065otk.363.1581633819941; Thu, 13 Feb 2020 14:43:39 -0800 (PST) MIME-Version: 1.0 References: <158155489850.3343782.2687127373754434980.stgit@dwillia2-desk3.amr.corp.intel.com> <158155490897.3343782.14216276134794923581.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: From: Dan Williams Date: Thu, 13 Feb 2020 14:43:28 -0800 Message-ID: Subject: Re: [PATCH v2 2/4] libnvdimm/namespace: Enforce memremap_compat_align() To: Jeff Moyer Cc: linux-nvdimm , "Aneesh Kumar K.V" , Vishal L Verma , Linux Kernel Mailing List , linuxppc-dev 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, Feb 13, 2020 at 1:55 PM Jeff Moyer wrote: > > Dan Williams writes: > > > The pmem driver on PowerPC crashes with the following signature when > > instantiating misaligned namespaces that map their capacity via > > memremap_pages(). > > > > BUG: Unable to handle kernel data access at 0xc001000406000000 > > Faulting instruction address: 0xc000000000090790 > > NIP [c000000000090790] arch_add_memory+0xc0/0x130 > > LR [c000000000090744] arch_add_memory+0x74/0x130 > > Call Trace: > > arch_add_memory+0x74/0x130 (unreliable) > > memremap_pages+0x74c/0xa30 > > devm_memremap_pages+0x3c/0xa0 > > pmem_attach_disk+0x188/0x770 > > nvdimm_bus_probe+0xd8/0x470 > > > > With the assumption that only memremap_pages() has alignment > > constraints, enforce memremap_compat_align() for > > pmem_should_map_pages(), nd_pfn, or nd_dax cases. > > > > Reported-by: Aneesh Kumar K.V > > Cc: Jeff Moyer > > Reviewed-by: Aneesh Kumar K.V > > Link: https://lore.kernel.org/r/158041477336.3889308.4581652885008605170.stgit@dwillia2-desk3.amr.corp.intel.com > > Signed-off-by: Dan Williams > > --- > > drivers/nvdimm/namespace_devs.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c > > index 032dc61725ff..aff1f32fdb4f 100644 > > --- a/drivers/nvdimm/namespace_devs.c > > +++ b/drivers/nvdimm/namespace_devs.c > > @@ -1739,6 +1739,16 @@ struct nd_namespace_common *nvdimm_namespace_common_probe(struct device *dev) > > return ERR_PTR(-ENODEV); > > } > > > > + if (pmem_should_map_pages(dev) || nd_pfn || nd_dax) { > > + struct nd_namespace_io *nsio = to_nd_namespace_io(&ndns->dev); > > + resource_size_t start = nsio->res.start; > > + > > + if (!IS_ALIGNED(start | size, memremap_compat_align())) { > > + dev_dbg(&ndns->dev, "misaligned, unable to map\n"); > > + return ERR_PTR(-EOPNOTSUPP); > > + } > > + } > > + > > if (is_namespace_pmem(&ndns->dev)) { > > struct nd_namespace_pmem *nspm; > > > > Actually, I take back my ack. :) This prevents a previously working > namespace from being successfully probed/setup. Do you have a test case handy? I can see a potential gap with a namespace that used internal padding to fix up the alignment. The goal of this check is to catch cases that are just going to fail devm_memremap_pages(), and the expectation is that it could not have worked before unless it was ported from another platform, or someone flipped the page-size switch on PowerPC. > I thought we were only > going to enforce the alignment for a newly created namespace? This should > only check whether the alignment works for the current platform. The model is a new default 16MB alignment is enforced at creation time, but if you need to support previously created namespaces then you can manually trim that alignment requirement to no less than memremap_compat_align() because that's the point at which devm_memremap_pages() will start failing or crashing. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9AF41C352A3 for ; Thu, 13 Feb 2020 22:45:46 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0C0CA2082F for ; Thu, 13 Feb 2020 22:45:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="SmXDDB05" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0C0CA2082F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 48JWnM5T5yzDqXX for ; Fri, 14 Feb 2020 09:45:43 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=intel.com (client-ip=2607:f8b0:4864:20::343; helo=mail-ot1-x343.google.com; envelope-from=dan.j.williams@intel.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.a=rsa-sha256 header.s=20150623 header.b=SmXDDB05; dkim-atps=neutral Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 48JWlC6MszzDqVP for ; Fri, 14 Feb 2020 09:43:44 +1100 (AEDT) Received: by mail-ot1-x343.google.com with SMTP id g64so7245118otb.13 for ; Thu, 13 Feb 2020 14:43:44 -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=hY6CV+ND7e1YGXWSjo+0nHc7akywE0TMpMRwKM18M98=; b=SmXDDB05FgkSDjl82jr0vRzKFNDC3TzgJv9zwXei/I8lhH2nzhediAtWrWFbK9wXps wqfiVO9vLKiQJNvx+mp9CQFnigfPh8wsRpGBXWaHzSNrFsKci0RSWKoq+fG8mOU1ja3K /NCtdPzVJL3iA8WlfgAGnEM6bun1wPKuHZEjQxtkZChKXjNflJXcfsnvL1rclMTMlK6x gJQBCVPju+i+TEYEemIW2T1wXWG0kEK3aCPIDm7r9cls3Ljs7SmIhsmz4tCY7Narvkw4 zbytoCGOxRXBfvQLCi0bOqRXCJxEiRUBxiMN+CtG/8LyrUCmJy9Hbtn4FVG7+NX2yDTj lGqA== 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=hY6CV+ND7e1YGXWSjo+0nHc7akywE0TMpMRwKM18M98=; b=Ph+6uGG+T9+oV8OTQD9jc4G+6D1gVi80qZbX8A3VUASDFWnUwZ6R3LafUlm27jfz/W MD0nET8MvxjULzOtgUHC6Eykt3kbQhu0XW6kTBmA9SDnQOdKIcNly/qz3Mi52n9UIxZ1 E/UsvjMmxN0LChNMbSe29m0AMuB+9iGUbjfKRB3L3ts9w6B3tKWHRPwMKgnqKO1HQZgn DrT8XHTOzVn8kHQL8ZFLWf+3iUTC/G5lNl2wzP2PrvwJLc5bYELFuf0Gw2izZmVAj3WZ I25aBvRxpz+Zzv0qkkYGqBhrtDMGRIR3veutMTTzOdnduJzrxaWSYsYKkWk10GyPU0SI +XGg== X-Gm-Message-State: APjAAAULDUO76BzqPHo9HGmGcb5NV8LCVcaU961ammJXoYVNWPLCjpSo fBU/Vvw2ll+s7IaVpFZdoMpXhiZ2ZS47t3zqHmtyjw== X-Google-Smtp-Source: APXvYqwh0QpibBwkg8wqD1qCgWrU0VARu4V8rflQRY8+mOYx9YxokcdwDNt0F3KAuE2fZ50H4DcCVvTlaEy10NTp/PU= X-Received: by 2002:a9d:4e99:: with SMTP id v25mr15692065otk.363.1581633819941; Thu, 13 Feb 2020 14:43:39 -0800 (PST) MIME-Version: 1.0 References: <158155489850.3343782.2687127373754434980.stgit@dwillia2-desk3.amr.corp.intel.com> <158155490897.3343782.14216276134794923581.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: From: Dan Williams Date: Thu, 13 Feb 2020 14:43:28 -0800 Message-ID: Subject: Re: [PATCH v2 2/4] libnvdimm/namespace: Enforce memremap_compat_align() To: Jeff Moyer Content-Type: text/plain; charset="UTF-8" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Aneesh Kumar K.V" , Vishal L Verma , linuxppc-dev , Linux Kernel Mailing List , linux-nvdimm Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, Feb 13, 2020 at 1:55 PM Jeff Moyer wrote: > > Dan Williams writes: > > > The pmem driver on PowerPC crashes with the following signature when > > instantiating misaligned namespaces that map their capacity via > > memremap_pages(). > > > > BUG: Unable to handle kernel data access at 0xc001000406000000 > > Faulting instruction address: 0xc000000000090790 > > NIP [c000000000090790] arch_add_memory+0xc0/0x130 > > LR [c000000000090744] arch_add_memory+0x74/0x130 > > Call Trace: > > arch_add_memory+0x74/0x130 (unreliable) > > memremap_pages+0x74c/0xa30 > > devm_memremap_pages+0x3c/0xa0 > > pmem_attach_disk+0x188/0x770 > > nvdimm_bus_probe+0xd8/0x470 > > > > With the assumption that only memremap_pages() has alignment > > constraints, enforce memremap_compat_align() for > > pmem_should_map_pages(), nd_pfn, or nd_dax cases. > > > > Reported-by: Aneesh Kumar K.V > > Cc: Jeff Moyer > > Reviewed-by: Aneesh Kumar K.V > > Link: https://lore.kernel.org/r/158041477336.3889308.4581652885008605170.stgit@dwillia2-desk3.amr.corp.intel.com > > Signed-off-by: Dan Williams > > --- > > drivers/nvdimm/namespace_devs.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c > > index 032dc61725ff..aff1f32fdb4f 100644 > > --- a/drivers/nvdimm/namespace_devs.c > > +++ b/drivers/nvdimm/namespace_devs.c > > @@ -1739,6 +1739,16 @@ struct nd_namespace_common *nvdimm_namespace_common_probe(struct device *dev) > > return ERR_PTR(-ENODEV); > > } > > > > + if (pmem_should_map_pages(dev) || nd_pfn || nd_dax) { > > + struct nd_namespace_io *nsio = to_nd_namespace_io(&ndns->dev); > > + resource_size_t start = nsio->res.start; > > + > > + if (!IS_ALIGNED(start | size, memremap_compat_align())) { > > + dev_dbg(&ndns->dev, "misaligned, unable to map\n"); > > + return ERR_PTR(-EOPNOTSUPP); > > + } > > + } > > + > > if (is_namespace_pmem(&ndns->dev)) { > > struct nd_namespace_pmem *nspm; > > > > Actually, I take back my ack. :) This prevents a previously working > namespace from being successfully probed/setup. Do you have a test case handy? I can see a potential gap with a namespace that used internal padding to fix up the alignment. The goal of this check is to catch cases that are just going to fail devm_memremap_pages(), and the expectation is that it could not have worked before unless it was ported from another platform, or someone flipped the page-size switch on PowerPC. > I thought we were only > going to enforce the alignment for a newly created namespace? This should > only check whether the alignment works for the current platform. The model is a new default 16MB alignment is enforced at creation time, but if you need to support previously created namespaces then you can manually trim that alignment requirement to no less than memremap_compat_align() because that's the point at which devm_memremap_pages() will start failing or crashing.