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 DF78BC54E58 for ; Mon, 11 Mar 2024 15:12:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 67FDF6B00B6; Mon, 11 Mar 2024 11:12:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 62FE76B00B7; Mon, 11 Mar 2024 11:12:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 51E346B00B8; Mon, 11 Mar 2024 11:12: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 3F2A26B00B6 for ; Mon, 11 Mar 2024 11:12:43 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0E58CA0A0F for ; Mon, 11 Mar 2024 15:12:43 +0000 (UTC) X-FDA: 81885100206.30.669885A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf27.hostedemail.com (Postfix) with ESMTP id C81BB40022 for ; Mon, 11 Mar 2024 15:12:40 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YcrLYFHo; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf27.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710169960; a=rsa-sha256; cv=none; b=VHgdQtmBICL4lhIjUt3xGkrN/w39JUicnK/Y5CUCoVEjupfJsb+w00GP2PIPMmfEpjrSRp 3uvHiG47o/fJR5gBaAN6PVImoixmJSCU0LfHmfNS5gdyO3vC0d83yfZVcrnhaBxOsxhDMZ xHOrxvIIbnYWD7yeJ6eblPyvcvI7gzQ= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YcrLYFHo; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf27.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710169960; 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=AFanvjXG3rXgRJ8bbFZLl5XUXc6amGVnuEQBqyJ9x9c=; b=QHYT1gntwOlTXN9B/GX/JMVNEYi51Nsz26Sgeup8/4cTe2tddMy3s4tndN+RvwuXzxToK4 mUwGMJOFF8rLtQymOhiV3INY67mmqhBPwc0ytSkDPyrCgzmdPCaJfI4QINz3vx6oq9o/yy RK9pKrEH7p2noEGkmtu6CO/RbjvI298= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1710169960; 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=AFanvjXG3rXgRJ8bbFZLl5XUXc6amGVnuEQBqyJ9x9c=; b=YcrLYFHomuUTFpQs2NnvsldV97wiYMeWJV8VUno+cT1/rNm8fj3pFub7XppBTZDu+jwd23 avr4rzDr00ZHn3fSUGeqWlGCsTnNBfnD2JK7DPd++hwXNG34BWh8qExfwiIQ5AOlGD4D5o l2afFbb5JRYmPUSRYRikUF12upr1IhY= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-152-JzMmCnpgP36Q5CrzvEPaFg-1; Mon, 11 Mar 2024 11:12:38 -0400 X-MC-Unique: JzMmCnpgP36Q5CrzvEPaFg-1 Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-7830635331bso153530385a.1 for ; Mon, 11 Mar 2024 08:12:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710169958; x=1710774758; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AFanvjXG3rXgRJ8bbFZLl5XUXc6amGVnuEQBqyJ9x9c=; b=l89jV2r3ce9r1ifpppDHinsnzInXGvIq5TCtnmoDZq9zbQ8if+thYZlTAfS6mA6P51 h3arBKQw7DGFxtY/ZKLGw+DDPqkwQ63hWLCeKfDgSlGH7PAUPY/lG7HQ2qGjFSKaMsfd sWIjTR9Gcir3xxe7BsupFgfvlx0xGIfPqzpSv0veoMpPMLH98+LkiXzHOsq7OHU76B5W PJbs/F2qjciVsFex04vk9k8zzlXUjqs11BK6Gyk1GLzDZIpIEtFWGWO6UcGGhok5m38i t38JewyK4f/98Q1ZMm5VmRm+e8FYs9jgv7cRDajpfT3uDxUw0rffnT1Iog/PX0y5ef8Y 3dEw== X-Forwarded-Encrypted: i=1; AJvYcCXTMdLQMRdX5RnXllQ93Gb/tvsTJPUmKPnlXBpI0OJvkxmuRAZLskWTcgVLhQ62FCd3QQpxxYXLBHJYZrU9/FETPSE= X-Gm-Message-State: AOJu0Yyaf4bDW5h7o3guwB8rbS+ASH7f2h2O3w4qxcgqASa//lQ3jW3F o6m0sxXvnhV1o77nV/BfSI1g27QGteKfYjEBGZ+TgQyi84iyBjs/r/5uMy2pnJZvvp0MVsFXbbC E18Xn73ziva5vHaCNAUdnt3CG0BQ+WPW4e54kx6lbgKxVwspO X-Received: by 2002:ac8:5f83:0:b0:42e:ddf9:9aed with SMTP id j3-20020ac85f83000000b0042eddf99aedmr9709640qta.3.1710169955898; Mon, 11 Mar 2024 08:12:35 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFgS0vpduQhbNU6Es5e7zITzendlncyrCParQzSDx1src5DiL1ZtFEh1SFUyLgdnb237oLtsA== X-Received: by 2002:ac8:5f83:0:b0:42e:ddf9:9aed with SMTP id j3-20020ac85f83000000b0042eddf99aedmr9709604qta.3.1710169955433; Mon, 11 Mar 2024 08:12:35 -0700 (PDT) Received: from x1n (cpe688f2e2cb7c3-cm688f2e2cb7c0.cpe.net.cable.rogers.com. [99.254.121.117]) by smtp.gmail.com with ESMTPSA id c18-20020a05620a0cf200b007871bac855fsm2767216qkj.47.2024.03.11.08.12.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Mar 2024 08:12:35 -0700 (PDT) Date: Mon, 11 Mar 2024 11:12:32 -0400 From: Peter Xu To: David Hildenbrand Cc: Mirsad Todorovac , linux-mm@kvack.org, Andrew Morton , Shuah Khan , linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Axel Rasmussen Subject: Re: BUG selftests/mm] Message-ID: References: <4a5c8d28-7f73-4c15-b288-641f0ccc91c2@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C81BB40022 X-Stat-Signature: 67qtwzb74zg1x96p1q36njixdbmg67ob X-HE-Tag: 1710169960-888044 X-HE-Meta: U2FsdGVkX19K9opn3LRlxYnQqG8gchYO2aJG9H8pCuXJaKCcO6OBBmlCzzU9fI4VOfB5YqeDPdaq5Tco2JWeyhJ9qhuOV8nMsOSzr526bP7vgtT/2vxEjC0VI3Owxj2yETB5a9bQcxTfG7YBw3TrfLm0x3EZEjv4qNKMTxD1t9uexwFlV3Cf+yEIn8hzWmK4gXIEqLPZXncI6dZIGRBMw5mgCvV3NZ+gkxphBwRAAksElYcdPmJI6TQdhyGbvKcL1YWRxKr5YImxSg3dlSW5Pp3EEZA8hg2bJJyh1ABpmGRZtedtqg5ulqGQ+X6TqF/lVFqZdeSnKs8KGxcI46be4me7EP5VXG2Y92MVhWpjnBcHym7E76/X8wdF6GIwhj3F62bEvzSTHpmdAnSp1/9iiVvnik8TUXZvjSuVUGF9WOS6S2NrQyToSbuZcmVvRwAlWb/epVcZgumDsYK/nMYyhbxZc/WxqgukpKkhShgTH1YZTlcjcQUlBG8XyM7h5TwE2tessVtccHhx2ySvcCmKyslACY5kcGk1qSwne/y+AzoN47LlfklZvQcOkxCVpEEw9HjmObPsTiIOAZjKg2KlBOBnWmf02J0Ae1ga8ny5X21BE4AEDzQjzeORM8p7oGtRtLkwSf/3i8g5pP6LoC+Unj0bUAvBVkPTvScZ7yjzwukcupmIuryDi/OOMrgItpu/nESDWi8vq9oaf/RcnOX94kNo5y1PuOStwlU+cl5QEAvJLCNY1b/r1JAvuCo5evg2268WcetFFAKfJ9tqUnnpZjiRer6surkN9h0yOCSfrl57FP7CMAX0NpQVk3DAa93lIKYm5GfyfdIUY9Yf1kjF3mtI22odBA06afZi0chn4hb2czvPKN2Y3of31zSgQD7QkG2EXZ+i0PiOQkxtruIbNKoK7vAJiDrhn2y51QKBZSSU9nHGj5+QoRv25vepxvYUi5nEzLVc46e+vonlXWe 4uDKcdKn TEU6yBtJLDH5tUAQfzsNLo4eKGZas3XbfLqklGZT9IQbbke7+W0+9GrYW6/rISkFvfFtYNzmyJyYFyJpqGffJDGL3NIlQ9TrUKkUj67k7jQWWMGb8oyvURd9ok+6PKJVajHMGX781Uc/FHE3XWj93Io4aUeJEEwoDUJYKI6aT6Cs7zJYUXRx3n/mYoFhecpcl8RLzCP1lwdeE2/FSBhGLPdeUtEMh0tA2IQPRQiFqUuiwXMzZu+IcgZExZtiwuNKjOvjH50jiDEe39b9LOCQJS6UrUXzg3iFhiIaCcn76JBACiHS2op3iPlOboi6ioYd0B/vWIbmbJbYn7GVkDWznN+Hcgn1cK3HwxV6zRSiYB8apSLw= 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 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 allocation failed] > > > > Testing register-ioctls on hugetlb-private... skipped [reason: memory 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 allocation 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 allocation 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 allocation 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: memory allocation failed] > > > > Testing wp-fork-pin-with-event on hugetlb-private... skipped [reason: memory allocation failed] > > > > Testing wp-unpopulated on anon... done > > > > Testing minor on shmem... done > > > > Testing minor on hugetlb... skipped [reason: memory allocation failed] > > > > 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 failed] > > > > Testing sigbus on hugetlb-private... skipped [reason: memory allocation 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 allocation failed] > > > > Testing sigbus-wp on hugetlb-private... skipped [reason: memory allocation 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 failed] > > > > Testing events on hugetlb-private... skipped [reason: memory allocation 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 allocation failed] > > > > Testing events-wp on hugetlb-private... skipped [reason: memory allocation 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 failed] > > > > Testing poison on hugetlb-private... skipped [reason: memory allocation failed] > > > > Userfaults unit tests: pass=42, skip=24, fail=0 (total=66) > > > > root@defiant:tools/testing/selftests/mm# grep -i huge /proc/meminfo > > > > > > > > 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 something with HUGETLB. > > > > > > > > However, since the "classic" allocations were successful, the problem 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 locations > > > (not actual memory) and expect a SIGBUS on next access. While testing that, > > > we receive these messages. > > > > Correct. > > > > > > > > The "ugly" thing here seems to be that we can trigger repeated pr_err() from > > > user space. There is no rate-limiting in place. Maybe UFFDIO_POISON requires > > > root permissions so this cannot be exploited by unprivileged user space to > > > flood the system log? > > > > > > CCing Axel > > > > This is pretty unfortunate. > > > > I'm not concerned too much on flooding whoever kicks off the selftests, but > > indeed this seems to be able to be used by anyone to trigger such endless > > reports in dmesg. > > Right. > > > > > The issue with requiring a privilege means any hypervisor that will need to > > use this to emulate memory errors will also require such privilege, and 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 require > > (besides another bit in pte markers) one extra VM_FAULT_* flag just for > > such reports. Might be slightly an overkill, but I don't see another > > better way; not reporting HWPOISON will complicate at least kvm use case > > even more. > > > > Or.. does syslog has its own protection in general for such printk floods? > > It'll be easier if that's not a concern to flood then, but I'm not sure > > from that regard. > > From what I know, flooding is considered problematic and we fix it up using > "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 may not be necessary if the whole system is on risk. What I don't know however 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 concern 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. -- Peter Xu