Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752118AbcDOTNc (ORCPT ); Fri, 15 Apr 2016 15:13:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44212 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751402AbcDOTNa (ORCPT ); Fri, 15 Apr 2016 15:13:30 -0400 From: Jeff Moyer To: Dan Williams Cc: "Verma\, Vishal L" , "hch\@infradead.org" , "jack\@suse.cz" , "axboe\@fb.com" , "linux-nvdimm\@ml01.01.org" , "david\@fromorbit.com" , "linux-kernel\@vger.kernel.org" , "xfs\@oss.sgi.com" , "linux-block\@vger.kernel.org" , "linux-mm\@kvack.org" , "viro\@zeniv.linux.org.uk" , "linux-fsdevel\@vger.kernel.org" , "akpm\@linux-foundation.org" , "linux-ext4\@vger.kernel.org" , "Wilcox\, Matthew R" Subject: Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io References: <1459303190-20072-1-git-send-email-vishal.l.verma@intel.com> <1459303190-20072-6-git-send-email-vishal.l.verma@intel.com> <1460739288.3012.3.camel@intel.com> <1460741821.3012.11.camel@intel.com> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Fri, 15 Apr 2016 15:13:26 -0400 In-Reply-To: (Dan Williams's message of "Fri, 15 Apr 2016 11:56:20 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 15 Apr 2016 19:13:29 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 816 Lines: 21 Dan Williams writes: > On Fri, Apr 15, 2016 at 11:24 AM, Jeff Moyer wrote: >>> Moreover, we're going to do the full badblocks lookup anyway when we >>> call ->direct_access(). If we had that information earlier we can >>> avoid this fallback dance. >> >> None of the proposed approaches looks clean to me. I'll go along with >> whatever you guys think is best. I am in favor of wrapping up all that >> duplicated code, though. > > Christoph originally pushed for open coding this fallback decision > per-filesystem. I agree with you on the "none the above" options are > clean. I don't recall him saying "open code". Rather, the sentiment was to leave the fallback to the callers. That doesn't mean you can't wrap it up in a convenience function. Cheers, Jeff