linux-kernel - Re: regression introduced by "block: Add support for DAX reads/writes to block devices"

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]

Date:	Thu, 13 Aug 2015 10:00:06 -0400
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Boaz Harrosh <boaz@...xistor.com>
Cc:	"Wilcox\, Matthew R" <matthew.r.wilcox@...el.com>,
	"linda.knippers\@hp.com" <linda.knippers@...com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fsdevel\@vger.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: regression introduced by "block: Add support for DAX reads/writes to block devices"

Boaz Harrosh <boaz@...xistor.com> writes:

> On 08/13/2015 12:11 AM, Jeff Moyer wrote:
>> Boaz Harrosh <boaz@...xistor.com> writes:
>> 
>>> 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?
>> 
>> No.  Unaligned partitions on RAID arrays or 512e devices are bad because
>> they result in suboptimal performance.  They are most certainly still
>> supported, though.
>> 
>
> What ?
>
> I meant for dax on pmem or brd. I meant that we *do not* support dax access
> on an unaligned partition start. (None dax is perfectly supported)

Sorry, I thought your statement was broader than that.

> We did it this way because of the direct_access API that returns a pfn
> with is PAGE_SIZE. We could introduce a pfn+offset but we thought it is
> not worth it, and that dax should be page aligned for code simplicity

I'd be fine with changing the persistent memory block device to only
support 4k logical, 4k physical block size.  That probably makes the
most sense.

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/