Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Liam Howlett <liam.howlett@oracle.com>
To:     Luigi Rizzo <lrizzo@google.com>
CC:     Jason Gunthorpe <jgg@ziepe.ca>, Jann Horn <jannh@google.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        David Rientjes <rientjes@google.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH] Add mmap_assert_locked() annotations to find_vma*()
Thread-Topic: [PATCH] Add mmap_assert_locked() annotations to find_vma*()
Thread-Index: AQHXhjmoYtMFsOr1JUGtL1OdK4dvaath9waAgABfMgCAABX5gA==
Date:   Tue, 3 Aug 2021 23:07:35 +0000
Message-ID: <20210803230725.ao3i2emejyyor36n@revolver>
References: <20210731175341.3458608-1-lrizzo@google.com>
 <20210803160803.GG543798@ziepe.ca>
 <CAMOZA0JKjRFUHbs3zc4kiGcuXxR0arCN=oPZZsLCa4qHvRrH_A@mail.gmail.com>
In-Reply-To: <CAMOZA0JKjRFUHbs3zc4kiGcuXxR0arCN=oPZZsLCa4qHvRrH_A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?b21dhzAaoxikQTxOcxO1snKbFJIo9LHRnHz1Zq0PZCZhi8pUpWLn4uVvFC2i?=
 =?us-ascii?Q?e8JIEPfVQlGY0zHHgsTYO1ntnlcdROY0Spkqt0+FKXF9V0IyvEf3Ex+GaGR4?=
 =?us-ascii?Q?Ctxeu5HIio54Z5pYIuNk188FOHJThdz4elRqVQWhfm+qjxcuWUO/jImH9Kky?=
 =?us-ascii?Q?qTd3v3XSq0MNOAaJkswTiOeUCMvr7f5bRtJonLiK3EeCoVA6+EVW6HLKvLVT?=
 =?us-ascii?Q?/iZupAQUtRYpyDLhF66sDAIBzvQsbUi9rddkY/8c2RouhdqmbL63uhIIOssu?=
 =?us-ascii?Q?nOPMh9fg2kax6kkcyJo4r+IrhIk2lOwwVv1WB5gpl8OnF/v9gjvjdt0oM5qf?=
 =?us-ascii?Q?R/UnivdrrHfMtZUTCYsAZ7zeoonfbtxtqVeN6LBOhVANnGyKLggAzbB6zbI1?=
 =?us-ascii?Q?K3yh1E025DE3jjtpOuTpyYG5vgIRJ3HZUhqzgUJpeSU3t67GJHEVcq6y4jhu?=
 =?us-ascii?Q?CxT3SPycAjlHkzjri62fr/3FBf50ye7m+uc9tXcq5KglEJy1LZDQQNzSfeeq?=
 =?us-ascii?Q?ntG1Gfvz4aAUuIJfUieO5FI+Ooq2TNN7yxpcsNTb8IKpW47Ixx5pWwwAHozk?=
 =?us-ascii?Q?8hrST7AZVit8e2HrfSV1IqhlXJGU3u/VMCWwRMRRcQTaSstu5DpKtg+aElQ4?=
 =?us-ascii?Q?P53TM458SaVtYY5KG29TYVQ+/S98FRl22A+DhaO9BQBejZD2Rw0VnuSE6azZ?=
 =?us-ascii?Q?IZDy9O5OBr2LRxCGEyRM92SuvUlzcAAhUW6I1Y6SjIxwrv+wBv2K7OYq9UzI?=
 =?us-ascii?Q?Qki3k7Qeek9aWKvYSLi3w6FPKgRA7u7bMsh8b85oBHrFhXFFn/ncILMMngld?=
 =?us-ascii?Q?94cJP8VQ+eympI9CvMuYzKgUTTJJ+91kKkWmLLwXfRlIWWQEAuw2WWxE9s+G?=
 =?us-ascii?Q?H/kaqqEM5QtvQM70gULuca33z2DmKAA8DLYHQCO9S4zcsHr0zRQYexKKt7Vn?=
 =?us-ascii?Q?ha+I2yMSFCeti/YgNpN/7Ov26ZTHaVat/9Fd9d+1zO2ptaOclM/0Kv+CwkxM?=
 =?us-ascii?Q?xkm14vjM/qAKt1V+/lDI1MPeSraBlM05rdwX2oTfpbndwPTFavay1Qv20kS4?=
 =?us-ascii?Q?T0xHlbKXU/wl310GWM5qPecvH+7yoi3CbAl6571/4zk9/AMO+pQGaUeUlbh9?=
 =?us-ascii?Q?r/1io2hFF3apLCV8HqmpxHeMi5nRn70gf3mpDAjY5VQPlFoeKTVm3oGF9Azl?=
 =?us-ascii?Q?Olj0xq+4zm+fapnpP+sPpsoWks3k5/V25W6j1vclfXYGc8ufxepGCJfmcXym?=
 =?us-ascii?Q?KqcmJ97khNrc8yRnEInpOTkOORLMZVSxeg3uT6Olc1MvkIV+obK2t6+YwupB?=
 =?us-ascii?Q?Fsh+MCLAVDlDE1t78FFU5mh/?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6854C3F2EE3E964893C07773B288AAA7@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR10MB4380.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a9e42df-f804-4faf-3b0d-08d956d37b19
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2021 23:07:35.1660
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6OT0lu29nRGa5OB3+9m/aGk4iqHmaTZXPesMmAJn4PveGq2Pinw806SPT/XnUT4W/npn6+nnmnLMQ1CX1K/DLw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB4380
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=10065 signatures=668682
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 malwarescore=0
 bulkscore=0 spamscore=0 adultscore=0 mlxlogscore=949 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000
 definitions=main-2108030141
