diff for duplicates of <1462988808.29294.26.camel@intel.com>

diff --git a/a/1.txt b/N1/1.txt
index d53639e..07e8ff2 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,34 +1,49 @@
-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==
+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 :)
diff --git a/a/content_digest b/N1/content_digest
index a2ebf82..a81d945 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -23,39 +23,54 @@
  " david@fromorbit.com <david@fromorbit.com>\0"
  "\00:1\0"
  "b\0"
- "T24gV2VkLCAyMDE2LTA1LTExIGF0IDEwOjE1ICswMjAwLCBKYW4gS2FyYSB3cm90ZToNCj4gT24g\n"
- "VHVlIDEwLTA1LTE2IDEyOjQ5OjE1LCBWaXNoYWwgVmVybWEgd3JvdGU6DQo+ID4gDQo+ID4gSW4g\n"
- "dGhlIHRydW5jYXRlIG9yIGhvbGUtcHVuY2ggcGF0aCBpbiBkYXgsIHdlIGNsZWFyIG91dCBzdWIt\n"
- "cGFnZQ0KPiA+IHJhbmdlcy4NCj4gPiBJZiB0aGVzZSBzdWItcGFnZSByYW5nZXMgYXJlIHNlY3Rv\n"
- "ciBhbGlnbmVkIGFuZCBzaXplZCwgd2UgY2FuIGRvIHRoZQ0KPiA+IHplcm9pbmcgdGhyb3VnaCB0\n"
- "aGUgZHJpdmVyIGluc3RlYWQgc28gdGhhdCBlcnJvci1jbGVhcmluZyBpcyBoYW5kbGVkDQo+ID4g\n"
- "YXV0b21hdGljYWxseS4NCj4gPiANCj4gPiBGb3Igc3ViLXNlY3RvciByYW5nZXMsIHdlIHN0aWxs\n"
- "IGhhdmUgdG8gcmVseSBvbiBjbGVhcl9wbWVtIGFuZCBoYXZlDQo+ID4gdGhlDQo+ID4gcG9zc2li\n"
- "aWxpdHkgb2YgdHJpcHBpbmcgb3ZlciBlcnJvcnMuDQo+ID4gDQo+ID4gQ2M6IERhbiBXaWxsaWFt\n"
- "cyA8ZGFuLmoud2lsbGlhbXNAaW50ZWwuY29tPg0KPiA+IENjOiBSb3NzIFp3aXNsZXIgPHJvc3Mu\n"
- "endpc2xlckBsaW51eC5pbnRlbC5jb20+DQo+ID4gQ2M6IEplZmYgTW95ZXIgPGptb3llckByZWRo\n"
- "YXQuY29tPg0KPiA+IENjOiBDaHJpc3RvcGggSGVsbHdpZyA8aGNoQGluZnJhZGVhZC5vcmc+DQo+\n"
- "ID4gQ2M6IERhdmUgQ2hpbm5lciA8ZGF2aWRAZnJvbW9yYml0LmNvbT4NCj4gPiBDYzogSmFuIEth\n"
- "cmEgPGphY2tAc3VzZS5jej4NCj4gPiBSZXZpZXdlZC1ieTogQ2hyaXN0b3BoIEhlbGx3aWcgPGhj\n"
- "aEBsc3QuZGU+DQo+ID4gU2lnbmVkLW9mZi1ieTogVmlzaGFsIFZlcm1hIDx2aXNoYWwubC52ZXJt\n"
- "YUBpbnRlbC5jb20+DQo+IC4uLg0KPiANCj4gPiANCj4gPiArc3RhdGljIGJvb2wgZGF4X3Jhbmdl\n"
- "X2lzX2FsaWduZWQoc3RydWN0IGJsb2NrX2RldmljZSAqYmRldiwNCj4gPiArCQkJCcKgc3RydWN0\n"
- "IGJsa19kYXhfY3RsICpkYXgsIHVuc2lnbmVkDQo+ID4gaW50IG9mZnNldCwNCj4gPiArCQkJCcKg\n"
- "dW5zaWduZWQgaW50IGxlbmd0aCkNCj4gPiArew0KPiA+ICsJdW5zaWduZWQgc2hvcnQgc2VjdG9y\n"
- "X3NpemUgPSBiZGV2X2xvZ2ljYWxfYmxvY2tfc2l6ZShiZGV2KTsNCj4gPiArDQo+ID4gKwlpZiAo\n"
- "IUlTX0FMSUdORUQoKCh1NjQpZGF4LT5hZGRyICsgb2Zmc2V0KSwgc2VjdG9yX3NpemUpKQ0KPiBP\n"
- "bmUgbW9yZSBxdWVzdGlvbjogJ2RheCcgaXMgaW5pdGlhbGl6ZWQgaW4gZGF4X3plcm9fcGFnZV9y\n"
- "YW5nZSgpIGFuZA0KPiBkYXgtPmFkZHIgaXMgZ29pbmcgdG8gYmUgYWx3YXlzIE5VTEwgaGVyZS4g\n"
- "U28gZWl0aGVyIHlvdSBmb3Jnb3QgdG8NCj4gY2FsbA0KPiBkYXhfbWFwX2F0b21pYygpIHRvIGdl\n"
- "dCB0aGUgYWRkciBvciB0aGUgdXNlIG9mIGRheC0+YWRkciBpcyBqdXN0IGJvZ3VzDQo+ICh3aGlj\n"
- "aCBpcyB3aGF0IEkgY3VycmVudGx5IGJlbGlldmUgc2luY2UgSSBzZWUgbm8gd2F5IGhvdyB0aGUg\n"
- "YWRkcmVzcw0KPiBjb3VsZA0KPiBiZSB1bmFsaWduZWQgd2l0aCB0aGUgc2VjdG9yX3NpemUpLi4u\n"
- "DQo+IA0KDQpHb29kIGNhdGNoLCBhbmQgeW91J3JlIHJpZ2h0LiBJIGRvbid0IHRoaW5rIEkgYWN0\n"
- "dWFsbHkgZXZlbiB3YW50IHRvIHVzZQ0KZGF4LT5hZGRyIGZvciB0aGUgYWxpZ25tZW50IGNoZWNr\n"
- "IGhlcmUgLSBJIHdhbnQgdG8gY2hlY2sgaWYgd2UncmUNCmFsaWduZWQgdG8gdGhlIGJsb2NrIGRl\n"
- "dmljZSBzZWN0b3IuIEknbSB0aGlua2luZyBzb21ldGhpbmcgbGlrZToNCg0KCWlmICghSVNfQUxJ\n"
- "R05FRChvZmZzZXQsIHNlY3Rvcl9zaXplKSkNCg0KVGVjaG5pY2FsbHkgd2Ugd2FudCB0byBjaGVj\n"
- "ayBpZiBzZWN0b3IgKiBzZWN0b3Jfc2l6ZSArIG9mZnNldCBpcw0KYWxpZ25lZCwgYnV0IHRoZSBm\n"
- aXJzdCBwYXJ0IG9mIHRoYXQgaXMgYWxyZWFkeSBhIHNlY3RvciA6KQ==
+ "On Wed, 2016-05-11 at 10:15 +0200, Jan Kara wrote:\n"
+ "> On Tue 10-05-16 12:49:15, Vishal Verma wrote:\n"
+ "> > \n"
+ "> > In the truncate or hole-punch path in dax, we clear out sub-page\n"
+ "> > ranges.\n"
+ "> > If these sub-page ranges are sector aligned and sized, we can do the\n"
+ "> > zeroing through the driver instead so that error-clearing is handled\n"
+ "> > automatically.\n"
+ "> > \n"
+ "> > For sub-sector ranges, we still have to rely on clear_pmem and have\n"
+ "> > the\n"
+ "> > possibility of tripping over errors.\n"
+ "> > \n"
+ "> > Cc: Dan Williams <dan.j.williams@intel.com>\n"
+ "> > Cc: Ross Zwisler <ross.zwisler@linux.intel.com>\n"
+ "> > Cc: Jeff Moyer <jmoyer@redhat.com>\n"
+ "> > Cc: Christoph Hellwig <hch@infradead.org>\n"
+ "> > Cc: Dave Chinner <david@fromorbit.com>\n"
+ "> > Cc: Jan Kara <jack@suse.cz>\n"
+ "> > Reviewed-by: Christoph Hellwig <hch@lst.de>\n"
+ "> > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>\n"
+ "> ...\n"
+ "> \n"
+ "> > \n"
+ "> > +static bool dax_range_is_aligned(struct block_device *bdev,\n"
+ "> > +\t\t\t\t\302\240struct blk_dax_ctl *dax, unsigned\n"
+ "> > int offset,\n"
+ "> > +\t\t\t\t\302\240unsigned int length)\n"
+ "> > +{\n"
+ "> > +\tunsigned short sector_size = bdev_logical_block_size(bdev);\n"
+ "> > +\n"
+ "> > +\tif (!IS_ALIGNED(((u64)dax->addr + offset), sector_size))\n"
+ "> One more question: 'dax' is initialized in dax_zero_page_range() and\n"
+ "> dax->addr is going to be always NULL here. So either you forgot to\n"
+ "> call\n"
+ "> dax_map_atomic() to get the addr or the use of dax->addr is just bogus\n"
+ "> (which is what I currently believe since I see no way how the address\n"
+ "> could\n"
+ "> be unaligned with the sector_size)...\n"
+ "> \n"
+ "\n"
+ "Good catch, and you're right. I don't think I actually even want to use\n"
+ "dax->addr for the alignment check here - I want to check if we're\n"
+ "aligned to the block device sector. I'm thinking something like:\n"
+ "\n"
+ "\tif (!IS_ALIGNED(offset, sector_size))\n"
+ "\n"
+ "Technically we want to check if sector * sector_size + offset is\n"
+ aligned, but the first part of that is already a sector :)
 
-17e1ca6ec3a1eb38acd366956b8704e6238221ad3c039454d2406658bc327ac2
+d381d0e978c3ce53368f800736a9595dbf86f1bc9a7ebffe08f2650af183c6d6
