From: sashiko-bot@kernel.org
To: "Claudio Imbrenda" <imbrenda@linux.ibm.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v1 1/3] KVM: s390: Silence potential warnings in _gmap_crstep_xchg_atomic()
Date: Tue, 09 Jun 2026 16:30:17 +0000 [thread overview]
Message-ID: <20260609163017.6EB381F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260609161646.695361-2-imbrenda@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `(void)` cast does not silence `__must_check` (`warn_unused_result`) warnings in GCC.
--
commit ba4c03a707e418c0a14a0a8490bf5c5ce461e30c
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>
KVM: s390: Silence potential warnings in _gmap_crstep_xchg_atomic()
This commit attempts to silence a compiler warning by casting the result of
dat_crstep_xchg_atomic() to (void). The function is annotated with
__must_check, and the caller intentionally ignores the result as it is a
best-effort clearing operation.
Fixes: d1adc098ce08 ("KVM: s390: Fix _gmap_crstep_xchg_atomic()")
CC: stable@vger.kernel.org # 7.1
> diff --git a/arch/s390/kvm/gmap.h b/arch/s390/kvm/gmap.h
> index 5374f21aaf8df..4e6979783e16b 100644
> --- a/arch/s390/kvm/gmap.h
> +++ b/arch/s390/kvm/gmap.h
> @@ -279,7 +279,11 @@ static inline bool __must_check _gmap_crstep_xchg_atomic(struct gmap *gmap, unio
> gmap_handle_vsie_unshadow_event(gmap, gfn);
> else
> _gmap_handle_vsie_unshadow_event(gmap, gfn);
> - dat_crstep_xchg_atomic(crstep, oldcrste, newcrste, gfn, gmap->asce);
> + /*
> + * Ignore the result, it's just a best effort clearing of the
> + * vsie_notif bit. The caller will have to try again regardless.
> + */
> + (void)dat_crstep_xchg_atomic(crstep, oldcrste, newcrste, gfn, gmap->asce);
[Severity: Low]
Does this actually silence the warning on GCC?
The Linux kernel defines __must_check as __attribute__((__warn_unused_result__)).
GCC ignores (void) casts when evaluating this attribute and will continue to emit
the warning, unlike Clang which allows the suppression.
Since GCC is the primary compiler for KVM on s390x, will this patch accomplish
its stated goal, or should we actively evaluate the return value instead (for
example, using an empty if block)?
> return false;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260609161646.695361-1-imbrenda@linux.ibm.com?part=1
next prev parent reply other threads:[~2026-06-09 16:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-09 16:16 [PATCH v1 0/3] KVM: s390: A few misc gmap fixes Claudio Imbrenda
2026-06-09 16:16 ` [PATCH v1 1/3] KVM: s390: Silence potential warnings in _gmap_crstep_xchg_atomic() Claudio Imbrenda
2026-06-09 16:30 ` sashiko-bot [this message]
2026-06-09 16:16 ` [PATCH v1 2/3] KVM: s390: Fix unlikely race in try_get_locked_pte() Claudio Imbrenda
2026-06-09 16:16 ` [PATCH v1 3/3] KVM: s390: vsie: Use mmu cache to allocate rmap Claudio Imbrenda
2026-06-09 16:33 ` 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=20260609163017.6EB381F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.