On Mon, Oct 23, 2017 at 3:44 AM, Martin Schwidefsky
wrote:
> On Mon, 23 Oct 2017 01:55:20 -0700
> Dan Williams wrote:
>
>> On Sun, Oct 22, 2017 at 10:18 PM, Martin Schwidefsky
>> wrote:
>> > On Fri, 20 Oct 2017 18:29:33 +0200
>> > Christoph Hellwig wrote:
>> >
>> >> On Fri, Oct 20, 2017 at 08:2
On Mon, 23 Oct 2017 01:55:20 -0700
Dan Williams wrote:
> On Sun, Oct 22, 2017 at 10:18 PM, Martin Schwidefsky
> wrote:
> > On Fri, 20 Oct 2017 18:29:33 +0200
> > Christoph Hellwig wrote:
> >
> >> On Fri, Oct 20, 2017 at 08:23:02AM -0700, Dan Williams wrote:
> >> > Yes, however it seems thes
On Sun, Oct 22, 2017 at 10:18 PM, Martin Schwidefsky
wrote:
> On Fri, 20 Oct 2017 18:29:33 +0200
> Christoph Hellwig wrote:
>
>> On Fri, Oct 20, 2017 at 08:23:02AM -0700, Dan Williams wrote:
>> > Yes, however it seems these drivers / platforms have been living with
>> > the lack of struct page fo
On Fri, 20 Oct 2017 18:29:33 +0200
Christoph Hellwig wrote:
> On Fri, Oct 20, 2017 at 08:23:02AM -0700, Dan Williams wrote:
> > Yes, however it seems these drivers / platforms have been living with
> > the lack of struct page for a long time. So they either don't use DAX,
> > or they have a const
On Fri, Oct 20, 2017 at 09:16:21PM -0700, Dan Williams wrote:
> > For example, I think it's entirely sensible to support ->direct_access
> > for RAID-0. Dell are looking at various different options for having
> > one pmemX device per DIMM and using RAID to lash them together.
> > ->direct_access
On Fri, Oct 20, 2017 at 8:20 PM, Matthew Wilcox wrote:
> On Fri, Oct 20, 2017 at 03:29:57PM -0700, Dan Williams wrote:
>> Ok, I'd also like to kill DAX support in the brd driver. It's a source
>> of complexity and maintenance burden for zero benefit. It's the only
>> ->direct_access() implementati
On Fri, Oct 20, 2017 at 03:29:57PM -0700, Dan Williams wrote:
> Ok, I'd also like to kill DAX support in the brd driver. It's a source
> of complexity and maintenance burden for zero benefit. It's the only
> ->direct_access() implementation that sleeps and it's the only
> implementation where there
On Fri, Oct 20, 2017 at 9:29 AM, Christoph Hellwig wrote:
> On Fri, Oct 20, 2017 at 08:23:02AM -0700, Dan Williams wrote:
>> Yes, however it seems these drivers / platforms have been living with
>> the lack of struct page for a long time. So they either don't use DAX,
>> or they have a constrained
On Fri, Oct 20, 2017 at 08:23:02AM -0700, Dan Williams wrote:
> Yes, however it seems these drivers / platforms have been living with
> the lack of struct page for a long time. So they either don't use DAX,
> or they have a constrained use case that never triggers
> get_user_pages(). If it is the l
On Fri, Oct 20, 2017 at 12:57 AM, Christoph Hellwig wrote:
>> --- a/arch/powerpc/sysdev/axonram.c
>> +++ b/arch/powerpc/sysdev/axonram.c
>> @@ -172,6 +172,7 @@ static size_t axon_ram_copy_from_iter(struct dax_device
>> *dax_dev, pgoff_t pgoff,
>>
>> static const struct dax_operations axon_ram_da
> --- a/arch/powerpc/sysdev/axonram.c
> +++ b/arch/powerpc/sysdev/axonram.c
> @@ -172,6 +172,7 @@ static size_t axon_ram_copy_from_iter(struct dax_device
> *dax_dev, pgoff_t pgoff,
>
> static const struct dax_operations axon_ram_dax_ops = {
> .direct_access = axon_ram_dax_direct_access,
>
If a dax buffer from a device that does not map pages is passed to
read(2) or write(2) as a target for direct-I/O it triggers SIGBUS. If
gdb attempts to examine the contents of a dax buffer from a device that
does not map pages it triggers SIGBUS. If fork(2) is called on a process
with a dax mappin
12 matches
Mail list logo
