From nobody Mon Feb 9 11:26:42 2026 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 D8E2B12D1EB for ; Thu, 4 Apr 2024 16:37:18 +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=1712248640; cv=none; b=DmsT8uhaaskka0z64tLPDktU9h2i8Cf16wOwE0EuWBv5AYyZcHLB4thW8CdK7HWPObxTew0/ltZbqu8sp78V2nEXvXtCaQPnZemHFITiS6f3Zt/vZk0dFW8C3IbNcLYDV0W0QSgAXSPOXjKFhd42dOTgD1+FjkDyNtx0mRlcIFw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712248640; c=relaxed/simple; bh=czE5N/0J5tmfJlu8WYjn9+LYDN7w0lpHFxch4r4j6P4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BPen9kNvCEzn9RhxdByO7hb5/ZhS0JN8LfubmiJi89hWhQnEtyiSyDXsxknZtfU9gshQTJBRckj5vicvauBL8gwr657UM44FkkKFmU7sTqfOGjWP1R6RqhJLXFRbAEKdVKPzen92M3i562lK3NJAmGBKSyldtPPU0Mq7cF5D9MU= 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=Zy9nG69G; arc=none smtp.client-ip=170.10.129.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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Zy9nG69G" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712248637; 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: in-reply-to:in-reply-to:references:references; bh=zaZWU0YkYnbWySa48R8KGwWh1EeftVOr0gzeEuzgbNQ=; b=Zy9nG69GyflDis2XEVjZIVmhdv5f1LJtNOSkJAT1gjkU5jrIFwM2uxe1poXRHlSafvu4aA ATEugUWNr41OA8aqd5r5P654XIfsibXxpv3NqWmWpYU+XIBK+NtcFpaLIxZemqcG9DWllL IiYmdiTE8OAEJg9tZeAtSMpEl1RACzc= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-587-telD-LxGMoCt6ciulojX3A-1; Thu, 04 Apr 2024 12:37:14 -0400 X-MC-Unique: telD-LxGMoCt6ciulojX3A-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (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 41945282479F; Thu, 4 Apr 2024 16:37:13 +0000 (UTC) Received: from t14s.fritz.box (unknown [10.39.192.101]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8064E3C24; Thu, 4 Apr 2024 16:37:08 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, David Hildenbrand , Matthew Wilcox , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Janosch Frank , Claudio Imbrenda , Gerald Schaefer , Thomas Huth Subject: [PATCH v1 1/5] s390/uv: don't call wait_on_page_writeback() without a reference Date: Thu, 4 Apr 2024 18:36:38 +0200 Message-ID: <20240404163642.1125529-2-david@redhat.com> In-Reply-To: <20240404163642.1125529-1-david@redhat.com> References: <20240404163642.1125529-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: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 Content-Type: text/plain; charset="utf-8" wait_on_page_writeback() requires that no spinlocks are held and that a page reference is held, as documented for folio_wait_writeback(). After we dropped the PTL, the page could get freed concurrently. So grab a temporary reference. Fixes: 214d9bbcd3a6 ("s390/mm: provide memory management functions for prot= ected KVM guests") Signed-off-by: David Hildenbrand Reviewed-by: Claudio Imbrenda --- arch/s390/kernel/uv.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/s390/kernel/uv.c b/arch/s390/kernel/uv.c index fc07bc39e698..7401838b960b 100644 --- a/arch/s390/kernel/uv.c +++ b/arch/s390/kernel/uv.c @@ -314,6 +314,13 @@ int gmap_make_secure(struct gmap *gmap, unsigned long = gaddr, void *uvcb) rc =3D make_page_secure(page, uvcb); unlock_page(page); } + + /* + * Once we drop the PTL, the page may get unmapped and + * freed immediately. We need a temporary reference. + */ + if (rc =3D=3D -EAGAIN) + get_page(page); } pte_unmap_unlock(ptep, ptelock); out: @@ -325,6 +332,7 @@ int gmap_make_secure(struct gmap *gmap, unsigned long g= addr, void *uvcb) * completion, this is just a useless check, but it is safe. */ wait_on_page_writeback(page); + put_page(page); } else if (rc =3D=3D -EBUSY) { /* * If we have tried a local drain and the page refcount --=20 2.44.0 From nobody Mon Feb 9 11:26:42 2026 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 69B3F12DD8E for ; Thu, 4 Apr 2024 16:37:23 +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=1712248645; cv=none; b=nUDH/O2u3VryjaKBYgJs/Ku9xM7kkBavofbHnsdp1jeceuClmaxOxiup2fY05++5FiA7LKMgJiLAQYoUo6+C80hYSROZRGfM7Bl+5vPwqmOqpkcI3N/S/u03wTA6b4q9FOIb3+1rdS2xvvg5tUwpkW3spfGm7qaqfkjCKah37yk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712248645; c=relaxed/simple; bh=3ds6qOcJAMp9Bcy8VHb/SlJBggTO4aUFH1a88oPcEWs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JGl0tIpFsH/+RjfynIOusjC9Dr+rndQ+0Tk7vvyZX/LTudlFBIXe8fr+RFioTSu4tCXlGrCeXc70hEzrzwSPtlSULZmGFGznPrAD9BoCqMu3E4vQkxm5SqcGJIWrNpnKeNsjVrmTpCKynlA69fh5rF8Dlziw7kGSuzWyMyg3NSY= 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=CnmRsrOd; arc=none smtp.client-ip=170.10.129.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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="CnmRsrOd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712248642; 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: in-reply-to:in-reply-to:references:references; bh=YqMhB+a0hiEG+4rkQzSAJvqocE9H8po4mJ+mzkWYDBs=; b=CnmRsrOdUB8nXoGrApte72Yukj6PtTjyEDGptq90T2YG4X/FVkDykOFhYIQA5dpEimeJwx ed5+OTp1H/rHwTt5QCt2exioWh8y1T93qi7eTQm1j9M7Y/o1LCvyTnwivWGh4MqS7sg0V4 ZRnDRoUewnU0PZrQfHszqa6wudP7VeM= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-41-eqwsHOp0NrySS1NYBlY5wA-1; Thu, 04 Apr 2024 12:37:18 -0400 X-MC-Unique: eqwsHOp0NrySS1NYBlY5wA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (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 2581E28116C5; Thu, 4 Apr 2024 16:37:17 +0000 (UTC) Received: from t14s.fritz.box (unknown [10.39.192.101]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8E09A5827; Thu, 4 Apr 2024 16:37:13 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, David Hildenbrand , Matthew Wilcox , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Janosch Frank , Claudio Imbrenda , Gerald Schaefer , Thomas Huth Subject: [PATCH v1 2/5] s390/uv: convert gmap_make_secure() to work on folios Date: Thu, 4 Apr 2024 18:36:39 +0200 Message-ID: <20240404163642.1125529-3-david@redhat.com> In-Reply-To: <20240404163642.1125529-1-david@redhat.com> References: <20240404163642.1125529-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: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 Content-Type: text/plain; charset="utf-8" We have various goals that require gmap_make_secure() to only work on folios. We want to limit the use of page_mapcount() to the places where it is absolutely necessary, we want to avoid using page flags of tail pages, and we want to remove page_has_private(). So, let's convert gmap_make_secure() to folios. While s390x makes sure to never have PMD-mapped THP in processes that use KVM -- by remapping them using PTEs in thp_split_walk_pmd_entry()->split_huge_pmd() -- we might still find PTE-mapped THPs and could end up working on tail pages of such large folios for now. To handle that cleanly, let's simply split any PTE-mapped large folio, so we can be sure that we are always working with small folios and never on tail pages. There is no real change: splitting will similarly fail on unexpected folio references, just like it would already when we try to freeze the folio refcount. Signed-off-by: David Hildenbrand --- arch/s390/include/asm/page.h | 1 + arch/s390/kernel/uv.c | 66 ++++++++++++++++++++++-------------- 2 files changed, 42 insertions(+), 25 deletions(-) diff --git a/arch/s390/include/asm/page.h b/arch/s390/include/asm/page.h index 9381879f7ecf..54d015bcd8e3 100644 --- a/arch/s390/include/asm/page.h +++ b/arch/s390/include/asm/page.h @@ -215,6 +215,7 @@ static inline unsigned long __phys_addr(unsigned long x= , bool is_31bit) =20 #define phys_to_page(phys) pfn_to_page(phys_to_pfn(phys)) #define page_to_phys(page) pfn_to_phys(page_to_pfn(page)) +#define folio_to_phys(page) pfn_to_phys(folio_pfn(folio)) =20 static inline void *pfn_to_virt(unsigned long pfn) { diff --git a/arch/s390/kernel/uv.c b/arch/s390/kernel/uv.c index 7401838b960b..adcbd4b13035 100644 --- a/arch/s390/kernel/uv.c +++ b/arch/s390/kernel/uv.c @@ -181,36 +181,36 @@ int uv_convert_owned_from_secure(unsigned long paddr) } =20 /* - * Calculate the expected ref_count for a page that would otherwise have no + * Calculate the expected ref_count for a folio that would otherwise have = no * further pins. This was cribbed from similar functions in other places in * the kernel, but with some slight modifications. We know that a secure - * page can not be a huge page for example. + * folio can only be a small folio for example. */ -static int expected_page_refs(struct page *page) +static int expected_folio_refs(struct folio *folio) { int res; =20 - res =3D page_mapcount(page); - if (PageSwapCache(page)) { + res =3D folio_mapcount(folio); + if (folio_test_swapcache(folio)) { res++; - } else if (page_mapping(page)) { + } else if (folio_mapping(folio)) { res++; - if (page_has_private(page)) + if (folio_has_private(folio)) res++; } return res; } =20 -static int make_page_secure(struct page *page, struct uv_cb_header *uvcb) +static int make_folio_secure(struct folio *folio, struct uv_cb_header *uvc= b) { int expected, cc =3D 0; =20 - if (PageWriteback(page)) + if (folio_test_writeback(folio)) return -EAGAIN; - expected =3D expected_page_refs(page); - if (!page_ref_freeze(page, expected)) + expected =3D expected_folio_refs(folio); + if (!folio_ref_freeze(folio, expected)) return -EBUSY; - set_bit(PG_arch_1, &page->flags); + set_bit(PG_arch_1, &folio->flags); /* * If the UVC does not succeed or fail immediately, we don't want to * loop for long, or we might get stall notifications. @@ -220,9 +220,9 @@ static int make_page_secure(struct page *page, struct u= v_cb_header *uvcb) * -EAGAIN and we let the callers deal with it. */ cc =3D __uv_call(0, (u64)uvcb); - page_ref_unfreeze(page, expected); + folio_ref_unfreeze(folio, expected); /* - * Return -ENXIO if the page was not mapped, -EINVAL for other errors. + * Return -ENXIO if the folio was not mapped, -EINVAL for other errors. * If busy or partially completed, return -EAGAIN. */ if (cc =3D=3D UVC_CC_OK) @@ -277,7 +277,7 @@ int gmap_make_secure(struct gmap *gmap, unsigned long g= addr, void *uvcb) bool local_drain =3D false; spinlock_t *ptelock; unsigned long uaddr; - struct page *page; + struct folio *folio; pte_t *ptep; int rc; =20 @@ -306,33 +306,49 @@ int gmap_make_secure(struct gmap *gmap, unsigned long= gaddr, void *uvcb) if (!ptep) goto out; if (pte_present(*ptep) && !(pte_val(*ptep) & _PAGE_INVALID) && pte_write(= *ptep)) { - page =3D pte_page(*ptep); + folio =3D page_folio(pte_page(*ptep)); rc =3D -EAGAIN; - if (trylock_page(page)) { + + /* We might get PTE-mapped large folios; split them first. */ + if (folio_test_large(folio)) { + rc =3D -E2BIG; + } else if (folio_trylock(folio)) { if (should_export_before_import(uvcb, gmap->mm)) - uv_convert_from_secure(page_to_phys(page)); - rc =3D make_page_secure(page, uvcb); - unlock_page(page); + uv_convert_from_secure(folio_to_phys(folio)); + rc =3D make_folio_secure(folio, uvcb); + folio_unlock(folio); } =20 /* - * Once we drop the PTL, the page may get unmapped and + * Once we drop the PTL, the folio may get unmapped and * freed immediately. We need a temporary reference. */ - if (rc =3D=3D -EAGAIN) - get_page(page); + if (rc =3D=3D -EAGAIN || rc =3D=3D -E2BIG) + folio_get(folio); } pte_unmap_unlock(ptep, ptelock); out: mmap_read_unlock(gmap->mm); =20 + if (rc =3D=3D -E2BIG) { + /* + * Splitting might fail with -EBUSY due to unexpected folio + * references, just like make_folio_secure(). So handle it + * ahead of time without the PTL being held. + */ + folio_lock(folio); + rc =3D split_folio(folio); + folio_unlock(folio); + folio_put(folio); + } + if (rc =3D=3D -EAGAIN) { /* * If we are here because the UVC returned busy or partial * completion, this is just a useless check, but it is safe. */ - wait_on_page_writeback(page); - put_page(page); + folio_wait_writeback(folio); + folio_put(folio); } else if (rc =3D=3D -EBUSY) { /* * If we have tried a local drain and the page refcount --=20 2.44.0 From nobody Mon Feb 9 11:26:42 2026 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 85AB712FF71 for ; Thu, 4 Apr 2024 16:37:27 +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=1712248649; cv=none; b=RMRNqhKHGy+lD2B00DFPxZd5M2V1wSW/b8d/WgYaAOC93rWz+hBkwkaoVVxV4dz3cDdbIFG0zj1dUtsUJSd1hCd1Z7RMC2OqnZo81HcCoVqnIShpgo6avejwiufFWhlEbV/O9ibuubRbU9/jA5ptE9KDsASDEvsPv3OzwbYcxso= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712248649; c=relaxed/simple; bh=gWXAtNL1jekuOMsqBd4bLsfbAVqcNuhBIDRPoGpv2CQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZKY6MiQ6D10zlaXdALHJXxI4zYiapeW0rqTasOtmUR0u+OrH+c1Z4IW9GPtRT4vj5o//BhApERmpazzwaHHdq0dw7rIe2TWbkJZ6Q+zhNxvHYLLB36kmK3SM6r+FG+LX6M1BnGHDUvXsRf/V37ZxLRO1foQZxS9nGyz4UCb/ddY= 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=dmHMxhro; 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="dmHMxhro" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712248646; 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: in-reply-to:in-reply-to:references:references; bh=gj+Px0USJVRdve0zHf2NII4M17BtyxK6NDqebl44nSI=; b=dmHMxhroa3EfssSaAdICuuaJN0CY/mRan/uEV1gbkKoJQI3C55QxJFDZ/1rRVLal5qQN+i lB+8YiGeA48PLDfxqpVHTC9WnEyeIQD/h89iYWG/rXJlzL8MqcPdc2leKgIKHLZ+90j/OW XLO0wdt3nalRBvbrGugQR+rNKSLXhJw= 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-656-OWEUhaqDPT6N364ahGpEZQ-1; Thu, 04 Apr 2024 12:37:22 -0400 X-MC-Unique: OWEUhaqDPT6N364ahGpEZQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (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 D7141101A531; Thu, 4 Apr 2024 16:37:21 +0000 (UTC) Received: from t14s.fritz.box (unknown [10.39.192.101]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8272E3C21; Thu, 4 Apr 2024 16:37:17 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, David Hildenbrand , Matthew Wilcox , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Janosch Frank , Claudio Imbrenda , Gerald Schaefer , Thomas Huth Subject: [PATCH v1 3/5] s390/uv: convert PG_arch_1 users to only work on small folios Date: Thu, 4 Apr 2024 18:36:40 +0200 Message-ID: <20240404163642.1125529-4-david@redhat.com> In-Reply-To: <20240404163642.1125529-1-david@redhat.com> References: <20240404163642.1125529-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: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 Content-Type: text/plain; charset="utf-8" Now that make_folio_secure() may only set PG_arch_1 for small folios, let's convert relevant remaining UV code to only work on (small) folios and simply reject large folios early. This way, we'll never end up touching PG_arch_1 on tail pages of a large folio in UV code. The folio_get()/folio_put() for functions that are documented to already hold a folio reference look weird and it should probably be removed. Similarly, uv_destroy_owned_page() and uv_convert_owned_from_secure() should really consume a folio reference instead. But these are cleanups for another day. Signed-off-by: David Hildenbrand --- arch/s390/include/asm/page.h | 1 + arch/s390/kernel/uv.c | 39 +++++++++++++++++++++--------------- 2 files changed, 24 insertions(+), 16 deletions(-) diff --git a/arch/s390/include/asm/page.h b/arch/s390/include/asm/page.h index 54d015bcd8e3..b64384872c0f 100644 --- a/arch/s390/include/asm/page.h +++ b/arch/s390/include/asm/page.h @@ -214,6 +214,7 @@ static inline unsigned long __phys_addr(unsigned long x= , bool is_31bit) #define pfn_to_phys(pfn) ((pfn) << PAGE_SHIFT) =20 #define phys_to_page(phys) pfn_to_page(phys_to_pfn(phys)) +#define phys_to_folio(phys) page_folio(phys_to_page(phys)) #define page_to_phys(page) pfn_to_phys(page_to_pfn(page)) #define folio_to_phys(page) pfn_to_phys(folio_pfn(folio)) =20 diff --git a/arch/s390/kernel/uv.c b/arch/s390/kernel/uv.c index adcbd4b13035..9c0113b26735 100644 --- a/arch/s390/kernel/uv.c +++ b/arch/s390/kernel/uv.c @@ -134,14 +134,17 @@ static int uv_destroy_page(unsigned long paddr) */ int uv_destroy_owned_page(unsigned long paddr) { - struct page *page =3D phys_to_page(paddr); + struct folio *folio =3D phys_to_folio(paddr); int rc; =20 - get_page(page); + if (unlikely(folio_test_large(folio))) + return 0; + + folio_get(folio); rc =3D uv_destroy_page(paddr); if (!rc) - clear_bit(PG_arch_1, &page->flags); - put_page(page); + clear_bit(PG_arch_1, &folio->flags); + folio_put(folio); return rc; } =20 @@ -169,14 +172,17 @@ int uv_convert_from_secure(unsigned long paddr) */ int uv_convert_owned_from_secure(unsigned long paddr) { - struct page *page =3D phys_to_page(paddr); + struct folio *folio =3D phys_to_folio(paddr); int rc; =20 - get_page(page); + if (unlikely(folio_test_large(folio))) + return 0; + + folio_get(folio); rc =3D uv_convert_from_secure(paddr); if (!rc) - clear_bit(PG_arch_1, &page->flags); - put_page(page); + clear_bit(PG_arch_1, &folio->flags); + folio_put(folio); return rc; } =20 @@ -457,33 +463,34 @@ EXPORT_SYMBOL_GPL(gmap_destroy_page); */ int arch_make_page_accessible(struct page *page) { + struct folio *folio =3D page_folio(page); int rc =3D 0; =20 - /* Hugepage cannot be protected, so nothing to do */ - if (PageHuge(page)) + /* Large folios cannot be protected, so nothing to do */ + if (unlikely(folio_test_large(folio))) return 0; =20 /* * PG_arch_1 is used in 3 places: * 1. for kernel page tables during early boot * 2. for storage keys of huge pages and KVM - * 3. As an indication that this page might be secure. This can + * 3. As an indication that this small folio might be secure. This can * overindicate, e.g. we set the bit before calling * convert_to_secure. * As secure pages are never huge, all 3 variants can co-exists. */ - if (!test_bit(PG_arch_1, &page->flags)) + if (!test_bit(PG_arch_1, &folio->flags)) return 0; =20 - rc =3D uv_pin_shared(page_to_phys(page)); + rc =3D uv_pin_shared(folio_to_phys(folio)); if (!rc) { - clear_bit(PG_arch_1, &page->flags); + clear_bit(PG_arch_1, &folio->flags); return 0; } =20 - rc =3D uv_convert_from_secure(page_to_phys(page)); + rc =3D uv_convert_from_secure(folio_to_phys(folio)); if (!rc) { - clear_bit(PG_arch_1, &page->flags); + clear_bit(PG_arch_1, &folio->flags); return 0; } =20 --=20 2.44.0 From nobody Mon Feb 9 11:26:42 2026 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 E163C130AC7 for ; Thu, 4 Apr 2024 16:37:32 +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=1712248654; cv=none; b=T7W1JFWQu3msX6PlJvu81ZSDqgE3ziBmC1WSBCb73VKS10HJnvwEGzv0qWk9E9J+Kkti5PJexlGDSn3WSK6dGT16YDEjH9H0ubdv/P4wFEhYQAXnjo1wKeuG+Zpb4gymqhODS2h1uDWNAiDhYOVojR59/p4NYZGAxjMItfpa/0A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712248654; c=relaxed/simple; bh=aCPNbBl5JKNxYSnh7bsg4bMZsFTro2yxg6Wzh277+Fs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rgQSLMOEmobL3fsShHiXQg7/BDPo9PcEsXLbK4+XNTox2DSpBFB3t1z04qku+tuDdxvkr3gblmu6pqzb39MCom29CvPXxdlaF3XChuOzfp/sFq25t716yP3E2pyYCACEZ74W+vjKhbOAscNMVJcvXRulUO4eIlR6j8vRxco/AKE= 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=GzHsUmHy; 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="GzHsUmHy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712248652; 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: in-reply-to:in-reply-to:references:references; bh=wn9vbDVG4YtRegf5ZBlenhUihh95CLw8Qi8j4juWPxs=; b=GzHsUmHyCQoTsB73RAAyHST7A7/syxAUBkvOuoBnPqxte9SXiojxx6yokp62rebPmwSqju XnYSCktC7WGrMpCE6O9v8TTJqP22+WBkG4j+OHVVOhwzb11c5qbQRGtl/us0O74y2tMJ26 uYny28Bq87d0bv68BrFNMfH1hrSSvN8= 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-546-ZB9ewTULNjmhHBCUXGQC7Q-1; Thu, 04 Apr 2024 12:37:26 -0400 X-MC-Unique: ZB9ewTULNjmhHBCUXGQC7Q-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (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 9D4C688D01A; Thu, 4 Apr 2024 16:37:25 +0000 (UTC) Received: from t14s.fritz.box (unknown [10.39.192.101]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1ADD23C54; Thu, 4 Apr 2024 16:37:21 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, David Hildenbrand , Matthew Wilcox , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Janosch Frank , Claudio Imbrenda , Gerald Schaefer , Thomas Huth Subject: [PATCH v1 4/5] s390/uv: update PG_arch_1 comment Date: Thu, 4 Apr 2024 18:36:41 +0200 Message-ID: <20240404163642.1125529-5-david@redhat.com> In-Reply-To: <20240404163642.1125529-1-david@redhat.com> References: <20240404163642.1125529-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: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 Content-Type: text/plain; charset="utf-8" We removed the usage of PG_arch_1 for page tables in commit a51324c430db ("s390/cmma: rework no-dat handling"). Let's update the comment in UV to reflect that. Signed-off-by: David Hildenbrand Reviewed-by: Claudio Imbrenda --- arch/s390/kernel/uv.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/s390/kernel/uv.c b/arch/s390/kernel/uv.c index 9c0113b26735..76fc61333fae 100644 --- a/arch/s390/kernel/uv.c +++ b/arch/s390/kernel/uv.c @@ -471,13 +471,12 @@ int arch_make_page_accessible(struct page *page) return 0; =20 /* - * PG_arch_1 is used in 3 places: - * 1. for kernel page tables during early boot - * 2. for storage keys of huge pages and KVM - * 3. As an indication that this small folio might be secure. This can + * PG_arch_1 is used in 2 places: + * 1. for storage keys of hugetlb folios and KVM + * 2. As an indication that this small folio might be secure. This can * overindicate, e.g. we set the bit before calling * convert_to_secure. - * As secure pages are never huge, all 3 variants can co-exists. + * As secure pages are never large folios, both variants can co-exists. */ if (!test_bit(PG_arch_1, &folio->flags)) return 0; --=20 2.44.0 From nobody Mon Feb 9 11:26:42 2026 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 671D3130E25 for ; Thu, 4 Apr 2024 16:37:35 +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=1712248656; cv=none; b=MxFbqfBnEkVsPzfCuFwkxauFYhqgGw4WJ5nXKS7d/lYFRlzHGMYIYcDxyVhqPVpDsjmgyPhVUyzBFXasddgnzf8DQtaI80mH7KLb2xdX5l4v3Q1z8qUS8x8HCcTzMwokPr9GHYpZmLmJZYYhp9cEVM7DmZpGwSovMyGNDoG+zsE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712248656; c=relaxed/simple; bh=MRKvUOhgbx1JCPqRkZYfqZCtresFIov/9ISiCIQgDR4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mrsPUev0b5vBHuscjtfy/RXMbS5VHO+IjWN0IfI04onTWiRK5wfAPdotUFjQL9jzL74qFj6rUr0uTRHwyvIplilQ89rAJbYSm+n5z3FRM4O3akdyqPHYbzmpmSHI2IWhFUWyXrJs1krlqXOfJC7lkdlHf2hPdIPa78IvZl1KVrg= 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=hOLd7dXM; arc=none smtp.client-ip=170.10.129.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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="hOLd7dXM" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712248654; 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: in-reply-to:in-reply-to:references:references; bh=Q3q+pZ5P34ghakudMZLyDnJaIa/cVUQD0kuqVhWGHj8=; b=hOLd7dXMAJrsahgszPN4y+MZdG3OJiuTEYEfv0dy5vijSCZkTdkS2Ech7sTmuBp62tLOte xwCUGKVbiXjEhlRDph9VDaEaH5Ic3BdPyknjQXUrVPbyqPdrrqa/u8wobC9BL2p0JuIdpU GtJaT7Faly/Q1JY8n0FImaHndWkfJeM= 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-383-iKIcEnTlP7OdF8dgEB13LQ-1; Thu, 04 Apr 2024 12:37:30 -0400 X-MC-Unique: iKIcEnTlP7OdF8dgEB13LQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (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 9AC5E88D016; Thu, 4 Apr 2024 16:37:29 +0000 (UTC) Received: from t14s.fritz.box (unknown [10.39.192.101]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0804E3C24; Thu, 4 Apr 2024 16:37:25 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, David Hildenbrand , Matthew Wilcox , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Janosch Frank , Claudio Imbrenda , Gerald Schaefer , Thomas Huth Subject: [PATCH v1 5/5] s390/hugetlb: convert PG_arch_1 code to work on folio->flags Date: Thu, 4 Apr 2024 18:36:42 +0200 Message-ID: <20240404163642.1125529-6-david@redhat.com> In-Reply-To: <20240404163642.1125529-1-david@redhat.com> References: <20240404163642.1125529-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: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 Content-Type: text/plain; charset="utf-8" Let's make it clearer that we are always working on folio flags and never page flags of tail pages. Signed-off-by: David Hildenbrand --- arch/s390/mm/gmap.c | 4 ++-- arch/s390/mm/hugetlbpage.c | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/s390/mm/gmap.c b/arch/s390/mm/gmap.c index 9233b0acac89..ca31f2143bc0 100644 --- a/arch/s390/mm/gmap.c +++ b/arch/s390/mm/gmap.c @@ -2731,7 +2731,7 @@ static int __s390_enable_skey_hugetlb(pte_t *pte, uns= igned long addr, { pmd_t *pmd =3D (pmd_t *)pte; unsigned long start, end; - struct page *page =3D pmd_page(*pmd); + struct folio *folio =3D pmd_folio(*pmd); =20 /* * The write check makes sure we do not set a key on shared @@ -2746,7 +2746,7 @@ static int __s390_enable_skey_hugetlb(pte_t *pte, uns= igned long addr, start =3D pmd_val(*pmd) & HPAGE_MASK; end =3D start + HPAGE_SIZE - 1; __storage_key_init_range(start, end); - set_bit(PG_arch_1, &page->flags); + set_bit(PG_arch_1, &folio->flags); cond_resched(); return 0; } diff --git a/arch/s390/mm/hugetlbpage.c b/arch/s390/mm/hugetlbpage.c index e1e63dc1b23d..21ed6ac5f1c5 100644 --- a/arch/s390/mm/hugetlbpage.c +++ b/arch/s390/mm/hugetlbpage.c @@ -121,7 +121,7 @@ static inline pte_t __rste_to_pte(unsigned long rste) =20 static void clear_huge_pte_skeys(struct mm_struct *mm, unsigned long rste) { - struct page *page; + struct folio *folio; unsigned long size, paddr; =20 if (!mm_uses_skeys(mm) || @@ -129,16 +129,16 @@ static void clear_huge_pte_skeys(struct mm_struct *mm= , unsigned long rste) return; =20 if ((rste & _REGION_ENTRY_TYPE_MASK) =3D=3D _REGION_ENTRY_TYPE_R3) { - page =3D pud_page(__pud(rste)); + folio =3D page_folio(pud_page(__pud(rste))); size =3D PUD_SIZE; paddr =3D rste & PUD_MASK; } else { - page =3D pmd_page(__pmd(rste)); + folio =3D pmd_folio(__pmd(rste)); size =3D PMD_SIZE; paddr =3D rste & PMD_MASK; } =20 - if (!test_and_set_bit(PG_arch_1, &page->flags)) + if (!test_and_set_bit(PG_arch_1, &folio->flags)) __storage_key_init_range(paddr, paddr + size - 1); } =20 --=20 2.44.0