[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4jzyofOTrymiQchXyRdNPZ+BXn3-W3hjCJ4mvtpDD2g4w@mail.gmail.com>
Date: Sat, 21 Apr 2018 16:56:56 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Souptick Joarder <jrdr.linux@...il.com>
Cc: Matthew Wilcox <willy@...radead.org>,
Al Viro <viro@...iv.linux.org.uk>,
Matthew Wilcox <mawilcox@...rosoft.com>,
Ross Zwisler <ross.zwisler@...ux.intel.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...e.com>, Jan Kara <jack@...e.cz>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] fs: dax: Adding new return type vm_fault_t
On Sat, Apr 21, 2018 at 2:54 PM, Souptick Joarder <jrdr.linux@...il.com> wrote:
> On Sun, Apr 22, 2018 at 3:04 AM, Matthew Wilcox <willy@...radead.org> wrote:
>> On Sun, Apr 22, 2018 at 02:35:29AM +0530, Souptick Joarder wrote:
>>> Use new return type vm_fault_t for fault handler. For
>>> now, this is just documenting that the function returns
>>> a VM_FAULT value rather than an errno. Once all instances
>>> are converted, vm_fault_t will become a distinct type.
>>>
>>> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>>>
>>> There was an existing bug inside dax_load_hole()
>>> if vm_insert_mixed had failed to allocate a page table,
>>> we'd return VM_FAULT_NOPAGE instead of VM_FAULT_OOM.
>>> With new vmf_insert_mixed() this issue is addressed.
>>>
>>> vm_insert_mixed_mkwrite has inefficiency when it returns
>>> an error value, driver has to convert it to vm_fault_t
>>> type. With new vmf_insert_mixed_mkwrite() this limitation
>>> will be addressed.
>>>
>>> As new function vmf_insert_mixed_mkwrite() only called
>>> from fs/dax.c, so keeping both the changes in a single
>>> patch.
>>>
>>> Signed-off-by: Souptick Joarder <jrdr.linux@...il.com>
>>
>> Reviewed-by: Matthew Wilcox <mawilcox@...rosoft.com>
>>
>> There's a couple of minor things which could be tidied up, but not worth
>> doing them as a revision to this patch.
>
> Which tree this patch will go through ? mm or fsdevel ?
nvdimm, since that tree has some pending reworks for dax-vs-truncate.
Powered by blists - more mailing lists