From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752336AbcEJTtO (ORCPT ); Tue, 10 May 2016 15:49:14 -0400 Received: from mga09.intel.com ([134.134.136.24]:51955 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751063AbcEJTtM (ORCPT ); Tue, 10 May 2016 15:49:12 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,605,1455004800"; d="scan'208";a="100760124" From: "Verma, Vishal L" To: "hch@infradead.org" , "axboe@fb.com" CC: "linux-kernel@vger.kernel.org" , "linux-block@vger.kernel.org" , "xfs@oss.sgi.com" , "linux-nvdimm@ml01.01.org" , "jmoyer@redhat.com" , "linux-mm@kvack.org" , "Williams, Dan J" , "akpm@linux-foundation.org" , "linux-fsdevel@vger.kernel.org" , "ross.zwisler@linux.intel.com" , "linux-ext4@vger.kernel.org" , "boaz@plexistor.com" , "david@fromorbit.com" , "jack@suse.cz" Subject: Re: [PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible Thread-Topic: [PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible Thread-Index: AQHRquy+6jGeewZS+0Kt5vObFk9OpJ+zAtGAgAAGn4A= Date: Tue, 10 May 2016 19:49:01 +0000 Message-ID: <1462909729.29294.21.camel@intel.com> References: <1462906156-22303-1-git-send-email-vishal.l.verma@intel.com> <1462906156-22303-5-git-send-email-vishal.l.verma@intel.com> <20160510192507.GA29312@infradead.org> In-Reply-To: <20160510192507.GA29312@infradead.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.232.112.171] Content-Type: text/plain; charset="utf-8" Content-ID: <21F7193DF9ABD64A97ED656576D4EB94@intel.com> MIME-Version: 1.0 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 u4AJnHgH017861 On Tue, 2016-05-10 at 12:25 -0700, Christoph Hellwig wrote: > Hi Vishal, > > can you also pick up the my patch to add a low-level __dax_zero_range > that I cced you on?  That way we can avoid a nasty merge conflict with > my xfs/iomap changes. Good idea - I'll do that for the next posting. I'll wait a day or two for any additional reviews/acks. I'm looking to get all this into a branch in the nvdimm tree once Jan splits up his dax-locking series.. Mostly I guess I'm looking for a yay or nay for the block layer changes (patch 2). Jens?