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 1F33EC25B0E for ; Tue, 16 Aug 2022 20:43:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 463496B0073; Tue, 16 Aug 2022 16:43:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 412CE8D0001; Tue, 16 Aug 2022 16:43:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B2476B0075; Tue, 16 Aug 2022 16:43:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 187E76B0073 for ; Tue, 16 Aug 2022 16:43:53 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E0E6B14048B for ; Tue, 16 Aug 2022 20:43:52 +0000 (UTC) X-FDA: 79806632304.24.786A3BB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf28.hostedemail.com (Postfix) with ESMTP id 6268CC01B8 for ; Tue, 16 Aug 2022 20:43:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660682631; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Fxf9g37yt4QV3sYboUS8drWbHKZT6H8bVu/xJaEn0Rg=; b=OnJanxmtG7pIMv5uiyCapIthtKNHB5A39pUY36vsUmny4C7lj5hGy1prJyTlGBuid+pE0x fFJ5Z+XggM3tDVMbC/hjPb0On88q6UPxHMaFmuWQkw8u9avcwWN5qed/QYhwcU//f89d0R p4kJCqyGsO+kH55g1pyvYerKSQoTp1M= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-640-BHyCnEQTN4KJjv1oOLdgXQ-1; Tue, 16 Aug 2022 16:43:50 -0400 X-MC-Unique: BHyCnEQTN4KJjv1oOLdgXQ-1 Received: by mail-ed1-f69.google.com with SMTP id j19-20020a05640211d300b0043ddce5c23aso7329979edw.14 for ; Tue, 16 Aug 2022 13:43:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=Fxf9g37yt4QV3sYboUS8drWbHKZT6H8bVu/xJaEn0Rg=; b=zrqE0HLO0HCCoMjlVr/vttDKFR36M5paIbi8JkA+QzL+5RUi96/7xVNKS9y0Lw7VR7 GxgZl4nFzoBmzEWEVhrU202WDytd9jIPXS7qBn1YS/IEs2KI2fU/rKN7OybF+EQu42+j W20xdgqC5lD3Xp6tFaHuKyAf4Uj5yQdqnOuYxPA5F3/tXUNVqh8YSv7BvNqdlOIjoNVl FyrsOgW9CXAgnfjmbh+JzDwAMIanAAhUgZeNbLaJ6ihHMYFpYORlRBq0Mj4KAwc3y0g7 jdOAjT0zPD+xlZkfyq91SRZW37MjzLke2jnNhfvZ8o8/A2ltFpTbki6461CqTn5z/cCG Nw6g== X-Gm-Message-State: ACgBeo0LLT/9XREbA09fDfdl362HGBytcumt3khj5WS2KM7d9EGL46jw wXLzlMTpr7zNvh+cxx/zmvkQS4wpdf49KG+uxGSIzRREYzHKe45f9Z9ap3Mehhdr1yo4yUNPCJG sENB5bfRqTyJxgZ20O0farRd7Oyk= X-Received: by 2002:a17:907:2d12:b0:731:6a4e:ceb0 with SMTP id gs18-20020a1709072d1200b007316a4eceb0mr14858114ejc.115.1660682628493; Tue, 16 Aug 2022 13:43:48 -0700 (PDT) X-Google-Smtp-Source: AA6agR6mQoJ2O5YQF6G2r3WkspIUVkvBOxFCch0fVBSiDl1gYE66/cPrbW4OldsDj5twWFTyEbDTfZf7egY2AUaRKbQ= X-Received: by 2002:a17:907:2d12:b0:731:6a4e:ceb0 with SMTP id gs18-20020a1709072d1200b007316a4eceb0mr14858098ejc.115.1660682628222; Tue, 16 Aug 2022 13:43:48 -0700 (PDT) MIME-Version: 1.0 References: <20220811103435.188481-1-david@redhat.com> <20220811103435.188481-3-david@redhat.com> <20220815153549.0288a9c6@thinkpad> <20220815175929.303774fd@thinkpad> <20220815203844.43b74fd1@thinkpad> <20220816113359.33843f54@thinkpad> In-Reply-To: <20220816113359.33843f54@thinkpad> From: David Hildenbrand Date: Tue, 16 Aug 2022 22:43:37 +0200 Message-ID: Subject: Re: [PATCH v2 2/2] mm/hugetlb: support write-faults in shared mappings To: Gerald Schaefer Cc: Mike Kravetz , Linux Kernel Mailing List , Linux MM , stable , linux-s390 , Heiko Carstens X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660682632; a=rsa-sha256; cv=none; b=fuyBtjUvkZcgo4aSXwy/vwj7qEWg6zGJem+u2RD5wzxEn22A4pCnvp6PPiXRDfHG9txswL YNdniMjHpgTOIaBuZjxn1kckTlLRLqOS2joDdD2YyFUgK6deml0PQIximWXBTdgKYPjpCO ndMByJ+X5bOpCfAW2ZXEm2cVPK8gW3Q= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=OnJanxmt; spf=pass (imf28.hostedemail.com: domain of dhildenb@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=dhildenb@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660682632; 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=Fxf9g37yt4QV3sYboUS8drWbHKZT6H8bVu/xJaEn0Rg=; b=26ej2J2nGH0QHmM0mFN0m3hII9TKuRkC5yOiqkFRQjpN+HR/EDLgkFN/OjcS8SAFVZEjX+ kC7G4O4TjV1xsTOPKjILiNp6CFNncwqSnxM6L+ISGqiaht7z1phgnl2dJlJtDseOB9+IMI DFrr/GGeLyf0d2VbNoO1FjHehyMq2pY= Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=OnJanxmt; spf=pass (imf28.hostedemail.com: domain of dhildenb@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=dhildenb@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Stat-Signature: xqs5b7a3m9y9smuoc9uzu79inmeczr6c X-Rspamd-Queue-Id: 6268CC01B8 X-Rspamd-Server: rspam06 X-HE-Tag: 1660682632-447176 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: Hi Gerald, > > Thanks, we were also trying to reproduce on x86, w/o success so far. But > I guess that matches David latest observations wrt to our exception handling > code on s390. > > Good news is that the problem goes away when I add this simple patch, which > should result in proper VM_WRITE check for vma flags, before triggering a > FAULT_FLAG_WRITE fault: > > --- a/arch/s390/mm/fault.c > +++ b/arch/s390/mm/fault.c > @@ -379,7 +379,9 @@ static inline vm_fault_t do_exception(struct pt_regs *regs, int access) > flags = FAULT_FLAG_DEFAULT; > if (user_mode(regs)) > flags |= FAULT_FLAG_USER; > - if (access == VM_WRITE || is_write) > + if (is_write) > + access = VM_WRITE; > + if (access == VM_WRITE) > flags |= FAULT_FLAG_WRITE; > mmap_read_lock(mm); That's what I had in mind, good. > > Still find it a bit hard to believe that this > 10 years old logic really > is/was broken all the time. I guess it simply did not matter for normal > PTE faults, probably because the common fault handling code later would > check itself via maybe_mkwrite(). And for hugetlb PTEs, it might not have > mattered before commit bcd51a3c679d. It is akward, but maybe we never really noticed for hugetlb (not sure how common read-only mappings are after all). > > > > > bcd51a3c679d eliminates the copying of page tables at fork for non-anon > > hugetlb vmas. So, in these tests you would likely see more pte_none() > > faults. > > Yes, makes sense, assuming now that it actually is related to s390 > exception handling code, not checking for VM_WRITE before triggering a > write fault for pte_none(). > > Thanks for checking! And Thanks a lot to David for finding that issue > in s390 exception handling code! Thanks! Looks like adding the WARN_ON_ONCE was the right decision.