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 B2907C5475B for ; Mon, 11 Mar 2024 22:28:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 333FC6B013E; Mon, 11 Mar 2024 18:28:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E3116B013F; Mon, 11 Mar 2024 18:28:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1AB026B0140; Mon, 11 Mar 2024 18:28:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0AD906B013E for ; Mon, 11 Mar 2024 18:28:45 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B7229160456 for ; Mon, 11 Mar 2024 22:28:44 +0000 (UTC) X-FDA: 81886198968.26.FD019F6 Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by imf30.hostedemail.com (Postfix) with ESMTP id DE87E80002 for ; Mon, 11 Mar 2024 22:28:42 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=dPmEugJ6; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=jiaqiyan@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710196122; 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=a0Txb94OJ7hs7tfFRmMyIrRYkzaZsNZOSHys/hiIups=; b=6kPYXfQCnjOfgO729nWI/8/S5PdTbhSWjAKTVlQLm14Fee/SxmDoFpg85ndTE9GF37NbWp qK2VPyCD372FrCOLfzPSSTvgG45q0D0hdUDJjcQjR4Qc/jGnWobaUD0BXfDy9ggklDFD3J PuKVMp/lbDBTXiJgMs2GQPAzzBqbq/4= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=dPmEugJ6; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=jiaqiyan@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710196122; a=rsa-sha256; cv=none; b=tJz844uw3n+duFfDF8tDlbU1uGSAcTFaZnO0iQ3b1oAd8CwFt25tEWKKEi6DurmAvn1JBR N7igjv0Dh7u91nTSw3LRQm2VZmcXAtBoVseOhbDyOaUaviP9bLSLMu2l4YJZfqmXcZRkoU ObUJu2bIy9mGsYcrGGkGtYriTZAClo4= Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-60a0579a955so36252477b3.3 for ; Mon, 11 Mar 2024 15:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1710196122; x=1710800922; 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=a0Txb94OJ7hs7tfFRmMyIrRYkzaZsNZOSHys/hiIups=; b=dPmEugJ6/s2rvS7DMch8os3ihYLwN2QLiHOcjgwe5MKlHQR/bFvdKDJ1UBylOCBmhZ eQpZ1Is/GR2k7XW1yqW3HxP7ALqsHLMjn+DRHetXWeXn7YSUC9FEQKPbV7K/hkwvdYST MnRzRy0DnKcVtKJ638iO0WejRj+P+CmOa3ufhjFs3GAwtlPZ9XXsIAxSPTTSHfc8TGlS At30aO2cgGTidkZdtSPKNxpzyewdWr+lE+tgQYuAn8j1tDLNJLa5DfoXWzAHp39lzds7 LuLrvBAoKNBb/12Tb3O4ZqwCDHJxLLd7at2f8+DoJb5YXpZ63Dsc60aUVhCfOUsyC2yK g1mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710196122; x=1710800922; 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=a0Txb94OJ7hs7tfFRmMyIrRYkzaZsNZOSHys/hiIups=; b=UZYWGJAfKxvVoH/+UHrYHhqwCR378nXEAZjyGUtDiBB8WSCuU7wiAIfz9yfVQEVnrZ fzOnmgvWgYGUiTKDS1YfzM34Afln/VvMl8RH8XTF01RsE5SaZl2qaJAVTq9YrFh/n4z+ W9LvhiUQ3yPs2Egc35stgLc3OCBEQfCS3QVJezG7Jv5G88+8QOtjx6ccUcVflxnP/j4M mkFN/A+Kw0faEr5E4fMOF2vGduFSLTmEneteW6XlvdsTUimItirWjp1rdtBAPzf7ltfj FbHA+2ZF0pLxkaM28RllVx0m3OIrraW0scMHWl6Euk6c2afEcOlLv0HJxOBXMpgJEF/u RgCA== X-Forwarded-Encrypted: i=1; AJvYcCVpVUKLnotco2D5UXQe/pZEvV7wfWD/7gY/b6PpVrhPY3OIgCDZOHIKO3VkUpPyCR2GvF4UcrZrRKd/78p6Cec+/tY= X-Gm-Message-State: AOJu0YymLgEhVOrLSIP/EzDc8I9eRNF6ClBk4BIcSceAym6YMg90p8Bg Xyu+ORNfy9rw4qtqLOAkrmFK6wXaGpROfAwAaZMzi4cc5iQXjwjrmHWyTSsu3r0AVfsOCU66oSG xb5grw9cj1JwuMPCgvZ7LLmDBPc9bvXxht54K X-Google-Smtp-Source: AGHT+IFkjV1f8hMHRyB1TAhaJ/A2QrLDjirsohIM262dKP47DUGZkxQitfL2dcRKha3oni1+rS4cbxLejs71fpkTj4g= X-Received: by 2002:a0d:ca84:0:b0:60a:2143:1b0e with SMTP id m126-20020a0dca84000000b0060a21431b0emr6505096ywd.13.1710196121755; Mon, 11 Mar 2024 15:28:41 -0700 (PDT) MIME-Version: 1.0 References: <4a5c8d28-7f73-4c15-b288-641f0ccc91c2@redhat.com> In-Reply-To: From: Jiaqi Yan Date: Mon, 11 Mar 2024 15:28:28 -0700 Message-ID: Subject: Re: BUG selftests/mm] To: James Houghton Cc: Peter Xu , Axel Rasmussen , 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: DE87E80002 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: jt61dqzhy8o4fbn1f7sec9tp8k71zhfs X-HE-Tag: 1710196122-963902 X-HE-Meta: U2FsdGVkX19wExDxZU5dr4GLf5bpq2uasneJDnGUuBaB8yDBAcDQNmX8IldFjFBMqY/uUzmKcdRyJVPSaRNzF6jWcGQv8WmwM7ZG74Pa8R0asZS2b93AOEZMq3jvoEfgWVG2q32vIUK/gdBK1WX1HJgVAtfa5+2bWzzi/g2/eyblA/V/1V44qePREREfG/AKC2fgfbezp5YvN/eHOaBXbbqE0zoe2BR4rFt6U5Y2rdfWwjR15vPmmddGtjNA2J477zlVMJKELGkkZYkNaaYWge06iZQ8umH4VZ0xxsPy8My7H5u+SVciil4fnmlrXAbzOXkpH3pa4sa15DstlbrWgzJtEWmC+3qSDWiKzNrW+IKLv2tDvvl6MvhanceSKadOyQY7chRuF5KkK10zZ2R9EDlKXqo+BAKqGKGwsE7G+J/vM/LPeAtippOuVgm5Gou5zYxm/iBmVXytdQyXPoezU0R9NgaiOYjAHgwS331IZ3nqetZZPuIA2K4JLhgV+47UEQ6mmxD/XPwurILz80WWLq+rjzAF1te3nc1bkhLUVfa/2hoGwVnc4kR3m1+pDEy/fHMe9VgrMNfkl+om9X6gdZyEjO1GKHE06FzEq1shobLeXt0w5DoTcvOMT0r2GAnRu6cWBUjBrqotx1EEqXhw8QpkVKlaeLVsnrSIFVvG8sdG4+11Zs6L+KZKNwsk6tAzUSteDP9iZkpAiN0n6p3z030vY2Gv3WyduF2Cvd/yeS2kRCqW+GQ0n5rbb9gBw2lOWcp368mb+bYWArnwSHo32/LbcD7xSmydzkTfcWOgKTdAaLB0YnQNO5h/SbAx4A6gzGg57rbiYQxcDQoXJZz2AvnXCxz6YH0/nhtGOydzl5awjrWmbtUiCSfQkG33cMxIwVMGBt2dlejokmo/viZjA6FrTVVd2h6CcC+47EyUMib/nCnaaMcSPKhwoH0eTFbiA865oD5Kq1NTsU+v5mL OXu0TuQh WYAKtoGh52CGO8V+IlVIG8Fp4Z7NeiKLM9T9SHI/qqizI9G+EinCqXdzYEs9ti6jBJM1Y4bhlP2aLawlMm05RezKiHO4Qd+4vS58fB6M2vqo4/7/CmnuOeLmvQ+wIGBoRvKgdrxYzZ6S5GDFEeC4eiQ24W9wIrShAXRtb1RzG37aCJikqmXKfPVZnWZd9xqyJxZUfN57Ufj2B1fqjncF+P3aumZzYSOSDkJcI5jdv/SC+fl4wrVxZr5eh+76JC/3dPPhzd5L9avHGe99MMlfTXuSoMQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000322, 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 2:27=E2=80=AFPM James Houghton wrote: > > On Mon, Mar 11, 2024 at 12:28=E2=80=AFPM Peter Xu wro= te: > > > > On Mon, Mar 11, 2024 at 11:59:59AM -0700, Axel Rasmussen wrote: > > > 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. :/ > > I agree; UFFDIO_POISON should not require CAP_SYS_ADMIN. +1. > > > > > > > Ratelimiting seems fairly reasonable to me. I do see the concern abou= t > > > dropping some addresses though. > > > > Do you know how much could an admin rely on such addresses? How freque= nt > > would MCE generate normally in a sane system? > > I'm not sure about how much admins rely on the address themselves. +cc > Jiaqi Yan I think admins mostly care about MCEs from **real** hardware. For example they may choose to perform some maintenance if the number of hardware DIMM errors, keyed by PFN, exceeds some threshold. And I think mcelog or /sys/devices/system/node/node${X}/memory_failure are better tools than dmesg. In the case all memory errors are emulated by hypervisor after a live migration, these dmesgs may confuse admins to think there is dimm error on host but actually it is not the case. In this sense, silencing these emulated by UFFDIO_POISON makes sense (if not too complicated to do). SIGBUS (and logged "MCE: Killing %s:%d due to hardware memory corruption fault at %lx\n") emit by fault handler due to UFFDIO_POISON are less useful to admins AFAIK. They are for sure crucial to userspace / vmm / hypervisor, but the SIGBUS sent already contains the poisoned address (in si_addr from force_sig_mceerr). > > It's possible for a sane hypervisor dealing with a buggy guest / guest > userspace to trigger lots of these pr_errs. Consider the case where a > guest userspace uses HugeTLB-1G, finds poison (which HugeTLB used to > ignore), and then ignores SIGBUS. It will keep getting MCEs / > SIGBUSes. > > The sane hypervisor will use UFFDIO_POISON to prevent the guest from > re-accessing *real* poison, but we will still get the pr_err, and we > still keep injecting MCEs into the guest. We have observed scenarios > like this before. > > > > > > Perhaps we can mitigate that concern by defining our own ratelimit > > > interval/burst configuration? > > > > Any details? > > > > > Another idea would be to only ratelimit it if !CONFIG_DEBUG_VM or > > > similar. Not sure if that's considered valid or not. :) > > > > This, OTOH, sounds like an overkill.. > > > > I just checked again on the detail of ratelimit code, where we by defau= lt > > it has: > > > > #define DEFAULT_RATELIMIT_INTERVAL (5 * HZ) > > #define DEFAULT_RATELIMIT_BURST 10 > > > > So it allows a 10 times burst rather than 2.. IIUC it means even if > > there're continous 10 MCEs it won't get suppressed, until the 11th came= , in > > 5 seconds interval. I think it means it's possibly even less of a conc= ern > > to directly use pr_err_ratelimited(). > > I'm okay with any rate limiting everyone agrees on. IMO, silencing > these pr_errs if they came from UFFDIO_POISON (or, perhaps, if they > did not come from real hardware MCE events) sounds like the most > correct thing to do, but I don't mind. Just don't make UFFDIO_POISON > require CAP_SYS_ADMIN. :) > > Thanks.