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 43AFDC001DF for ; Wed, 2 Aug 2023 18:09:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 54FBD2801D3; Wed, 2 Aug 2023 14:09:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4FF892801AA; Wed, 2 Aug 2023 14:09:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C73A2801D3; Wed, 2 Aug 2023 14:09:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 2C7A22801AA for ; Wed, 2 Aug 2023 14:09:53 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id ECF351A04A6 for ; Wed, 2 Aug 2023 18:09:52 +0000 (UTC) X-FDA: 81079953024.07.717521E Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf27.hostedemail.com (Postfix) with ESMTP id 342644000C for ; Wed, 2 Aug 2023 18:09:50 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=oRtOtKDj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690999791; 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=Iib+Xd2im+vZ2DqX3HEGdgepyyImF3VT4ZisE2yj1ys=; b=EuvEces3H8ysN9Vng9N0G6MNLv/nOFeXwdaX8C//uxxexe8Kx1umXWrgIEaGqmlxd+rk3z /vlvhe+hHjtm5YGfVRqpR/C7PeyPnF1DjzmMpJgv/uBJHt442fj/luMfHwAfJPDAYWNyjY 2If2GXgK1qy5j/yUw+6nlPxgiL/SOKs= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=oRtOtKDj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690999791; a=rsa-sha256; cv=none; b=TTDwxU7zNacDsZAiHgxAUz8oBEilEK+61G4Nx6qxYidtqGFyuxeCnKD986gDotjXfdL5Zv CSKCVwcUK2Q1CuxPltW784CCdEq+DbzQGFaTznKCLK5wLILwu2sn+sakd/0yFCvFItC5QW k4Nlz5y44OtXMqGOUXGYMMApMVdPGFQ= Received: by mail-yb1-f176.google.com with SMTP id 3f1490d57ef6-d35a9d7a5bdso93858276.0 for ; Wed, 02 Aug 2023 11:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690999790; x=1691604590; 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=Iib+Xd2im+vZ2DqX3HEGdgepyyImF3VT4ZisE2yj1ys=; b=oRtOtKDjkVBCb38qf+mS/3skawfAATDJfzXhOCYonPmwyEJ3aDUUHtY12ZPrkfSxrU QHKxlfUXoXekdHWtSbFd2kfposrCnzV6kIJtsRFB7HpejPYEfn5dXGzS679fnY6sz8ax Qcuy0veEvBzAAoNnZSIvAOb93CMlVa/DfdRVftzkvAJC7mCTgs6xKHPfHV9elwBsUuS0 oaF4pXYDYZoxVxgkM90NZMCuvK0Sv3/m/d5UIoAnXglUS9MNI6Z4cihQwLH3Ptz7uDbs jS4rqCLwdg8CA89xgDoFxv7IuGDC3Szd7oGret51d/nJFO60hJPIt1BHXTVRXybMODVQ d1XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690999790; x=1691604590; 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=Iib+Xd2im+vZ2DqX3HEGdgepyyImF3VT4ZisE2yj1ys=; b=SsT7divFIQ2QXddOWae5RAu15xiUKlbDh67f/tN0vp/8p6+2qSD8P+1VwxNew3SoCM LAvu0kVS4oAWfQTcny+FNjMp6sqge+k3zB4ov0GfQRD1yPhV2b2bBaBp8pV2y4VJTY/U yiGw83qrP1sSmJVu9lh3VoOt0rmMJjMk+IYfVRB26o0NSMbqGhqP4s053ajhWMey/T1p htyws1kb1DnfjChv0pC0mfoftUiwJkH307MsCDY3xfC4yjaXgYrPR3i15BGtzI843gCD 2kGibA7chYfXJ0/p+xdNRVDVaB90jAKXYjKd5ZUosqSplB5FBzvgsz1fOBL3PD21K5/R eRdQ== X-Gm-Message-State: AOJu0YyV4CxsTBmy9KZYJWbZpCcNMKuthD/+nnRJixi0upeKPH0w0XLG gaMiHqZcxQvNP5/GzQBRul73kpd9Md5zYrOJQZniGg== X-Google-Smtp-Source: AGHT+IEUC0dFG99W++f2WyMIi43qQ5eyHn34lPHwz5XXFxFSHJUXCaft8RZj3ShW9s9RbqGok9vSU7ZZRNdeAF3VH8g= X-Received: by 2002:a05:6902:100f:b0:d3c:e4aa:4985 with SMTP id w15-20020a056902100f00b00d3ce4aa4985mr2109823ybt.61.1690999790140; Wed, 02 Aug 2023 11:09:50 -0700 (PDT) MIME-Version: 1.0 References: <20230801220733.1987762-1-surenb@google.com> <20230801220733.1987762-5-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 2 Aug 2023 11:09:37 -0700 Message-ID: Subject: Re: [PATCH v2 4/6] mm: lock vma explicitly before doing vm_flags_reset and vm_flags_reset_once To: Linus Torvalds Cc: akpm@linux-foundation.org, jannh@google.com, willy@infradead.org, liam.howlett@oracle.com, david@redhat.com, peterx@redhat.com, ldufour@linux.ibm.com, vbabka@suse.cz, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, hannes@cmpxchg.org, dave@stgolabs.net, hughd@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 342644000C X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 4ij3nxsybddyikomsp4ygwi13n8wotie X-HE-Tag: 1690999790-605210 X-HE-Meta: U2FsdGVkX1+jnCDaDVIe4Z2RFgUqH/66monDEcfzKSpzVKqmI6YRukZkWaRYKwV1ybOr43RPmRqU2mOvpG+6DH5/jLIgIrniaAbky7cwbDe5J12CIHrZonsXDLNpSURuxeNf9Us6Q7hx383iF1mKAGGWKgHxZ5kszkeDvWkRfljxdx4e7RnC2FGb7wWEiGe/foWUoChMcX2jFudBJKlQElJB/RFD+Xd9+Xqs3DZnEtf/fiMpQM+BIBu518CjW1Tl1WI7UIi2+nzikQTBEJVI3N8SSF81YLEi4vmMbhsiqCcljfu7HysZBtvRJWD4uoSvQ9zygYDw8mFR9ZKTHykxnxEtrJREGommLkI1+oKKzvklZKK44eLpyvk+Q1/H7JBmPw0okaz+MVIc2t6Hb3b7PGuZ9GVTvEPkTzi1LTKei8IRw0j+/GLpWVaKpm7nK34Joa484EY/Idb/mcYcZITXtBBhzrvRET9DOduBwkPj6lh3QQKV9bbKHX4IU2TZ6rARB3zM9cUL0R8lc0FahBe1IHdS4k3nEOL2vyny5WQ7/mqWtQOvPcpyvtxvEaIJyFVeT4TIaQzaXlhzZF5TLhT3L47rrDLc+Tu1UM3VwnP0bniteEwNbOufFt+8ntnlZ8bUfsgLojfNS7lew/aIg/fusw9KJxS+s3ecu6hZhAA+/vj1TzxTgvWsYAzRwOB0enw5IemqtBeW9ubd3cdlfTWKvH4P1featQ4nYKOh153j5uKs3fvhUB7KGkPN1Gwgktt3qurJ97kRXj7sddzE5pYhkTGE3VCsbo+Es1vgjqyGgeyaJ8jVjWBtjGo7R8zgRHF4LWKcrFQwm4x9PSbsPKBsBmBI4OYthNpRCD9xXnBResrXvYtIn/thARYG0/l0cyzJHnsRfLxmuZVnWEKbF9NnUEgENQ7E3UK00Tue6IDFDqvZdcLYt2atxQA8zAyAAOHmTIpOp60NJuRFryb+Tqe Y8gSM2rz Ds/leA4kKx/BdUZKYbXvpLRc12s6MrSbjbeD5fv8mcbvMOyCQK4iU/RriN4mocc4nOlbZP5UFKmjaZqj3poG0nv51KnG/CZ8/lLlScC5jN+7DHkLp02FNWLKLJN+pnhm+obwHqc3HnZuiu5KSAyin3PdD7QyBdpIGIgo73fMMb/PZQK9qqstPl/zSDgWbt/nM8oLYF89Ptvfp4f6o1PSWv8sKI9PtIGB+k/sJ5p19RnNe1Ae2jgKhCprnw0KFmC7iySM0pAWJFM2bvnD72q/MXfWLMHqFs8CoT07Us+BmG0gA33yHLw2jzmjZbmHeTSQY0iTq1/7XKwWOTWRQW3c9KVuZx8AgQ4pox1TsBezfxmdWSzw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Aug 2, 2023 at 10:49=E2=80=AFAM Linus Torvalds wrote: > > On Tue, 1 Aug 2023 at 15:07, Suren Baghdasaryan wrote= : > > > > To make locking more visible, change these > > functions to assert that the vma write lock is taken and explicitly loc= k > > the vma beforehand. > > So I obviously think this is a good change, but the fact that it > touched driver files makes me go "we're still doing something wrong". > > I'm not super-happy with hfi1_file_mmap() doing something like > vma_start_write(), in that I *really* don't think drivers should ever > have to think about issues like this. > > And I think it's unnecessary. This is the mmap op in the > hfi1_file_ops, and I think that any actual mmap() code had _better_ > had locked the new vma before asking any driver to set things up (and > the assert would catch it if somebody didn't). > > I realize that it doesn't hurt in a technical sense, but I think > having drivers call these VM-internal subtle locking functions does > hurt in a maintenance sense, so we should make sure to not have it. Ok, IOW the vma would be already locked before mmap() is called... Just to confirm, you are suggesting to remove vma_start_write() call from hfi1_file_mmap() and let vm_flags_reset() generate an assertion if it's ever called with an unlocked vma, correct? > > Linus