On Thu, Jun 23, 2016 at 2:54 PM, Eric Sandeen <sandeen@xxxxxxxxxx> wrote: > This isn't functionally apparent for some reason, but > when we test io at extreme offsets at the end of the loff_t > rang, such as in fstests xfs/071, the calculation of > "max" in dax_io() can be wrong due to pos + size overflowing. > > For example, > > # xfs_io -c "pwrite 9223372036854771712 512" /mnt/test/file > > enters dax_io with: > > start 0x7ffffffffffff000 > end 0x7ffffffffffff200 > > and the rounded up "size" variable is 0x1000. This yields: > > pos + size 0x8000000000000000 (overflows loff_t) > end 0x7ffffffffffff200 > > Due to the overflow, the min() function picks the wrong > value for the "max" variable, and when we send (max - pos) > into i.e. copy_from_iter_pmem() it is also the wrong value. > > This somehow(tm) gets magically absorbed without incident, > probably because iter->count is correct. But it seems best > to fix it up properly by comparing the two values as > unsigned. So this is 4.8 material, or a user visible bug that we should take into 4.7 and -stable? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
