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 CC288C36010 for ; Fri, 11 Apr 2025 07:12:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E86AC28017E; Fri, 11 Apr 2025 03:12:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E375B28017D; Fri, 11 Apr 2025 03:12:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFDF328017E; Fri, 11 Apr 2025 03:12:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B63BA28017D for ; Fri, 11 Apr 2025 03:12:38 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C038B161CB8 for ; Fri, 11 Apr 2025 07:12:38 +0000 (UTC) X-FDA: 83320895196.16.223E24F Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by imf22.hostedemail.com (Postfix) with ESMTP id DAD3CC0009 for ; Fri, 11 Apr 2025 07:12:36 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gkcU809l; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of npiggin@gmail.com designates 209.85.216.53 as permitted sender) smtp.mailfrom=npiggin@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744355556; a=rsa-sha256; cv=none; b=wz8KD6AXZTvAo5ZY70fZ6TP57CvLTIezYYcYMVHxWxH9u1fp5E8/jZMATUwp1e493riJ4k c7eh7DwGMUrFaR9dkOkteHQ9U9/HOLcRuUeyXNddeL+HHv/nOHhpDeZvVtJ66FdoBBcS0o fI+6PWexGVRpnUyWWRTjV+jhMYNaJNk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gkcU809l; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of npiggin@gmail.com designates 209.85.216.53 as permitted sender) smtp.mailfrom=npiggin@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744355556; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KzShCwppEme7OMOnT5z5FD+rJw9aaKOfx1ISsPkjuh4=; b=604w/br6UkFwTeH/pf1pcK0+aa6aD2BSSH1qB3oedE51D7d7C85siA/eiAjjvurwqWUPCq 3/VJ/Z39XTdFogxmbqTrcHa94oV3DBAEsbXUKij5G9GeINd375pQnz8thgTTPJa3s0M9Az ZO1YYqIvphq2o48JHMpGEWOYwWXy2o4= Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-2ff784dc055so1700787a91.1 for ; Fri, 11 Apr 2025 00:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744355555; x=1744960355; darn=kvack.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KzShCwppEme7OMOnT5z5FD+rJw9aaKOfx1ISsPkjuh4=; b=gkcU809l8vbL3fbcI1hM6+d/F5P3p1xZsTUw6veoDcRoh6R2PwTiW89kxbvyFRozU6 SRAS2gqqSIunWTAprA8rUfl43cCGlZ4pLXo6mu6dGqJhmtd/srLfegFn4r4lb9EDkX77 17V3HRdHqT0l4rAchuCOTf4HREFwKx9MkIPqmg8asGYD9TBtuXHrDE1ekZsyk8SYtmhu xmdbk21qrYvIdsCMlfPlgm/hb4STu4PLty+etyQmdaisFfZOGAZD485cmYHBrr/pFsQw YjZcYf8nJRiZUW7a+cvSwAp3SHiZ5pA7kXHltVtKAWDbKDxR4R8cEyiJCcj0oPMFglF/ FGXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744355555; x=1744960355; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=KzShCwppEme7OMOnT5z5FD+rJw9aaKOfx1ISsPkjuh4=; b=pbof2hIjCNEh8eblnQnRI3oeENrcSNrXoZiB0gf2NmqQjGSGqpdK889PtNa/MT/QlD 0OBJEqkItgwzdh4We/beVoQEqCI2k7vFNv3Dpm55NHeb292ySBueQ1v2LJJjWOaXfveK Ev8W9OWJY/x4qr8si5Xfrj76vxZKxrWx6eTzHVwRYXJ9yuy+4jTFrb3nCfv33azOnWa3 fTkjp13Oa3WSFNft+fYE/sr37pjNzuOphYQgcvXOFGOAGpq7vVtet09GEJwKEwuuBS3X 9r46Ep+H60lNUkb4LA7POhTQAvW1vVXWUQZhbyrPRaO3msdGl9jVwNIdZMEOfDqfclbD 6cMg== X-Forwarded-Encrypted: i=1; AJvYcCW3MpyxCqMCpxlCdlo6px/1odKD6F0//QN9ks5/nbSYxOBWasulVrCd40ogcAPHw4Wkf9AU2WUdag==@kvack.org X-Gm-Message-State: AOJu0YxRiZCVsmIJw8P7e8WrLtlwX1Q/mSJN3VAgjCRBU+GTxaTwze7k WaC7vFh6LgZ4LscD7SpjZrLkGmmfS5nt9pGyd57oMkadGNmkLZ6t X-Gm-Gg: ASbGncuImbYS43AEU4QqxXPYLJ4qIAIwwZfn8s+sK42nmP2g0cQGnRseCHpVB1uEIMN IE0hlQZFEkOentePVRef8WKcu8zOV+XyFbevVmYd3RnhRafvCtd44E32B9pIoORQJzl+VIlbdY1 sXvz2WcfmRzL1Z4OIMlnWsopPvpm4fZpqX4MmrkbhaBCQHiLTXkz9gi0mEIr3wEd/r1xW6g7qBs toH8DhhGVuKOV7wWeoIOKNc6ts2AkeHmTobOli98sQQDWsmJCKsqVxwKGaw64i0DD9tEOo5UdNa CLNBvyXyQRGlbIvfRvxXLI6wWi0H9i6nXw== X-Google-Smtp-Source: AGHT+IHpSOk8rGIiMZXty/hbuCSKlXyveZLgB4pNTJ04Shha/BPkKtAvaM61qadHeDDYt8o+ld2JZA== X-Received: by 2002:a17:90b:5245:b0:2ff:784b:ffe with SMTP id 98e67ed59e1d1-3082377c271mr2980340a91.11.1744355555591; Fri, 11 Apr 2025 00:12:35 -0700 (PDT) Received: from localhost ([220.253.99.94]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-306dd171942sm4948139a91.33.2025.04.11.00.12.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Apr 2025 00:12:35 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 11 Apr 2025 17:12:28 +1000 Message-Id: Cc: "Hugh Dickins" , "Guenter Roeck" , "Juergen Gross" , "Jeremy Fitzhardinge" , , , , , , , Subject: Re: [PATCH v1 0/4] mm: Fix apply_to_pte_range() vs lazy MMU mode From: "Nicholas Piggin" To: "Alexander Gordeev" , "Andrew Morton" , "Andrey Ryabinin" X-Mailer: aerc 0.19.0 References: In-Reply-To: X-Rspamd-Queue-Id: DAD3CC0009 X-Stat-Signature: guz8eg3b8fgfmdpsfzesn9uunf6ni4d6 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1744355556-467286 X-HE-Meta: U2FsdGVkX19WQwh7+GtqcP5byrkzsTm+u30kd1Leo3A9TE1Ye+Hqe7/j88uEg88XK6l6PUXIUltUQgfIYwNbAiqwRhOlw2gD0POa2pWGYIwrSQ1ChYE7KB0JTErtopCl+PmOE1RR4avkkDv29+I1Gp5/GI+74PRzzewZFx/4HVoZSO+K+T3O85Ovjqj9csBPRe2ITsa4lC9RkJod9Vn+8mU2HV0qQkFLvs/EW3+2ChFSyY4t7enYp7IvOXSQXPq0cAgODwncjv10eeWdl773QboAfeXRdFnTamd3m4ng1liwM95D5RYaZXV7huFxrRueElWGZCpQMgfxdVpwAz1ZPoGbmbSxY2EzduasqBqW5/xElX+6+ugwgEdOIma7U2DrpPBaupHg2ZKUsEUWBFaediMZMh8Ai27/IO78maD9+nBVk5ssgZhTNVMpqYjwyM+6vZXv+Yx9ntQmnOFwuNYGNBZxTiCkh6ZjyMV70CeXqr2LIQ47dyZoXV9PNaWYrJNPPukBE3m0ftRmbj55snOzFUHO1v7ZSKuht2rCle40fpmba9sB/n0GxrdJzBmpUlCro+vKmZ6fTdS8l7xwXlPj0+PW2ZH2poNrQZzXW93X2fSJTkhniQDqJr3IPZyKiibYqW188D2YoSioMNJCgYqTU0pnKDq7d56K/BwyptBnBOM9eYT8txiRi8xPOImkGc9KJjhkEopicIyCWQSwFLBLUEM0WSGHd7Q7/50MjGVNYi1LpnZ0s2IQM62cfVrK/B/j+6GkCu25A7ZXqnY2skBl6Jtp6VmHms1zARtvp8EGwy4iHQGjgK6we+LNs9z6CiCX/s1T3uz5T6mmntM4cCRGNYS18k8bA25z9XBfyYgrhM0ZNSSzdrkQuFwVkLeClQ/QvNp51DVWpTsBzbH4Md7IqPlD5hJuXthu+xC+BIiupxN0XKJQH9K3NSnfcjzBav1LMv3v6zJbkidbYijDcHu 7sXuqYEc OgNu6iUO0FfcDLUCvkulL8eamdlm2c/QG54tAMd1TGjBJsZYV5HuQwfcfIqk5vB0yBEq45bj7hP/mA4fhslVzMoZsammJhngVnQ02vpq1FNAf1oXXGWgMiRND66nASeKWYgKLvqdzu4rQQqKca+9A8f7/MDfECQhJAOqO9Jl7+iGmxUwxL8QlTLJKUmj7IC7y4fq0TNmtgXfA0TPusoTPDR2xydEgJ7bo8J4bVHL/SEHbWTJuVx0M7TOc83QtCYdjnmjVTc+RmnC8mS9gtikBvbFbZf1GazD+1NLEdUsCDbCJqkM4Yy0DLGE+ro5AOgySShtRcFpxUR2tEL2+qNyro8Wyk0N89ewZY/8O5lArLTLVbOccPQBYCaNPFiRqDkamxQS+aFa549G/VKS9TpaqiDXlC2CGthp7u16nAAdS0U3uwoi2UxHSsfobihvylRDh79GEgbCmvlnJ+NbegPR7FAA3nGjvB5rdh5nDfGbJOq0rGFPM8Bto8IXC7dfcUAjx+RQHuMUY8g7RYZfp0Nr9o9gVjuk4JpJ22Yfi0fXdsAOU+BdDp+40t8y9UQ== 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 Tue Apr 8, 2025 at 1:11 AM AEST, Alexander Gordeev wrote: > Hi All, > > This series is an attempt to fix the violation of lazy MMU mode context > requirement as described for arch_enter_lazy_mmu_mode(): > > This mode can only be entered and left under the protection of > the page table locks for all page tables which may be modified. > > On s390 if I make arch_enter_lazy_mmu_mode() -> preempt_enable() and > arch_leave_lazy_mmu_mode() -> preempt_disable() I am getting this: > > [ 553.332108] preempt_count: 1, expected: 0 > [ 553.332117] no locks held by multipathd/2116. > [ 553.332128] CPU: 24 PID: 2116 Comm: multipathd Kdump: loaded Taint= ed: > [ 553.332139] Hardware name: IBM 3931 A01 701 (LPAR) > [ 553.332146] Call Trace: > [ 553.332152] [<00000000158de23a>] dump_stack_lvl+0xfa/0x150 > [ 553.332167] [<0000000013e10d12>] __might_resched+0x57a/0x5e8 > [ 553.332178] [<00000000144eb6c2>] __alloc_pages+0x2ba/0x7c0 > [ 553.332189] [<00000000144d5cdc>] __get_free_pages+0x2c/0x88 > [ 553.332198] [<00000000145663f6>] kasan_populate_vmalloc_pte+0x4e/= 0x110 > [ 553.332207] [<000000001447625c>] apply_to_pte_range+0x164/0x3c8 > [ 553.332218] [<000000001448125a>] apply_to_pmd_range+0xda/0x318 > [ 553.332226] [<000000001448181c>] __apply_to_page_range+0x384/0x76= 8 > [ 553.332233] [<0000000014481c28>] apply_to_page_range+0x28/0x38 > [ 553.332241] [<00000000145665da>] kasan_populate_vmalloc+0x82/0x98 > [ 553.332249] [<00000000144c88d0>] alloc_vmap_area+0x590/0x1c90 > [ 553.332257] [<00000000144ca108>] __get_vm_area_node.constprop.0+0= x138/0x260 > [ 553.332265] [<00000000144d17fc>] __vmalloc_node_range+0x134/0x360 > [ 553.332274] [<0000000013d5dbf2>] alloc_thread_stack_node+0x112/0x= 378 > [ 553.332284] [<0000000013d62726>] dup_task_struct+0x66/0x430 > [ 553.332293] [<0000000013d63962>] copy_process+0x432/0x4b80 > [ 553.332302] [<0000000013d68300>] kernel_clone+0xf0/0x7d0 > [ 553.332311] [<0000000013d68bd6>] __do_sys_clone+0xae/0xc8 > [ 553.332400] [<0000000013d68dee>] __s390x_sys_clone+0xd6/0x118 > [ 553.332410] [<0000000013c9d34c>] do_syscall+0x22c/0x328 > [ 553.332419] [<00000000158e7366>] __do_syscall+0xce/0xf0 > [ 553.332428] [<0000000015913260>] system_call+0x70/0x98 > > This exposes a KASAN issue fixed with patch 1 and apply_to_pte_range() > issue fixed with patches 2-3. Patch 4 is a debug improvement on top, > that could have helped to notice the issue. > > Commit b9ef323ea168 ("powerpc/64s: Disable preemption in hash lazy mmu > mode") looks like powerpc-only fix, yet not entirely conforming to the > above provided requirement (page tables itself are still not protected). > If I am not mistaken, xen and sparc are alike. Huh. powerpc actually has some crazy code in __switch_to() that is supposed to handle preemption while in lazy mmu mode. So we probably don't even need to disable preemption, just use the raw per-cpu accessors (or keep disabling preemption and remove the now dead code from context switch). IIRC all this got built up over a long time with some TLB flush rules changing at the same time, we could probably stay in lazy mmu mode for a longer time until it was discovered we really need to flush before dropping the PTL. ppc64 and sparc I think don't even need lazy mmu mode for kasan (TLBs do not require flushing) and will function just fine if not in lazy mode (they just flush one TLB at a time), not sure about xen. We could actually go the other way and require that archs operate properly when not in lazy mode (at least for kernel page tables) and avoid it for apply_to_page_range()? Thanks, Nick