Received: by 2002:ab2:7855:0:b0:1f9:5764:f03e with SMTP id m21csp323504lqp; Wed, 22 May 2024 05:57:53 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCUo20AsTN1WTbw5UkyGLF4ezy1IR3s3aq2fkoqAXTzCT3doAGsNY03+LaoiCPTIbsXLvSfi003T7OHcKTkYzs8tEiZnEnBhKj6o1WWblw== X-Google-Smtp-Source: AGHT+IEAZqJEPLlU5Fi5KS4aMzkr+JeWlzQcYUQjyfgJwPBsejPNy7++jaanFJUgCYhlE+isvxZJ X-Received: by 2002:a05:620a:2697:b0:790:c18f:5d94 with SMTP id af79cd13be357-79470ebc401mr2053190585a.4.1716382672933; Wed, 22 May 2024 05:57:52 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1716382661; cv=pass; d=google.com; s=arc-20160816; b=XnhM3MemkaGjP17ySp2empKocliXbGp8F+h8eIxRTVJWPZO/z+5j4dWVXbRVW2VdsY PHu7L5FNCIzngcX1e3pIvCCI5S3cfpkJTJ1yH3dJwwizhp/Zj7aPW8aqFsWlNVoiH0R/ K8ZQ16zgh+PeQPuoqTct2YzxjHkvisw358DTiCSEqOr/FXoWx+UPLDB3sBorLkIzMtYL xe7MdcX9Z23euJiH4kMyj0TLkFxZz1aSgOZ1J98IM6wqvmbP60YlsaCGe2FmkgQlWFnn 2mYaJOuk6rjxS9c0W/p+tMCTHYwsuI0/BM/UJDxsbZkTksVtfxvohBGcl8cZupy8BHlC DOEg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=o/utX1MEHc2TwOEpLKg+wlbdf8OjMA6nlb8SpmUn5jQ=; fh=Fwb2oUXuDeDvZJGHn0wIaOPi60cuosViVSI+x3pjv5s=; b=SI/4oOMOZHNXPGWTvZwhqgC30sCnWwod4v9S2VZu15fvUCn5YC7eotk34OT/UDEvXS KStYEh2c8LXuMLQg+e48Qz3+hJatevTX9SVnpIDYww2W6dbBdLSUXcj8wZZVqScThoRy kdsubR0Spjc6NrndX7kpntq+KxTxUudBsReDRsObtHN9hfR+n1yC9shcpgkHMQli3hC6 lLJEADxiox11AJN1xMrhKJO0/agxFO3mA26JXrYL8NGwtsj1XFt919+O/n6jqoH7itJ9 gwPD4rdTqGts7TTJRTReuUmcbpXIHlHe5VnePInog5QP4h1t1HTyZJIbD3Mq79j4lpyD TC3g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LOvzzPqj; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-186245-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-186245-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id af79cd13be357-792bf38de30si1201761785a.782.2024.05.22.05.57.41 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 May 2024 05:57:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-186245-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LOvzzPqj; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-186245-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-186245-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id E44231C21EC5 for ; Wed, 22 May 2024 12:57:28 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0DB2613A3F2; Wed, 22 May 2024 12:57:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LOvzzPqj" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.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 BC17E17C9 for ; Wed, 22 May 2024 12:57:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716382642; cv=none; b=S/gYFEoA4pnezK+TJu+QzQzipTSZVay/LV6GvobCvQR3rD/7+FECp49egEy7lWeRgLefCyeNGNwH6bW5e7x+6oxusB3LhqNUPTOvIK68BJdy9FYQaUvrcGJVOIkMKt6L427oP6aGYHjnFTSjHYhfkfjoWmwkNMhUlurKoQ8S8G4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716382642; c=relaxed/simple; bh=R7VE9+fLKmBOLpnrP084vfG0UQrc8BBWSiV8jddInkk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=nAGkCVV2LxtoHkpfIlmlK0IW/ginjX+G6AdOzGeryLZZbYIBubQ/HUEPAbGLpipy//Mn7svFmv5N7k8SxTdP5XlbTtN99/1i/sIY75zC3RV9kt+zOwF0iDh2F5ffzXZs3yMi7a7/58kZ1wxxyCrSqgIxeoYRZTC+QeanIEClRN4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none 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=LOvzzPqj; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1716382639; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=o/utX1MEHc2TwOEpLKg+wlbdf8OjMA6nlb8SpmUn5jQ=; b=LOvzzPqjNjoPKNEbRzmiU87KbrZBaPrvtduEd2/dzFgZUCUNcYOIMKJIYbQNmv4tKA4sI/ n37QhyswLyph/5Fp6ypnjp0J+OTYyE37Ts3Y7DD57s9UZpsU1SBG00FT2B+TdyeJ2hPYhs IHwDBRWlxsSoyiWHgsEtETIg7a5/hkM= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-590-AwzxaaifN8WmtjwIMvUPeQ-1; Wed, 22 May 2024 08:57:15 -0400 X-MC-Unique: AwzxaaifN8WmtjwIMvUPeQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (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 mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5C2EE185A780; Wed, 22 May 2024 12:57:15 +0000 (UTC) Received: from t14s.redhat.com (unknown [10.39.195.53]) by smtp.corp.redhat.com (Postfix) with ESMTP id 13B5040C6EB7; Wed, 22 May 2024 12:57:13 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, David Hildenbrand , Andrew Morton , Vincent Donnefort , Dan Williams Subject: [PATCH v2 0/3] mm/memory: cleanly support zeropage in vm_insert_page*(), vm_map_pages*() and vmf_insert_mixed() Date: Wed, 22 May 2024 14:57:10 +0200 Message-ID: <20240522125713.775114-1-david@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 There is interest in mapping zeropages via vm_insert_pages() [1] into MAP_SHARED mappings. For now, we only get zeropages in MAP_SHARED mappings via vmf_insert_mixed() from FSDAX code, and I think it's a bit shaky in some cases because we refcount the zeropage when mapping it but not necessarily always when unmapping it ... and we should actually never refcount it. It's all a bit tricky, especially how zeropages in MAP_SHARED mappings interact with GUP (FOLL_LONGTERM), mprotect(), write-faults and s390x forbidding the shared zeropage (rewrite [2] s now upstream). This series tries to take the careful approach of only allowing the zeropage where it is likely safe to use (which should cover the existing FSDAX use case and [1]), preventing that it could accidentally get mapped writable during a write fault, mprotect() etc, and preventing issues with FOLL_LONGTERM in the future with other users. Tested with a patch from Vincent that uses the zeropage in context of [1]. Vincent will post that patch based on this series soon. (not tested with FSDAX, but I don't expect surprises). [1] https://lkml.kernel.org/r/20240430111354.637356-1-vdonnefort@google.com [2] https://lkml.kernel.org/r/20240411161441.910170-1-david@redhat.com v1 -> v2: * "mm/memory: move page_count() check into validate_page_before_insert()" -> Added * "mm/memory: cleanly support zeropage in vm_insert_page*(), ..." -> Fixed "return true;" for never-writable VMAs Cc: Andrew Morton Cc: Vincent Donnefort Cc: Dan Williams David Hildenbrand (3): mm/memory: move page_count() check into validate_page_before_insert() mm/memory: cleanly support zeropage in vm_insert_page*(), vm_map_pages*() and vmf_insert_mixed() mm/rmap: sanity check that zeropages are not passed to RMAP include/linux/rmap.h | 3 ++ mm/memory.c | 97 ++++++++++++++++++++++++++++++++------------ mm/mprotect.c | 2 + 3 files changed, 77 insertions(+), 25 deletions(-) base-commit: 29c73fc794c83505066ee6db893b2a83ac5fac63 -- 2.45.0