[PATCH v3] KVM: s390: Fall back to short-term pinning in MAP ioctl

[PATCH v3] KVM: s390: Fall back to short-term pinning in MAP ioctl

[Jaehoon Kim]

FOLL_LONGTERM pinning fails for some memory types, such as file-backed
guest memory. As a result, kvm_s390_adapter_map() returns -EINVAL and
irqfd adapter registration fails even though interrupt delivery could
still work via the existing non-atomic path.

When FOLL_LONGTERM pinning fails, verify that the page is accessible
using a short-term pin instead. If the short-term pin succeeds, unpin
the page and add a map entry with pinned=false to preserve MAP/UNMAP
symmetry. The non-atomic irqfd path already performs short-term pinning
for interrupt delivery, so this restores the previous behavior for
memory that cannot be pinned long-term.

get_map_info() is updated to return NULL for unpinned entries so that
the atomic irqfd fast path falls back to the non-atomic path.
kvm_s390_adapter_unmap() and kvm_s390_unmap_all_adapters() skip dirty
marking and unpin for unpinned entries.

Update Documentation/virt/kvm/devices/s390_flic.rst to reflect the
new MAP/UNMAP behavior.

Fixes: c9a568838086 ("KVM: s390: Add map/unmap ioctl and clean mappings post-guest")
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Reviewed-by: Douglas Freimuth <freimuth@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
---
 Documentation/virt/kvm/devices/s390_flic.rst | 15 +++++-
 arch/s390/include/asm/kvm_host.h             |  5 ++
 arch/s390/kvm/interrupt.c                    | 56 +++++++++++++++-----
 3 files changed, 60 insertions(+), 16 deletions(-)

diff --git a/Documentation/virt/kvm/devices/s390_flic.rst b/Documentation/virt/kvm/devices/s390_flic.rst
index b784f8016748..983c858b444a 100644
--- a/Documentation/virt/kvm/devices/s390_flic.rst
+++ b/Documentation/virt/kvm/devices/s390_flic.rst
@@ -112,9 +112,20 @@ Groups:
       mask or unmask the adapter, as specified in mask
 
     KVM_S390_IO_ADAPTER_MAP
-      This is now a no-op. The mapping is purely done by the irq route.
+      Map an adapter indicator or summary page for long-term pinning so that
+      interrupt injection can be performed in atomic context. If long-term
+      pinning is not possible (e.g. file-backed memory), the page is verified
+      via a short-term pin and the ioctl returns success; interrupt injection
+      will use the non-atomic irqfd path with short-term pinning on each
+      interrupt. In Secure Execution mode this is a no-op and the ioctl
+      returns success.
+
     KVM_S390_IO_ADAPTER_UNMAP
