Received: by 2002:a05:6512:3d0e:0:0:0:0 with SMTP id d14csp42041lfv; Tue, 12 Apr 2022 16:29:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyrGfIJ7p9j3VRMGEHjxuv7ANhpnJNq0Pc0jGiXQwWe63Q/ICjk+T2tev7VTeoIl473VyYW X-Received: by 2002:a17:902:b495:b0:158:8318:4cf9 with SMTP id y21-20020a170902b49500b0015883184cf9mr7023940plr.33.1649806149019; Tue, 12 Apr 2022 16:29:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649806149; cv=none; d=google.com; s=arc-20160816; b=HdN33hIWvE1II4iBVFOCvbx2LMt0quQSZqDVzZ0tiZU1tRKhyTBlPyiskISMRMbTHS Icg9lx6BgUVPK0ORafUllOKfXgI7MQUXSjs/v3U1UkH8Nis+ijb7sfRnZuLhf5S3tUJ7 2TtEd7F1IypTRC/fawvIVSwRqU3isdH3TNdHevlivByhs2fGMaQ1V2VV/ijRRqB5sS7y kqDW1jl/1iXs1cMnX0b8Su9YGEXgZHWvkrSofc2OWi8Df4h2cDRu5ooecWTnlzfp0zYd lp21gbcywEvYk2eioNPShz0/iqN6ZogzajdLM5brW/XjNknGD9yWJZDPEubrd3aMGkwf 8UbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=UCrOTwn1Apaa4uQLVmk5UD3cOc527xiwJT4PNuBWV0U=; b=MBbJygkWNyCferTGHAznqtIigde13XTMzZACqfepW/mpKVL3hbwte8Nvr4LaLVPAWP EjaYzry/TfKneIoudJBfhXkY8B6ntdlQitgP4IM4noco6CI+NV6R5H1zIN9DK7rUsO66 csTTx9eBEY9N1OUhuD027tcMI18dudk+tP/BR1iz/svpvrcsgUpbqOZ63HswKXUaNtln 0GOKpZR6BgfoZENR5PtvtspMpklPEsar3/0YWG9NfKfdUoOODWYZ2BAmanX4zT/T/b4A 8BmQDfstuCekDwM9HV11ZAXy8nTOeLsDUb/lT2+PCNJBlXE305LyriiMqLgi4AfecOfB nbWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20210112.gappssmtp.com header.s=20210112 header.b=qj1azZVR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1: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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id f2-20020a63de02000000b0039d13e0dc4asi3729936pgg.202.2022.04.12.16.29.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 16:29:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20210112.gappssmtp.com header.s=20210112 header.b=qj1azZVR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1: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: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 405611820F6; Tue, 12 Apr 2022 14:21:33 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345786AbiDLE3H (ORCPT + 99 others); Tue, 12 Apr 2022 00:29:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51894 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345813AbiDLE3D (ORCPT ); Tue, 12 Apr 2022 00:29:03 -0400 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E94F32997 for ; Mon, 11 Apr 2022 21:26:47 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id y6so15706629plg.2 for ; Mon, 11 Apr 2022 21:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UCrOTwn1Apaa4uQLVmk5UD3cOc527xiwJT4PNuBWV0U=; b=qj1azZVRiLRWoOmK62O5jlUS3eBsOBIqGZrTPkVTrhXug25XR9RPlwdGNSyUk6Cn4Q O2h7oNKaIwwR0F/KAXVsmKOmZQHsE4nq+VcPu6FVr2QkdlsNenKN4YVbKRVtAVD7u7b4 I3TXIiz7RmEJHBwtR9BUhZjSikRfkKsP2qKeq9uIwnIe5tR2LVuM+/vMUI/GaRim758K qpLoQglwz9v9mBUy4ZF8OIj7vFFvKFSsACWjKZnX/zRinYHwXhHZ8rpo2gkwmxTBjBjs SyNSru4EiN82wpRW3gwhJCjwubkugBNJd5Ve8Thx53DS0elOAsHJVybqbBJhleyoy6f0 XOqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UCrOTwn1Apaa4uQLVmk5UD3cOc527xiwJT4PNuBWV0U=; b=1WNn7jSS3kwzHF9c6rnqbVwB1CWCqUcVphfdR2h4cc353n1Hn9hu5RwDSUjbPtMTwj G574Mko+vM9gXJryzxCFI6SXnTcWvlK2I/N03E/XicEsHL8R6vBuGcUtz1EbENFm4zyU sNoubZmZAdvzwKp0E3Wer6Kc9ZhSG09LwBkzqfLRXVqnHharoLbT/qST4iUhWs6ZNYOR jJVQ/t4ywAnpm5muHPofe836cTozLk//v7t8rlIPzd2x7RRMo2XudgiB+2IbCJz9dEro UnSTGFV2TSKUHktdugxHY2oLAfGXRUzhVnj9O4x0mzTbHXCwle0sGYI6rlK0vdzmNUzH HlAw== X-Gm-Message-State: AOAM532H896gBWXcbwWIuww8ZX4CX+40e+AKnhuvg6QxY+4eaeB7PvxC +lUV8BbulbjhHtV4xTgpBcdLy3DH7RnyT4QvSvVfPQ== X-Received: by 2002:a17:90b:1804:b0:1cb:82e3:5cd0 with SMTP id lw4-20020a17090b180400b001cb82e35cd0mr2859224pjb.8.1649737606512; Mon, 11 Apr 2022 21:26:46 -0700 (PDT) MIME-Version: 1.0 References: <20220405194747.2386619-1-jane.chu@oracle.com> <20220405194747.2386619-6-jane.chu@oracle.com> In-Reply-To: <20220405194747.2386619-6-jane.chu@oracle.com> From: Dan Williams Date: Mon, 11 Apr 2022 21:26:35 -0700 Message-ID: Subject: Re: [PATCH v7 5/6] pmem: refactor pmem_clear_poison() To: Jane Chu Cc: david , "Darrick J. Wong" , Christoph Hellwig , Vishal L Verma , Dave Jiang , Alasdair Kergon , Mike Snitzer , device-mapper development , "Weiny, Ira" , Matthew Wilcox , Vivek Goyal , linux-fsdevel , Linux NVDIMM , Linux Kernel Mailing List , linux-xfs , X86 ML Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 5, 2022 at 12:48 PM Jane Chu wrote: > > Refactor the pmem_clear_poison() in order to share common code > later. > I would just add a note here about why, i.e. to factor out the common shared code between the typical write path and the recovery write path. > Signed-off-by: Jane Chu > --- > drivers/nvdimm/pmem.c | 78 ++++++++++++++++++++++++++++--------------- > 1 file changed, 52 insertions(+), 26 deletions(-) > > diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c > index 0400c5a7ba39..56596be70400 100644 > --- a/drivers/nvdimm/pmem.c > +++ b/drivers/nvdimm/pmem.c > @@ -45,10 +45,27 @@ static struct nd_region *to_region(struct pmem_device *pmem) > return to_nd_region(to_dev(pmem)->parent); > } > > -static void hwpoison_clear(struct pmem_device *pmem, > - phys_addr_t phys, unsigned int len) > +static phys_addr_t to_phys(struct pmem_device *pmem, phys_addr_t offset) > { > + return (pmem->phys_addr + offset); Christoph already mentioned dropping the unnecessary parenthesis. > +} > + > +static sector_t to_sect(struct pmem_device *pmem, phys_addr_t offset) > +{ > + return (offset - pmem->data_offset) >> SECTOR_SHIFT; > +} > + > +static phys_addr_t to_offset(struct pmem_device *pmem, sector_t sector) > +{ > + return ((sector << SECTOR_SHIFT) + pmem->data_offset); > +} > + > +static void pmem_clear_hwpoison(struct pmem_device *pmem, phys_addr_t offset, > + unsigned int len) Perhaps now is a good time to rename this to something else like pmem_clear_mce_nospec()? Just to make it more distinct from pmem_clear_poison(). While "hwpoison" is the page flag name pmem_clear_poison() is the function that's actually clearing the poison in hardware ("hw") and the new pmem_clear_mce_nospec() is toggling the page back into service. > +{ > + phys_addr_t phys = to_phys(pmem, offset); > unsigned long pfn_start, pfn_end, pfn; > + unsigned int blks = len >> SECTOR_SHIFT; > > /* only pmem in the linear map supports HWPoison */ > if (is_vmalloc_addr(pmem->virt_addr)) > @@ -67,35 +84,44 @@ static void hwpoison_clear(struct pmem_device *pmem, > if (test_and_clear_pmem_poison(page)) > clear_mce_nospec(pfn); > } > + > + dev_dbg(to_dev(pmem), "%#llx clear %u sector%s\n", > + (unsigned long long) to_sect(pmem, offset), blks, > + blks > 1 ? "s" : ""); In anticipation of better tracing support and the fact that this is no longer called from pmem_clear_poison() let's drop it for now. > } > > -static blk_status_t pmem_clear_poison(struct pmem_device *pmem, > +static void pmem_clear_bb(struct pmem_device *pmem, sector_t sector, long blks) > +{ > + if (blks == 0) > + return; > + badblocks_clear(&pmem->bb, sector, blks); > + if (pmem->bb_state) > + sysfs_notify_dirent(pmem->bb_state); > +} > + > +static long __pmem_clear_poison(struct pmem_device *pmem, > phys_addr_t offset, unsigned int len) > { > - struct device *dev = to_dev(pmem); > - sector_t sector; > - long cleared; > - blk_status_t rc = BLK_STS_OK; > - > - sector = (offset - pmem->data_offset) / 512; > - > - cleared = nvdimm_clear_poison(dev, pmem->phys_addr + offset, len); > - if (cleared < len) > - rc = BLK_STS_IOERR; > - if (cleared > 0 && cleared / 512) { > - hwpoison_clear(pmem, pmem->phys_addr + offset, cleared); > - cleared /= 512; > - dev_dbg(dev, "%#llx clear %ld sector%s\n", > - (unsigned long long) sector, cleared, > - cleared > 1 ? "s" : ""); > - badblocks_clear(&pmem->bb, sector, cleared); > - if (pmem->bb_state) > - sysfs_notify_dirent(pmem->bb_state); > + phys_addr_t phys = to_phys(pmem, offset); > + long cleared = nvdimm_clear_poison(to_dev(pmem), phys, len); > + > + if (cleared > 0) { > + pmem_clear_hwpoison(pmem, offset, cleared); > + arch_invalidate_pmem(pmem->virt_addr + offset, len); > } > + return cleared; > +} > > - arch_invalidate_pmem(pmem->virt_addr + offset, len); > +static blk_status_t pmem_clear_poison(struct pmem_device *pmem, > + phys_addr_t offset, unsigned int len) > +{ > + long cleared = __pmem_clear_poison(pmem, offset, len); > > - return rc; > + if (cleared < 0) > + return BLK_STS_IOERR; > + > + pmem_clear_bb(pmem, to_sect(pmem, offset), cleared >> SECTOR_SHIFT); > + return (cleared < len) ? BLK_STS_IOERR : BLK_STS_OK; I prefer "if / else" syntax instead of a ternary conditional. > } > > static void write_pmem(void *pmem_addr, struct page *page, > @@ -143,7 +169,7 @@ static blk_status_t pmem_do_read(struct pmem_device *pmem, > sector_t sector, unsigned int len) > { > blk_status_t rc; > - phys_addr_t pmem_off = sector * 512 + pmem->data_offset; > + phys_addr_t pmem_off = to_offset(pmem, sector); > void *pmem_addr = pmem->virt_addr + pmem_off; > > if (unlikely(is_bad_pmem(&pmem->bb, sector, len))) > @@ -158,7 +184,7 @@ static blk_status_t pmem_do_write(struct pmem_device *pmem, > struct page *page, unsigned int page_off, > sector_t sector, unsigned int len) > { > - phys_addr_t pmem_off = sector * 512 + pmem->data_offset; > + phys_addr_t pmem_off = to_offset(pmem, sector); > void *pmem_addr = pmem->virt_addr + pmem_off; > > if (unlikely(is_bad_pmem(&pmem->bb, sector, len))) { With those small fixups you can add: Reviewed-by: Dan Williams