Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1458047pxb; Tue, 8 Feb 2022 18:45:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJz4I/RJFOig0MJFysOqn7SmvyufFhsQsY26finqCStp1R02ZqsLBV1xweDSV4a1BzLLWsCw X-Received: by 2002:a17:90a:58:: with SMTP id 24mr1087523pjb.118.1644374719636; Tue, 08 Feb 2022 18:45:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644374719; cv=none; d=google.com; s=arc-20160816; b=aVMSU7CXltQ69xzcFwPCtFr9j+cCQVGMSEPpbdhp95Tt37FG5zAlog4A7ctqJiMdXD Mc11IYIjDv+ZpSLrEqM1bTMeqpWJOvjB3oGs7RAHrrHVFoQjecDhdAdaRl6OfWhXaoNQ 15hLaOQApD0L8Bad9b4/x+Ts3MjI/TwrHc1riZYVXKOpw5eA1Mh38cJ+257BqiiTtwAW ZbrZMynVqllosLO98DvC9ChVaOmm2Aq73D5KyNOlErv7I2YLO9A0keUQAiZObe/IOp+d qx3ZdvI2PPpER2HxnrXPSKXAmHyg6tlQIOvMP1YCbmshzKUBLCShB0gP3a+YC4cv2Tmg LD9Q== 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=ADbV2ue0euhPpU9doft99rslDDTP7SctadFXHagiPcw=; b=tZq9+K+0qn9S6pXEIqGe+a8mNAFZTwKch6JpZbaU/mUnG4ASuTSznegupR5EIUVaAk Cor8JuqUiAxBiYuZy/GWeu5SOthhETvoccfuJpbrFOp7gGEZ5Q7dlseCJAw11NJWO+5h oua1fS19CQ0mcw0D1Yq8QCNghhH9ln82/0dwfKBvPS8T/x5JQAGSyoqZl2bGSGQ5+e71 9l0kWExCMi0YLEmcTc98acwobfbmXqbxG6nYsSDJNxEqpZTpbMg9fBxUQUPz8DaCzUVI BNo84KAAsnZwcgkYoFEFbbjpkQgWIzpwodgS7SW7KwQhjo9dea23crrBh7ULtmMsibXg zz3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20210112.gappssmtp.com header.s=20210112 header.b=iXDtyFJP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y22si13338151plp.25.2022.02.08.18.45.05; Tue, 08 Feb 2022 18:45:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20210112.gappssmtp.com header.s=20210112 header.b=iXDtyFJP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S232882AbiBDFRX (ORCPT + 99 others); Fri, 4 Feb 2022 00:17:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231770AbiBDFRV (ORCPT ); Fri, 4 Feb 2022 00:17:21 -0500 Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 16FA9C061714 for ; Thu, 3 Feb 2022 21:17:21 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id x3so4212500pll.3 for ; Thu, 03 Feb 2022 21:17:21 -0800 (PST) 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=ADbV2ue0euhPpU9doft99rslDDTP7SctadFXHagiPcw=; b=iXDtyFJP5WtiAy0xBjR8o34yPHnEQRbyQYdWa57M1Yeo0LLgXvIX15A5LJEQ6AAc0C M+oj+BBkthciCSEr5D9A/ZPzjoo9IIfQFDH0g6ZSAjDLbvXegqkjTKRVnHrXRbGMQEEN +uq4Go8PgIlUO6ptZ8qiEyy7lRQ63LkMf5Hbti84XU/dyIXgmK77j3fQBCKKVDrAh+xO mE1q/7xS6/eVN8s0FriHvE3+QFjHjDzE7jCGDL6JqpiP8nZ27q+Tlb9grC04zikPvOBu wpSKHQDMCq5J5McJk+EXZJKVWLLnSE8X19QK2JBXj1syqjawR+/fY5z7lPlbuRCKdASu /pBg== 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=ADbV2ue0euhPpU9doft99rslDDTP7SctadFXHagiPcw=; b=JbY/L+O2TKfn6zt/9H5x4SpHXiLFK7vMiJhndVXQT7m1b7m9E1jRAzxkw5EQQQjMto ePfiSuVVCiHYH41zRdSDkjJVzmZKjsuwTYFP+ag85vpvHl06Mov6CnUMTMWJ+cMdBAVv Mp4nA+M2WatLqER2ftAEaHs+x2jUbE8y4N7kwgNoaimzjQx+XEc8ccp1GyI46ZWcWRjD hKIARvbacku73bg/W/ceR0g+MRoxGid8c4zj2pJpm/njBrXL7TvvZyeCidgkZwyFXTWc l9f/5inh7HzoeYAZjo9fqvX7SIY/t9bCQmcAzU+UTs4wSC3+iXR39hI6TpNWg854Wy/q TlaA== X-Gm-Message-State: AOAM533dUhDFRE/t/23tgr0mtkrGtteWYyCe6wVDHbeAVtXB8gMSDT3C Dc006yXlEy6Vfr3+56PpF14BlsTSREGfnx4EJqnbRQ== X-Received: by 2002:a17:902:b20a:: with SMTP id t10mr1357273plr.132.1643951840594; Thu, 03 Feb 2022 21:17:20 -0800 (PST) MIME-Version: 1.0 References: <20220128213150.1333552-1-jane.chu@oracle.com> <20220128213150.1333552-3-jane.chu@oracle.com> <45b4a944-1fb1-73e2-b1f8-213e60e27a72@oracle.com> In-Reply-To: From: Dan Williams Date: Thu, 3 Feb 2022 21:17:08 -0800 Message-ID: Subject: Re: [PATCH v5 2/7] dax: introduce dax device flag DAXDEV_RECOVERY To: Christoph Hellwig Cc: Jane Chu , "david@fromorbit.com" , "djwong@kernel.org" , "vishal.l.verma@intel.com" , "dave.jiang@intel.com" , "agk@redhat.com" , "snitzer@redhat.com" , "dm-devel@redhat.com" , "ira.weiny@intel.com" , "willy@infradead.org" , "vgoyal@redhat.com" , "linux-fsdevel@vger.kernel.org" , "nvdimm@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "linux-xfs@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 3, 2022 at 5:43 AM Christoph Hellwig wrote: > > On Wed, Feb 02, 2022 at 09:27:42PM +0000, Jane Chu wrote: > > Yeah, I see. Would you suggest a way to pass the indication from > > dax_iomap_iter to dax_direct_access that the caller intends the > > callee to ignore poison in the range because the caller intends > > to do recovery_write? We tried adding a flag to dax_direct_access, and > > that wasn't liked if I recall. > > To me a flag seems cleaner than this magic, but let's wait for Dan to > chime in. So back in November I suggested modifying the kaddr, mainly to avoid touching all the dax_direct_access() call sites [1]. However, now seeing the code and Chrisoph's comment I think this either wants type safety (e.g. 'dax_addr_t *'), or just add a new flag. Given both of those options involve touching all dax_direct_access() call sites and a @flags operation is more extensible if any other scenarios arrive lets go ahead and plumb a flag and skip the magic.