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 2CEFDC54E58 for ; Mon, 11 Mar 2024 19:00:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B4BB66B0106; Mon, 11 Mar 2024 15:00:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AFB796B0107; Mon, 11 Mar 2024 15:00:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 99C866B0108; Mon, 11 Mar 2024 15:00:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 87D876B0106 for ; Mon, 11 Mar 2024 15:00:42 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 228DF160500 for ; Mon, 11 Mar 2024 19:00:42 +0000 (UTC) X-FDA: 81885674724.25.3390F68 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by imf15.hostedemail.com (Postfix) with ESMTP id 2AFE3A002F for ; Mon, 11 Mar 2024 19:00:39 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EYZicPtK; spf=pass (imf15.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.221.52 as permitted sender) smtp.mailfrom=axelrasmussen@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710183640; 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=92UaEgw1QR+X2SR9bZcDvQ4N0TtiusowEqo+9QUTs/s=; b=DAhrPOQd72+fE8MXLLHdOsquv25h9ofPDTnyXHT2XV6x8dm2n16y/DfKwrBsLeSkqe0ctl 7NQ5MgHV6WFviuvD9gb3mnHAtEQoE66FHJls4wXdVAZZVpiF1djZ2393gaMJorBeqBUiWo HVE+azYVkzw8nJfy4BJJ3zFoVuI5Qyw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710183640; a=rsa-sha256; cv=none; b=eJ8L96dqZJzrOpdeCnoNJRYLRL7ofUPq6Qrx9SKn6Ksp6nv6NBFY2WMsX0sChPufkzcQjt p783RYe/v3XLrq8n1LqXoljpx/BooKE3GHpr0zC+XZDKewZPK/NiF/TfV6h4Y2n7AwmaT1 1962zHujwhbq9X54blcZvyqCGuaJ0e0= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EYZicPtK; spf=pass (imf15.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.221.52 as permitted sender) smtp.mailfrom=axelrasmussen@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-33e672e10cfso2273797f8f.0 for ; Mon, 11 Mar 2024 12:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1710183638; x=1710788438; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=92UaEgw1QR+X2SR9bZcDvQ4N0TtiusowEqo+9QUTs/s=; b=EYZicPtKwDJGar/6zSDDKeJJbo/9TV7V2/Xr5bGTQhI9k/1eRULkXZW7BcqRGXZti6 zDvloSkyIsaOyqiEXamzaTtTYBoWoq6wV109yzzCX7c3Xzg7Ah3NqX4nTSA6V9mK/SKs 5oEtTsL2iW0tDovJAL9D4JpCPgrJaWV7Kj/BzNoMTR7rhEVkOzj64Eq18H9bmkNOWA7W 5RfhMxcrQHcMcFQAk1K7lVGbJV2sfkc6OmAMColrjW7LzfUu9vNcgLqhG1wO5j2Zck6S sFFyBvAUs0Ro4njVFC5L1ifiHxaWkw9o9XMIxSp+moA+AJcKl1r8AGPVKGl43Ltfcg4p acGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710183638; x=1710788438; h=content-transfer-encoding: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=92UaEgw1QR+X2SR9bZcDvQ4N0TtiusowEqo+9QUTs/s=; b=TFervd+w0EuYjOok8dsOUocLkpvoc7dUK48h6ZmEND5EcdXk7l3Ly+AaARgANmFbmc CNMnXAW1kjNTwC9u4XM0h0UVzdibNsP24TdDIKbiPXA2iGzqL9xXYXLPyFCdApa8HEv7 39FLB8zUf0llodaQw1L+FRMVcz8ea5t8Rb8WAviX+0F9D/TDqlyH0XrWQHZvTjYDEG3o RJ2Zi4ZY3yJcwJVdiigj4+ITUBQHXrKgZVzoDBh62DwtCG+EoWFSsLxFIP1/OMqAu5j7 Msu7CeTZifzc4KFnfNugiBvchfJ8Fi/DycjS1f6hUgouhxOsEWyOlMkWVnxt0l1auJnv 3BrA== X-Forwarded-Encrypted: i=1; AJvYcCVIW5VGA0UxegLmzo372pLRWfJVmGSDF6Sh0z1dugt/SOsFDAvooefzuQDj0KHKT4bPqfkDw0B+i9jk7lGyy8GGy5I= X-Gm-Message-State: AOJu0Yw6Gk6lbW/mpVgV00xFT2nUkVkCjmuLxeEa3Q1A8YoNArvqlS4k 4AKBiyxnM1xCi5icL1fF0Nunz/9YHRPrCu4TsxGLNViUvMjQW0b5QVB4RAnbIawM7v8qz9dXkJC jhUjEHQ5eWSFeQJOIf0UJ9knTxBdMYFP8WEiC X-Google-Smtp-Source: AGHT+IFqA/7ZEdzACvv2yaoobZtZ/wD0lAiJnn38GnMJ/ie4F+pNJ4+7Jlih62ZraeCYFNkDvJBm2hN+zJgfEq0lXh4= X-Received: by 2002:adf:fcd2:0:b0:33d:d82e:85c7 with SMTP id f18-20020adffcd2000000b0033dd82e85c7mr5519195wrs.47.1710183638305; Mon, 11 Mar 2024 12:00:38 -0700 (PDT) MIME-Version: 1.0 References: <4a5c8d28-7f73-4c15-b288-641f0ccc91c2@redhat.com> In-Reply-To: From: Axel Rasmussen Date: Mon, 11 Mar 2024 11:59:59 -0700 Message-ID: Subject: Re: BUG selftests/mm] To: Peter Xu Cc: David Hildenbrand , Mirsad Todorovac , linux-mm@kvack.org, Andrew Morton , Shuah Khan , linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 2AFE3A002F X-Rspam-User: X-Stat-Signature: wbdbyq6rdxqzsr195frygwfiq3bjjogc X-Rspamd-Server: rspam03 X-HE-Tag: 1710183639-492389 X-HE-Meta: U2FsdGVkX1/DPFgEgsjoUlR5WcZ6/zJUtOa+DKRcgmfhHRCM4gHaLeooT7Gb+2964JW0VI3PAzKfjCJn2/oINbDNiAE9cpFM5n4Pu7060du7OeL08kQaI+hBr6YNViqlM+4ZR7TuW7ZXUdwMVze95Z1ih05kbjrAxrOZ4dIUaChsi6gSWkZjlIXqKdFW1AkEOt5hsloZIvW81gFY6Fuh2bHHMRV2/caDhIKMIEPimtM2qackxNQPIwxVtAEHPJcAoHC2/zzVy9mLDXQmH0Cm+bvERMRGyKD2Ipp0UWAJeDCFqGpRevbhne2/gyP3g22BWzOuZprGtKvitpgbFIL5OE+ZZmeqRqbtLvDEjLTAMl7UDGIqODaAaW8FVJIMZFiW7W3xzwrcAz0bUfz2I8FfDgFqcvwXJwzhOSVOJPPGhmJ8jWA5pttVEboLxwHvcpNLt4YT7ca+bloKSGCildsgwZRXMoQCk4nKafFeoevobTDkoh+VrUsmuopQtQtw68OFR1A0R6WcFjRoMLBfFExiJgl651H53LIDb/8pwTTq8rco6OTadZtlwooQi0wIB5YUzKIUBZNOWGjFSbr7AvEzA7LAhC54T8QQJQDl7YFmkuD67UiHerB7GkT9DgxhdU8aHG/7bDm7D+4vWFbAEpQ7gfD6tMXL4WQrvoU6DauUw73RrBQNzpt0TGzuQa++K90dHce7otke7nfc0X3Gm15677fBjVOvDKuhLVXk/vY5xUPCeGsmmdNqwjwwu7deppwase5VkKw+vW21hyEgO0OAYQKUlxfxBPDM0YFY9VkZg0ggPJXxkEivDiFjTrvpmx+p9bfup7nhogbDvqe031rC8Q3oAFVp3DiNktBwcApe5q7vtObLKU+MNxF4n6fVqEFPK8i2SmpFT5tA3GajE8nDPgC3bBlxeKjKc8ocP1enopJiiBUTvLEaDt54EM52Uk+2Wx43/CKjo6TctSKA5uL vSQ== 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, Mar 11, 2024 at 8:12=E2=80=AFAM Peter Xu wrote: > > On Mon, Mar 11, 2024 at 03:48:14PM +0100, David Hildenbrand wrote: > > On 11.03.24 15:35, Peter Xu wrote: > > > On Mon, Mar 11, 2024 at 10:31:41AM +0100, David Hildenbrand wrote: > > > > On 09.03.24 20:12, Mirsad Todorovac wrote: > > > > > Hi, > > > > > > > > > > Routine run of the test in net-next gave also this mm unit error. > > > > > > > > > > root@defiant:tools/testing/selftests/mm# ./uffd-unit-tests > > > > > Testing UFFDIO_API (with syscall)... done > > > > > Testing UFFDIO_API (with /dev/userfaultfd)... done > > > > > Testing register-ioctls on anon... done > > > > > Testing register-ioctls on shmem... done > > > > > Testing register-ioctls on shmem-private... done > > > > > Testing register-ioctls on hugetlb... skipped [reason: memory all= ocation failed] > > > > > Testing register-ioctls on hugetlb-private... skipped [reason: me= mory allocation failed] > > > > > Testing zeropage on anon... done > > > > > Testing zeropage on shmem... done > > > > > Testing zeropage on shmem-private... done > > > > > Testing zeropage on hugetlb... skipped [reason: memory allocation= failed] > > > > > Testing zeropage on hugetlb-private... skipped [reason: memory al= location failed] > > > > > Testing move on anon... done > > > > > Testing move-pmd on anon... done > > > > > Testing move-pmd-split on anon... done > > > > > Testing wp-fork on anon... done > > > > > Testing wp-fork on shmem... done > > > > > Testing wp-fork on shmem-private... done > > > > > Testing wp-fork on hugetlb... skipped [reason: memory allocation = failed] > > > > > Testing wp-fork on hugetlb-private... skipped [reason: memory all= ocation failed] > > > > > Testing wp-fork-with-event on anon... done > > > > > Testing wp-fork-with-event on shmem... done > > > > > Testing wp-fork-with-event on shmem-private... done > > > > > Testing wp-fork-with-event on hugetlb... skipped [reason: memory = allocation failed] > > > > > Testing wp-fork-with-event on hugetlb-private... skipped [reason:= memory allocation failed] > > > > > Testing wp-fork-pin on anon... done > > > > > Testing wp-fork-pin on shmem... done > > > > > Testing wp-fork-pin on shmem-private... done > > > > > Testing wp-fork-pin on hugetlb... skipped [reason: memory allocat= ion failed] > > > > > Testing wp-fork-pin on hugetlb-private... skipped [reason: memory= allocation failed] > > > > > Testing wp-fork-pin-with-event on anon... done > > > > > Testing wp-fork-pin-with-event on shmem... done > > > > > Testing wp-fork-pin-with-event on shmem-private... done > > > > > Testing wp-fork-pin-with-event on hugetlb... skipped [reason: mem= ory allocation failed] > > > > > Testing wp-fork-pin-with-event on hugetlb-private... skipped [rea= son: memory allocation failed] > > > > > Testing wp-unpopulated on anon... done > > > > > Testing minor on shmem... done > > > > > Testing minor on hugetlb... skipped [reason: memory allocation fa= iled] > > > > > Testing minor-wp on shmem... done > > > > > Testing minor-wp on hugetlb... skipped [reason: memory allocation= failed] > > > > > Testing minor-collapse on shmem... done > > > > > Testing sigbus on anon... done > > > > > Testing sigbus on shmem... done > > > > > Testing sigbus on shmem-private... done > > > > > Testing sigbus on hugetlb... skipped [reason: memory allocation f= ailed] > > > > > Testing sigbus on hugetlb-private... skipped [reason: memory allo= cation failed] > > > > > Testing sigbus-wp on anon... done > > > > > Testing sigbus-wp on shmem... done > > > > > Testing sigbus-wp on shmem-private... done > > > > > Testing sigbus-wp on hugetlb... skipped [reason: memory allocatio= n failed] > > > > > Testing sigbus-wp on hugetlb-private... skipped [reason: memory a= llocation failed] > > > > > Testing events on anon... done > > > > > Testing events on shmem... done > > > > > Testing events on shmem-private... done > > > > > Testing events on hugetlb... skipped [reason: memory allocation f= ailed] > > > > > Testing events on hugetlb-private... skipped [reason: memory allo= cation failed] > > > > > Testing events-wp on anon... done > > > > > Testing events-wp on shmem... done > > > > > Testing events-wp on shmem-private... done > > > > > Testing events-wp on hugetlb... skipped [reason: memory allocatio= n failed] > > > > > Testing events-wp on hugetlb-private... skipped [reason: memory a= llocation failed] > > > > > Testing poison on anon... done > > > > > Testing poison on shmem... done > > > > > Testing poison on shmem-private... done > > > > > Testing poison on hugetlb... skipped [reason: memory allocation f= ailed] > > > > > Testing poison on hugetlb-private... skipped [reason: memory allo= cation failed] > > > > > Userfaults unit tests: pass=3D42, skip=3D24, fail=3D0 (total=3D66= ) > > > > > root@defiant:tools/testing/selftests/mm# grep -i huge /proc/memin= fo > > > > > > > > > > It resulted in alarming errors in the syslog: > > > > > > > > > > Mar 9 19:48:24 defiant kernel: [77187.055103] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 4631e000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055132] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 46320000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055160] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 46322000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055189] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 46324000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055218] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 46326000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055250] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 46328000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055278] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 4632a000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055307] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 4632c000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055336] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 4632e000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055366] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 46330000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055395] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 46332000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055423] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 46334000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055452] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 46336000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055480] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 46338000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055509] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 4633a000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055538] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 4633c000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055567] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 4633e000 > > > > > Mar 9 19:48:24 defiant kernel: [77187.055597] MCE: Killing uffd-= unit-tests:1321817 due to hardware memory corruption fault at 46340000 > > > > > > > > > > At this point, it can be problem with my box's memory chips, or s= omething with HUGETLB. > > > > > > > > > > However, since the "classic" allocations were successful, the pro= blem might be in huge pages, or > > > > > if I understood well, in deliberate poisoning of pages? > > > > > > > > > > > > > Isn't that just the (expected) side effect of UFFDIO_POISON tests? > > > > > > > > IOW, there is no problem here. We are poisoning virtual memory loca= tions > > > > (not actual memory) and expect a SIGBUS on next access. While testi= ng that, > > > > we receive these messages. > > > > > > Correct. > > > > > > > > > > > The "ugly" thing here seems to be that we can trigger repeated pr_e= rr() from > > > > user space. There is no rate-limiting in place. Maybe UFFDIO_POISON= requires > > > > root permissions so this cannot be exploited by unprivileged user s= pace to > > > > flood the system log? > > > > > > > > CCing Axel > > > > > > This is pretty unfortunate. > > > > > > I'm not concerned too much on flooding whoever kicks off the selftest= s, but > > > indeed this seems to be able to be used by anyone to trigger such end= less > > > reports in dmesg. > > > > Right. > > > > > > > > The issue with requiring a privilege means any hypervisor that will n= eed to > > > use this to emulate memory errors will also require such privilege, a= nd it > > > can be a problem. > > > > > > > Yes, we don't want that. > > > > > Logically such "hwpoison errors" are not real so it is not needed to = be > > > reported in dmesg, but now we're leveraging it to be exactly the same= as a > > > real hw error to share the code path, iiuc (e.g. on MCE injections). > > > > > > One option is to use a different marker reflecting that such hwpoison= error > > > is internal, so we don't need to report in dmesg. That'll also requir= e > > > (besides another bit in pte markers) one extra VM_FAULT_* flag just f= or > > > such reports. Might be slightly an overkill, but I don't see another > > > better way; not reporting HWPOISON will complicate at least kvm use c= ase > > > even more. > > > > > > Or.. does syslog has its own protection in general for such printk fl= oods? > > > It'll be easier if that's not a concern to flood then, but I'm not su= re > > > from that regard. > > > > From what I know, flooding is considered problematic and we fix it up u= sing > > "Fixes:" commits. See 1b0a151c10a6d823f033023b9fdd9af72a89591b as one > > "recent" example. > > > > > > Usually we switch to the _ratelimited() functions, maybe > > pr_warn_ratelimited() is good enough? But we'd lose some details on a "= real" > > MCE storm, though. > > Yeah, I didn't consider that previously because I thought leaking MCE > addresses might be a problem. > > But now thinking it again, it'll be great if pr_err_ratelimited() works > here (I think we'd still want to report them with "err" not "warnings", > btw). > > I don't worry too much on MCE storm, as in that case explicit addresses m= ay > not be necessary if the whole system is on risk. What I don't know howev= er > is whether the addresses may still matter if e.g. two continuous MCEs are > reported in a small time window, and whether those addresses are a concer= n > in that case if some got lost. > > My MCE experience is pretty limited, so I don't have an answer to that. > Maybe it can be verified by proposing a patch like that and see whether > there can be any objections making it rate limtied. I'll leave that to > Axel to decide how to move forward. I'd prefer not to require root or CAP_SYS_ADMIN or similar for UFFDIO_POISON, because those control access to lots more things besides, which we don't necessarily want the process using UFFD to be able to do. :/ Ratelimiting seems fairly reasonable to me. I do see the concern about dropping some addresses though. Perhaps we can mitigate that concern by defining our own ratelimit interval/burst configuration? Another idea would be to only ratelimit it if !CONFIG_DEBUG_VM or similar. Not sure if that's considered valid or not. :) > > -- > Peter Xu >