X-Proofpoint-GUID: ujAFy6N0ysZ19ONkiz2vJxA1ibAg4hbx
X-Proofpoint-ORIG-GUID: ujAFy6N0ysZ19ONkiz2vJxA1ibAg4hbx
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

* Luigi Rizzo <lrizzo@google.com> [210803 17:49]:
> On Tue, Aug 3, 2021 at 6:08 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > On Sat, Jul 31, 2021 at 10:53:41AM -0700, Luigi Rizzo wrote:
> > > find_vma() and variants need protection when used.
> > > This patch adds mmap_assert_lock() calls in the functions.
> > >
> > > To make sure the invariant is satisfied, we also need to add a
> > > mmap_read_loc() around the get_user_pages_remote() call in
> > > get_arg_page(). The lock is not strictly necessary because the mm
> > > has been newly created, but the extra cost is limited because
> > > the same mutex was also acquired shortly before in __bprm_mm_init(),
> > > so it is hot and uncontended.
> > >
> > > Signed-off-by: Luigi Rizzo <lrizzo@google.com>
> > >  fs/exec.c | 2 ++
> > >  mm/mmap.c | 2 ++
> > >  2 files changed, 4 insertions(+)
> > >
> > > diff --git a/fs/exec.c b/fs/exec.c
> > > index 38f63451b928..ac7603e985b4 100644
> > > +++ b/fs/exec.c
> > > @@ -217,8 +217,10 @@ static struct page *get_arg_page(struct linux_bi=
nprm *bprm, unsigned long pos,
> > >        * We are doing an exec().  'current' is the process
> > >        * doing the exec and bprm->mm is the new process's mm.
> > >        */
> > > +     mmap_read_lock(bprm->mm);
> > >       ret =3D get_user_pages_remote(bprm->mm, pos, 1, gup_flags,
> > >                       &page, NULL, NULL);
> > > +     mmap_read_unlock(bprm->mm);
> > >       if (ret <=3D 0)
> > >               return NULL;
> >
> > Wasn't Jann Horn working on something like this too?
> >
> > https://lore.kernel.org/linux-mm/20201016225713.1971256-1-jannh@google.=
com/
> >
> > IIRC it was very tricky here, are you sure it is OK to obtain this lock
> > here?
>=20
> I cannot comment on Jann's patch series but no other thread knows
> about this mm at this point in the code so the lock is definitely
> safe to acquire (shortly before there was also a write lock acquired
> on the same mm, in the same conditions).

If there is no other code that knows about this mm, then does one need
the lock at all?  Is this just to satisfy the new check you added?

If you want to make this change, I would suggest writing it in a way to
ensure the call to expand_downwards() in the same function also holds
the lock.  I believe this is technically required as well?  What do you
think?

Thanks,
Liam

>=20
> cheers
> luigi
>=20
> >
> > I would much rather see Jann's complete solution be merged then
> > hacking at the exec problem on the side..
> >
> > Jason
> =