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 4B68BC5475B for ; Mon, 11 Mar 2024 19:28:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BF7036B0110; Mon, 11 Mar 2024 15:28:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BA7376B0111; Mon, 11 Mar 2024 15:28:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6EC36B0112; Mon, 11 Mar 2024 15:28:37 -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 97A436B0110 for ; Mon, 11 Mar 2024 15:28:37 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 59E13A0A3B for ; Mon, 11 Mar 2024 19:28:37 +0000 (UTC) X-FDA: 81885745074.04.8E8A87A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf08.hostedemail.com (Postfix) with ESMTP id 48B6216000E for ; Mon, 11 Mar 2024 19:28:32 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PhJVSfHI; spf=pass (imf08.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710185315; a=rsa-sha256; cv=none; b=WucQaTGJonQ06jYlNwBOu9I3YNK3iTHGcM88rm7eIUPUBhxsjrhjNJYnHK8iIqbOp1/9BX GfIwUn67s8l2erbLsHebVDCJYCgSBfaIDy1loT8hsH5TvZKpgryyS2MkESjUoaDcT4W2Ee m6JoPWlmvRBYISvIszjfZCieWbtFk+Y= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PhJVSfHI; spf=pass (imf08.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710185315; 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=FAVXB/mXoK7CZU4s1o0G19dHxslq0BXaeV69BqYUoiw=; b=mUB1fl0Cq0v45tDkYPgNIADzVfeAPk30OlP04N/SqNIF4buodyAycJop1q2bPtK+GJDTrs AAxK60zH6XB4gT/k4WjatNiWIB/36Suhb/WLPLQmVOXDjn+xnIOJCBEQ5enCs5mgq9y3DY 0mfWLkaknLvhcojaS4CyHdtXQJCcKHk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1710185311; 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=FAVXB/mXoK7CZU4s1o0G19dHxslq0BXaeV69BqYUoiw=; b=PhJVSfHI2DRTSafBU7gJKuIAWZhB2mKMXxo690c4EwMjOkG2jUjtpuSlBGRmVrezJVUbzl ydDFowJAfYlUQnanclwdNtbxcWtOTqp4uKFDZYwSfV7kWkPYlieIUdIKyd6pXMvDp577oP gmdsEze2kGEIE0+YszXg8FiICAqmRLY= Received: from mail-ot1-f69.google.com (mail-ot1-f69.google.com [209.85.210.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-672-J2-qpJLMOI6R5yh_FndTfw-1; Mon, 11 Mar 2024 15:28:30 -0400 X-MC-Unique: J2-qpJLMOI6R5yh_FndTfw-1 Received: by mail-ot1-f69.google.com with SMTP id 46e09a7af769-6e4eed7401dso1330335a34.1 for ; Mon, 11 Mar 2024 12:28:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710185309; x=1710790109; 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=FAVXB/mXoK7CZU4s1o0G19dHxslq0BXaeV69BqYUoiw=; b=V51rMc399tnaXrr8AsiIs8w+cfpSsVYFNymGECG1Y1bgff+B3UJm3ucAL9bo3mH41a x8b78wTpev+TnofWKAy5wWFViTjQ7HWcl4eBxPrlM2Yj9+uhDgUE94gwc9DIij0rZkzB 86GhrEhhgCsZHN+/Zkfg4IAvGznUSo6V4xslRsNzNNnw4ZeOCwXHU0o70X/jspKZrMM5 RwQeiCKXJXS8MmU8M7tCJbPMBjtV2SxfkY+CjI04WI3UiTLdYmq0KF3UlzO+WhbbKefj 5JHxsJV1FJQBvMUga+a8hyfoGg7K4hUhLK4z+8wC0FSdOAtdcIk7SSnLSkmBoIqs+wp/ sAug== X-Forwarded-Encrypted: i=1; AJvYcCWp6YR0wWjz0HnMmS+q7a+F/Kn8ISrYJk7Jd/UM/LcXVdPuYcRgAEfY9ahYEXntBt5yT9xclydyyhY3Gktxll2Hg4A= X-Gm-Message-State: AOJu0Yzg4B1rD+rX9bNLBcMiHKQOsxLYyESxqdlHs7uRM22xXLJ9xzWw Iih9alhpr4M+lpmvd/oBqkMHB6xmLAPgL0hZ9rP8TyUTYL/M3m8a8l9u1qSObpv+EMnnsQNWGef 5V0BAEensIIYcvV7V/hg6dopIZB4rUkyX1hkeZ/CnR2KNet4m X-Received: by 2002:a4a:a44c:0:b0:5a2:3c1:a624 with SMTP id w12-20020a4aa44c000000b005a203c1a624mr3727470ool.1.1710185309487; Mon, 11 Mar 2024 12:28:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF/VMFWq2kIQEJ16kIMzxcU9BTefs+9QqGcG3RbD0ZtdZlOIyjSBXC6THIfOoARSG3/qusrVQ== X-Received: by 2002:a4a:a44c:0:b0:5a2:3c1:a624 with SMTP id w12-20020a4aa44c000000b005a203c1a624mr3727456ool.1.1710185309168; Mon, 11 Mar 2024 12:28:29 -0700 (PDT) Received: from x1n (cpe688f2e2cb7c3-cm688f2e2cb7c0.cpe.net.cable.rogers.com. [99.254.121.117]) by smtp.gmail.com with ESMTPSA id h7-20020a05620a400700b007882e50260fsm2950520qko.104.2024.03.11.12.28.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Mar 2024 12:28:28 -0700 (PDT) Date: Mon, 11 Mar 2024 15:28:26 -0400 From: Peter Xu To: Axel Rasmussen Cc: David Hildenbrand , Mirsad Todorovac , linux-mm@kvack.org, Andrew Morton , Shuah Khan , linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org 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-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 48B6216000E X-Stat-Signature: u5zoi93osyrfpmdh8oxwkrwt9s9wtzpu X-Rspam-User: X-HE-Tag: 1710185312-667176 X-HE-Meta: U2FsdGVkX1/CLnnGSXj1QP2tGAbFkL+krdBM1SGoOXThRZty5dmXxVY+nzfH0nuN5Vg2utGe6Fp/R2Luwsowj4/FhHjVyH6HS9xl6iYc/BqsegQvBssT3ovDK/V5184oDMiKRVhCE//K1x3r8dAlTjtKV3KDA5vYRGRbruIqe7gR4Ji7GHrt5NALyxujqna/I3Pb1xAFyP52+k5hiiiUJmuDpBEdLxXNQQO84uug+NBT0RVwlnqkgTls9lDoLFukzy7hYq6HQGx+YZeMZk03B5LO9BsUslKIlcq1Ce58hpP0SrTqqaOVd7pNDjX825E2AH/isIPU67hPjyX/IcDvnTjBrsarrIy8IT0wzLATJoM+yst8If/266/6u/ifsCoDRWhgTs3fvxA0Kxpr2ikSvaHYcVzG5jRh+vRvdq6ANMj/7CIJztCtv3RWtCpB5SNyXt16wmRmMP15IAEn06OA5D1DoWPCJeXEWFiIvtW7ammcYkEkCuaekCS9zJOHIMoYO2zfRY8SytMUFq/DW8TsyHiUVAk4hfcNFkyWvcaQmf6nIbXxcVDx7dvfoQ/DQYWpGC5deRfgvwzLlXxWR8tTyHVwg0N8jcgacsE0sLrJL6sxFkodqrsn0kfwjDGTWyJIVQHsbN9IHn6zVUEogUmONWIXLZqA7aWGblWzy7a6n8eAazqgEG30NftX9/FB0xiUVhC/Y5U1KVTvAlbS35pSZSE4MrnMfMuVcFag/WCLE0KqgLz7A6llLOre12D6D9oaBBlymhFHKc3SJoy2mJPTQ3DoneEWgjxKZ0XR2QiYrQ96DUPucH/+fBP3uRYVcuQgE/kWPxRqFpGueYleylDQ7MpD6GhUQjCz6nneR7F5a5iP+ybMFR6b3HIzRnvxfN618uSXkB4/jyK7i2GrtFxiR8eRmOK1+hWRdrmWFtK6cdTbb0tueYGt8zPCe3dcb0VICLC+BvmiOvSxZGh6Qft PIXr1F0H xbpr4ZPcTuid75g8JaWoepF7GS3liecKVVmd3b8lHZZtsYIbp5oKZMWtnPuyIcfkDhjQr9ogrZeBQpfkXPCrwvr7Hefuwy7He9/cbgsEOMpcFzrPzUvnT+lS3g7c6TIOnV9iXeo+dBMX/COI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.018375, 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 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. :/ > > Ratelimiting seems fairly reasonable to me. I do see the concern about > dropping some addresses though. Do you know how much could an admin rely on such addresses? How frequent would MCE generate normally in a sane system? > 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 default 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 concern to directly use pr_err_ratelimited(). Thanks, -- Peter Xu