From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by kanga.kvack.org (Postfix) with ESMTP id C85646B0672 for ; Fri, 11 May 2018 12:34:37 -0400 (EDT) Received: by mail-oi0-f69.google.com with SMTP id k186-v6so3125354oib.7 for ; Fri, 11 May 2018 09:34:37 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id q66-v6sor1590880oif.234.2018.05.11.09.34.36 for (Google Transport Security); Fri, 11 May 2018 09:34:36 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180511163421.GA32728@jordon-HP-15-Notebook-PC> References: <20180511163421.GA32728@jordon-HP-15-Notebook-PC> From: Dan Williams Date: Fri, 11 May 2018 09:34:36 -0700 Message-ID: Subject: Re: [PATCH v4] dax: Change return type to vm_fault_t Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Souptick Joarder Cc: Matthew Wilcox , Andrew Morton , "Kirill A. Shutemov" , zi.yan@cs.rutgers.edu, Ross Zwisler , "Huang, Ying" , Michal Hocko , Peter Zijlstra , "Aneesh Kumar K.V" , David Rientjes , linux-nvdimm , Linux Kernel Mailing List , Linux MM On Fri, May 11, 2018 at 9:34 AM, 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") > > Previously vm_insert_mixed() returns err which driver > mapped into VM_FAULT_* type. The new function > vmf_insert_mixed() will replace this inefficiency by > returning VM_FAULT_* type. > > Signed-off-by: Souptick Joarder > Reviewed-by: Matthew Wilcox > Reviewed-by: Ross Zwisler > --- > v2: Modified the change log > > v3: Updated the change log and > added Ross in review list > > v4: Addressed David's comment. > Changes in huge_memory.c put > together in a single patch that > it is bisectable in furture Thanks, I'll carry this in the nvdimm tree since it collides with some work-in progress development.