From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>, linux-kernel@vger.kernel.org
Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org,
borntraeger@de.ibm.com, frankja@linux.ibm.com, david@kernel.org,
seiden@linux.ibm.com, nrb@linux.ibm.com,
schlameuss@linux.ibm.com, gra@linux.ibm.com
Subject: Re: [PATCH v2 1/6] KVM: s390: Fix dirty marking in adapter_indicators_set*()
Date: Tue, 18 Aug 2026 09:26:00 -0400 [thread overview]
Message-ID: <2bb8cf48-2dcf-4457-86ad-f1424d9ae28b@linux.ibm.com> (raw)
In-Reply-To: <20260814163355.227191-2-imbrenda@linux.ibm.com>
On 8/14/26 12:33 PM, Claudio Imbrenda wrote:
> When the indicator and/or summary bits are set in the guest, the
> accessed page was only marked dirty in KVM if the access was performed
> using the slow path; accesses through the new kvm_arch_set_irq_inatomic
> fast inject path would not mark the page as dirty.
>
> Fix by adding/moving the missing calls to mark_page_dirty(). Note that
> for the inatomic path set_page_dirty{,_lock}() is not needed as the
> page stays pinned; the unpin path correctly marks it as dirty.
>
> Opportunistically reorder the local variables to be in reverse
> Christmas tree order and refactor to use guard().
>
> Fixes: 1e95e3bc6b05 ("KVM: s390: Enable adapter_indicators_set to use mapped pages")
So I'm not strictly opposed to adding the dirtying on the 'fast path'
but AFAIU the idea here was to still mark the page as dirty right before
unpin.
Is it strictly required to dirty the page every time it's touched even
if it's long-term pinned, so long as we make sure to mark the page dirty
before we eventually unpin it?
I think the answer to that dictates whether this is a fix or not (or if
there was a missing path that failed to mark the page dirty)
Thanks,
Matt
next prev parent reply other threads:[~2026-08-18 13:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 16:33 [PATCH v2 0/6] KVM: s390: Even more misc fixes Claudio Imbrenda
2026-08-14 16:33 ` [PATCH v2 1/6] KVM: s390: Fix dirty marking in adapter_indicators_set*() Claudio Imbrenda
2026-08-14 16:42 ` sashiko-bot
2026-08-17 6:45 ` Christian Borntraeger
2026-08-18 13:26 ` Matthew Rosato [this message]
2026-08-18 15:16 ` Christian Borntraeger
2026-08-18 20:43 ` Matthew Rosato
2026-08-24 14:25 ` Douglas Freimuth
2026-08-14 16:33 ` [PATCH v2 2/6] KVM: s390: Fix _gaccess_shadow_fault() Claudio Imbrenda
2026-08-14 16:59 ` sashiko-bot
2026-08-14 16:33 ` [PATCH v2 3/6] KVM: s390: Refactor dat_set_slot() Claudio Imbrenda
2026-08-14 16:46 ` sashiko-bot
2026-08-14 16:33 ` [PATCH v2 4/6] KVM: s390: Move all code into kvm_arch_prepare_memory_region() Claudio Imbrenda
2026-08-14 16:46 ` sashiko-bot
2026-08-14 16:33 ` [PATCH v2 5/6] KVM: s390: Add missing srcu in kvm_s390_set_irq_state() Claudio Imbrenda
2026-08-14 16:43 ` sashiko-bot
2026-08-19 11:46 ` Christoph Schlameuss
2026-08-14 16:33 ` [PATCH v2 6/6] KVM: s390: Fix potential races in dat skey functions Claudio Imbrenda
2026-08-14 16:46 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2bb8cf48-2dcf-4457-86ad-f1424d9ae28b@linux.ibm.com \
--to=mjrosato@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=david@kernel.org \
--cc=frankja@linux.ibm.com \
--cc=gra@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=nrb@linux.ibm.com \
--cc=schlameuss@linux.ibm.com \
--cc=seiden@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox