From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754716AbdECSrF (ORCPT ); Wed, 3 May 2017 14:47:05 -0400 Received: from g4t3426.houston.hpe.com ([15.241.140.75]:45474 "EHLO g4t3426.houston.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751159AbdECSq5 (ORCPT ); Wed, 3 May 2017 14:46:57 -0400 From: "Kani, Toshimitsu" To: "dan.j.williams@intel.com" CC: "linux-kernel@vger.kernel.org" , "dave.jiang@intel.com" , "linux-nvdimm@lists.01.org" Subject: Re: [RFC PATCH] dax: add badblocks check to Device DAX Thread-Topic: [RFC PATCH] dax: add badblocks check to Device DAX Thread-Index: AQHSxCJYsIkXTJcozUeBmwgaJMx1HaHiwjaAgAAEtwCAAAXrgIAAJiGA Date: Wed, 3 May 2017 18:46:54 +0000 Message-ID: <1493837209.30303.47.camel@hpe.com> References: <20170503153103.30756-1-toshi.kani@hpe.com> <1493827750.30303.44.camel@hpe.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=hpe.com; x-originating-ip: [15.219.163.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;AT5PR84MB0258;7:c1soDcwCZs5zrAOzHHWPi5pXKCBBSpBAO8cbQ59UxktaQljxYtjhKGlMexp9fr20KCAJgzoWURK3BeOTDZFtnlfJ4f18KC+3/vBLyFtrkcoZlt137QAwgEOCscSvWmxDJYuiDPzKAGuahOXgIefWxGrf05Pa/f6B8BLaZsBdhfGpR+YAmO+ZBwahXQT/tD9CVWiw4JrC/tq++fCL6xEJqTjv5trxUBXFO90B3W7cWum9w6ZfH64fpeHQ6kwuLAURpSQ/GXKfHTDaqOlly262Xl8fQhtGyEhsO8NFqVhsD5/a/tNshWYvmKKAN/oQE4XsoQ6OQIx6Ql91oqrx9UT1Aw== x-ms-office365-filtering-correlation-id: b47c00ca-d134-40cb-3c9f-08d49254c4c1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075);SRVR:AT5PR84MB0258; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227479698468861); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148);SRVR:AT5PR84MB0258;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0258; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39840400002)(39860400002)(39400400002)(39410400002)(39850400002)(39450400003)(377454003)(24454002)(377424004)(3280700002)(53936002)(8676002)(2906002)(76176999)(81166006)(54906002)(50986999)(54356999)(3660700001)(6512007)(189998001)(2950100002)(6246003)(36756003)(229853002)(93886004)(110136004)(103116003)(38730400002)(6916009)(4326008)(6506006)(33646002)(6486002)(5660300001)(25786009)(7736002)(8936002)(6436002)(5640700003)(305945005)(478600001)(5250100002)(86362001)(2351001)(102836003)(2501003)(6116002)(2900100001)(3846002)(53546009);DIR:OUT;SFP:1102;SCL:1;SRVR:AT5PR84MB0258;H:AT5PR84MB0260.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1525569F81A4294E9F7B5AEADFF66DA0@NAMPRD84.PROD.OUTLOOK.COM> MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2017 18:46:54.0113 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0258 X-OriginatorOrg: hpe.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v43IlFP1015065 On Wed, 2017-05-03 at 09:30 -0700, Dan Williams wrote: > On Wed, May 3, 2017 at 9:09 AM, Kani, Toshimitsu > wrote: > > On Wed, 2017-05-03 at 08:52 -0700, Dan Williams wrote: > > > On Wed, May 3, 2017 at 8:31 AM, Toshi Kani > > > wrote: > > > > This is a RFC patch for seeking suggestions.  It adds support > > > > of badblocks check in Device DAX by using region-level > > > > badblocks list. This patch is only briefly tested. > > > > > > > > device_dax is a well-isolated self-contained module as it calls > > > > alloc_dax() with dev_dax, which is private to device_dax.  For > > > > checking badblocks, it needs to call dax_pmem to check with > > > > region-level badblocks. > > > > > > > > This patch attempts to keep device_dax self-contained.  It adds > > > > check_error() to dax_operations, and dax_check_error() as a > > > > stub with *dev_dax and *dev pointers to convey it to > > > > dax_pmem.  I am wondering if this is the right direction, or we > > > > should change the modularity to let dax_pmem call alloc_dax() > > > > with its dax_pmem (or I completely missed something). > > > > > > The problem is that device-dax guarantees a given fault > > > granularity. To make that guarantee we can't fallback from 1G or > > > 2M mappings due to an error. We also can't reasonably go the > > > other way and fail mappings that contain a badblock because that > > > would change the blast radius of a media error to the fault size. > > > > Does it mean we expect users to have CPUs with MCE recovery for > > Device DAX?  Can we add an attributes like allow error-check & > > fall-back? > > Yes, without MCE recovery device-dax mappings that consume errors > will reboot. If an application needs the kernel protection it should > be using filesystem-dax. Understood. Are we going to provide sysfs "badblocks" for Device DAX as it is also needed for ndctl clear-error? Thanks, -Toshi