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 D858FC433FE for ; Sat, 19 Nov 2022 14:06:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 21C1B6B0072; Sat, 19 Nov 2022 09:06:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1CBF96B0073; Sat, 19 Nov 2022 09:06:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 094CD6B0074; Sat, 19 Nov 2022 09:06:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id ED1116B0072 for ; Sat, 19 Nov 2022 09:06:36 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id ADDF940357 for ; Sat, 19 Nov 2022 14:06:36 +0000 (UTC) X-FDA: 80150367192.27.DA2FAEA Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) by imf28.hostedemail.com (Postfix) with ESMTP id 34BF5C0007 for ; Sat, 19 Nov 2022 14:06:36 +0000 (UTC) Received: by mail-il1-f175.google.com with SMTP id x13so519256ilp.8 for ; Sat, 19 Nov 2022 06:06:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hev-cc.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HySLA6s6PCTDYfxJoms8KAj8+52rJt19Ujaob1kBIRs=; b=f3XhTlyJ4Lqf8RKe7v195+NYw5qxAHZXQX70hGAEglD0G4ibAPgUpVQ1t2MWLc3ONa i1RoAYVJRaIF352vk/1j/W3UbY1o38ALaPuVy1HTaLJ1X2yVSWOmDy+4GvrnMHXPCdp/ mpDO9qkNxE7XGvKSo0ilz1XFkQLdAgWjd1TAUG2xZ7oip1J087nBU5pqVEZG8MDzHBF0 QgJDWWCY0smj4xqk9VPA2UQ8njnuJRt4EewZ1Q/O6jA2gYt6cjH3/yXbMlBsqWRy31yR XQQf7cbaNUn13gCjovSNJvLaUKHLk/C0y45Mq8I3vjo2Tc2CQy0DOJBjSLg/tXIWyBO5 rvBw== 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:subject:date:message-id :reply-to; bh=HySLA6s6PCTDYfxJoms8KAj8+52rJt19Ujaob1kBIRs=; b=jkeJxOVUjsMurMfxVsJVxiNqUtbiYgco8sr+UTQFOhHAOIq6w+vAISCRcpotDkQ1Q4 o0egYZoG52H7+0ZoMjhen0SvSzB3bioGsrXQS16i+Hmxyrj7JMX5mTgQ33kWUoZiWyEV G0x303KZIl/tQwVIlZyNh8rCBwz0QZysE684fzde90DZ8ugaJgvBXTHgjT40s+eWbNpj Xg7K7cxOUPiRHDrjduw3S+Gfsa64cAuPW06IdfMiO0LoCWMv5UdI9QOnN7PnbNb5ao05 35rdTUe2D2vcTtuy3wiQRO3ZN6aAKciWZoaQ+ga9n/6prW6Z7BHFRzkHyWkDJ2nbbKwY bMiw== X-Gm-Message-State: ANoB5pmiNmzmd6MZiS3rzyXoBuL8oDkKIvmfGTFMmHfYUB0tgMvaBiJu nnCaEiuo3+OVdUQ9arQ3Ku62tfEGK4O3xInI0BubTQ== X-Google-Smtp-Source: AA0mqf6Q47ASy2lOn7xhwiwVK+Kr1p4PdbXvwnDQKTXaAndihBA03dFdxprODH/qtdjgY8Nw7TTfE++Z5E3w7PNwWgQ= X-Received: by 2002:a92:d1d2:0:b0:302:535a:6eca with SMTP id u18-20020a92d1d2000000b00302535a6ecamr4974303ilg.256.1668866795323; Sat, 19 Nov 2022 06:06:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: hev Date: Sat, 19 Nov 2022 22:06:23 +0800 Message-ID: Subject: Re: Test case for "mm/thp: carry over dirty bit when thp splits on pmd" To: Peter Xu Cc: Anatoly Pugachev , Thorsten Leemhuis , Sparc kernel list , linux-mm Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668866796; a=rsa-sha256; cv=none; b=7510HI9Ll+wRCoKaRom0A8EA7fNLzEKIN5KT/rEGPUaYjuwlEtbaRfOyK/VF2D66A9uMKW uZRFHXSVhKJPuKn96pQKbRHFoyRBK/V02KvepdS/n7V7Y/JPhlV0x2yaifpgvKIuDXkaxw xWAhvPvlfxRfpTIw3q+d41s7FnWPpZI= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=hev-cc.20210112.gappssmtp.com header.s=20210112 header.b=f3XhTlyJ; dmarc=none; spf=pass (imf28.hostedemail.com: domain of r@hev.cc designates 209.85.166.175 as permitted sender) smtp.mailfrom=r@hev.cc ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668866796; 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=HySLA6s6PCTDYfxJoms8KAj8+52rJt19Ujaob1kBIRs=; b=WIfcksjHZJOZZtibsUU2rpmKHXMZ4kTjrvdxat9Y363nXucK7ezvB2Up5kuz3o5FrGDmFU LjvpXtUgw+iY2uA3kE/xt1HYrry5wDA0yPWxyD/zzHaRBm/LMr7qxYFcr3cvJu6GsPA93V 9L+eAXUUxuk/BfgDfz9A1Bu17zlHIZU= Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=hev-cc.20210112.gappssmtp.com header.s=20210112 header.b=f3XhTlyJ; dmarc=none; spf=pass (imf28.hostedemail.com: domain of r@hev.cc designates 209.85.166.175 as permitted sender) smtp.mailfrom=r@hev.cc X-Rspam-User: X-Stat-Signature: jjhc3dzq1m61b36o48o83xso9yh5a37m X-Rspamd-Queue-Id: 34BF5C0007 X-Rspamd-Server: rspam11 X-HE-Tag: 1668866796-646165 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000051, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, Peter, On Fri, Nov 18, 2022 at 2:29 AM Peter Xu wrote: > > On Thu, Nov 17, 2022 at 10:29:57AM +0800, hev wrote: > > Hi Peter, > > Hi, Hev, > > > > > On Thu, Nov 17, 2022 at 12:25 AM Peter Xu wrote: > > > > > > On Wed, Nov 16, 2022 at 01:45:15PM +0300, Anatoly Pugachev wrote: > > > > On Wed, Nov 16, 2022 at 11:49 AM hev wrote: > > > > > > > > > > Hello Peter, > > > > > > Hi, Hev, > > > > > > Thanks for letting me know. > > > > > > > > > > > > > I see a random crash issue on the LoongArch system, that is caused by > > > > > commit 0ccf7f1 ("mm/thp: carry over dirty bit when thp splits on > > > > > pmd"). > > > > > > > > > > Now, the thing is already resolved. The root cause is arch's mkdirty > > > > > is set hardware writable bit in unconditional. That breaks > > > > > write-protect and then breaks COW. > > > > > > Could you help explain how that happened? > > > > > > I'm taking example of loongarch here: > > > > > > static inline pte_t pte_mkdirty(pte_t pte) > > > { > > > pte_val(pte) |= (_PAGE_DIRTY | _PAGE_MODIFIED); > > > return pte; > > > } > > > > > > #define _PAGE_MODIFIED (_ULCAST_(1) << _PAGE_MODIFIED_SHIFT) > > > #define _PAGE_MODIFIED_SHIFT 9 > > > > _PAGE_MODIFIED is a software dirty bit > > > > > #define _PAGE_DIRTY (_ULCAST_(1) << _PAGE_DIRTY_SHIFT) > > > #define _PAGE_DIRTY_SHIFT 1 > > > > _PAGE_DIRTY is a hardware writable bit (bad naming), meaning that mmu > > allows write memory without any exception raised. > > (I just missed this email before I reply to the other one, I should have > read this one first..) > > I see. This surprises me a bit, as I can't quickly tell how it'll always > work with the generic mm code. > > Say, is there a quick answer on why _PAGE_DIRTY is set here rather than > pte_mkwrite()? Because AFAIU that's where the mm wants to grant write > permission to a page table entry as the API, no? > > > > > > > > > I don't see when write bit is set, which is bit 8 instead: > > > > > > #define _PAGE_WRITE (_ULCAST_(1) << _PAGE_WRITE_SHIFT) > > > #define _PAGE_WRITE_SHIFT 8 > > > > _PAGE_WRITE is a software writable bit (not hardware). > > > > As David said, In __split_huge_pmd_locked, the VMA does not include VM_WRITE, > > > > entry = maybe_mkwrite(entry, vma); > > > > so the pte does not include software writable bit (_PAGE_WRITE). > > Are you sure? In your test case you mapped with RW, IIUC it means even > after the fork() VM_WRITE is set on both sides? Sorry, I was wrong. In this case, both VMAs are writable, the pte's writable bit is cleared by pte_wrprotect. So if pte_mkdirty sets hardware writable bit unconditionally, then there will be no way to catch writes to implement COW. I will try to explain how it works about pte write, dirty and write-protect on LoongArch in the LoongArch mailing-list. Regards, Ray > > But I agree the write bit is not set, not because !VM_WRITE, but because we > take care of that explicitly to make sure pte has the same write bit as pmd: > > (pmd used to be wr-protected due to fork()) > write = pmd_write(old_pmd); > ... > > (then when split pte shouldn't have write bit too) > if (!write) > entry = pte_wrprotect(entry); > > > > > and the dirty is true, > > > > if (dirty) > > entry = pte_mkdirty(entry); > > > > so the incorrect arch's pte_mkdirty set hardware writable > > bit(_PAGE_DIRTY) in unconditional for read-only pages. > > True, that does also apply to sparc64 pte_mkdirty() with _PAGE_W_4[UV]. I > should have noticed earlier that its comment told me that's a write bit > already.. > > #define _PAGE_W_4U _AC(0x0000000000000002,UL) /* Writable */ > > Thanks, > > -- > Peter Xu >