lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55C855D5.1070001@plexistor.com>
Date:	Mon, 10 Aug 2015 10:42:13 +0300
From:	Boaz Harrosh <boaz@...xistor.com>
To:	Jeff Moyer <jmoyer@...hat.com>,
	"Wilcox, Matthew R" <matthew.r.wilcox@...el.com>
CC:	"linda.knippers@...com" <linda.knippers@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: regression introduced by "block: Add support for DAX reads/writes
 to block devices"

On 08/07/2015 11:41 PM, Jeff Moyer wrote:
<>
> 
>> We need to cope with the case where the end of a partition isn't on a
>> page boundary though.
> 
> Well, that's usually done by falling back to buffered I/O.  I gave that
> a try and panicked the box.  :)  I'll keep looking into it, but probably
> won't have another patch until next week.
> 

lets slow down for a sec, please.

We have all established that an unaligned partition start is BAD and not supported?
(If we want to also support this, which is possible then all the below is mute)

Well we do know that any real pmem device will actually be 128M aligned because of
how the DIMM thing work. So any start-aligned partition means length aligned as well.
(Emulated pmem is 4k aligned as well)

That said, you might want to protect against unaligned start / length. Even though
we have the 4k physical sector patch, a forced fdisk could produce such a partition.

I would suggest that for such un-aligned partitions the code in bdev that sets
IS_DAX on the bdev-inode should only do so if the start / length is aligned.
Else it becomes a !IS_DAX inode and all is fine.
Users will learn soon enough that for dax you need to keep the recommended 4k
alignments.

In the DAX filesystem case the start-un-aligned case is fatal and the FS would
not mount (dax enabled) . The length-un-aligned case is not a problem because
the 4k block size mandatory for dax will trim the device length to an FS block
boundary.

So it is only a problem with RAW bdev inodes and I would just not let it be
IS_DAX in the un-aligned case. (or trim its size)

Thanks
Boaz

> Cheers,
> Jeff


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