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 5FB51CF9C6B for ; Tue, 24 Sep 2024 18:01:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E6AB26B00AD; Tue, 24 Sep 2024 14:01:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E1ADD6B00AE; Tue, 24 Sep 2024 14:01:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBB776B00AF; Tue, 24 Sep 2024 14:01:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A83806B00AD for ; Tue, 24 Sep 2024 14:01:15 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 5C178AB425 for ; Tue, 24 Sep 2024 18:01:15 +0000 (UTC) X-FDA: 82600398510.07.73DA690 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf26.hostedemail.com (Postfix) with ESMTP id 6E8ED140012 for ; Tue, 24 Sep 2024 18:01:12 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=vKnufJ+w; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of jannh@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727200740; 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=cjhiFYP9ZLzgH4eZvCkFY1gAOy9o8UQ0O08H+0Dp/FU=; b=pc2T9EawvaVvZ1bIfYtYIHi0kmvSEblPeGS9tHbEHKCdRYwflINdTwTGBMRtSGMEgRmDxf 8+VyxYxyaOU6CHZnXHu+E7MPjlBVefHH83sOiOm92LLUYxK/sbFoKTFHObGksDVCM2YtmH D98iSSoF3J2F/ht0IaO98F2vGXJqvx8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727200740; a=rsa-sha256; cv=none; b=2kyyIM9w0D++pQkdGDD2W6RUoPzf7LwKwXMz78/XZt2heURm2RL9abpObs06hM1tws9J4s w1eWbRACBpa8BXEW63q6yymBx1YHE6fY8axPWQyZ2spidP0XGTnXavftwDu28ba2wHk5ZC SOFxJgM7HUJs56LLO66Cl2RceGzMZ2I= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=vKnufJ+w; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of jannh@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=jannh@google.com Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-5c2460e885dso2387a12.0 for ; Tue, 24 Sep 2024 11:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1727200871; x=1727805671; 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=cjhiFYP9ZLzgH4eZvCkFY1gAOy9o8UQ0O08H+0Dp/FU=; b=vKnufJ+wOLdWyFwAKFeaIipA06XI/gsBd5NfKcUecBl5ejszhJeZ1TWg2KxXLJVW3b 8Ym3jpimCX3KyCREij5PVVsHZf+IMu+sc1dAqQsUy7MnvZsYAYlXUj4VRyl2jZr52Qrx OVJ8+khTqSdQs4Bu8gfPB16PpLsf/uOo0ZmZIKwOWupawBFkAJKivlvrAUBFIuJMewAQ QecYRKi01DcLlkSgtwS9PBIDeewbAjWoa45vkZk0djT1ullIp384TQJXHCRb69zLJK7C ZONjVvZi6URYjxskO2rHPZYwjxe7kCmesixJAADoatlyG9CcsE5EIuQNhr29L/35bQ4j BKXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727200871; x=1727805671; 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=cjhiFYP9ZLzgH4eZvCkFY1gAOy9o8UQ0O08H+0Dp/FU=; b=ZUMIj7yqbdf2rnhPLrB9E4BWjVy/2vuBlyDqyLoM1h1r5aYvU+J6X5XyKmPsPN0ahg /F0798+/J1U13dv0nq2Vk5zTfl+BmOVSOjAKNlyn4nlBwMiXHs8Lbf1NBf+TleAV4OQM +yCUFm/Zp7CItQSJOfl60W7zaSjtMST8DhqaS5lTyiKObuOY9zR7ljzvYXXBx5HFYgf0 BvZAi+wjF3OPUTb8DfQlotP+/2cvqOVLKyHhKhAxd13R6zRzDUwf6H1dsoidr4qDa/Td aGkD+MmjLBzmxTbk3pSIQeydemznzAPK28jzqyjU5vfE/h/LVVWa5BRrPZ9Vyyz0BgbJ r0+g== X-Forwarded-Encrypted: i=1; AJvYcCXUPLKPcMAqYXCzFXDM+G6VNyfcbV6PY5+ZzmPH9WsRLQHYSagFlHuKFbhATGIv7q7RgPGbdGASCg==@kvack.org X-Gm-Message-State: AOJu0Yy/cFEv/rc9h3VucRLnGt0/t3eS7l+C5kZcKQhvWkaxLc6YQSJq nObGj56+QEF0Zjd0EmkICdW5iHKSaTqeRTGk4qTgKDUmfPtwJTqr6ZdX9LSAWS57J/ffzr2ydG4 fX0J0qo6FQfViketSWzQ2BiNDmhkykO/3ik1p X-Google-Smtp-Source: AGHT+IGauZmcTAmbWAYK0JUSi5/BirlMPx1JVwLFWuHaMRUoRmepOtiQ7z74xNp5Rgwdm/FNTBH4pFL40akueNX7x10= X-Received: by 2002:a05:6402:26d3:b0:5c5:c5fb:d3f0 with SMTP id 4fb4d7f45d1cf-5c7209c91fcmr22261a12.4.1727200870366; Tue, 24 Sep 2024 11:01:10 -0700 (PDT) MIME-Version: 1.0 References: <20240912210222.186542-1-surenb@google.com> In-Reply-To: From: Jann Horn Date: Tue, 24 Sep 2024 20:00:32 +0200 Message-ID: Subject: Re: [PATCH v2 1/1] mm: introduce mmap_lock_speculation_{start|end} To: Matthew Wilcox Cc: Suren Baghdasaryan , linux-trace-kernel@vger.kernel.org, peterz@infradead.org, oleg@redhat.com, rostedt@goodmis.org, mhiramat@kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, jolsa@kernel.org, paulmck@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, mjguzik@gmail.com, brauner@kernel.org, andrii@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 6E8ED140012 X-Stat-Signature: z9gae35z3c7ozz4q4dmzdaghqxm4n4r1 X-Rspam-User: X-HE-Tag: 1727200872-861091 X-HE-Meta: U2FsdGVkX1/0LHXXXPKUnnGX/KyeKuFyelRPG2e/QePLz1oWHhi38v0cCtOALEu0h8/ZsUkqxuq4QWJPRq1ucDZPVFnDEZpAi8S4npALrU89xH6dGl2iWyniQ66zPA5mezCVAdGWdceTDuZFZb5xE2XiCFnLFtGJHGnTiR0mwgTTcbFlv5DaKFDWHibmSu01ESUsPIy+DMVdTuk0uaM5xWywvv03rGT4VmDaB9A8uhB8004Je16YG/JAoDWZFC3xrd2avFa1akScHuxpIFjwsfjiI39UN7UB/Ny6oYgp8E3HB+H7kLcKqGJJWUZXzHHcGQWdLZec/7mVc46/1rj/g7G6IqR0bZkPyEB2Bj8DRmu8+vL2203EtpIfi4RSfVcLv7bwpS8OtF+F7MhHrZza29oeNXdeHkjjvU9+BdSBpBsCGbCs1hf5URGAgM8ydzHNCEbZYjkT0rR1pDD9/ekqUj9J2Kybq0fsQTtZdbhCT/ZZZPATBHh6om+0+xI79dZDkhHvgdsHfCp6m+l9GrmoS8KZ/tyGwSnuzOA6debOkBZ2KJ1yqunslsAwgNof2AEvAWrEIA/Ok8UM4DLNJnvrngiPVdRZlvJ17MLX7ZmmpSu02olN7QAp0kTSBwFQfu0cwzZX0MM1Ar7QhBO01CFwKFFZkgZo5An34x5KCoVxq3WK3pvLIbAuobKHv2+qfJ0FxBaRBkKyNc7Et0A6dykqCDzShNxCrBZrMFVpNKkcApZFVVT0zpl6Q72ww40K9v1WXtLW8jNiwbkQkbWYn+a0YBlXYnTLWKg1Tgn5UXQ4zkAhgljoQARxvuoZLQ1isypaadfTm/8U5RwKuctjHyeMFoUPIGoswrP4nFA6JYHucmQxSVjWbDEIRDxTqTKs85itlW5N/VsYlPLjiEUqZbITiVJk5Sf31xzDvkV+xLimbbtpOBJvtE8i1YCJHOYnDvPlkWNfR7m4IAQl7ADkW08 sPCSokra tD7UjqPq/H5dZdl/N395IOOTEMJ2/HA8sLT3+jmw5eNssjA5A3SRdRJ9ZicyEwFlyNeh0gJ1KKVHvgnRTFF82Y+5qsU3K+dqCGiqN/3JhQ9n1Q1slYBHe7f12qEJcHQdQv1c4PpL/M0lxSzfryotlSrYNx6VljNfQg0CwG4UEZ5csrZHi5A2SStUT5rvj8Yzhkp9IipzXM8mfBXKxj13o5voz9jDW5nSKe4Tq2XKr9PMxI2MUmSyahe5gx+hWn4JiWTltQ6nC1f9AKby8GVP4RJUf8HsdinNKbH3GpBgQLU2hLWxZXPIP2dmzFLXyz08esscqv5f9rF7FawM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000032, 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, Sep 24, 2024 at 7:15=E2=80=AFPM Matthew Wilcox wrote: > On Fri, Sep 13, 2024 at 12:52:39AM +0200, Jann Horn wrote: > > FWIW, I would still feel happier if this was a 64-bit number, though I > > guess at least with uprobes the attack surface is not that large even > > if you can wrap that counter... 2^31 counter increments are not all > > that much, especially if someone introduces a kernel path in the > > future that lets you repeatedly take the mmap_lock for writing within > > a single syscall without doing much work, or maybe on some machine > > where syscalls are really fast. I really don't like hinging memory > > safety on how fast or slow some piece of code can run, unless we can > > make strong arguments about it based on how many memory writes a CPU > > core is capable of doing per second or stuff like that. > > You could repeatedly call munmap(1, 0) which will take the > mmap_write_lock, do no work and call mmap_write_unlock(). We could > fix that by moving the start/len validation outside the > mmap_write_lock(), but it won't increase the path length by much. > How many syscalls can we do per second? > https://blogs.oracle.com/linux/post/syscall-latency suggests 217ns per > syscall, so we'll be close to 4.6m syscalls/second or 466 seconds (7 > minutes, 46 seconds). Yeah, that seems like a pretty reasonable guess. One method that may or may not be faster would be to use an io-uring worker to dispatch a bunch of IORING_OP_MADVISE operations - that would save on syscall entry overhead but in exchange you'd have to worry about feeding a constant stream of work into the worker thread in a cache-efficient way, maybe by having one CPU constantly switch back and forth between a userspace thread and a uring worker or something like that.