-      This is now a no-op. The mapping is purely done by the irq route.
+      Unmap a previously mapped adapter indicator or summary page and release
+      the long-term pin. If the page was not long-term pinned (e.g. file-backed
+      memory), the map entry is removed and success is returned; if no prior
+      map entry exists, -ENOENT is returned. In Secure Execution mode this is
+      a no-op and the ioctl returns success.
 
   KVM_DEV_FLIC_AISM
     modify the adapter-interruption-suppression mode for a given isc if the
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index eaa34c5bd3c1..c172f9b212d1 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -476,6 +476,11 @@ struct s390_map_info {
 	__u64 guest_addr;
 	__u64 addr;
 	struct page *page;
+	/*
+	 * True if the page is long-term pinned. False if long-term pinning
+	 * failed and this entry exists only to preserve MAP/UNMAP symmetry.
+	 */
+	bool pinned;
 };
 
 struct s390_io_adapter {
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index 9e3e6b0d72ad..7514d9e2403c 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -2520,8 +2520,22 @@ static int kvm_s390_adapter_map(struct kvm *kvm, unsigned int id, __u64 addr)
 	map->addr = host_addr;
 	map->page = pin_map_page(kvm, host_addr, FOLL_LONGTERM);
 	if (!map->page) {
-		ret = -EINVAL;
-		goto out;
+		/*
+		 * Long-term pinning may fail for memory types such as file-backed
+		 * memory. Verify that short-term pinning succeeds so that the
+		 * non-atomic irqfd path can handle interrupt injection.
+		 */
+		map->page = pin_map_page(kvm, host_addr, 0);
+		if (!map->page) {
+			ret = -EINVAL;
+			goto out;
+		}
+		unpin_user_page(map->page);
+		map->page = NULL;
+		map->pinned = false;
+		/* Add an entry to preserve MAP/UNMAP symmetry. */
+	} else {
+		map->pinned = true;
 	}
 	spin_lock_irqsave(&adapter->maps_lock, flags);
 	if (adapter->nr_maps < MAX_S390_ADAPTER_MAPS) {
@@ -2532,7 +2546,7 @@ static int kvm_s390_adapter_map(struct kvm *kvm, unsigned int id, __u64 addr)
 		ret = -EINVAL;
 	}
 	spin_unlock_irqrestore(&adapter->maps_lock, flags);
-	if (ret)
+	if (ret && map->page)
 		unpin_user_page(map->page);
 out:
 	if (ret)
@@ -2546,6 +2560,7 @@ static int kvm_s390_adapter_unmap(struct kvm *kvm, unsigned int id, __u64 addr)
 	struct s390_map_info *map, *tmp, *map_to_free;
 	struct page *map_page_to_put = NULL;
 	u64 map_addr_to_mark = 0;
+	bool map_pinned = false;
 	unsigned long flags;
 	int found = 0, idx;
 
@@ -2560,6 +2575,7 @@ static int kvm_s390_adapter_unmap(struct kvm *kvm, unsigned int id, __u64 addr)
 			list_del(&map->list);
 			map_page_to_put = map->page;
 			map_addr_to_mark = map->guest_addr;
+			map_pinned = map->pinned;
 			map_to_free = map;
 			break;
 		}
@@ -2568,11 +2584,18 @@ static int kvm_s390_adapter_unmap(struct kvm *kvm, unsigned int id, __u64 addr)
 
 	if (found) {
 		kfree(map_to_free);
-		idx = srcu_read_lock(&kvm->srcu);
-		mark_page_dirty(kvm, map_addr_to_mark >> PAGE_SHIFT);
-		set_page_dirty_lock(map_page_to_put);
-		srcu_read_unlock(&kvm->srcu, idx);
-		unpin_user_page(map_page_to_put);
+		if (map_pinned) {
+			/*
+			 * Only long-term pinned pages need to be marked dirty
+			 * and released. Fallback entries exist only for
+			 * MAP/UNMAP symmetry.
+			 */
+			idx = srcu_read_lock(&kvm->srcu);
+			mark_page_dirty(kvm, map_addr_to_mark >> PAGE_SHIFT);
+			set_page_dirty_lock(map_page_to_put);
+			srcu_read_unlock(&kvm->srcu, idx);
+			unpin_user_page(map_page_to_put);
+		}
 	}
 
 	return found ? 0 : -ENOENT;
@@ -2598,11 +2621,13 @@ void kvm_s390_unmap_all_adapters(struct kvm *kvm)
 
 		list_for_each_entry_safe(map, tmp, &local_list, list) {
 			list_del(&map->list);
-			idx = srcu_read_lock(&kvm->srcu);
-			mark_page_dirty(kvm, map->guest_addr >> PAGE_SHIFT);
-			set_page_dirty_lock(map->page);
-			srcu_read_unlock(&kvm->srcu, idx);
-			unpin_user_page(map->page);
+			if (map->pinned) {
+				idx = srcu_read_lock(&kvm->srcu);
+				mark_page_dirty(kvm, map->guest_addr >> PAGE_SHIFT);
+				set_page_dirty_lock(map->page);
+				srcu_read_unlock(&kvm->srcu, idx);
+				unpin_user_page(map->page);
+			}
 			kfree(map);
 		}
 	}
@@ -2929,8 +2954,11 @@ static struct s390_map_info *get_map_info(struct s390_io_adapter *adapter,
 		return NULL;
 
 	list_for_each_entry(map, &adapter->maps, list) {
-		if (map->addr == addr)
+		if (map->addr == addr) {
+			if (!map->pinned)
+				return NULL;
 			return map;
+		}
 	}
 	return NULL;
 }
