Received: by 2002:a25:b323:0:0:0:0:0 with SMTP id l35csp2157562ybj; Sun, 22 Sep 2019 21:28:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqxhhXyMnR/JR2t+/rFx0558OhgJUkHVTpFcV5D10sAVtSQS7pgIfy7xRrSte7Rt3jxRLn5H X-Received: by 2002:a50:b6aa:: with SMTP id d39mr34178304ede.16.1569212891311; Sun, 22 Sep 2019 21:28:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569212891; cv=none; d=google.com; s=arc-20160816; b=byptMKWVLjP6qh9NB7IRZnpeBi3+OUfw0JkDhn/NuiDOY26wEUYxoYdWlLsrHBdnVr V0iZDRVeu335CBJip65LGSsGFHzoIpk7fWX2xoMpF/oUDHylqOk2B863GlIGvEQcT2Zd NaG2WehSLkEGIRj53tEtIIo2aFCl0NC1DvtNEHh8WiVzD/oIJNAFP7ZUkEFsCne0x8Mf oPYxTp1sceh17umzT2w6RrpChjjJ8L5rThdKN7ZmYy8F4NXUvse7KvT/ZklCt5jSc623 zrZdenlSZ/Zah2KeOrH78N6sOHTnUwOg4x9Y3vNojs0P1WjkE8UPpmhsa5xP5uMbdK5G wh2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=ehfHqKGq02VDpyHgsdO6CgZKeSAkHux13i46LeTOUmM=; b=NtpLy0aPTbEOOpiVv0uoLFD0gMCo42JOc8AOmNDqlt7tGG/iEMw8QNTRqHEVHlmkCw p+d1ZpgqIUL68E/VN8h83WcWrqLDT6VPt0b148jQJ1Ddp+02WgPih/KhO+/+H91/5bQE /NmtjriezUf0cVrtdyK0Pd7rIJepxUjxrpGtaSnxtFW+VVbOzXVAtyA5eWe/vF6W6QBj opIlMHUlK/SPKtd97eCJHy2gnjWYC31YZyoSC1vxDcyxAvM4qhC6gYWR3TCqLzms5rbN gk+jzlS8d2fYTAbyxfNRbq6lcrPMFzfQibplqtA4lGz+nD2FRTbcWaoUZp2lGjUqxAYQ pkOg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=hETyHfgl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id gz26si4419200ejb.65.2019.09.22.21.27.48; Sun, 22 Sep 2019 21:28:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=hETyHfgl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404526AbfITPxE (ORCPT + 99 others); Fri, 20 Sep 2019 11:53:04 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:47280 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404366AbfITPxD (ORCPT ); Fri, 20 Sep 2019 11:53:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ehfHqKGq02VDpyHgsdO6CgZKeSAkHux13i46LeTOUmM=; b=hETyHfglQKP6WR4B6RG5ZmaQD 95C2f8tvVoss9pKS2CCwzh/44MR1IyzmMPxDliQc4yCQ4itL0mJex15dHhpw1ucGzyvOIO7o/jsr7 jofX0RjUj16USAEJCkU3VblfmrZvkT5X3grzhzOtxns4zR2HeKwp0ROGCYgr/6BZWsnrt9hrMJC3U bETYi0g+1ASXehjzUWv0+6FhtyBB+Nw3ivPf83z/RYRa49ay5KeoJIdddaB1O9dxBB6XaaxuRiInX rHEQfzmMWnXGaWIFmspCPjhFUtiTIqXfCX4myMqxSQyzp0jeHAhd2Ls8a2bZrR+3pzmi6iObihOnT tQ1driPtQ==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.2 #3 (Red Hat Linux)) id 1iBLDQ-0003vK-Bt; Fri, 20 Sep 2019 15:53:00 +0000 Date: Fri, 20 Sep 2019 08:53:00 -0700 From: Matthew Wilcox To: Jia He Cc: Catalin Marinas , Will Deacon , Mark Rutland , James Morse , Marc Zyngier , "Kirill A. Shutemov" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Suzuki Poulose , Punit Agrawal , Anshuman Khandual , Alex Van Brunt , Robin Murphy , Thomas Gleixner , Andrew Morton , =?iso-8859-1?B?Suly9G1l?= Glisse , Ralph Campbell , hejianet@gmail.com, Kaly Xin , nd@arm.com Subject: Re: [PATCH v7 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared Message-ID: <20190920155300.GC15392@bombadil.infradead.org> References: <20190920135437.25622-1-justin.he@arm.com> <20190920135437.25622-4-justin.he@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190920135437.25622-4-justin.he@arm.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 20, 2019 at 09:54:37PM +0800, Jia He wrote: > -static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va, struct vm_area_struct *vma) > +static inline int cow_user_page(struct page *dst, struct page *src, > + struct vm_fault *vmf) > { Can we talk about the return type here? > + } else { > + /* Other thread has already handled the fault > + * and we don't need to do anything. If it's > + * not the case, the fault will be triggered > + * again on the same address. > + */ > + pte_unmap_unlock(vmf->pte, vmf->ptl); > + return -1; ... > + return 0; > } So -1 for "try again" and 0 for "succeeded". > + if (cow_user_page(new_page, old_page, vmf)) { Then we use it like a bool. But it's kind of backwards from a bool because false is success. > + /* COW failed, if the fault was solved by other, > + * it's fine. If not, userspace would re-fault on > + * the same address and we will handle the fault > + * from the second attempt. > + */ > + put_page(new_page); > + if (old_page) > + put_page(old_page); > + return 0; And we don't use the return value; in fact we invert it. Would this make more sense: static inline bool cow_user_page(struct page *dst, struct page *src, struct vm_fault *vmf) ... pte_unmap_unlock(vmf->pte, vmf->ptl); return false; ... return true; ... if (!cow_user_page(new_page, old_page, vmf)) { That reads more sensibly for me. We could also go with returning a vm_fault_t, but that would be more complex than needed today, I think.