linux-kernel - Re: [PATCH v4 1/1] KVM: s390: pv: fix race when making a page secure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c60e60a2-07ed-4692-8952-c125c34122f8@redhat.com>
Date: Thu, 6 Mar 2025 11:23:29 +0100
From: David Hildenbrand <david@...hat.com>
To: Claudio Imbrenda <imbrenda@...ux.ibm.com>, kvm@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
 frankja@...ux.ibm.com, borntraeger@...ibm.com, nrb@...ux.ibm.com,
 seiden@...ux.ibm.com, nsg@...ux.ibm.com, schlameuss@...ux.ibm.com,
 hca@...ux.ibm.com
Subject: Re: [PATCH v4 1/1] KVM: s390: pv: fix race when making a page secure

>   /**
> - * make_folio_secure() - make a folio secure
> + * __make_folio_secure() - make a folio secure
>    * @folio: the folio to make secure
>    * @uvcb: the uvcb that describes the UVC to be used
>    *
> @@ -243,14 +276,13 @@ static int expected_folio_refs(struct folio *folio)
>    *         -EINVAL if the UVC failed for other reasons.
>    *
>    * Context: The caller must hold exactly one extra reference on the folio
> - *          (it's the same logic as split_folio())
> + *          (it's the same logic as split_folio()), and the folio must be
> + *          locked.
>    */
> -int make_folio_secure(struct folio *folio, struct uv_cb_header *uvcb)
> +static int __make_folio_secure(struct folio *folio, struct uv_cb_header *uvcb)

One more nit: -EBUSY can no longer be returned from his function, so you 
might just remove it from the doc above.


While chasing a very weird folio split bug that seems to result in late 
validation issues (:/), I was wondering if __gmap_destroy_page could 
similarly be problematic.

We're now no longer holding the PTL while performing the operation.

(not that that would explain the issue I am chasing, because 
gmap_destroy_page() is never called in my setup)

-- 
Cheers,

David / dhildenb