From nobody Fri Dec 19 21:46:40 2025 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 B528723F404 for ; Fri, 16 May 2025 12:39:54 +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=1747399197; cv=none; b=M6sUVv5RVETXz+q3AAAPAdcBMwtQaRU4P9Bt09BU0GwzgTr54cTz9PabpQfZflroynzZgWBGUPqetBY1EXL/L614zjRPgVYeuE7siZ85o3bTB9a9iiEQO4CRCwsfy5jeMlvLrmATgsH/3CHlMac8ZWg7l2vfHdlxVUdrkPRLfW8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747399197; c=relaxed/simple; bh=NmMEnvYRjcgEyI5M5m7hBi79ExciAcqQbeWQvpSCOTg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qZxwZ3NCsBaU/SwRH7Ec9d6mwv25cMm3TYSWOeh5eASPGdrf0684YckxMTuAnYb/yQjO/C9DB3p2EwZE91xSA4zZeB9WWcwIiRXppWIEu0fiMgi0BNiZOENkr4DHArqM/MaIh00o/JC4hVjztDF4mDC/TIC/7mU4CCRnyr//72g= 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=HJp0rFIw; arc=none smtp.client-ip=170.10.133.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="HJp0rFIw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1747399193; 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=dD4s5BjWgdY0XRygYfoiKVTZtRM5PGr6HfbLhrnOYkc=; b=HJp0rFIw/4KdU2ihKrOou43c+zZzN7YDSXQDamf+9ua5o9nNNUdgsvpNMCYApv9L5CTZX/ +j4rCu135M0zHuLoaf3zVfzAhvneh33tmQNXeDPXs2dkjppDAiH9cqMiLaojI5xu+bakeR HpLYbheRVNvFZNK1rcrQV+hl0QcPSH8= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-166-2nmt5uMePkOLl0tzVoeJaA-1; Fri, 16 May 2025 08:39:52 -0400 X-MC-Unique: 2nmt5uMePkOLl0tzVoeJaA-1 X-Mimecast-MFC-AGG-ID: 2nmt5uMePkOLl0tzVoeJaA_1747399191 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-3a1c86b62a8so1400346f8f.3 for ; Fri, 16 May 2025 05:39:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747399191; x=1748003991; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dD4s5BjWgdY0XRygYfoiKVTZtRM5PGr6HfbLhrnOYkc=; b=QhKUpO6TV4OpiCMPV5KZya2JxBcXaAddyaYrINS2iuR7efhq2ZZ+UtG5hR+4NBdqQx jqRtqsHTaCkhPaSlxst/YIzDyJSRAcTkC18H3fDnswJKIs+Ttfon+UhxBZYuRkk8BRNJ XC8tIQzSzvvAus4AvEZ+wKsW2CTC50aIeJby2mtqOlsau8otHkaFKhe6O2+wvFg0mZTB t8swFDmZ9c6VYy7JYCtZehocLsnls5ccIPo/4X+B+9eZD10feu2ragXAN/dzoM9zNJBh oTRB+g688s8Y0xL7u069WM7/Z8IYQyifJihbZCVVFe/4mjynwR03jxLKqZsfu52NiDLu LDpA== X-Gm-Message-State: AOJu0Ywi6pXheKZypk+ZtfI8QHq03eJDDZKVQ3tvi8A0ZLOIbk9mhXhI rpjtV5N/BNmHcliUk0WM0VbsaCAGaFI3PlokXzjnJa7ENXdSqD4LmBzbeuMWc28AdGR2/sViVb5 MQ6WXqccUnj1f2y7j97ROSG1I796jku620t3TgbrByZ7HlX7aoYKizPC51pCnu07DTzhya5cA7E MXNr9TrNgpg/bupHRDa9GtMoZVMhbUpY+XkpqH0/Yjfl6JgHJw X-Gm-Gg: ASbGncvIEyPwMOT8Urh4Y8EejJU5ujmTl+lmzGdMb1e6KQ8o3XKZZH5Scav+fPIkHwF veGbB31bNzp3FXrQxDoNy6Rwif5jkgOD88CjhLz5ErlQ+00cBpKQkZy+pbyN8RVS60KTpVZsBWE vPDi/BKQqDuGWvqyyT6HrIySWFbgtU5dA6DlMUK4CbJMaooUrBHTFlbVcOKenz856mPPDfJCSo+ GMTBvzsEb+1R/nta8AJA/yusnvOiiTmkd/30hz2kb44KNFD2fitdHIU4zam3MK1qyFjQbQwWARp 6PzDqJpoc9WYfpjiM5sRJcwqyIojUGyhxrvYxCPAEQ+4pltx3ifmRoQsJqbM/MrRRwXV6xCb X-Received: by 2002:a05:6000:2305:b0:3a0:7f9c:189a with SMTP id ffacd0b85a97d-3a35c7dd97fmr3453608f8f.0.1747399191372; Fri, 16 May 2025 05:39:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHv93D7EpnmZ+BrL8Zcx6nM5iZBOF7WC9roZjSuYlsEHMwzBOdkSWq8EgsH051sEEAROR2png== X-Received: by 2002:a05:6000:2305:b0:3a0:7f9c:189a with SMTP id ffacd0b85a97d-3a35c7dd97fmr3453568f8f.0.1747399190948; Fri, 16 May 2025 05:39:50 -0700 (PDT) Received: from localhost (p200300d82f474700e6f9f4539ece7602.dip0.t-ipconnect.de. [2003:d8:2f47:4700:e6f9:f453:9ece:7602]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-3a35ca62c70sm2792386f8f.54.2025.05.16.05.39.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 May 2025 05:39:49 -0700 (PDT) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, David Hildenbrand , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Sven Schnelle , Thomas Huth , Matthew Wilcox , Zi Yan , Sebastian Mitterle , stable@vger.kernel.org Subject: [PATCH v1 1/3] s390/uv: don't return 0 from make_hva_secure() if the operation was not successful Date: Fri, 16 May 2025 14:39:44 +0200 Message-ID: <20250516123946.1648026-2-david@redhat.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250516123946.1648026-1-david@redhat.com> References: <20250516123946.1648026-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 Content-Type: text/plain; charset="utf-8" If s390_wiggle_split_folio() returns 0 because splitting a large folio succeeded, we will return 0 from make_hva_secure() even though a retry is required. Return -EAGAIN in that case. Otherwise, we'll return 0 from gmap_make_secure(), and consequently from unpack_one(). In kvm_s390_pv_unpack(), we assume that unpacking succeeded and skip unpacking this page. Later on, we run into issues and fail booting the VM. So far, this issue was only observed with follow-up patches where we split large pagecache XFS folios. Maybe it can also be triggered with shmem? We'll cleanup s390_wiggle_split_folio() a bit next, to also return 0 if no split was required. Fixes: d8dfda5af0be ("KVM: s390: pv: fix race when making a page secure") Cc: stable@vger.kernel.org Signed-off-by: David Hildenbrand Reviewed-by: Claudio Imbrenda --- arch/s390/kernel/uv.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/s390/kernel/uv.c b/arch/s390/kernel/uv.c index 9a5d5be8acf41..2cc3b599c7fe3 100644 --- a/arch/s390/kernel/uv.c +++ b/arch/s390/kernel/uv.c @@ -393,8 +393,11 @@ int make_hva_secure(struct mm_struct *mm, unsigned lon= g hva, struct uv_cb_header folio_walk_end(&fw, vma); mmap_read_unlock(mm); =20 - if (rc =3D=3D -E2BIG || rc =3D=3D -EBUSY) + if (rc =3D=3D -E2BIG || rc =3D=3D -EBUSY) { rc =3D s390_wiggle_split_folio(mm, folio, rc =3D=3D -E2BIG); + if (!rc) + rc =3D -EAGAIN; + } folio_put(folio); =20 return rc; --=20 2.49.0 From nobody Fri Dec 19 21:46:40 2025 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 3C1F524169E for ; Fri, 16 May 2025 12:39:57 +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=1747399198; cv=none; b=AKny37uXMauGwndWIDRJfbb8+X5nbfDr/eozvUQ7N/C3FZyLcrjcbeAFY/BToD9+i3AgVgA/O2XWH2wyeOr+eX/vOdedT4AMh8XKXCljz2Ay2jE0ygA1hIAjjZMeQopGGxvRk3/GIgrrS4o+4B6I3bz8f0ACVXqLWUyWgDvri1Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747399198; c=relaxed/simple; bh=WYwxSxOVlYTosM+O5vFdzE/5LvJbOsbb5QgjUqEBTrs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=L47wqwDFO6dJZMPdZpBw6bDY5GXxyWGcfktupnyWpXtyTPBnQIgvVL/vH8sRDSTkEl9TFKf+iigZF2j+RSyRcoYR+fLtmoY0goTTc8TE5K3N/Qq/t86Xh3R/wzzea7aT8xCVUVQa0JOwCKzVYf1bdl2zGbhlKBIUsvWViNTeoJU= 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=PUyAt9K2; 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="PUyAt9K2" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1747399196; 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=7YgkObtSLivpA2litK1mMvMA1rBOwW9ugDKcEb23+bA=; b=PUyAt9K2+yqpO+zQCZb6QygGYkkH+569zaIAkI3jiixToPUdY/+3h14CoLD07JjemmtgDP 69JRXV5cOzDIbEcd1ZYZG2Nk9Q7Lfvduy5xqhuHzaptbkwPwxuAGwFMxvZnyyytJ7nnown h6ZFDL4tsNd990fsGLHXG816j943d14= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-595-tbeyANQqPBGbG9qTzE45OQ-1; Fri, 16 May 2025 08:39:55 -0400 X-MC-Unique: tbeyANQqPBGbG9qTzE45OQ-1 X-Mimecast-MFC-AGG-ID: tbeyANQqPBGbG9qTzE45OQ_1747399194 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-3a35ec8845cso399728f8f.2 for ; Fri, 16 May 2025 05:39:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747399194; x=1748003994; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7YgkObtSLivpA2litK1mMvMA1rBOwW9ugDKcEb23+bA=; b=hGDZGyusIDOCFJr1cAOVFUbw1zT0796+29Fc/PfFuTPNbDexEJjtqkJo3B05PDoYVe Nu8rZLuMHPiwgMfjRHlAWHs1D+/rLzI/tfJPNyY0VzUBmFnSkr007FIO3aqgtrwePFMP nKin15ZNmsmksK2kUdNBKjMdm4H/C2M1yWtUS+X/GHPAI9WKFgbuin4oIJy+av9S4fjj vR+agC7bDd3EL123AAZeJKYrfBuYSy/08gwD/nGTBiZCNefLtj5u3fvRFJwYS6Hs/vON k0JxNN3yZp+EjCrYB7PH+KYqZ+EYrzL/dwhAfgwJH6LjygyzWauwwe313Lv23A6+Gz0Q m3DQ== X-Gm-Message-State: AOJu0YylYn/zOSINbA9DG5UVOr7kzDeP5+OjS+a7ypH0pEsBTLG5zCuN L6IZaJNW9XyPx/LZwVeDSaNEGFLWZ1O0KKy0XJn6TdQkmIvvdwn7TBVROBooqu4WJLe8ZY0jRNF qAnrPA0/8W17GuOYskEGDn/Fu5Rt3Jkp525SR+cEwoEYMlbBNEwNAe4qquU+0bnZ5FNSPa/aPVv gPR+lHcHfLh3+/fck2sC9CWUHnUBYJV8i/M3/yYXhALfMHSYlq X-Gm-Gg: ASbGncvbI5aNnSQjBRiTIRddvKpG645MbgL4+PCIDsQPHOuspUXXYeDvFANFR4r+ZBS gl1Xm6w24oUotXwtJxKFelS2d3RkraJo/W1J2rTPStMB+ZzNO1G07ec5QINijoLcWSpXE07uuV5 YBiJqLQaKLuSgq6HZv/QHaL08p/UNyMnKE03BvzsvR5WfbS1MED9DWHal+5sTgmx7SuowbhglRH 9EuRWHe3U+SkKdhvG6Pz+1zOykHeL/FleyPzAXiXRku+OvoZ0nLioj2gZwCv8kE7IXO4oAIIDWJ ecCBwbtLjQbAmTK4jMyWV7e9BQy8nTY1l1WiAyGmuJO5uKgMV/0Yie6t5tlObT2hHsHpUGeX X-Received: by 2002:a05:6000:184c:b0:3a0:7139:d178 with SMTP id ffacd0b85a97d-3a35c845c40mr3418608f8f.51.1747399193857; Fri, 16 May 2025 05:39:53 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEE8vebfbLiwPBSuYo/cxaTZC41xWsZgY9lUxeJJRumkx2bu9v71dWhPZlXOhuoGEIxFJdFsw== X-Received: by 2002:a05:6000:184c:b0:3a0:7139:d178 with SMTP id ffacd0b85a97d-3a35c845c40mr3418562f8f.51.1747399193358; Fri, 16 May 2025 05:39:53 -0700 (PDT) Received: from localhost (p200300d82f474700e6f9f4539ece7602.dip0.t-ipconnect.de. [2003:d8:2f47:4700:e6f9:f453:9ece:7602]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-3a35ca8caaasm2674423f8f.83.2025.05.16.05.39.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 May 2025 05:39:52 -0700 (PDT) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, David Hildenbrand , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Sven Schnelle , Thomas Huth , Matthew Wilcox , Zi Yan , Sebastian Mitterle Subject: [PATCH v1 2/3] s390/uv: always return 0 from s390_wiggle_split_folio() if successful Date: Fri, 16 May 2025 14:39:45 +0200 Message-ID: <20250516123946.1648026-3-david@redhat.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250516123946.1648026-1-david@redhat.com> References: <20250516123946.1648026-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 Content-Type: text/plain; charset="utf-8" Let's consistently return 0 if the operation was successful, and just detect ourselves whether splitting is required -- folio_test_large() is a cheap operation. Update the documentation. Should we simply always return -EAGAIN instead of 0, so we don't have to handle it in the caller? Not sure, staring at the documentation, this way looks a bit cleaner. Signed-off-by: David Hildenbrand Reviewed-by: Claudio Imbrenda --- arch/s390/kernel/uv.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/arch/s390/kernel/uv.c b/arch/s390/kernel/uv.c index 2cc3b599c7fe3..f6ddb2b54032e 100644 --- a/arch/s390/kernel/uv.c +++ b/arch/s390/kernel/uv.c @@ -324,34 +324,36 @@ static int make_folio_secure(struct mm_struct *mm, st= ruct folio *folio, struct u } =20 /** - * s390_wiggle_split_folio() - try to drain extra references to a folio an= d optionally split. + * s390_wiggle_split_folio() - try to drain extra references to a folio and + * split the folio if it is large. * @mm: the mm containing the folio to work on * @folio: the folio - * @split: whether to split a large folio * * Context: Must be called while holding an extra reference to the folio; * the mm lock should not be held. - * Return: 0 if the folio was split successfully; - * -EAGAIN if the folio was not split successfully but another att= empt - * can be made, or if @split was set to false; - * -EINVAL in case of other errors. See split_folio(). + * Return: 0 if the operation was successful; + * -EAGAIN if splitting the large folio was not successful, + * but another attempt can be made; + * -EINVAL in case of other folio splitting errors. See split_folio(). */ -static int s390_wiggle_split_folio(struct mm_struct *mm, struct folio *fol= io, bool split) +static int s390_wiggle_split_folio(struct mm_struct *mm, struct folio *fol= io) { int rc; =20 lockdep_assert_not_held(&mm->mmap_lock); folio_wait_writeback(folio); lru_add_drain_all(); - if (split) { + + if (folio_test_large(folio)) { folio_lock(folio); rc =3D split_folio(folio); folio_unlock(folio); =20 if (rc !=3D -EBUSY) return rc; + return -EAGAIN; } - return -EAGAIN; + return 0; } =20 int make_hva_secure(struct mm_struct *mm, unsigned long hva, struct uv_cb_= header *uvcb) @@ -394,7 +396,7 @@ int make_hva_secure(struct mm_struct *mm, unsigned long= hva, struct uv_cb_header mmap_read_unlock(mm); =20 if (rc =3D=3D -E2BIG || rc =3D=3D -EBUSY) { - rc =3D s390_wiggle_split_folio(mm, folio, rc =3D=3D -E2BIG); + rc =3D s390_wiggle_split_folio(mm, folio); if (!rc) rc =3D -EAGAIN; } --=20 2.49.0 From nobody Fri Dec 19 21:46:40 2025 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 34AB1242923 for ; Fri, 16 May 2025 12:39:58 +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=1747399200; cv=none; b=b27ud3kWSO2ktSaf43yJ3NqyEJ5y8i9UgMlACp/yrgNU9WvPUKM6MJmSYcqnapbRfkh1iqI4ySXyYnQmY20Nkq9eZPZo/e41yXBMFx0ZUQe38dzuIL5w7KSGo0gDXiq9c+5gZq98+TZDOrt3aJ4z0nVvBhQREAosGaFn+FZncEk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747399200; c=relaxed/simple; bh=rdOAlDn565rE1FqMI4nBJDb9BzleRulrsucs0xSkJLA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Na7F/mpAtIaAY5lwDZ3WGLFXmcbdo7f8b1RYGMHElDK9/FE/4aQ/28K0z57Cbiv3g08ykgeQ6ukOcWAsJilYgLYoZiBe7eojMMbEd5huV8NKniWyfj8tHvp54IHA0qwDVu80ocbtYcBjKO8ef/aOVvOSH0xSf8FuCPxZ2fj8b9w= 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=a8tg98+G; arc=none smtp.client-ip=170.10.133.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="a8tg98+G" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1747399198; 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=hiLZZy7QAtq/50XMExKGpNPia0HeTXt82qBD/QjAX4s=; b=a8tg98+GvyQ4oA8fHZ1RYO2AK4cEYGhr5Dc6etsEV7j+0sehPQLB25vR1xWJw3wuZJ6TOR K+hJqEvCRBdf4HYp61zVi5XArIuX9kO3LwygwQB9pcSquTONY3EOlBQIloDOcK6haDGVyv GoMgXEcrE84eRY8mmbnBXnf//nrQCz4= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-582-E-gcCyCNN6C8ego3w_n8Jg-1; Fri, 16 May 2025 08:39:57 -0400 X-MC-Unique: E-gcCyCNN6C8ego3w_n8Jg-1 X-Mimecast-MFC-AGG-ID: E-gcCyCNN6C8ego3w_n8Jg_1747399196 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-442f4a3851fso17436975e9.1 for ; Fri, 16 May 2025 05:39:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747399196; x=1748003996; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hiLZZy7QAtq/50XMExKGpNPia0HeTXt82qBD/QjAX4s=; b=frtNOoTmf8BdhRxv2VVdj6Ko5YZBaJDsr7Ohb+5bIWGZGwuwON6aTtyA49fiCIJ6UG ZX7gjQ4myv+07OfBHqjpBcuJ+Yp8yE/XaMiXNitXlL0eRKsueF4A2nZpUpqAAfX9tjCX bET3Ffgm5ix6WhBlGjYaPFX1xPlzH/0axrXmn75LiYXMBNfQ0E3eHUY7Yc8kajFZWfmO RExbXKSaKjrihvLK5sSkzEVYPkOkxnVVBdOUsuh5v6LNLONx329XJVN49P1tGXTfapL5 Db/yvp/rVdskcbT2AYWL1k9AT/kSIQlRivZIGAsDtbu/5ovmsSV0Vrt4sxg4bi4Fi/FJ s9ig== X-Gm-Message-State: AOJu0YzcQSzOxWPvHCZpHjhkDiQRWvRxnDlhbZdxlKwC1+aryL2l3x7U Lp3PoCPMWTPAyzymKbbbPAnwji/r8H2pTuWHEodyc8OTLQZQf4WSTysdp/QJW55UzPG0tMISubb 9zEVM5wVF0tp2qMLg5HjW1ZVVbyGbSFK4HWJ61d5H9eWKTvdySC2dTPhOQ5yceTQDmmpJhHr0nt /A7M4oIKZaup4xu3tUFBkoTxKx7rSu+bIxTtBovUJe5g+Mziou X-Gm-Gg: ASbGncu1wKMNZ6ZLATI38tszWciChVzkaqVUTlGT5zsjOSXLZ27zDVuGA7uRWM+fXA6 nRSLCIMquYiG8mSiFFOQnwWaOqbo7kgLCHrcdku+BNbmnethE0nUGuAssxlXBA4jyKtKCisJmAL xi2TIAO5Xjwv6LJ1/juBtCMok/bMIME7Nr7WTHCbbW8TfKbYXfl3LYmnjNK0AhyLSLvxWfN6d/R TNjjCqgyKqArVwObzXSu/lbHHQdVEf0jvRATkiFTpnyOrxEXsmkgj9/WXtpbkWo2Da12nt07G9r i42tu6dl10IDb9zLovc43kurBsZ++QoE3/9fwRwd7a6Cdf4YbCieyAwOw6cVB8299O5eKIkG X-Received: by 2002:a05:600c:c1b:b0:43c:e481:3353 with SMTP id 5b1f17b1804b1-442feffbb8dmr28003505e9.17.1747399195811; Fri, 16 May 2025 05:39:55 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHPCjYc5Wqc+yI//ttOUMN3UV92gYVHaHXlQYA3K8J/bBkEM9DoFCaA+VbVbF4V9/mI2J6diA== X-Received: by 2002:a05:600c:c1b:b0:43c:e481:3353 with SMTP id 5b1f17b1804b1-442feffbb8dmr28002955e9.17.1747399195319; Fri, 16 May 2025 05:39:55 -0700 (PDT) Received: from localhost (p200300d82f474700e6f9f4539ece7602.dip0.t-ipconnect.de. [2003:d8:2f47:4700:e6f9:f453:9ece:7602]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-442f3380498sm108750375e9.11.2025.05.16.05.39.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 May 2025 05:39:54 -0700 (PDT) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, David Hildenbrand , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Sven Schnelle , Thomas Huth , Matthew Wilcox , Zi Yan , Sebastian Mitterle Subject: [PATCH v1 3/3] s390/uv: improve splitting of large folios that cannot be split while dirty Date: Fri, 16 May 2025 14:39:46 +0200 Message-ID: <20250516123946.1648026-4-david@redhat.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250516123946.1648026-1-david@redhat.com> References: <20250516123946.1648026-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 Content-Type: text/plain; charset="utf-8" Currently, starting a PV VM on an iomap-based filesystem with large folio support, such as XFS, will not work. We'll be stuck in unpack_one()->gmap_make_secure(), because we can't seem to make progress splitting the large folio. The problem is that we require a writable PTE but a writable PTE under such filesystems will imply a dirty folio. So whenever we have a writable PTE, we'll have a dirty folio, and dirty iomap folios cannot currently get split, because split_folio()->split_huge_page_to_list_to_order()->filemap_release_folio() will fail in iomap_release_folio(). So we will not make any progress splitting such large folios. Until dirty folios can be split more reliably, let's manually trigger writeback of the problematic folio using filemap_write_and_wait_range(), and retry the split immediately afterwards exactly once, before looking up the folio again. Should this logic be part of split_folio()? Likely not; most split users don't have to split so eagerly to make any progress. For now, this seems to affect xfs, zonefs and erofs, and this patch makes it work again (tested on xfs only). While this could be considered a fix for 6795801366da ("xfs: Support large folios"), df2f9708ff1f ("zonefs: enable support for large folios") and ce529cc25b18 ("erofs: enable large folios for iomap mode"), before commit eef88fe45ac9 ("s390/uv: Split large folios in gmap_make_secure()"), we did not try splitting large folios at all. So it's all rather part of making SE compatible with file systems that support large folios. But to have some "Fixes:" tag, let's just use eef88fe45ac9. Not CCing stable, because there are a lot of dependencies, and it simply not working is not critical in stable kernels. Reported-by: Sebastian Mitterle Closes: https://issues.redhat.com/browse/RHEL-58218 Fixes: eef88fe45ac9 ("s390/uv: Split large folios in gmap_make_secure()") Signed-off-by: David Hildenbrand Reviewed-by: Claudio Imbrenda --- arch/s390/kernel/uv.c | 66 +++++++++++++++++++++++++++++++++++++++---- 1 file changed, 60 insertions(+), 6 deletions(-) diff --git a/arch/s390/kernel/uv.c b/arch/s390/kernel/uv.c index f6ddb2b54032e..d278bf0c09d1b 100644 --- a/arch/s390/kernel/uv.c +++ b/arch/s390/kernel/uv.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include #include @@ -338,22 +339,75 @@ static int make_folio_secure(struct mm_struct *mm, st= ruct folio *folio, struct u */ static int s390_wiggle_split_folio(struct mm_struct *mm, struct folio *fol= io) { - int rc; + int rc, tried_splits; =20 lockdep_assert_not_held(&mm->mmap_lock); folio_wait_writeback(folio); lru_add_drain_all(); =20 - if (folio_test_large(folio)) { + if (!folio_test_large(folio)) + return 0; + + for (tried_splits =3D 0; tried_splits < 2; tried_splits++) { + struct address_space *mapping; + loff_t lstart, lend; + struct inode *inode; + folio_lock(folio); rc =3D split_folio(folio); + if (rc !=3D -EBUSY) { + folio_unlock(folio); + return rc; + } + + /* + * Splitting with -EBUSY can fail for various reasons, but we + * have to handle one case explicitly for now: some mappings + * don't allow for splitting dirty folios; writeback will + * mark them clean again, including marking all page table + * entries mapping the folio read-only, to catch future write + * attempts. + * + * While the system should be writing back dirty folios in the + * background, we obtained this folio by looking up a writable + * page table entry. On these problematic mappings, writable + * page table entries imply dirty folios, preventing the + * split in the first place. + * + * To prevent a livelock when trigger writeback manually and + * letting the caller look up the folio again in the page + * table (turning it dirty), immediately try to split again. + * + * This is only a problem for some mappings (e.g., XFS); + * mappings that do not support writeback (e.g., shmem) do not + * apply. + */ + if (!folio_test_dirty(folio) || folio_test_anon(folio) || + !folio->mapping || !mapping_can_writeback(folio->mapping)) { + folio_unlock(folio); + break; + } + + /* + * Ideally, we'd only trigger writeback on this exact folio. But + * there is no easy way to do that, so we'll stabilize the + * mapping while we still hold the folio lock, so we can drop + * the folio lock to trigger writeback on the range currently + * covered by the folio instead. + */ + mapping =3D folio->mapping; + lstart =3D folio_pos(folio); + lend =3D lstart + folio_size(folio) - 1; + inode =3D igrab(mapping->host); folio_unlock(folio); =20 - if (rc !=3D -EBUSY) - return rc; - return -EAGAIN; + if (unlikely(!inode)) + break; + + filemap_write_and_wait_range(mapping, lstart, lend); + iput(mapping->host); } - return 0; + return -EAGAIN; } =20 int make_hva_secure(struct mm_struct *mm, unsigned long hva, struct uv_cb_= header *uvcb) --=20 2.49.0