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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DC8BFC38147 for ; Wed, 18 Jan 2023 13:10:27 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4NxmMk1z21z3fFl for ; Thu, 19 Jan 2023 00:10:26 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=aculab.com (client-ip=185.58.85.151; helo=eu-smtp-delivery-151.mimecast.com; envelope-from=david.laight@aculab.com; receiver=) Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4NxmM344WMz2yZd for ; Thu, 19 Jan 2023 00:09:50 +1100 (AEDT) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-196-D91O4sklP1ukofntLRLNnQ-1; Wed, 18 Jan 2023 13:09:43 +0000 X-MC-Unique: D91O4sklP1ukofntLRLNnQ-1 Received: from AcuMS.Aculab.com (10.202.163.6) by AcuMS.aculab.com (10.202.163.6) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Wed, 18 Jan 2023 13:09:39 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.044; Wed, 18 Jan 2023 13:09:39 +0000 From: David Laight To: 'Michal Hocko' , Jann Horn Subject: RE: [PATCH 12/41] mm: add per-VMA lock and helper functions to control it Thread-Topic: [PATCH 12/41] mm: add per-VMA lock and helper functions to control it Thread-Index: AQHZKzh830K0jWE0Ukmpq6Ok7Uauu66kJWqQ Date: Wed, 18 Jan 2023 13:09:39 +0000 Message-ID: <45d1809ae1cf4fb1a4bcaf30590a46f2@AcuMS.aculab.com> References: <20230109205336.3665937-1-surenb@google.com> <20230109205336.3665937-13-surenb@google.com> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "michel@lespinasse.org" , "joelaf@google.com" , "songliubraving@fb.com" , "leewalsh@google.com" , "david@redhat.com" , "peterz@infradead.org" , "bigeasy@linutronix.de" , "peterx@redhat.com" , "dhowells@redhat.com" , "linux-mm@kvack.org" , "edumazet@google.com" , "jglisse@google.com" , "punit.agrawal@bytedance.com" , Will Deacon , "arjunroy@google.com" , "dave@stgolabs.net" , "paulmck@kernel.org" , "x86@kernel.org" , "hughd@google.com" , "willy@infradead.org" , "gurua@google.com" , "laurent.dufour@fr.ibm.com" , Ingo Molnar , "vbabka@suse.cz" , "rientjes@google.com" , "axelrasmussen@google.com" , "kernel-team@android.com" , "soheil@google.com" , "minchan@google.com" , "liam.howlett@oracle.com" , "shakeelb@google.com" , "luto@kernel.org" , "gthelen@google.com" , "ldufour@linux.ibm.com" , Suren Baghdasaryan , "linux-arm-kernel@lists.infradead.org" , "posk@google.com" , "lstoakes@gmail.com" , "peterjung1337@gmail.com" , "mgorman@techsingularity.net" , "kent.overstreet@linux.dev" , "hughlynch@google.com" , "linux-kernel@vger.kernel.org" , "hannes@ cm pxchg.org" , "akpm@linux-foundation.org" , "tatashin@google.com" , "linuxppc-dev@lists.ozlabs.org" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" ... > > One thing that might be gnarly here is that I think you might not be > > allowed to use up_read() to fully release ownership of an object - > > from what I remember, I think that up_read() (unlike something like > > spin_unlock()) can access the lock object after it's already been > > acquired by someone else. >=20 > Yes, I think you are right. From a look into the code it seems that > the UAF is quite unlikely as there is a ton of work to be done between > vma_write_lock used to prepare vma for removal and actual removal. > That doesn't make it less of a problem though. All it takes is a hardware interrupt.... Especially if the softint code can also run. =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)