All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "jack@suse.cz" <jack@suse.cz>
Cc: "hch@infradead.org" <hch@infradead.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	"axboe@fb.com" <axboe@fb.com>,
	"david@fromorbit.com" <david@fromorbit.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible
Date: Wed, 11 May 2016 17:47:00 +0000	[thread overview]
Message-ID: <1462988808.29294.26.camel@intel.com> (raw)
In-Reply-To: <20160511081532.GB14744@quack2.suse.cz>

On Wed, 2016-05-11 at 10:15 +0200, Jan Kara wrote:
> On Tue 10-05-16 12:49:15, Vishal Verma wrote:
> > 
> > In the truncate or hole-punch path in dax, we clear out sub-page
> > ranges.
> > If these sub-page ranges are sector aligned and sized, we can do the
> > zeroing through the driver instead so that error-clearing is handled
> > automatically.
> > 
> > For sub-sector ranges, we still have to rely on clear_pmem and have
> > the
> > possibility of tripping over errors.
> > 
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> > Cc: Jeff Moyer <jmoyer@redhat.com>
> > Cc: Christoph Hellwig <hch@infradead.org>
> > Cc: Dave Chinner <david@fromorbit.com>
> > Cc: Jan Kara <jack@suse.cz>
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> ...
> 
> > 
> > +static bool dax_range_is_aligned(struct block_device *bdev,
> > +				 struct blk_dax_ctl *dax, unsigned
> > int offset,
> > +				 unsigned int length)
> > +{
> > +	unsigned short sector_size = bdev_logical_block_size(bdev);
> > +
> > +	if (!IS_ALIGNED(((u64)dax->addr + offset), sector_size))
> One more question: 'dax' is initialized in dax_zero_page_range() and
> dax->addr is going to be always NULL here. So either you forgot to
> call
> dax_map_atomic() to get the addr or the use of dax->addr is just bogus
> (which is what I currently believe since I see no way how the address
> could
> be unaligned with the sector_size)...
> 

Good catch, and you're right. I don't think I actually even want to use
dax->addr for the alignment check here - I want to check if we're
aligned to the block device sector. I'm thinking something like:

	if (!IS_ALIGNED(offset, sector_size))

Technically we want to check if sector * sector_size + offset is
aligned, but the first part of that is already a sector :)
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "jack@suse.cz" <jack@suse.cz>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"hch@infradead.org" <hch@infradead.org>,
	"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
	"jmoyer@redhat.com" <jmoyer@redhat.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"axboe@fb.com" <axboe@fb.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	"boaz@plexistor.com" <boaz@plexistor.com>,
	"david@fromorbit.com" <david@fromorbit.com>
