From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 586223E1CFE for ; Thu, 9 Apr 2026 17:09:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775754587; cv=none; b=iq/+4JlHowEJpOcdu/Fkxr2vA2FrjyjMxhT5uWnQg5+/D/alAvafs1hNuF84Rg5UdoanwH8bI6Hfcjm0K2pYpVkohQ+Gr14WIbivNJDj2Pzi7njgsAJXahOmDqQ9sLxQtqO3vmvZpOZVun4BvAc1ckrIX6hEHbYkhoFw/v9qM4k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775754587; c=relaxed/simple; bh=rJFr80r2JHY3A2S2g4k95ZMsiecnVu9dOq5mQl6hDbo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PD4A1EyXCvY6ph+ukJsjsKMmvmAPWQFwuQjuFWbyAcyBAUiuKrBaOgantx0HsK/ooEisc/rM+DMsal37FqTzhC/0azZ8MqlvLxJARjD94DzVRIuYxXEEtkbMa9lDs0drpC5bOFKo2qZfQb45B1gjUQkMN6OYQd4snOhMmW4UeMk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=FThtOdRo; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=t1Yhsq7o; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="FThtOdRo"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="t1Yhsq7o" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775754585; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+Oxezvv+XY94eqFB5rhe7YtVnfzUNjVg60HqVaktujI=; b=FThtOdRoSyXykU8hvOVvH8dU0Ecvl1CYOuzYvq5f0rH/0VwWF1g4uLg+vAtqUFdJJphVqx TRT528fmhzDlvUDdAQoG8g+UM3Kv2U41sfQiUYnALUHiaQ6j2i8ycsL6XKmxnch5g3/WI6 o2prjJXJHO+x9+taQ4ODQahy/W3sXtg= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-479-8RWuzxdWPLa6mfaqHr4Gow-1; Thu, 09 Apr 2026 13:09:43 -0400 X-MC-Unique: 8RWuzxdWPLa6mfaqHr4Gow-1 X-Mimecast-MFC-AGG-ID: 8RWuzxdWPLa6mfaqHr4Gow_1775754583 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-8cd722c1a69so195025185a.0 for ; Thu, 09 Apr 2026 10:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1775754583; x=1776359383; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=+Oxezvv+XY94eqFB5rhe7YtVnfzUNjVg60HqVaktujI=; b=t1Yhsq7oZscGda4nf6GwAq7MejLAbWkGC1v5Fx768AX602uZSF1oB3fn0tWNENA8Qf 3uk5CRMthoKXR4yMjan+2U7Ja1ESuH+aa/pigcD+zDuRCYqAN4S/8RsvFm1TjqbYH8JC TtowgqBJnEreTCli3a1qWNRiNv/E2iPyZqoishhjrHOHnevxVmVZkFPSMxoHO0pSpGjo rNeNrXq3qVdgIp+WqUQ5hQkXP4MSTKDBOqnMl3ebOmN+sQLhNcZ2LTzXknm+gQPSxJj6 X/CDHeVlx+0euc7sKsN5SZixZXyE38KvNaWK8ilKpN54hJDIExohujjO1ejrPJwong9G e3TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775754583; x=1776359383; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+Oxezvv+XY94eqFB5rhe7YtVnfzUNjVg60HqVaktujI=; b=jjUmZsY9TxdU5VUpb21wEWy/sespEG61FqB/DefGcOwLcqZ0dnQp7Jd3vlnINtDKhu iTnstiv3jWJxNid29gSxGZTnm2923YyiSQdkHZ6FDcclBTlGqzm/OGcJ70o5fB2jk50C JbXaUJVL0J4jcouNUulkwvIzd7Boks53iUs7alW7SVEtr4zuRAf3qIuUj9TsbusqEgR1 rNi0toEnc2ONM2MMFvG7qLN7Cz645oICI+yqiWHuXLHqCLgi9U+FQfDxKl0RmJLLcILI MrlKp4p7B9Jz6uIxmpFcdMbFB1TYxNvRkGf+EGoO191diah5MjHEUz8IdxXQMLj3LExI /Ukw== X-Forwarded-Encrypted: i=1; AJvYcCVDWEmktiH7iNFil6HX4yXAqCfnkUnOKYWpSQDuZd0liQ9QGEKV6SuND2urRzBmqa+KdG+S+1Isbs0UtAQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyvwI6kFv4LcJQ34d5rd5U1O4TTwpaPSC6Uc+vUpKVy/vQlizOo rHuc/H7J5MsQl7RnmzSIYAaIwQwMOmOC8c/53HRkoJWiENdGS+Lj9y2mnYwTOqj7aaAqHp08ZQy El/KB56hUqiZW0TCYLmGh1Q/mN8fbeuPTv+NR9DmgGO4C4Wh4M0Z2jgLm44cd2netHQ== X-Gm-Gg: AeBDieuTGy+JIlkqkWB2pALNxNHzivzhmfOrjGyIT4JASHIPsuYBI8za4OX/ehI3UTz cBN10hFXB+9qb6H3sXGCpHbyCrFk0Y/xyxNBnejegzmX0oe5S23iis96pnLx8buYIfvDOK+i5a9 25IyajyWIrzUAzrIILiHz8KfwC+3tH6CIPqImus+VBLZXWe3q12gUl91iP6Sftiyo787YFmTkI6 ETfC4MyUl0VdRQ/+kC01k5SpPPGxcbbZGWQQ//Z96DJGF9f5JF1U/7IIDzJywa6ZwgIdGheWnKl fVJA/wNtOiyLUJTLBn9GXmsLV7VK6SZVx3GLdNv8QF9LZPxtMxog7DAdecWWGjoDAiQomY0U6d4 ZBDtcl7Cjmk/S+x2kls8SH/wd8CR3I4aM12xUOrnFbNxzgio= X-Received: by 2002:a05:620a:4505:b0:8cf:dd93:acb3 with SMTP id af79cd13be357-8d41e62f87cmr3528894385a.56.1775754583151; Thu, 09 Apr 2026 10:09:43 -0700 (PDT) X-Received: by 2002:a05:620a:4505:b0:8cf:dd93:acb3 with SMTP id af79cd13be357-8d41e62f87cmr3528887785a.56.1775754582478; Thu, 09 Apr 2026 10:09:42 -0700 (PDT) Received: from x1.local ([142.189.10.167]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8d40495cd32sm1615693985a.22.2026.04.09.10.09.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Apr 2026 10:09:42 -0700 (PDT) Date: Thu, 9 Apr 2026 13:09:41 -0400 From: Peter Xu To: David Carlier Cc: Andrew Morton , Mike Rapoport , "Liam R . Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5] mm/userfaultfd: detect VMA type change after copy retry in mfill_copy_folio_retry() Message-ID: References: <20260409120653.290386-1-devnexen@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260409120653.290386-1-devnexen@gmail.com> On Thu, Apr 09, 2026 at 01:06:53PM +0100, David Carlier wrote: > mfill_copy_folio_retry() drops mmap_lock for the copy_from_user() call. > During this window, the VMA can be replaced with a different type (e.g. > hugetlb), making the caller's ops pointer stale. Subsequent use of the > stale ops can lead to incorrect folio handling or a kernel crash. > > Pass the caller's ops into mfill_copy_folio_retry() and compare against > the current vma_uffd_ops() after re-acquiring the lock. Return -EAGAIN > if they differ so the operation can be retried. > > Fixes: 59da5c32ffa3 ("userfaultfd: mfill_atomic(): remove retry logic") > Signed-off-by: David Carlier > --- > mm/userfaultfd.c | 14 ++++++++++++-- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c > index 481ec7eb4442..214923a411c1 100644 > --- a/mm/userfaultfd.c > +++ b/mm/userfaultfd.c > @@ -443,7 +443,9 @@ static int mfill_copy_folio_locked(struct folio *folio, unsigned long src_addr) > return ret; > } > > -static int mfill_copy_folio_retry(struct mfill_state *state, struct folio *folio) > +static int mfill_copy_folio_retry(struct mfill_state *state, > + const struct vm_uffd_ops *ops, > + struct folio *folio) > { > unsigned long src_addr = state->src_addr; > void *kaddr; > @@ -465,6 +467,14 @@ static int mfill_copy_folio_retry(struct mfill_state *state, struct folio *folio > if (err) > return err; > > + /* > + * The VMA type may have changed while the lock was dropped > + * (e.g. replaced with a hugetlb mapping), making the caller's > + * ops pointer stale. > + */ > + if (vma_uffd_ops(state->vma) != ops) > + return -EAGAIN; I agree with -EAGAIN here, but we discussed over all the things on possible inode change and I don't know why we don't consider that. I still think those should be considered. If the vma snapshot idea is not welcomed, fine. We need to think of something to cover those too. Current patch won't cover "ops unchaged" but "inode changed", or offset changed, for example. Thanks, > + > err = mfill_establish_pmd(state); > if (err) > return err; > @@ -495,7 +505,7 @@ static int __mfill_atomic_pte(struct mfill_state *state, > * will take care of unlocking if needed. > */ > if (unlikely(ret)) { > - ret = mfill_copy_folio_retry(state, folio); > + ret = mfill_copy_folio_retry(state, ops, folio); > if (ret) > goto err_folio_put; > } > -- > 2.53.0 > -- Peter Xu