-- 
2.43.0

Re: [PATCH v3] KVM: s390: Fall back to short-term pinning in MAP ioctl

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Guest-triggerable WARN_ON_ONCE in adapter_indicators_set leads to host DoS.
--

--- Patch [1]: [PATCH v3] KVM: s390: Fall back to short-term pinning in MAP ioctl ---
commit 07b3642c0ab06a5f6b361f58b4393eb785c7021c
Author: Jaehoon Kim <jhkim@linux.ibm.com>

KVM: s390: Fall back to short-term pinning in MAP ioctl

This commit modifies the KVM s390 MAP ioctl to support memory types that cannot
be long-term pinned, such as file-backed memory. It falls back to verifying
access with a short-term pin, preserving a map entry with a new pinned flag
set to false. Accesses in the interrupt fast path are updated to skip these
unpinned entries, causing them to fall back to the non-atomic path.

> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
> --- a/arch/s390/kvm/interrupt.c
> +++ b/arch/s390/kvm/interrupt.c
[ ... ]
> @@ -2929,8 +2954,11 @@ static struct s390_map_info *get_map_info(struct s390_io_adapter *adapter,
>  		return NULL;
>  
>  	list_for_each_entry(map, &adapter->maps, list) {
> -		if (map->addr == addr)
> +		if (map->addr == addr) {
> +			if (!map->pinned)
> +				return NULL;

[Severity: High]
This isn't a bug introduced by this patch, but returning NULL here forces
the caller to fall back to the non-atomic path in adapter_indicators_set().

If a malicious guest or untrusted userspace configures an IRQ routing entry
with an unmapped host virtual address for summary_addr, the short-term pin
will fail:

arch/s390/kvm/interrupt.c:adapter_indicators_set() {
    ...
    summary_info = get_map_info(adapter, adapter_int->summary_addr);
    if (!summary_info) {
        ...
        summary_page = pin_map_page(kvm, adapter_int->summary_addr, 0);
        if (WARN_ON_ONCE(!summary_page))
            return -1;
    ...
}

Could this guest-triggerable WARN_ON_ONCE lead to a host denial of service
if panic_on_warn is enabled on the host?

Should this WARN_ON_ONCE be downgraded to a normal error return so that it
safely handles unmapped addresses?

>  			return map;
> +		}
>  	}
>  	return NULL;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260724133943.1664961-1-jhkim@linux.ibm.com?part=1

Re: [PATCH v3] KVM: s390: Fall back to short-term pinning in MAP ioctl

[Christian Borntraeger]

Am 24.07.26 um 15:39 schrieb Jaehoon Kim:
> FOLL_LONGTERM pinning fails for some memory types, such as file-backed
> guest memory. As a result, kvm_s390_adapter_map() returns -EINVAL and
> irqfd adapter registration fails even though interrupt delivery could
> still work via the existing non-atomic path.
> 
> When FOLL_LONGTERM pinning fails, verify that the page is accessible
> using a short-term pin instead. If the short-term pin succeeds, unpin
> the page and add a map entry with pinned=false to preserve MAP/UNMAP
> symmetry. The non-atomic irqfd path already performs short-term pinning
> for interrupt delivery, so this restores the previous behavior for
> memory that cannot be pinned long-term.
> 
> get_map_info() is updated to return NULL for unpinned entries so that
> the atomic irqfd fast path falls back to the non-atomic path.
> kvm_s390_adapter_unmap() and kvm_s390_unmap_all_adapters() skip dirty
> marking and unpin for unpinned entries.
> 
> Update Documentation/virt/kvm/devices/s390_flic.rst to reflect the
> new MAP/UNMAP behavior.
> 
> Fixes: c9a568838086 ("KVM: s390: Add map/unmap ioctl and clean mappings post-guest")
> Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
> Reviewed-by: Douglas Freimuth <freimuth@linux.ibm.com>
> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>

queued for kvm/master.

Doug, Jaehoon, Matt,

can you have a look at the sashiko feedback for the pre-existing issue and work on a
followup fix?

Re: [PATCH v3] KVM: s390: Fall back to short-term pinning in MAP ioctl

[Matthew Rosato]

On 7/27/26 3:29 AM, Christian Borntraeger wrote:
> Am 24.07.26 um 15:39 schrieb Jaehoon Kim:
>> FOLL_LONGTERM pinning fails for some memory types, such as file-backed
>> guest memory. As a result, kvm_s390_adapter_map() returns -EINVAL and
>> irqfd adapter registration fails even though interrupt delivery could
>> still work via the existing non-atomic path.
>>
>> When FOLL_LONGTERM pinning fails, verify that the page is accessible
>> using a short-term pin instead. If the short-term pin succeeds, unpin
>> the page and add a map entry with pinned=false to preserve MAP/UNMAP
>> symmetry. The non-atomic irqfd path already performs short-term pinning
>> for interrupt delivery, so this restores the previous behavior for
>> memory that cannot be pinned long-term.
>>
>> get_map_info() is updated to return NULL for unpinned entries so that
>> the atomic irqfd fast path falls back to the non-atomic path.
>> kvm_s390_adapter_unmap() and kvm_s390_unmap_all_adapters() skip dirty
>> marking and unpin for unpinned entries.
>>
>> Update Documentation/virt/kvm/devices/s390_flic.rst to reflect the
>> new MAP/UNMAP behavior.
>>
>> Fixes: c9a568838086 ("KVM: s390: Add map/unmap ioctl and clean
>> mappings post-guest")
>> Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
>> Reviewed-by: Douglas Freimuth <freimuth@linux.ibm.com>
>> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
> 
> queued for kvm/master.
> 
> Doug, Jaehoon, Matt,
> 
> can you have a look at the sashiko feedback for the pre-existing issue
> and work on a
> followup fix?
> 

I believe this report is not nearly as extreme as it sounds.

It claims:
"If a malicious guest or untrusted userspace configures an IRQ routing
entry with an unmapped host virtual address for summary_addr, the
short-term pin will fail:"

However: the summary_page was previously validated when the route was
setup in kvm_set_routing_entry():

uaddr_s = gpa_to_hva(kvm, ue->u.adapter.summary_addr);
...
if (kvm_is_error_hva(uaddr_s) || kvm_is_error_hva(uaddr_i))
	return -EFAULT;
e->adapter.summary_addr = uaddr_s;

So we already know that the address was pre-validated before we try to
use it in adapter_indicators_set().  BTW this is similar to what Janosch
did for
dcf96f7ad556 KVM: s390: Limit adapter indicator access to mapped page

I think we could only have some problem if we later remove a memslot
that happened to have the summary page on it such that the up-front
validation is no longer accurate?  Can this even happen?

So: Not nearly as easy or user-controlled as 'guest provides bogus
address, crashing panic_on_warn=1 host'

All that said:
The only reason this case is 'weird' is because we may have already
indicated AIBV successfully (made changes to the guest) but cannot
complete delivery because AISB is unreachable.
Maybe the simple answer is to downgrade this to something like
pr_warn_once("Cannot indicate summary on previously-validated routing
entry") so we don't lose the breadcrumbs for this highly-unlikely
scenario but also don't add the potential panic in the first place?  If
we ever reach this situation, the guest in question is going to get bits
set in AIBV but will likely never see them because it will poll first on
AISB which we cannot set anymore.


That would track with
https://docs.kernel.org/process/coding-style.html#do-not-warn-lightly
even if I don't think it's easy to trigger.

Doug / Jaehoon / s390 KVM maintainers -- thoughts?

Re: [PATCH v3] KVM: s390: Fall back to short-term pinning in MAP ioctl

[JAEHOON KIM]

On 7/28/2026 11:21 AM, Matthew Rosato wrote:
> On 7/27/26 3:29 AM, Christian Borntraeger wrote:
>> Am 24.07.26 um 15:39 schrieb Jaehoon Kim:
>>> FOLL_LONGTERM pinning fails for some memory types, such as file-backed
>>> guest memory. As a result, kvm_s390_adapter_map() returns -EINVAL and
>>> irqfd adapter registration fails even though interrupt delivery could
>>> still work via the existing non-atomic path.
>>>
>>> When FOLL_LONGTERM pinning fails, verify that the page is accessible
>>> using a short-term pin instead. If the short-term pin succeeds, unpin
>>> the page and add a map entry with pinned=false to preserve MAP/UNMAP
>>> symmetry. The non-atomic irqfd path already performs short-term pinning
>>> for interrupt delivery, so this restores the previous behavior for
>>> memory that cannot be pinned long-term.
>>>
>>> get_map_info() is updated to return NULL for unpinned entries so that
>>> the atomic irqfd fast path falls back to the non-atomic path.
>>> kvm_s390_adapter_unmap() and kvm_s390_unmap_all_adapters() skip dirty
>>> marking and unpin for unpinned entries.
>>>
>>> Update Documentation/virt/kvm/devices/s390_flic.rst to reflect the
>>> new MAP/UNMAP behavior.
>>>
>>> Fixes: c9a568838086 ("KVM: s390: Add map/unmap ioctl and clean
>>> mappings post-guest")
>>> Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
>>> Reviewed-by: Douglas Freimuth <freimuth@linux.ibm.com>
>>> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
>> queued for kvm/master.
>>
>> Doug, Jaehoon, Matt,
>>
>> can you have a look at the sashiko feedback for the pre-existing issue
>> and work on a
>> followup fix?
>>
> I believe this report is not nearly as extreme as it sounds.
>
> It claims:
> "If a malicious guest or untrusted userspace configures an IRQ routing
> entry with an unmapped host virtual address for summary_addr, the
> short-term pin will fail:"
>
> However: the summary_page was previously validated when the route was
> setup in kvm_set_routing_entry():
>
> uaddr_s = gpa_to_hva(kvm, ue->u.adapter.summary_addr);
> ...
> if (kvm_is_error_hva(uaddr_s) || kvm_is_error_hva(uaddr_i))
> 	return -EFAULT;
> e->adapter.summary_addr = uaddr_s;
>
> So we already know that the address was pre-validated before we try to
> use it in adapter_indicators_set().  BTW this is similar to what Janosch
> did for
> dcf96f7ad556 KVM: s390: Limit adapter indicator access to mapped page
>
> I think we could only have some problem if we later remove a memslot
> that happened to have the summary page on it such that the up-front
> validation is no longer accurate?  Can this even happen?
>
> So: Not nearly as easy or user-controlled as 'guest provides bogus
> address, crashing panic_on_warn=1 host'
>
> All that said:
> The only reason this case is 'weird' is because we may have already
> indicated AIBV successfully (made changes to the guest) but cannot
> complete delivery because AISB is unreachable.
> Maybe the simple answer is to downgrade this to something like
> pr_warn_once("Cannot indicate summary on previously-validated routing
> entry") so we don't lose the breadcrumbs for this highly-unlikely
> scenario but also don't add the potential panic in the first place?  If
> we ever reach this situation, the guest in question is going to get bits
> set in AIBV but will likely never see them because it will poll first on
> AISB which we cannot set anymore.
>
>
> That would track with
> https://docs.kernel.org/process/coding-style.html#do-not-warn-lightly
> even if I don't think it's easy to trigger.
>
> Doug / Jaehoon / s390 KVM maintainers -- thoughts?

Thanks for clarifying. I agree that this is different from the original
Sashiko concern, since the address is already validated. pr_warn_once()
sounds like a good balance to keep the breadcrumb while avoiding a
potential panic.

Re: [PATCH v3] KVM: s390: Fall back to short-term pinning in MAP ioctl

[Douglas Freimuth]

On 7/28/26 12:47 PM, JAEHOON KIM wrote:
> On 7/28/2026 11:21 AM, Matthew Rosato wrote:
>> On 7/27/26 3:29 AM, Christian Borntraeger wrote:
>>> Am 24.07.26 um 15:39 schrieb Jaehoon Kim:
>>>> FOLL_LONGTERM pinning fails for some memory types, such as file-backed
>>>> guest memory. As a result, kvm_s390_adapter_map() returns -EINVAL and
>>>> irqfd adapter registration fails even though interrupt delivery could
>>>> still work via the existing non-atomic path.
>>>>
>>>> When FOLL_LONGTERM pinning fails, verify that the page is accessible
>>>> using a short-term pin instead. If the short-term pin succeeds, unpin
>>>> the page and add a map entry with pinned=false to preserve MAP/UNMAP
>>>> symmetry. The non-atomic irqfd path already performs short-term pinning
>>>> for interrupt delivery, so this restores the previous behavior for
>>>> memory that cannot be pinned long-term.
>>>>
>>>> get_map_info() is updated to return NULL for unpinned entries so that
>>>> the atomic irqfd fast path falls back to the non-atomic path.
>>>> kvm_s390_adapter_unmap() and kvm_s390_unmap_all_adapters() skip dirty
>>>> marking and unpin for unpinned entries.
>>>>
>>>> Update Documentation/virt/kvm/devices/s390_flic.rst to reflect the
>>>> new MAP/UNMAP behavior.
>>>>
>>>> Fixes: c9a568838086 ("KVM: s390: Add map/unmap ioctl and clean
>>>> mappings post-guest")
>>>> Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
>>>> Reviewed-by: Douglas Freimuth <freimuth@linux.ibm.com>
>>>> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
>>> queued for kvm/master.
>>>
>>> Doug, Jaehoon, Matt,
>>>
>>> can you have a look at the sashiko feedback for the pre-existing issue
>>> and work on a
>>> followup fix?
>>>
>> I believe this report is not nearly as extreme as it sounds.
>>
>> It claims:
>> "If a malicious guest or untrusted userspace configures an IRQ routing
>> entry with an unmapped host virtual address for summary_addr, the
>> short-term pin will fail:"
>>
>> However: the summary_page was previously validated when the route was
>> setup in kvm_set_routing_entry():
>>
>> uaddr_s = gpa_to_hva(kvm, ue->u.adapter.summary_addr);
>> ...
>> if (kvm_is_error_hva(uaddr_s) || kvm_is_error_hva(uaddr_i))
>>     return -EFAULT;
>> e->adapter.summary_addr = uaddr_s;
>>
>> So we already know that the address was pre-validated before we try to
>> use it in adapter_indicators_set().  BTW this is similar to what Janosch
>> did for
>> dcf96f7ad556 KVM: s390: Limit adapter indicator access to mapped page
>>
>> I think we could only have some problem if we later remove a memslot
>> that happened to have the summary page on it such that the up-front
>> validation is no longer accurate?  Can this even happen?
>>
>> So: Not nearly as easy or user-controlled as 'guest provides bogus
>> address, crashing panic_on_warn=1 host'
>>
>> All that said:
>> The only reason this case is 'weird' is because we may have already
>> indicated AIBV successfully (made changes to the guest) but cannot
>> complete delivery because AISB is unreachable.
>> Maybe the simple answer is to downgrade this to something like
>> pr_warn_once("Cannot indicate summary on previously-validated routing
>> entry") so we don't lose the breadcrumbs for this highly-unlikely
>> scenario but also don't add the potential panic in the first place?  If
>> we ever reach this situation, the guest in question is going to get bits
>> set in AIBV but will likely never see them because it will poll first on
>> AISB which we cannot set anymore.
>>
>>
>> That would track with
>> https://docs.kernel.org/process/coding-style.html#do-not-warn-lightly
>> even if I don't think it's easy to trigger.
>>
>> Doug / Jaehoon / s390 KVM maintainers -- thoughts?
> 
> Thanks for clarifying. I agree that this is different from the original
> Sashiko concern, since the address is already validated. pr_warn_once()
> sounds like a good balance to keep the breadcrumb while avoiding a
> potential panic.
> 

The answer depends on the environment the system is running in. If it is 
running in an environment with tight tolerances for good reason then we 
might want to panic since the error state should be rare and we have 
note warned lightly. Tight tolerances can be set by enabling panic on 
WARN_ON_ONCE.

The admin knows how tightly they want to control the system so if they 
dont configure panic on WARN_ON_ONCE then this is just logged as desired 
without panic.

If we are concerned or have observed that the usage of panic for 
WARN_ON_ONCE is not done very discreetly then pr_warn_once("Cannot 
indicate summary on previously-validated routing
entry") is the answer.