From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3A6C38170F for ; Mon, 6 Feb 2017 08:24:50 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id 65so65701282otq.2 for ; Mon, 06 Feb 2017 08:24:50 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20170206143648.GA461@infradead.org> References: <148615748258.43180.1690152053774975329.stgit@djiang5-desk3.ch.intel.com> <20170206143648.GA461@infradead.org> From: Dan Williams Date: Mon, 6 Feb 2017 08:24:48 -0800 Message-ID: Subject: Re: [PATCH] mm: replace FAULT_FLAG_SIZE with parameter to huge_fault List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Christoph Hellwig Cc: Matthew Wilcox , "linux-nvdimm@lists.01.org" , Dave Hansen , linux-xfs@vger.kernel.org, Linux MM , Vlastimil Babka , Jan Kara , Andrew Morton , linux-ext4 , "Kirill A. Shutemov" List-ID: On Mon, Feb 6, 2017 at 6:36 AM, Christoph Hellwig wrote: > On Fri, Feb 03, 2017 at 02:31:22PM -0700, Dave Jiang wrote: >> Since the introduction of FAULT_FLAG_SIZE to the vm_fault flag, it has >> been somewhat painful with getting the flags set and removed at the >> correct locations. More than one kernel oops was introduced due to >> difficulties of getting the placement correctly. Removing the flag >> values and introducing an input parameter to huge_fault that indicates >> the size of the page entry. This makes the code easier to trace and >> should avoid the issues we see with the fault flags where removal of the >> flag was necessary in the fallback paths. > > Why is this not in struct vm_fault? Because this is easier to read and harder to get wrong. Same arguments as getting rid of struct blk_dax_ctl. > Also can be use this opportunity > to fold ->huge_fault into ->fault? Hmm, yes, just need a scheme to not attempt huge_faults on pte-only handlers. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Williams Subject: Re: [PATCH] mm: replace FAULT_FLAG_SIZE with parameter to huge_fault Date: Mon, 6 Feb 2017 08:24:48 -0800 Message-ID: References: <148615748258.43180.1690152053774975329.stgit@djiang5-desk3.ch.intel.com> <20170206143648.GA461@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Dave Jiang , Matthew Wilcox , "linux-nvdimm@lists.01.org" , Dave Hansen , linux-xfs@vger.kernel.org, Linux MM , "Kirill A. Shutemov" , Jan Kara , Andrew Morton , linux-ext4 , Vlastimil Babka To: Christoph Hellwig Return-path: In-Reply-To: <20170206143648.GA461@infradead.org> Sender: owner-linux-mm@kvack.org List-Id: linux-ext4.vger.kernel.org On Mon, Feb 6, 2017 at 6:36 AM, Christoph Hellwig wrote: > On Fri, Feb 03, 2017 at 02:31:22PM -0700, Dave Jiang wrote: >> Since the introduction of FAULT_FLAG_SIZE to the vm_fault flag, it has >> been somewhat painful with getting the flags set and removed at the >> correct locations. More than one kernel oops was introduced due to >> difficulties of getting the placement correctly. Removing the flag >> values and introducing an input parameter to huge_fault that indicates >> the size of the page entry. This makes the code easier to trace and >> should avoid the issues we see with the fault flags where removal of the >> flag was necessary in the fallback paths. > > Why is this not in struct vm_fault? Because this is easier to read and harder to get wrong. Same arguments as getting rid of struct blk_dax_ctl. > Also can be use this opportunity > to fold ->huge_fault into ->fault? Hmm, yes, just need a scheme to not attempt huge_faults on pte-only handlers. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f177.google.com ([74.125.82.177]:33677 "EHLO mail-ot0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752553AbdBFQYz (ORCPT ); Mon, 6 Feb 2017 11:24:55 -0500 Received: by mail-ot0-f177.google.com with SMTP id 73so65727618otj.0 for ; Mon, 06 Feb 2017 08:24:55 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20170206143648.GA461@infradead.org> References: <148615748258.43180.1690152053774975329.stgit@djiang5-desk3.ch.intel.com> <20170206143648.GA461@infradead.org> From: Dan Williams Date: Mon, 6 Feb 2017 08:24:48 -0800 Message-ID: Subject: Re: [PATCH] mm: replace FAULT_FLAG_SIZE with parameter to huge_fault Content-Type: text/plain; charset=UTF-8 Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: Christoph Hellwig Cc: Dave Jiang , Matthew Wilcox , "linux-nvdimm@lists.01.org" , Dave Hansen , linux-xfs@vger.kernel.org, Linux MM , "Kirill A. Shutemov" , Jan Kara , Andrew Morton , linux-ext4 , Vlastimil Babka On Mon, Feb 6, 2017 at 6:36 AM, Christoph Hellwig wrote: > On Fri, Feb 03, 2017 at 02:31:22PM -0700, Dave Jiang wrote: >> Since the introduction of FAULT_FLAG_SIZE to the vm_fault flag, it has >> been somewhat painful with getting the flags set and removed at the >> correct locations. More than one kernel oops was introduced due to >> difficulties of getting the placement correctly. Removing the flag >> values and introducing an input parameter to huge_fault that indicates >> the size of the page entry. This makes the code easier to trace and >> should avoid the issues we see with the fault flags where removal of the >> flag was necessary in the fallback paths. > > Why is this not in struct vm_fault? Because this is easier to read and harder to get wrong. Same arguments as getting rid of struct blk_dax_ctl. > Also can be use this opportunity > to fold ->huge_fault into ->fault? Hmm, yes, just need a scheme to not attempt huge_faults on pte-only handlers.