From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 6FECD3CA4AD for ; Tue, 2 Jun 2026 11:06:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780398404; cv=none; b=Fbih+JNHD4pojdqJS5j1npajViRgHa5EtvdTKLJqwEs72oY9Z6pTER6+k17hXhT1S3BO55+LKLNutBlHsp/B9R/mqlkximGnW0TfO20zXS+8Zk7eu0H+noVfRzMQq5+hXhgncYrjjxrdeqVyYIYqVY7UuWLKnWmqWqXS6wRaFfg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780398404; c=relaxed/simple; bh=kbHB3+BMAKK8oJPmnzxNvRSEyA7swdoLOD3WYdkW3RY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JLIppcZV/7i+wPPq6pCds3yaKAQk6FJSnMOAhlcIQ99+6tyfNcAPG5eb7umCUvKuNBb5vcAqiLF5HpURLCnTOwtYgY0V2WG2vPd842XKhGh2IglIVDNPdTtfEkIVrVNr1o7m71d7G2+ZJl3nM0LdeWXC1LRjAhVLSOgdQomFYmM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bJutkObC; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bJutkObC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24CDD1F00898; Tue, 2 Jun 2026 11:06:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780398401; bh=RDbr0381BRy8zwWOC6o0iLlxNMOQ3y9mZNJBCj9lknk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=bJutkObCCB7dbwzH+nmbp+9/fDeqAqs1G+pqV/651Br86DAHsBVDaO2fRhjPGNqII EJY/iPr0YV8u7ko9Btc8J2X5LMkomEPSt6m+Y4HuF5tJ7WFmpDveHVQtc9xegh10Rn TYe3Ly0RTOPhUXWm1gjp/LEz0gIitCxhuXqYdeyIj4SsaMeRiOtx733jk5KzpK7Gi6 FVuaN2c+t45aNzgtfM763kE1AfG3XzAkb9Ndi2oyvAKb46u5r9dpjOR9WQJZWE4YUf jsG5z0nOCH3JWX6F/QefKZxU5WwKDMUEK115a+qLsLJhgFNmzwtCpMwb+PZEOivPN9 bTRKg1p3dOMQw== From: Lorenzo Stoakes To: Andrew Morton Cc: Arnd Bergmann , Greg Kroah-Hartman , David Hildenbrand , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jann Horn , Pedro Falcato , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v3 2/3] mm/vma: remove mmap_action->success_hook Date: Tue, 2 Jun 2026 12:06:26 +0100 Message-ID: X-Mailer: git-send-email 2.54.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This hook was introduced to work around code that seemed to absolutely require access to a VMA pointer upon mmap(). However, providing this hook leaves a backdoor to drivers getting access to the very thing mmap_prepare eliminates - a pointer to the VMA. Let's solve this contradiction by removing it. The key intended user was hugetlb, however it seems that the best course now is to avoid allowing all drivers the ability to work around mmap_prepare, and find a different solution there. Signed-off-by: Lorenzo Stoakes Acked-by: David Hildenbrand (Arm) --- include/linux/mm_types.h | 10 ---------- mm/util.c | 2 -- tools/testing/vma/include/dup.h | 10 ---------- 3 files changed, 22 deletions(-) diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h index a308e2c23b82..945c0a5386d6 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -843,16 +843,6 @@ struct mmap_action { }; enum mmap_action_type type; - /* - * If specified, this hook is invoked after the selected action has been - * successfully completed. Note that the VMA write lock still held. - * - * The absolute minimum ought to be done here. - * - * Returns 0 on success, or an error code. - */ - int (*success_hook)(const struct vm_area_struct *vma); - /* * If specified, this hook is invoked when an error occurred when * attempting the selected action. diff --git a/mm/util.c b/mm/util.c index 2b2a9df689d7..4e172990afcd 100644 --- a/mm/util.c +++ b/mm/util.c @@ -1397,8 +1397,6 @@ static int mmap_action_finish(struct vm_area_struct *vma, if (!err) err = call_vma_mapped(vma); - if (!err && action->success_hook) - err = action->success_hook(vma); /* do_munmap() might take rmap lock, so release if held. */ maybe_rmap_unlock_action(vma, action); diff --git a/tools/testing/vma/include/dup.h b/tools/testing/vma/include/dup.h index 306171d061e7..fddfd1b57c09 100644 --- a/tools/testing/vma/include/dup.h +++ b/tools/testing/vma/include/dup.h @@ -482,16 +482,6 @@ struct mmap_action { }; enum mmap_action_type type; - /* - * If specified, this hook is invoked after the selected action has been - * successfully completed. Note that the VMA write lock still held. - * - * The absolute minimum ought to be done here. - * - * Returns 0 on success, or an error code. - */ - int (*success_hook)(const struct vm_area_struct *vma); - /* * If specified, this hook is invoked when an error occurred when * attempting the selection action. -- 2.54.0