Subject: Re: [PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible
Date: Wed, 11 May 2016 17:47:00 +0000	[thread overview]
Message-ID: <1462988808.29294.26.camel@intel.com> (raw)
In-Reply-To: <20160511081532.GB14744@quack2.suse.cz>

T24gV2VkLCAyMDE2LTA1LTExIGF0IDEwOjE1ICswMjAwLCBKYW4gS2FyYSB3cm90ZToNCj4gT24g
VHVlIDEwLTA1LTE2IDEyOjQ5OjE1LCBWaXNoYWwgVmVybWEgd3JvdGU6DQo+ID4gDQo+ID4gSW4g
dGhlIHRydW5jYXRlIG9yIGhvbGUtcHVuY2ggcGF0aCBpbiBkYXgsIHdlIGNsZWFyIG91dCBzdWIt
cGFnZQ0KPiA+IHJhbmdlcy4NCj4gPiBJZiB0aGVzZSBzdWItcGFnZSByYW5nZXMgYXJlIHNlY3Rv
ciBhbGlnbmVkIGFuZCBzaXplZCwgd2UgY2FuIGRvIHRoZQ0KPiA+IHplcm9pbmcgdGhyb3VnaCB0
aGUgZHJpdmVyIGluc3RlYWQgc28gdGhhdCBlcnJvci1jbGVhcmluZyBpcyBoYW5kbGVkDQo+ID4g
YXV0b21hdGljYWxseS4NCj4gPiANCj4gPiBGb3Igc3ViLXNlY3RvciByYW5nZXMsIHdlIHN0aWxs
IGhhdmUgdG8gcmVseSBvbiBjbGVhcl9wbWVtIGFuZCBoYXZlDQo+ID4gdGhlDQo+ID4gcG9zc2li
aWxpdHkgb2YgdHJpcHBpbmcgb3ZlciBlcnJvcnMuDQo+ID4gDQo+ID4gQ2M6IERhbiBXaWxsaWFt
cyA8ZGFuLmoud2lsbGlhbXNAaW50ZWwuY29tPg0KPiA+IENjOiBSb3NzIFp3aXNsZXIgPHJvc3Mu
endpc2xlckBsaW51eC5pbnRlbC5jb20+DQo+ID4gQ2M6IEplZmYgTW95ZXIgPGptb3llckByZWRo
YXQuY29tPg0KPiA+IENjOiBDaHJpc3RvcGggSGVsbHdpZyA8aGNoQGluZnJhZGVhZC5vcmc+DQo+
ID4gQ2M6IERhdmUgQ2hpbm5lciA8ZGF2aWRAZnJvbW9yYml0LmNvbT4NCj4gPiBDYzogSmFuIEth
cmEgPGphY2tAc3VzZS5jej4NCj4gPiBSZXZpZXdlZC1ieTogQ2hyaXN0b3BoIEhlbGx3aWcgPGhj
aEBsc3QuZGU+DQo+ID4gU2lnbmVkLW9mZi1ieTogVmlzaGFsIFZlcm1hIDx2aXNoYWwubC52ZXJt
YUBpbnRlbC5jb20+DQo+IC4uLg0KPiANCj4gPiANCj4gPiArc3RhdGljIGJvb2wgZGF4X3Jhbmdl
X2lzX2FsaWduZWQoc3RydWN0IGJsb2NrX2RldmljZSAqYmRldiwNCj4gPiArCQkJCcKgc3RydWN0
IGJsa19kYXhfY3RsICpkYXgsIHVuc2lnbmVkDQo+ID4gaW50IG9mZnNldCwNCj4gPiArCQkJCcKg
dW5zaWduZWQgaW50IGxlbmd0aCkNCj4gPiArew0KPiA+ICsJdW5zaWduZWQgc2hvcnQgc2VjdG9y
X3NpemUgPSBiZGV2X2xvZ2ljYWxfYmxvY2tfc2l6ZShiZGV2KTsNCj4gPiArDQo+ID4gKwlpZiAo
IUlTX0FMSUdORUQoKCh1NjQpZGF4LT5hZGRyICsgb2Zmc2V0KSwgc2VjdG9yX3NpemUpKQ0KPiBP
bmUgbW9yZSBxdWVzdGlvbjogJ2RheCcgaXMgaW5pdGlhbGl6ZWQgaW4gZGF4X3plcm9fcGFnZV9y
YW5nZSgpIGFuZA0KPiBkYXgtPmFkZHIgaXMgZ29pbmcgdG8gYmUgYWx3YXlzIE5VTEwgaGVyZS4g
U28gZWl0aGVyIHlvdSBmb3Jnb3QgdG8NCj4gY2FsbA0KPiBkYXhfbWFwX2F0b21pYygpIHRvIGdl
dCB0aGUgYWRkciBvciB0aGUgdXNlIG9mIGRheC0+YWRkciBpcyBqdXN0IGJvZ3VzDQo+ICh3aGlj
aCBpcyB3aGF0IEkgY3VycmVudGx5IGJlbGlldmUgc2luY2UgSSBzZWUgbm8gd2F5IGhvdyB0aGUg
YWRkcmVzcw0KPiBjb3VsZA0KPiBiZSB1bmFsaWduZWQgd2l0aCB0aGUgc2VjdG9yX3NpemUpLi4u
DQo+IA0KDQpHb29kIGNhdGNoLCBhbmQgeW91J3JlIHJpZ2h0LiBJIGRvbid0IHRoaW5rIEkgYWN0
dWFsbHkgZXZlbiB3YW50IHRvIHVzZQ0KZGF4LT5hZGRyIGZvciB0aGUgYWxpZ25tZW50IGNoZWNr
IGhlcmUgLSBJIHdhbnQgdG8gY2hlY2sgaWYgd2UncmUNCmFsaWduZWQgdG8gdGhlIGJsb2NrIGRl
dmljZSBzZWN0b3IuIEknbSB0aGlua2luZyBzb21ldGhpbmcgbGlrZToNCg0KCWlmICghSVNfQUxJ
R05FRChvZmZzZXQsIHNlY3Rvcl9zaXplKSkNCg0KVGVjaG5pY2FsbHkgd2Ugd2FudCB0byBjaGVj
ayBpZiBzZWN0b3IgKiBzZWN0b3Jfc2l6ZSArIG9mZnNldCBpcw0KYWxpZ25lZCwgYnV0IHRoZSBm
aXJzdCBwYXJ0IG9mIHRoYXQgaXMgYWxyZWFkeSBhIHNlY3RvciA6KQ==

WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "jack@suse.cz" <jack@suse.cz>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"hch@infradead.org" <hch@infradead.org>,
	"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
	"jmoyer@redhat.com" <jmoyer@redhat.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"axboe@fb.com" <axboe@fb.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	"boaz@plexistor.com" <boaz@plexistor.com>,
	"david@fromorbit.com" <david@fromorbit.com>
Subject: Re: [PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible
Date: Wed, 11 May 2016 17:47:00 +0000	[thread overview]
Message-ID: <1462988808.29294.26.camel@intel.com> (raw)
In-Reply-To: <20160511081532.GB14744@quack2.suse.cz>

On Wed, 2016-05-11 at 10:15 +0200, Jan Kara wrote:
> On Tue 10-05-16 12:49:15, Vishal Verma wrote:
> > 
> > In the truncate or hole-punch path in dax, we clear out sub-page
> > ranges.
> > If these sub-page ranges are sector aligned and sized, we can do the
> > zeroing through the driver instead so that error-clearing is handled
> > automatically.
> > 
> > For sub-sector ranges, we still have to rely on clear_pmem and have
> > the
> > possibility of tripping over errors.
> > 
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> > Cc: Jeff Moyer <jmoyer@redhat.com>
> > Cc: Christoph Hellwig <hch@infradead.org>
> > Cc: Dave Chinner <david@fromorbit.com>
> > Cc: Jan Kara <jack@suse.cz>
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> ...
> 
> > 
> > +static bool dax_range_is_aligned(struct block_device *bdev,
> > +				 struct blk_dax_ctl *dax, unsigned
> > int offset,
> > +				 unsigned int length)
> > +{
> > +	unsigned short sector_size = bdev_logical_block_size(bdev);
> > +
> > +	if (!IS_ALIGNED(((u64)dax->addr + offset), sector_size))
> One more question: 'dax' is initialized in dax_zero_page_range() and
> dax->addr is going to be always NULL here. So either you forgot to
> call
> dax_map_atomic() to get the addr or the use of dax->addr is just bogus
> (which is what I currently believe since I see no way how the address
> could
> be unaligned with the sector_size)...
> 

Good catch, and you're right. I don't think I actually even want to use
dax->addr for the alignment check here - I want to check if we're
aligned to the block device sector. I'm thinking something like:

	if (!IS_ALIGNED(offset, sector_size))

Technically we want to check if sector * sector_size + offset is
aligned, but the first part of that is already a sector :)

WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "jack@suse.cz" <jack@suse.cz>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"hch@infradead.org" <hch@infradead.org>,
	"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
	"jmoyer@redhat.com" <jmoyer@redhat.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"axboe@fb.com" <axboe@fb.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	"boaz@plexistor.com" <boaz@plexistor.com>,
	"david@fromorbit.com" <david@fromorbit.com>
Subject: Re: [PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible
Date: Wed, 11 May 2016 17:47:00 +0000	[thread overview]
Message-ID: <1462988808.29294.26.camel@intel.com> (raw)
In-Reply-To: <20160511081532.GB14744@quack2.suse.cz>

On Wed, 2016-05-11 at 10:15 +0200, Jan Kara wrote:
> On Tue 10-05-16 12:49:15, Vishal Verma wrote:
> > 
> > In the truncate or hole-punch path in dax, we clear out sub-page
> > ranges.
> > If these sub-page ranges are sector aligned and sized, we can do the
> > zeroing through the driver instead so that error-clearing is handled
> > automatically.
> > 
> > For sub-sector ranges, we still have to rely on clear_pmem and have
> > the
> > possibility of tripping over errors.
> > 
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> > Cc: Jeff Moyer <jmoyer@redhat.com>
> > Cc: Christoph Hellwig <hch@infradead.org>
> > Cc: Dave Chinner <david@fromorbit.com>
> > Cc: Jan Kara <jack@suse.cz>
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> ...
> 
> > 
> > +static bool dax_range_is_aligned(struct block_device *bdev,
> > +				 struct blk_dax_ctl *dax, unsigned
> > int offset,
> > +				 unsigned int length)
> > +{
> > +	unsigned short sector_size = bdev_logical_block_size(bdev);
> > +
> > +	if (!IS_ALIGNED(((u64)dax->addr + offset), sector_size))
> One more question: 'dax' is initialized in dax_zero_page_range() and
> dax->addr is going to be always NULL here. So either you forgot to
> call
> dax_map_atomic() to get the addr or the use of dax->addr is just bogus
> (which is what I currently believe since I see no way how the address
> could
> be unaligned with the sector_size)...
> 

Good catch, and you're right. I don't think I actually even want to use
dax->addr for the alignment check here - I want to check if we're
aligned to the block device sector. I'm thinking something like:

	if (!IS_ALIGNED(offset, sector_size))

Technically we want to check if sector * sector_size + offset is
aligned, but the first part of that is already a sector :)

WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "jack@suse.cz" <jack@suse.cz>
Cc: "hch@infradead.org" <hch@infradead.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	"axboe@fb.com" <axboe@fb.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"jmoyer@redhat.com" <jmoyer@redhat.com>,
	"boaz@plexistor.com" <boaz@plexistor.com>,
	"ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible
Date: Wed, 11 May 2016 17:47:00 +0000	[thread overview]
Message-ID: <1462988808.29294.26.camel@intel.com> (raw)
In-Reply-To: <20160511081532.GB14744@quack2.suse.cz>

On Wed, 2016-05-11 at 10:15 +0200, Jan Kara wrote:
> On Tue 10-05-16 12:49:15, Vishal Verma wrote:
> > 
> > In the truncate or hole-punch path in dax, we clear out sub-page
> > ranges.
> > If these sub-page ranges are sector aligned and sized, we can do the
> > zeroing through the driver instead so that error-clearing is handled
> > automatically.
> > 
> > For sub-sector ranges, we still have to rely on clear_pmem and have
> > the
> > possibility of tripping over errors.
> > 
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> > Cc: Jeff Moyer <jmoyer@redhat.com>
> > Cc: Christoph Hellwig <hch@infradead.org>
> > Cc: Dave Chinner <david@fromorbit.com>
> > Cc: Jan Kara <jack@suse.cz>
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> ...
> 
> > 
> > +static bool dax_range_is_aligned(struct block_device *bdev,
> > +				 struct blk_dax_ctl *dax, unsigned
> > int offset,
> > +				 unsigned int length)
> > +{
> > +	unsigned short sector_size = bdev_logical_block_size(bdev);
> > +
> > +	if (!IS_ALIGNED(((u64)dax->addr + offset), sector_size))
> One more question: 'dax' is initialized in dax_zero_page_range() and
> dax->addr is going to be always NULL here. So either you forgot to
> call
> dax_map_atomic() to get the addr or the use of dax->addr is just bogus
> (which is what I currently believe since I see no way how the address
> could
> be unaligned with the sector_size)...
> 

Good catch, and you're right. I don't think I actually even want to use
dax->addr for the alignment check here - I want to check if we're
aligned to the block device sector. I'm thinking something like:

	if (!IS_ALIGNED(offset, sector_size))

Technically we want to check if sector * sector_size + offset is
aligned, but the first part of that is already a sector :)
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2016-05-11 17:47 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-10 18:49 [PATCH v6 0/5] dax: handling media errors (clear-on-zero only) Vishal Verma
2016-05-10 18:49 ` Vishal Verma
2016-05-10 18:49 ` Vishal Verma
2016-05-10 18:49 ` Vishal Verma
2016-05-10 18:49 ` Vishal Verma
2016-05-10 18:49 ` [PATCH v6 1/5] dax: fallback from pmd to pte on error Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49 ` [PATCH v6 2/5] dax: enable dax in the presence of known media errors (badblocks) Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49 ` [PATCH v6 3/5] dax: use sb_issue_zerout instead of calling dax_clear_sectors Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49 ` [PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 19:25   ` Christoph Hellwig
2016-05-10 19:25     ` Christoph Hellwig
2016-05-10 19:25     ` Christoph Hellwig
2016-05-10 19:49     ` Verma, Vishal L
2016-05-10 19:49       ` Verma, Vishal L
2016-05-10 19:49       ` Verma, Vishal L
2016-05-11  8:15   ` Jan Kara
2016-05-11  8:15     ` Jan Kara
2016-05-11  8:15     ` Jan Kara
2016-05-11  8:15     ` Jan Kara
2016-05-11  8:15     ` Jan Kara
2016-05-11 17:47     ` Verma, Vishal L [this message]
2016-05-11 17:47       ` Verma, Vishal L
2016-05-11 17:47       ` Verma, Vishal L
2016-05-11 17:47       ` Verma, Vishal L
2016-05-11 17:47       ` Verma, Vishal L
2016-05-11 18:39   ` Verma, Vishal L
2016-05-11 18:39     ` Verma, Vishal L
2016-05-11 18:39     ` Verma, Vishal L
2016-05-11 18:39     ` Verma, Vishal L
2016-05-11 18:39     ` Verma, Vishal L
2016-05-10 18:49 ` [PATCH v6 5/5] dax: fix a comment in dax_zero_page_range and dax_truncate_page Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49   ` Vishal Verma
2016-05-10 18:49   ` Vishal Verma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1462988808.29294.26.camel@intel.com \
    --to=vishal.l.verma@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@fb.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.