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 9CC73EDE99D for ; Tue, 10 Sep 2024 15:32:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 040848D0084; Tue, 10 Sep 2024 11:32:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F322C8D0002; Tue, 10 Sep 2024 11:31:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DFB988D0084; Tue, 10 Sep 2024 11:31:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id C26408D0002 for ; Tue, 10 Sep 2024 11:31:59 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6E70C1205CB for ; Tue, 10 Sep 2024 15:31:59 +0000 (UTC) X-FDA: 82549219158.20.0D268D8 Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) by imf09.hostedemail.com (Postfix) with ESMTP id 7F0AC14001B for ; Tue, 10 Sep 2024 15:31:57 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wrTjZw0n; spf=pass (imf09.hostedemail.com: domain of jannh@google.com designates 209.85.167.45 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=1725982214; 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=11EJWGDdB3TRpoNJTX71d90zkEuZ3hMNes9yKkfvSyM=; b=onXbole18V+5xc1kNBIrUEvDh4UfbMsGcXfOn4J13xe2zwMBXlcWO19enOR7GL4HQ/WuI1 HJk8KwFmwBi25+syiqk22MvPhWCpTUlGfDq4KJEzBNoYhTgsP1FuTk+yGaMusu4nIzdFnZ 6jxwa4qxR0mWxFGOmxIJWXz0mKyeKnY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725982214; a=rsa-sha256; cv=none; b=INuw+XdRqU7W/TAcSnKDWfEJGKqWPFtakomJXNBswqwpGwLulck8faI86F21Se5PC8f+n0 9QxffREgSb/ed5Sr3/fEWb0RMw4o/9lqfzgiuFWKcaIayUrqsToxjDacV07iYYdS4ET99i 753iLIkM91cKWMRvBRRPuwCtL6lBe30= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wrTjZw0n; spf=pass (imf09.hostedemail.com: domain of jannh@google.com designates 209.85.167.45 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-lf1-f45.google.com with SMTP id 2adb3069b0e04-53661d95508so25803e87.1 for ; Tue, 10 Sep 2024 08:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1725982315; x=1726587115; 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=11EJWGDdB3TRpoNJTX71d90zkEuZ3hMNes9yKkfvSyM=; b=wrTjZw0nBbxcg4RE8eAY+YmJ+EX2r/qyMVCxQXfWRFIktdZKNH+w/ptVxiiMURWWxM AD/a4Tuax7A24a8CVb4G+bxtuexWUackw3uMm8M4F9fxkcluoloKOd9fPUxhfY+qb/Zw qFzI6iPbqg9D8ldyv+GnayX1WLPaJl7RUdcX/M6rAW09leOm06wU/y/VJkAqSrtFuAWL ZjZOmQQeAisg6NQ3QhCp1FDDmU6cTbhqc3P17CJ9W1PC/D04yFQPKen9PfXtlXbcBYOv fa8aB/Wt9/C7Ij5M3QP9PNDgPhJ44ev0K9tgOSXnjRwFVjkPlGb/vcGNFe79sPQz6v2u g0Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725982315; x=1726587115; 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=11EJWGDdB3TRpoNJTX71d90zkEuZ3hMNes9yKkfvSyM=; b=F7QOxYhcYuFdy3kmPDujqQ8vlf0GLH/lbsFi/sx01Fye10ecZRSBI8VV2Mp6bZZRU1 +5O+NyRavbH7b+3oWGIyIdhoT0ESH7K+kL+RD77TQvpVivf62CJBy1xcgeOPa799z3Bi wSRFTAlmZBxGAIIdzD0fyHMeJ6C7IPlI3daAnlykfHPt5TVTY4MlWSW872vkP43CcGww hPPAY1QCJwWx3KJXwU4TrAcA8HDwoN/nHecivtaXXEpojDPZZeoZ3LA9nP8g4ephigwD 5AZHs1tDqKYbdgX328q9Y2QhJ0AVnIwxq2R5AoFVe0jD1P5HQVTEFE7hqeXk+3hcN4PS +vQQ== X-Forwarded-Encrypted: i=1; AJvYcCVjALWDT0M+AsKAXyEoaTpJx49Zs/U5wPpYFOFc2QeXR0yPVFbehPeGc8etehEhl+EQq9QIavB0Hg==@kvack.org X-Gm-Message-State: AOJu0YwTN49hTNkoOuBhe4Y50BWbxKZnrSvI0nHqh/z6fc9dA8kNSqxV PgXSYcNAP+1o/lZk+IVitQ5raYTTcmnmjhqNQHCudkzNHO89Aoj/WjVMDj8FxMLphoeVCvAqODF RSgZr84/OXJd90rbJ2pnLODrWXTjEihWl6uo9 X-Google-Smtp-Source: AGHT+IF7llpzPIrM5lV//xsMPBS037RtCLtLhRWp5fDTFuzae3HG0GApRNkf/Tgi/uVU1gb2WlLVcCtp5hQEeg5tgCQ= X-Received: by 2002:a05:6512:1154:b0:52c:dd42:cf57 with SMTP id 2adb3069b0e04-5366ca457ebmr607822e87.0.1725982315020; Tue, 10 Sep 2024 08:31:55 -0700 (PDT) MIME-Version: 1.0 References: <20240906051205.530219-1-andrii@kernel.org> <20240906051205.530219-2-andrii@kernel.org> In-Reply-To: From: Jann Horn Date: Tue, 10 Sep 2024 17:31:16 +0200 Message-ID: Subject: Re: [PATCH 1/2] mm: introduce mmap_lock_speculation_{start|end} To: Suren Baghdasaryan Cc: Andrii Nakryiko , 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, 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-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7F0AC14001B X-Stat-Signature: mm4a8hp9orsy7pps3q3rnmge91os9wjn X-HE-Tag: 1725982317-614887 X-HE-Meta: U2FsdGVkX1/0fwAx5l+64AeVyUnfBc44ZfQ9EoDK7F2ZN95zHFk23ktvu8QxV0O52k+KMKjIyw5Hqes5upbsI54ZeAFKpmSxCb2qj5xiUhAZM4GHBL00pQHrtAGOOcYZpAdWaxF955f8Fu7eC7VCTuxmnx+hBWQT/Ruw8vhZH9l79QyxL50tf+Mtfs8GCPOWVcAKWl/Zgfwi/tLWwKoojYnAWTKj00UNYnarls61kfBWgfjRb0U69tQ/vhA3rptWnAfQAreL+NTTOkBBSFaFP7vjCXP1dx/nGP9996QobPcbOIuHYkv/F8j+f2wwKhorwqsPuo7E8Eum4xKF7b/xd9rFiFQtmAhDGiNKx29GxktNlxO508OrQR9nnOqzkbOw9fSSRCNeRiJKaM5AFXoWEelrv4laoql8bYcXmXPMKuWbshmtLM5bwrOb80ql4ZsnFQmjKuQ6XNdzLs4WN0bRB8XKXyy5Y26W1oAffYY1qmpjM1H8HxreCGXmuGDrCjD6ZRoABbnhjGz1odZDQk7FxcUS0rEzLF26MjnXS3q7q4t+vTT7t0b0bUFgR/gsWfhMZgmOM9B+jwcOENKqsRQca+8knl8ZcxLYANKfyax63dB3qQIKFbNsz8RyIAmPezm6sISopV4JIxdd9/ISHdptFPUd0M7IqEaFDgcX8kg5dUDMejBHFJOtEM3ydTY8hrN40z/5DWbwbcuJ6cGt1R8T4jj/PMVfHEfm61w4pBIZSPhd98g38V3grJB99u/3mVCic3y9ECkC+p6n6Qp8l6qhpzI6FQWN0hJqaQdu1+J1k8HxOc56XMpcLhtlR3QSRi9tTRxfZy7BbrK5BG49ViCsWfsb0Q8YhxZ1AL+YsaJn0tz0gpkAXNCq5NuYyldFMLjuPyp1ha1tguC7J8jSQHteB9/zKpg26RznfA/hbfA2DS6RMX5ZcBLxK7wWG0TwAO8kpj7bZZU2llZfU9UUQq8 /uwR4M9X s+8FqzOXaSyKG57nuJeLylUwVQkYyXSDY3eBbTAeNO6BSoBEuLxn1yjIEEzpSwqDwwe4cjQbpmDiU8Lm51D92SBa8XT4OcwbgFhA63QA75fSwKCFQNJuySva+UKA9YD/l//uZP0wt4oJpcMgOpaiHkHlvF7+rEenOec7GDpdVexJIl2tbAl8TLe/FCVQmXCgkNS8vWhyw8Gw04UDsM0cvbvLBM5yD0OMzaN5rs/6EiN6dcFwp0sNxxg/WLTd8+NoA7P9Kqpe9BxReGoORwRVbPP7AkZ/xGa8rFVER X-Bogosity: Ham, tests=bogofilter, spamicity=0.013630, 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 10, 2024 at 4:09=E2=80=AFAM Suren Baghdasaryan wrote: > On Mon, Sep 9, 2024 at 5:35=E2=80=AFAM Jann Horn wrote= : > > On Fri, Sep 6, 2024 at 7:12=E2=80=AFAM Andrii Nakryiko wrote: > > > 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. > > Ugh, yes. We do need smp_wmb() AFTER the inc_mm_lock_seq(). Whenever > we use inc_mm_lock_seq() for "take lock" semantics, it's preceded by a > down_write(&mm->mmap_lock) with implied ACQUIRE ordering. So I thought > we can use it but I realize now that this reordering is still > possible: > CPU1 CPU2 > mmap_write_lock() > down_write(&mm->mmap_lock); > vma->vm_file =3D ...; > > mmap_lock_speculation_start() // seq =3D mm->mm_lock_seq > > mmap_lock_speculation_end() // return (mm->mm_lock_seq =3D=3D seq) > > inc_mm_lock_seq(mm); > mmap_write_unlock() // inc_mm_lock_seq(m= m) > > Is that what you were describing? Yeah, that's the scenario I was thinking of (though I did not spend the time to look at the surroundings to see if there are other implied barriers that happen to stop this).