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 C4D46ECE57A for ; Mon, 9 Sep 2024 12:36:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 481746B0169; Mon, 9 Sep 2024 08:36:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4316A6B016A; Mon, 9 Sep 2024 08:36:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F8C26B016B; Mon, 9 Sep 2024 08:36:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 109F26B0169 for ; Mon, 9 Sep 2024 08:36:00 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A7AEAC0174 for ; Mon, 9 Sep 2024 12:35:59 +0000 (UTC) X-FDA: 82545146838.19.B645CA2 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf17.hostedemail.com (Postfix) with ESMTP id 910FA40013 for ; Mon, 9 Sep 2024 12:35:57 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JaC4tHuE; spf=pass (imf17.hostedemail.com: domain of jannh@google.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=jannh@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=1725885330; 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=ItkNpbg3b1iQLTwUvcYvCzK1VuBRAi6YVDO131ItVjs=; b=1E0ZCNauRM26fQp6bNvp6e6gHI7EtDQaKWaF/1BjyMAXzgvJdLlN+k7ms5i9PNGHTUvvmz euCRQVRHJT90j0yBgfaCxhGHOKxe5MuSRngwsZmJ+j6M+tZAQndS4Bg3HuCTfeVqSrBa32 Wt6VCurMFskHV1iWFSr8qXe1sbz7F5g= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JaC4tHuE; spf=pass (imf17.hostedemail.com: domain of jannh@google.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725885330; a=rsa-sha256; cv=none; b=C1z2OtMj229hkrESLeRoNrrdogxlNQCZWX71+NuI44kKIZXbRBkqOlsMnHDCashnoDF/0g UpGt/I11OU6KQBaLalX0dHKpTBRMN8uzQ9Oy7wxKkrCKYQQ4SeWPU/sYQCE18Ax4HvtPgz RRfDtv8odVR3Y1ScgvkMEPCRTg0I35o= Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-5356a2460ceso8232e87.0 for ; Mon, 09 Sep 2024 05:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1725885356; x=1726490156; 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=ItkNpbg3b1iQLTwUvcYvCzK1VuBRAi6YVDO131ItVjs=; b=JaC4tHuEPZqoGxaYKp5Rqro+tdS5ASJ1VWBe9KxmHNiuT9LIbajHxdFtJ83aQoc0pN 5rEAfeoW0J0A6WWWhxFT2pONxHiMe6oQeaF73qNLbU54D2UZwasx6q3svGo5XA4+MOjU LLRQJ6sVOFagzZel8Osnx6ifOom0C9QqEdqBaQ8ceq7KiVoR0PUmmDyb7yNLPMtOE0c1 CmjayYGVGUMJABoHvEBzjQUUWoY4lueOQdrbhUjtKTxURUmuTWmefq0IyAExjTiL4w// mQp5hf+38dYEbVslYyAUOgE7ck13zYQ24ENUR/KmNFE0HfNnL+rREqkI43Ygv3AavRke jHqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725885356; x=1726490156; 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=ItkNpbg3b1iQLTwUvcYvCzK1VuBRAi6YVDO131ItVjs=; b=PQBDWtHbN+nKP+R0ZxJ4D7SAYKdmKHelbPLG/3GqgloBO5DSdYJOExoAqOv2dB4BuG kTG/7csNBSrN4Ui+L7E7WRIqaeOLbXw8hwx9kkFkwmeK/gAEqdbXkaVg3TOupWCGM2sO QKG81Hi4fnV51dJa24i6svxsLTFC963OF7DkCtu8DvpA0bqLFakZz3UPIkxQyQWcBBf+ Jypn0qxFGhAjTFZDJFHT1npvD7BllFvu4NB6mXVhJj9H5mChcif0u1N4spiz/c5qWNPq O/kr7Mm80z747IiO/DCoqDXcPH37Ca8vGeCfBR67gRiVAqzOf//fxAeyzpZuyDSqDEpQ stGA== X-Forwarded-Encrypted: i=1; AJvYcCVkDS+KdCktgyYRFQ9MT4CUtYI2i27SjgrTeE+CtjCC7Tp/YkZPusIBbdJYT4IF4oPw+XEBOSonvg==@kvack.org X-Gm-Message-State: AOJu0Yw/BjI9ZRzoHSB/mbvt6tJPAqSlrJeJgbpAwUtgjTgifJDI70dJ vIkjhdc4xuCHoir5PBpezyySVAFMVWbS0E03n1i5qj/Hme2tUwCcweK4egYD3CSoejl3JGMxpKz g/1MWuCT13vc28OehyUkoLSkiHYsXFk/EcAvJ X-Google-Smtp-Source: AGHT+IGGsTOsKMOzuVujWW/9F9gatm28KzGs7KuJZ0r/H8oFsyXYru+A8pCPf172NNXYDzQoEw6rG6CU7Y501Yf4VYs= X-Received: by 2002:a05:6512:23aa:b0:536:52dc:291f with SMTP id 2adb3069b0e04-5365eb6a2f4mr188381e87.1.1725885354776; Mon, 09 Sep 2024 05:35:54 -0700 (PDT) MIME-Version: 1.0 References: <20240906051205.530219-1-andrii@kernel.org> <20240906051205.530219-2-andrii@kernel.org> In-Reply-To: <20240906051205.530219-2-andrii@kernel.org> From: Jann Horn Date: Mon, 9 Sep 2024 14:35:17 +0200 Message-ID: Subject: Re: [PATCH 1/2] mm: introduce mmap_lock_speculation_{start|end} To: Andrii Nakryiko Cc: 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, willy@infradead.org, surenb@google.com, akpm@linux-foundation.org, linux-mm@kvack.org, mjguzik@gmail.com, brauner@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: f6e5juwee5igrwq8a8fm7rafgjxgujf4 X-Rspamd-Queue-Id: 910FA40013 X-Rspamd-Server: rspam11 X-HE-Tag: 1725885357-879039 X-HE-Meta: U2FsdGVkX18WrtiYBni+lmauVf9LFVd+LRWeRvgqdKlH6jgI31TDbQ82O9Heb2vJMdcmwUKf7ryBjk7bAygANa5J+WDAwiqxWQYqTgKiNstFyXWUj36AbSqEHynGLC3UjiKrYoB9i6lpXsKNxR8tPaC6y+tMDvWJncXjWdBJe/8daqXvznzcPWJuzNbOfBPU1d98RNH+4OlEQEuoCS4CIho7tvs8uCzeKy4DxDnJBPBQST0xK96odabBNoPhn9rtFmhb4j/qD7LGe1WtXdM3JSzi0aXB9JnO0R5216y967nHr4RiW9cz5mQs3ZuTSG7saaysRjOiiQgiO6/7x33pwApESi0cRvgWKiYXSq1o9mV76k3qtoQ2AnU4PNV+FtefCqSQ1FGTFNmWca75wcDK7RJlstq5CgH/GabSdAYAB8yWqBRI2yzSelyMVvjNumlQVrk0bJjXAQPh6aVzXpNmsOCAlRtlY4TIeacuIXjhld0gNEcUZ/fJ+wwncjRFx3qGfDpOGhGlAvBVk+kGxZ2fCCWPLJ2hQvah8tmo3TOg3gIRGXfpasUIrHE3Hci+SIs1VbsaLIN+78XQMAh+BIikJrgHgj1EtWDlTCP9JGjtYUtb9kfpTR9fM1/SIMVnIv+5bWhDxt7Q12p1KkIMN2FrfVxq1gwEJz97GDF27aafGiPpuT70D4lW+/1nLBY/PX1qqMFoxp+pQZvGBK9Git6HBIXQu1HpXUs+cc6HEIRFI+IgziJQsNdwum0xf1e/Vom+0EmZ9Z5xiXyt2EzjBIsfJmKQ7ayNgIWejGjMtj53xo7syl8gQae8Y1JnDolT0xU3gwAI3iONfCOCt/g0ERkxhBHpvkHmqCruV46jb1PGYpHCpgMQge5GH5rys/VYelNTm6cR1JZ7EtdbQMocRZddXceIPz7XEuZ7/oU9vaQPG971b0JI44AblPDXhpeH1wGd20snIFgZucZmgbXbWwn 6/EN3k+Z 114eCv1l22757+3z8+sdJ/83NNeBFdU+QdVqeabe5yQ9yCP/g/ufvZKGpJHqoyV0HKNP2aavc/uiqjfa6fn4y4RmQHYGibEwvedqp6H00uyS5MRRuJfM1clV9AuyQ+vQ22x6VSIj7fNTGmSxJk8AC5GVBQmBepXT+JBDTxPIgWg2eDqJcbzwTWIoLrJ3FQTTnIETrKniv3mh6nOQV1d1KTi1Es1n6LAuZJW5v6N1dC+OFksafiTZxSWxXaEcT6Ck0eIBQA6m9V2k4Xr4wQCAkh9I1Jg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000370, 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 Fri, Sep 6, 2024 at 7:12=E2=80=AFAM Andrii Nakryiko = wrote: > +static inline bool mmap_lock_speculation_end(struct mm_struct *mm, int s= eq) > +{ > + /* Pairs with RELEASE semantics in inc_mm_lock_seq(). */ > + return seq =3D=3D smp_load_acquire(&mm->mm_lock_seq); > +} A load-acquire can't provide "end of locked section" semantics - a load-acquire is a one-way barrier, you can basically use it for "acquire lock" semantics but not for "release lock" semantics, because the CPU will prevent reordering the load with *later* loads but not with *earlier* loads. So if you do: mmap_lock_speculation_start() [locked reads go here] mmap_lock_speculation_end() then the CPU is allowed to reorder your instructions like this: mmap_lock_speculation_start() mmap_lock_speculation_end() [locked reads go here] so the lock is broken. > static inline void mmap_write_lock(struct mm_struct *mm) > { > __mmap_lock_trace_start_locking(mm, true); > down_write(&mm->mmap_lock); > + inc_mm_lock_seq(mm); > __mmap_lock_trace_acquire_returned(mm, true, true); > } Similarly, inc_mm_lock_seq(), which does a store-release, can only provide "release lock" semantics, not "take lock" semantics, because the CPU can reorder it with later stores; for example, this code: inc_mm_lock_seq() [locked stuff goes here] inc_mm_lock_seq() can be reordered into this: [locked stuff goes here] inc_mm_lock_seq() inc_mm_lock_seq() so the lock is broken. For "taking a lock" with a memory store, or "dropping a lock" with a memory load, you need heavier memory barriers, see Documentation/memory-barriers.txt.