Received-SPF: pass (google.com: domain of linux-kernel+bounces-43912-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Mon, 29 Jan 2024 22:46:27 -0500
From: "Liam R. Howlett" <Liam.Howlett@Oracle.com>
To: Lokesh Gidra <lokeshgidra@google.com>
Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        selinux@vger.kernel.org, surenb@google.com, kernel-team@android.com,
        aarcange@redhat.com, peterx@redhat.com, david@redhat.com,
        axelrasmussen@google.com, bgeffon@google.com, willy@infradead.org,
        jannh@google.com, kaleshsingh@google.com, ngeoffray@google.com,
        timmurray@google.com, rppt@kernel.org
Subject: Re: [PATCH v2 2/3] userfaultfd: protect mmap_changing with rw_sem in
 userfaulfd_ctx
Message-ID: <20240130034627.4aupq27mksswisqg@revolver>
Mail-Followup-To: "Liam R. Howlett" <Liam.Howlett@Oracle.com>,
	Lokesh Gidra <lokeshgidra@google.com>, akpm@linux-foundation.org,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, selinux@vger.kernel.org,
	surenb@google.com, kernel-team@android.com, aarcange@redhat.com,
	peterx@redhat.com, david@redhat.com, axelrasmussen@google.com,
	bgeffon@google.com, willy@infradead.org, jannh@google.com,
	kaleshsingh@google.com, ngeoffray@google.com, timmurray@google.com,
	rppt@kernel.org
References: <20240129193512.123145-1-lokeshgidra@google.com>
 <20240129193512.123145-3-lokeshgidra@google.com>
 <20240129210014.troxejbr3mzorcvx@revolver>
 <CA+EESO6XiPfbUBgU3FukGvi_NG5XpAQxWKu7vg534t=rtWmGXg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <CA+EESO6XiPfbUBgU3FukGvi_NG5XpAQxWKu7vg534t=rtWmGXg@mail.gmail.com>
User-Agent: NeoMutt/20220429
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?TWZBTjZlaTlXd0N2M2VrS1NPRG5DZytwcnprMTZxdDNCWWY1dzZReVNNYnk0?=
 =?utf-8?B?UlQ5U3hnN1pLV1BSVlhJQm5BVmdEKzE1S1lpYlp1UDllaTExRXZaUkdEV1ls?=
 =?utf-8?B?TjdtSUpKUVpwblJJM0tyQzNDRUVJekJoZ3h6STU4NFRQaXQxZEdwNWpIT3VQ?=
 =?utf-8?B?R3JvRXh5S0U5RkRzTEtnTHFCc3JvNm9naGhxN0hQcE5hQWwxNE5kVC9mbzRV?=
 =?utf-8?B?ZU1SaXdCK3R6WGNTZ1FmbXhiRzU3aUEyQWZlR0thZ3FpdWdvd21kekVFYkFC?=
 =?utf-8?B?Q1lNbGFQTnNuMngzLzFZTnZwRThNcnMveWVHaFVQNWJ6S1M2Zk13R1ZtYjl5?=
 =?utf-8?B?R0Fwa0dFQS8zSnVtRll6TEk0cFRTSDhqVzhSUXhoanhlUUYxbFdFQkpyTGJJ?=
 =?utf-8?B?VzlIdkY5aUtsTHpSWjNSQVJWTjVMRWQzd2tmeGpUelZ4SnFuQk1sUWFJL2VU?=
 =?utf-8?B?YlBDMWF4RjRBdFJVVmxPSHIxMDhnME9yVWdYOERKVjV0YWhRM3dxVWIyZkl3?=
 =?utf-8?B?blViVzJJWkRhNUZJT0pnYUdGUG04anEzdUsya0UrdFpJdVVjTHJqTTNwbmhm?=
 =?utf-8?B?S2NOeEl4ZlZuQUVQN3phdHlwaDRObU14VEhIR2ZyK1o2QlFNbTg2MjVBSkRL?=
 =?utf-8?B?U25wRGlHZGdYR3BnK0IwNGxraWpaMVY4Y1VTVGlaQVl6OFF2eTlHVm8yZERS?=
 =?utf-8?B?aEZLMkdjb2htTUZpaUtlNzd6dkcwL05ma1pCL2F1WURxWnQxVHRyYUdnYXpZ?=
 =?utf-8?B?YnMwc0tFbzgreWlQdTROT1B5Q1lOMDNwdW1GMm93VmpENW5Fd2FycnB3RzNU?=
 =?utf-8?B?M2ZSYmxzeTlhSkxWemlIanVSMmRyNHhlazZaSU9zeldZRkQwNFpOS0plUTcz?=
 =?utf-8?B?dHhjN0VoYkFVK2xyeU9vR3ZlUXphRFk3cGNXdG9JNi9WQ3BTTFA5NmVuNHgz?=
 =?utf-8?B?ZCtqbDdibHdJTk5wU1ZQOC9hSkxIUVdtNEFpWUErOXdVZEtyaXI2OURPM1lm?=
 =?utf-8?B?dlFkSFZyR0ZGRUdFbHBxdExJVHozQ3c1bVZVUGVwcmdTZGFkMWJubG5rZVYr?=
 =?utf-8?B?TGtuZmcyUmE3V0pHTmx6d0t1OW1Qc3Z2NXBwbkIxVXdpTHpSUnRDQVE3eUxO?=
 =?utf-8?B?OFhNWE5HWVUycGRYT0l4cFUwbFNLMGljYUZzTDN1REdoQlFTSW11OWE5TUpR?=
 =?utf-8?B?TGd3VVJnV0JoWSs0WDQ1bFdLaEV2RDVsczZnZm9HaW1uL2U0MS8rTjhLd3lO?=
 =?utf-8?B?NWI0WDhpQ24yUkQwQlRDeUFZRkg5MytMWGZjMkt2QzRTdlA1VTkzSlBjaEds?=
 =?utf-8?B?TTFJdmZHR1FlNkhRL3ZsR21wNXNDclZMYXZmUmdtYUJLRDQ5SVh5QnFnbXRH?=
 =?utf-8?B?SWdPNUxTblByYlduU2lzcWlYQ0lFZDdWNzF4QkVDSHBTcXV0aWllaTdNVk14?=
 =?utf-8?B?V2lqam02MkNpZlM4aGFQTThhOEtuU09JOTIyeUJEVVk4UEtEY1E4djV1Q2o4?=
 =?utf-8?B?MlI2bWIxYW9Oa09ieTllUnV5YUd1YXQ2NWxacFpPY3lBTlEyeGRHNFpZSzFr?=
 =?utf-8?B?NkZ1NEYva1VPNktsci9oRU8yMmFPTWhySFZSZUR0T1JaY0MvTDN6TEtFOElD?=
 =?utf-8?B?bXBzK3BoejJ0QjZpajB2RGpPRjd5ZU0rR2NoTWVDVXRINkdjaitQRDJOdFNN?=
 =?utf-8?B?OEg2SXVDdDEyMjV2UisvZ0VEdEV1eFJKUTRkNHlHemhTRXliWTdDMkc3Nzd3?=
 =?utf-8?B?MTdOT2JYQmh1TzVhTWhscm5xeTV3eWRXL2hwREpvWDJVWVBpWU1XOWE4NlFm?=
 =?utf-8?B?YjdLaFNjcE0xd0lkZFVGUEY2cnYvMXZYTkFIVHBjdmRPZTJJbDJCTjZTRXE4?=
 =?utf-8?B?L0NVWGxnVmEzY3hSell0TENZaXR5eGl6VDNCUlVHQldwcGFzSGdzbkRLREcx?=
 =?utf-8?B?Y2p1TURpcllpUnBoaGFmRXhjWlR3bStiWkd2eU1peDFuZElpRlFEMm13eVFG?=
 =?utf-8?B?NEZMbnFrM3NZOG9qUFRhVjlEd1FHc3dJaU5sNjIxdlRLTU90N3RQZE94ZytD?=
 =?utf-8?B?OEI5clgrS0ZUb0xKWjdQSkNuem5Gb0s3bWhabDFidlBCYzZ1VmRueTU0ZVNY?=
 =?utf-8?Q?CDBOpUi503SWGOhelmwzT9/nd?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	h2UIbSnlnD7XGre2Xw9fksQhnalzaNpJR0QeC9IGsIK6vhZFO60q7WYDxeTUJpTwNbVxH8MXy3QNpsLVFQOamRjqiac4sLrL7jExRMLeBM23/qVQ+mh8s7Hsi7VtOiNrmEJF95vKlPSxFXfgt7kFkdIwv768JipuKFhxLWu563L/goVTTnb5O3JnvLJujB+27eZ5cRTJmnlBwy8OzeK9TbF6NjKJxJ8piPlSV83LG11xSgDQu6aehDeSZ1ryMg0qd+tNcTmBRdp37yJ0F33Y0Q6semzqoWJutee0ggg4I//vVNHAekInE67b4ZrzrFKkr1G1VIyHueuo8wzPevaISYgGxBGs00lRzT4MmNnWmlZyid+EZoox0jLZOjWU8TFStN4QRIcVvd/X/jPvI2dICYGqx8pMOAdmfV5+HT0vYVph0/h4+EzseIrnZDMEMJyuQq8To++iAX+Cg2UsEWF1hKquPWBGsd+JaF5F7i/88Agbwi/SPLqddXiP3sWiu697wSDGVNVAm18UnK3fDeGGR7wdNhp2p19JYe8e8jtcyKiY4SGO6E4YsTwsge8aaN92GoYbdR07VLYroT8HU3zc80u/fdyJ7bSEon527VCBwtk=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8f449012-f730-407c-7e01-08dc21460b37
X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB7933.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2024 03:46:30.0418
 (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: 6GwaYxV3Ndt6J9luxdUY7Jl6CNiPWAs9g6bCrCBXOsM1n06+/1dceMpsBk5JNYUihBYRZ10V0R8Xr6k2I2XMdg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR10MB4947
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-01-29_15,2024-01-29_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 malwarescore=0
 suspectscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000
 definitions=main-2401300024
X-Proofpoint-ORIG-GUID: ldWyDb6ZIBxMYu-fmm8zedDxCHuAyKeQ
X-Proofpoint-GUID: ldWyDb6ZIBxMYu-fmm8zedDxCHuAyKeQ

* Lokesh Gidra <lokeshgidra@google.com> [240129 17:35]:
> On Mon, Jan 29, 2024 at 1:00=E2=80=AFPM Liam R. Howlett <Liam.Howlett@ora=
cle.com> wrote:
> >
> > * Lokesh Gidra <lokeshgidra@google.com> [240129 14:35]:
> > > Increments and loads to mmap_changing are always in mmap_lock
> > > critical section.
> >
> > Read or write?
> >
> It's write-mode when incrementing (except in case of
> userfaultfd_remove() where it's done in read-mode) and loads are in
> mmap_lock (read-mode). I'll clarify this in the next version.
> >
> > > This ensures that if userspace requests event
> > > notification for non-cooperative operations (e.g. mremap), userfaultf=
d
> > > operations don't occur concurrently.
> > >
> > > This can be achieved by using a separate read-write semaphore in
> > > userfaultfd_ctx such that increments are done in write-mode and loads
> > > in read-mode, thereby eliminating the dependency on mmap_lock for thi=
s
> > > purpose.
> > >
> > > This is a preparatory step before we replace mmap_lock usage with
> > > per-vma locks in fill/move ioctls.
> > >
> > > Signed-off-by: Lokesh Gidra <lokeshgidra@google.com>
> > > ---
> > >  fs/userfaultfd.c              | 40 ++++++++++++----------
> > >  include/linux/userfaultfd_k.h | 31 ++++++++++--------
> > >  mm/userfaultfd.c              | 62 ++++++++++++++++++++-------------=
--
> > >  3 files changed, 75 insertions(+), 58 deletions(-)
> > >
> > > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> > > index 58331b83d648..c00a021bcce4 100644
> > > --- a/fs/userfaultfd.c
> > > +++ b/fs/userfaultfd.c
> > > @@ -685,12 +685,15 @@ int dup_userfaultfd(struct vm_area_struct *vma,=
 struct list_head *fcs)
> > >               ctx->flags =3D octx->flags;
> > >               ctx->features =3D octx->features;
> > >               ctx->released =3D false;
> > > +             init_rwsem(&ctx->map_changing_lock);
> > >               atomic_set(&ctx->mmap_changing, 0);
> > >               ctx->mm =3D vma->vm_mm;
> > >               mmgrab(ctx->mm);
> > >
> > >               userfaultfd_ctx_get(octx);
> > > +             down_write(&octx->map_changing_lock);
> > >               atomic_inc(&octx->mmap_changing);
> > > +             up_write(&octx->map_changing_lock);

On init, I don't think taking the lock is strictly necessary - unless
there is a way to access it before this increment?  Not that it would
cost much.

> >
> > This can potentially hold up your writer as the readers execute.  I
> > think this will change your priority (ie: priority inversion)?
>=20
> Priority inversion, if any, is already happening due to mmap_lock, no?
> Also, I thought rw_semaphore implementation is fair, so the writer
> will eventually get the lock right? Please correct me if I'm wrong.

You are correct.  Any writer will stop any new readers, but readers
currently in the section must finish before the writer.

>=20
> At this patch: there can't be any readers as they need to acquire
> mmap_lock in read-mode first. While writers, at the point of
> incrementing mmap_changing, already hold mmap_lock in write-mode.
>=20
> With per-vma locks, the same synchronization that mmap_lock achieved
> around mmap_changing, will be achieved by ctx->map_changing_lock.

The inversion I was thinking was that the writer cannot complete the
write until the reader is done failing because the atomic_inc has
happened..?  I see the writer as a priority since readers cannot
complete within the write, but I read it wrong.  I think the readers are
fine if the happen before, during, or after a write.  The work is thrown
out if the reader happens during the transition between those states,
which is detected through the atomic.  This makes sense now.

> >
> > You could use the first bit of the atomic_inc as indication of a write.
> > So if the mmap_changing is even, then there are no writers.  If it
> > didn't change and it's even then you know no modification has happened
> > (or it overflowed and hit the same number which would be rare, but
> > maybe okay?).
>=20
> This is already achievable, right? If mmap_changing is >0 then we know
> there are writers. The problem is that we want writers (like mremap
> operations) to block as long as there is a userfaultfd operation (also
> reader of mmap_changing) going on. Please note that I'm inferring this
> from current implementation.
>=20
> AFAIU, mmap_changing isn't required for correctness, because all
> operations are happening under the right mode of mmap_lock. It's used
> to ensure that while a non-cooperative operations is happening, if the
> user has asked it to be notified, then no other userfaultfd operations
> should take place until the user gets the event notification.

I think it is needed, mmap_changing is read before the mmap_lock is
taken, then compared after the mmap_lock is taken (both read mode) to
ensure nothing has changed.

..

> > > @@ -783,7 +788,9 @@ bool userfaultfd_remove(struct vm_area_struct *vm=
a,
> > >               return true;
> > >
> > >       userfaultfd_ctx_get(ctx);
> > > +     down_write(&ctx->map_changing_lock);
> > >       atomic_inc(&ctx->mmap_changing);
> > > +     up_write(&ctx->map_changing_lock);
> > >       mmap_read_unlock(mm);
> > >
> > >       msg_init(&ewq.msg);

If this happens in read mode, then why are you waiting for the readers
to leave?  Can't you just increment the atomic?  It's fine happening in
read mode today, so it should be fine with this new rwsem.

Thanks,
Liam

..