From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46A3EC04FF6 for ; Tue, 16 Apr 2024 06:37:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C59C6B007B; Tue, 16 Apr 2024 02:37:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7748D6B0082; Tue, 16 Apr 2024 02:37:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6157F6B0083; Tue, 16 Apr 2024 02:37:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3890D6B007B for ; Tue, 16 Apr 2024 02:37:43 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E1AB81C0B87 for ; Tue, 16 Apr 2024 06:37:42 +0000 (UTC) X-FDA: 82014439164.16.C50CAD0 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by imf05.hostedemail.com (Postfix) with ESMTP id B23B4100004 for ; Tue, 16 Apr 2024 06:37:39 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=C52ykLAI; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf05.hostedemail.com: domain of agordeev@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=agordeev@linux.ibm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713249459; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DW16ByiGfzFf/HY70BHZqJnP86YV7zinx9U7rOft9MA=; b=hk4N9QRub9DU+CHzSG99JpLB8Yyqu/mWowHGcOb0A061m12mSrsZdXoNl71iN0HKxl416G TOUwPeSpPUt8+nI8VJLBmSnmdN/xr/d+2X/46kcI60t7Vcr7Lpzr1juA9AP5EThVlkOQil snSGQfED9cWPBBMGWrM2hoCmD97A7zk= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=C52ykLAI; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf05.hostedemail.com: domain of agordeev@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=agordeev@linux.ibm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713249459; a=rsa-sha256; cv=none; b=GeqQ/9ec2L7J400cPBCW1UKDqRS5uB97AFOVT+G+DC4lcUTboR88iy7WEqFVQ7yU3r1LO3 0XV+DZq5fSbuNmrfcW3Xj3FPiNhNczHpfu/kirYWc0a493zdtQtAwT1FS1fmYPl3KE0HXb 6ssAl1qfW2Ywok0i/HL1HU45ZcHEteg= Received: from pps.filterd (m0353724.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 43G5fOSv004182; Tue, 16 Apr 2024 06:37:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=pp1; bh=DW16ByiGfzFf/HY70BHZqJnP86YV7zinx9U7rOft9MA=; b=C52ykLAIL5hb9D87Z0TQLaf/5sslvrWqpVCXBCTQbhn9BD1krcLVW34ItjEuOov28X5y YP2tSP1nI+MdLgYjocz5VK+noEtMXpb8K0iTS7F8BRUMfrEYygx8u0I6Z8Hvxip6yX9a Y4wNo79g+F6N6Se53JH/1+maVulxeiXDo5p4JMbXz6z+Wt3vti3psg9J+O5aR3WEOqd6 aLLZVZYJ+JAlB7oBBILaNpDJet5wQYLy5LJ0IiefzhoGmDCK7mi7AkOPJLMD9tFpNu7g 7phT32WfGXgBLV6CNqKXDkoIJ/adHBrxptsqH0Yc5xzBpFloX0Xbl+bHnFmQANgqLCNu fw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3xhk9pr37j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Apr 2024 06:37:38 +0000 Received: from m0353724.ppops.net (m0353724.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 43G6TY0u011654; Tue, 16 Apr 2024 06:37:38 GMT Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3xhk9pr37e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Apr 2024 06:37:37 +0000 Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 43G3nxam011111; Tue, 16 Apr 2024 06:37:37 GMT Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 3xg732c2p5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Apr 2024 06:37:37 +0000 Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 43G6bV4948628208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 16 Apr 2024 06:37:34 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D703620067; Tue, 16 Apr 2024 06:37:31 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DD6E62004B; Tue, 16 Apr 2024 06:37:30 +0000 (GMT) Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown [9.171.55.218]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTPS; Tue, 16 Apr 2024 06:37:30 +0000 (GMT) Date: Tue, 16 Apr 2024 08:37:29 +0200 From: Alexander Gordeev To: David Hildenbrand , Christian Borntraeger Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Janosch Frank , Claudio Imbrenda , Heiko Carstens , Vasily Gorbik , Andrew Morton , Peter Xu , Sven Schnelle , Gerald Schaefer , Andrea Arcangeli , kvm@vger.kernel.org, linux-s390@vger.kernel.org Subject: Re: [PATCH v3 2/2] s390/mm: re-enable the shared zeropage for !PV and !skeys KVM guests Message-ID: References: <20240411161441.910170-1-david@redhat.com> <20240411161441.910170-3-david@redhat.com> <8533cb18-42ff-42bc-b9e5-b0537aa51b21@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8533cb18-42ff-42bc-b9e5-b0537aa51b21@redhat.com> X-TM-AS-GCONF: 00 X-Proofpoint-GUID: VQ3fX6EJCnt1qACDHjS0ldPm_TLFiIBK X-Proofpoint-ORIG-GUID: BHnBQ49bCE71R5CAArUmGZYPuxCu31hV X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-04-16_03,2024-04-15_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 suspectscore=0 clxscore=1015 adultscore=0 priorityscore=1501 bulkscore=0 malwarescore=0 impostorscore=0 mlxlogscore=781 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2404010000 definitions=main-2404160038 X-Rspamd-Queue-Id: B23B4100004 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: e8w5c4pzzbuepqwbg8ob4uw6c5q4hm8h X-HE-Tag: 1713249459-726681 X-HE-Meta: U2FsdGVkX199gNCi1Zb8KyDplxamaQT5TLQojjVk0Scb3xGDpeRv1gXgkgZOG2h6c/e2C067ibzB5fW3hq9H+JMMru/+pQQjjHQUHqxS4dV9jRB6l/Oem5kjdc1kepzyrggaDej8A5buIACU2Yxd4X0HyRMXRNPFWehltPU2QaTflQF32KrvhlgRuEVihDTGQ0BBzDQ/DuMZcTAoiVdfjVT3u7FOyr45ZmCsVSI/yaAbDEUXIJ64XGMs1DfcLCVRwnI9XZOb4/Cbyv47OiLJrERboNA7iuz51Mf9FUfY1gMrNqnCl+d/tAikT619rj1lu/RNygt1dPxc9Pyjnb7IVW5a0s0zyKLJcQA7BEPYdx9tFo3fQvCC7AU6qSDPXRNyKXF3NABoFmVqHhRjbkFKwPCDNN6GVXxM1IP5EfPqyLHkbPQzMrQiQQ4bOuYi/Vy4MgexJnBcTRJ1auDAT2Xd30LDLwi5nWpLI22yg54j2Ou2gXgQ1CKBINxeBI515+Z9rmHgUiq7yK3f23uVBwYYti0DMadjIAnVW4rm4nlDvEoD8KKXY33qEsTglX/2gJAU7qQBMDqZujCn3IJeLwC839+iYLEji7ugDRmFIgPiMA4+Uckze3MpffRCVDMvV5UrylrZCELitQUVTV6rBQux6qSd9moGWKLsYVIeWy7iRA1TG5+08tETcx7+eoXUFvZc9Aa0PXwMSPMXqMDoJ7tB4K7IKglys9jImt/teMgGRbq5m8537aIZtvHwZme6XYUyE+h2GpwoHrKjMu08hL7kFMyhvZfH3JO/Wv7b7armVJjuBJqM+/Djf0X04RyqbNvjXfYMzuRXHfGJUSQFuTnNBazlGPPW3qkyOSTltLrj93NZo8mm9mGeCPZyK52oqcSNa88uY4TeQ2st5ZQeWG+/1X2igV37DWsVD6i+g5PZv2WD1szytxca7eNKhP7xYlgxMpMxc9YTToDGPfcNFUw GhpCde6U XT1h/vXuU7mLitUBZMG6DgAL3WHHsMUSaknR2YIOTcbSTLIApNQoKOz2l8M4eov8PyoRTGrbromV2F1WNx7fz/L5eePX3sMEnChoS0fQrShs2Nkex/m0xC8/oc9d6pCYi2KWk2Xh/BEjI0w5Ypr13UG8+Gztq9GJf9lNcswYGdcSLg2JVKZCbeIvNY3a3Ofxt0TvpBANR3OKkAHRzztBciFUXsPCE0b8v9DdEZlQFr9ouqDDm9fOsUzSCj0Cf2nn0vJ5yEdPRu61IrtDv/YOpzNzQtg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Apr 15, 2024 at 09:14:03PM +0200, David Hildenbrand wrote: > > > +retry: > > > + rc = walk_page_range_vma(vma, addr, vma->vm_end, > > > + &find_zeropage_ops, &addr); > > > + if (rc <= 0) > > > + continue; > > > > So in case an error is returned for the last vma, __s390_unshare_zeropage() > > finishes with that error. By contrast, the error for a non-last vma would > > be ignored? > > Right, it looks a bit off. walk_page_range_vma() shouldn't fail > unless find_zeropage_pte_entry() would fail -- which would also be > very unexpected. > > To handle it cleanly in case we would ever get a weird zeropage where we > don't expect it, we should probably just exit early. > > Something like the following (not compiled, addressing the comment below): > @@ -2618,7 +2618,8 @@ static int __s390_unshare_zeropages(struct mm_struct *mm) > struct vm_area_struct *vma; > VMA_ITERATOR(vmi, mm, 0); > unsigned long addr; > - int rc; > + vm_fault_t rc; > + int zero_page; I would use "fault" for mm faults (just like everywhere else handle_mm_fault() is called) and leave rc as is: vm_fault_t fault; int rc; > for_each_vma(vmi, vma) { > /* > @@ -2631,9 +2632,11 @@ static int __s390_unshare_zeropages(struct mm_struct *mm) > addr = vma->vm_start; > retry: > - rc = walk_page_range_vma(vma, addr, vma->vm_end, > - &find_zeropage_ops, &addr); > - if (rc <= 0) > + zero_page = walk_page_range_vma(vma, addr, vma->vm_end, > + &find_zeropage_ops, &addr); > + if (zero_page < 0) > + return zero_page; > + else if (!zero_page) > continue; > /* addr was updated by find_zeropage_pte_entry() */ > @@ -2656,7 +2659,7 @@ static int __s390_unshare_zeropages(struct mm_struct *mm) > goto retry; > } > - return rc; > + return 0; > } > static int __s390_disable_cow_sharing(struct mm_struct *mm) ... > > > + /* addr was updated by find_zeropage_pte_entry() */ > > > + rc = handle_mm_fault(vma, addr, > > > + FAULT_FLAG_UNSHARE | FAULT_FLAG_REMOTE, > > > + NULL); > > > + if (rc & VM_FAULT_OOM) > > > + return -ENOMEM; > > > > Heiko pointed out that rc type is inconsistent vs vm_fault_t returned by > > Right, let's use another variable for that. > > > handle_mm_fault(). While fixing it up, I've got concerned whether is it > > fine to continue in case any other error is met (including possible future > > VM_FAULT_xxxx)? > > Such future changes would similarly break break_ksm(). Staring at it, I do wonder > if break_ksm() should be handling VM_FAULT_HWPOISON ... very likely we should > handle it and fail -- we might get an MC while copying from the source page. > > VM_FAULT_HWPOISON on the shared zeropage would imply a lot of trouble, so > I'm not concerned about that for the case here, but handling it in the future > would be cleaner. > > Note that we always retry the lookup, so we won't just skip a zeropage on unexpected > errors. > > We could piggy-back on vm_fault_to_errno(). We could use > vm_fault_to_errno(rc, FOLL_HWPOISON), and only continue (retry) if the rc is 0 or > -EFAULT, otherwise fail with the returned error. > > But I'd do that as a follow up, and also use it in break_ksm() in the same fashion. @Christian, do you agree with this suggestion? Thanks!