public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/2] KVM: s390: Don't use %pK through debug printing or tracepoints
@ 2025-02-17 13:13 Thomas Weißschuh
  2025-02-17 13:13 ` [PATCH 1/2] KVM: s390: Don't use %pK through tracepoints Thomas Weißschuh
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Thomas Weißschuh @ 2025-02-17 13:13 UTC (permalink / raw)
  To: Christian Borntraeger, Janosch Frank, Claudio Imbrenda,
	David Hildenbrand, Heiko Carstens, Vasily Gorbik,
	Alexander Gordeev, Sven Schnelle
  Cc: kvm, linux-s390, linux-kernel, Thomas Weißschuh

Restricted pointers ("%pK") are only meant to be used when directly
printing to a file from task context.
Otherwise it can unintentionally expose security sensitive, raw pointer values.

Use regular pointer formatting instead.

Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
Thomas Weißschuh (2):
      KVM: s390: Don't use %pK through tracepoints
      KVM: s390: Don't use %pK through debug printing

 arch/s390/kvm/intercept.c  |  2 +-
 arch/s390/kvm/interrupt.c  |  8 ++++----
 arch/s390/kvm/kvm-s390.c   | 10 +++++-----
 arch/s390/kvm/trace-s390.h |  4 ++--
 4 files changed, 12 insertions(+), 12 deletions(-)
---
base-commit: 0ad2507d5d93f39619fc42372c347d6006b64319
change-id: 20250217-restricted-pointers-s390-3e93b67a9996

Best regards,
-- 
Thomas Weißschuh <thomas.weissschuh@linutronix.de>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH 1/2] KVM: s390: Don't use %pK through tracepoints
  2025-02-17 13:13 [PATCH 0/2] KVM: s390: Don't use %pK through debug printing or tracepoints Thomas Weißschuh
@ 2025-02-17 13:13 ` Thomas Weißschuh
  2025-02-25 13:08   ` Michael Mueller
  2025-02-17 13:13 ` [PATCH 2/2] KVM: s390: Don't use %pK through debug printing Thomas Weißschuh
  2025-02-27 16:04 ` [PATCH 0/2] KVM: s390: Don't use %pK through debug printing or tracepoints Janosch Frank
  2 siblings, 1 reply; 6+ messages in thread
From: Thomas Weißschuh @ 2025-02-17 13:13 UTC (permalink / raw)
  To: Christian Borntraeger, Janosch Frank, Claudio Imbrenda,
	David Hildenbrand, Heiko Carstens, Vasily Gorbik,
	Alexander Gordeev, Sven Schnelle
  Cc: kvm, linux-s390, linux-kernel, Thomas Weißschuh

Restricted pointers ("%pK") are not meant to be used through TP_format().
It can unintentionally expose security sensitive, raw pointer values.

Use regular pointer formatting instead.

Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 arch/s390/kvm/trace-s390.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/s390/kvm/trace-s390.h b/arch/s390/kvm/trace-s390.h
index 9ac92dbf680dbbe7703dd63945968b1cda46cf13..9e28f165c114caab99857ed3b53edc6ed5045dfa 100644
--- a/arch/s390/kvm/trace-s390.h
+++ b/arch/s390/kvm/trace-s390.h
@@ -56,7 +56,7 @@ TRACE_EVENT(kvm_s390_create_vcpu,
 		    __entry->sie_block = sie_block;
 		    ),
 
-	    TP_printk("create cpu %d at 0x%pK, sie block at 0x%pK",
+	    TP_printk("create cpu %d at 0x%p, sie block at 0x%p",
 		      __entry->id, __entry->vcpu, __entry->sie_block)
 	);
 
@@ -255,7 +255,7 @@ TRACE_EVENT(kvm_s390_enable_css,
 		    __entry->kvm = kvm;
 		    ),
 
-	    TP_printk("enabling channel I/O support (kvm @ %pK)\n",
+	    TP_printk("enabling channel I/O support (kvm @ %p)\n",
 		      __entry->kvm)
 	);
 

-- 
2.48.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [PATCH 2/2] KVM: s390: Don't use %pK through debug printing
  2025-02-17 13:13 [PATCH 0/2] KVM: s390: Don't use %pK through debug printing or tracepoints Thomas Weißschuh
  2025-02-17 13:13 ` [PATCH 1/2] KVM: s390: Don't use %pK through tracepoints Thomas Weißschuh
@ 2025-02-17 13:13 ` Thomas Weißschuh
  2025-02-25 12:56   ` Michael Mueller
  2025-02-27 16:04 ` [PATCH 0/2] KVM: s390: Don't use %pK through debug printing or tracepoints Janosch Frank
  2 siblings, 1 reply; 6+ messages in thread
From: Thomas Weißschuh @ 2025-02-17 13:13 UTC (permalink / raw)
  To: Christian Borntraeger, Janosch Frank, Claudio Imbrenda,
	David Hildenbrand, Heiko Carstens, Vasily Gorbik,
	Alexander Gordeev, Sven Schnelle
  Cc: kvm, linux-s390, linux-kernel, Thomas Weißschuh

Restricted pointers ("%pK") are only meant to be used when directly
printing to a file from task context.
Otherwise it can unintentionally expose security sensitive,
raw pointer values.

Use regular pointer formatting instead.

Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 arch/s390/kvm/intercept.c |  2 +-
 arch/s390/kvm/interrupt.c |  8 ++++----
 arch/s390/kvm/kvm-s390.c  | 10 +++++-----
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c
index 610dd44a948b22945b0a35b760ded64bd44ef7cb..a06a000f196ce0066bfd21b0d914492a1796819a 100644
--- a/arch/s390/kvm/intercept.c
+++ b/arch/s390/kvm/intercept.c
@@ -95,7 +95,7 @@ static int handle_validity(struct kvm_vcpu *vcpu)
 
 	vcpu->stat.exit_validity++;
 	trace_kvm_s390_intercept_validity(vcpu, viwhy);
-	KVM_EVENT(3, "validity intercept 0x%x for pid %u (kvm 0x%pK)", viwhy,
+	KVM_EVENT(3, "validity intercept 0x%x for pid %u (kvm 0x%p)", viwhy,
 		  current->pid, vcpu->kvm);
 
 	/* do not warn on invalid runtime instrumentation mode */
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index 07ff0e10cb7f5c0294bf85f1d65d1eb124698705..c0558f05400732b2fe6911c1ef58f86b62364770 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -3161,7 +3161,7 @@ void kvm_s390_gisa_clear(struct kvm *kvm)
 	if (!gi->origin)
 		return;
 	gisa_clear_ipm(gi->origin);
-	VM_EVENT(kvm, 3, "gisa 0x%pK cleared", gi->origin);
+	VM_EVENT(kvm, 3, "gisa 0x%p cleared", gi->origin);
 }
 
 void kvm_s390_gisa_init(struct kvm *kvm)
@@ -3178,7 +3178,7 @@ void kvm_s390_gisa_init(struct kvm *kvm)
 	gi->timer.function = gisa_vcpu_kicker;
 	memset(gi->origin, 0, sizeof(struct kvm_s390_gisa));
 	gi->origin->next_alert = (u32)virt_to_phys(gi->origin);
-	VM_EVENT(kvm, 3, "gisa 0x%pK initialized", gi->origin);
+	VM_EVENT(kvm, 3, "gisa 0x%p initialized", gi->origin);
 }
 
 void kvm_s390_gisa_enable(struct kvm *kvm)
@@ -3219,7 +3219,7 @@ void kvm_s390_gisa_destroy(struct kvm *kvm)
 		process_gib_alert_list();
 	hrtimer_cancel(&gi->timer);
 	gi->origin = NULL;
-	VM_EVENT(kvm, 3, "gisa 0x%pK destroyed", gisa);
+	VM_EVENT(kvm, 3, "gisa 0x%p destroyed", gisa);
 }
 
 void kvm_s390_gisa_disable(struct kvm *kvm)
@@ -3468,7 +3468,7 @@ int __init kvm_s390_gib_init(u8 nisc)
 		}
 	}
 
-	KVM_EVENT(3, "gib 0x%pK (nisc=%d) initialized", gib, gib->nisc);
+	KVM_EVENT(3, "gib 0x%p (nisc=%d) initialized", gib, gib->nisc);
 	goto out;
 
 out_unreg_gal:
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index ebecb96bacce7d75563bd3a130a7cc31869dc254..9e427ba3aed42edf617d6625b5bcaba8f43dc464 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -1020,7 +1020,7 @@ static int kvm_s390_set_mem_control(struct kvm *kvm, struct kvm_device_attr *att
 		}
 		mutex_unlock(&kvm->lock);
 		VM_EVENT(kvm, 3, "SET: max guest address: %lu", new_limit);
-		VM_EVENT(kvm, 3, "New guest asce: 0x%pK",
+		VM_EVENT(kvm, 3, "New guest asce: 0x%p",
 			 (void *) kvm->arch.gmap->asce);
 		break;
 	}
@@ -3464,7 +3464,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
 		kvm_s390_gisa_init(kvm);
 	INIT_LIST_HEAD(&kvm->arch.pv.need_cleanup);
 	kvm->arch.pv.set_aside = NULL;
-	KVM_EVENT(3, "vm 0x%pK created by pid %u", kvm, current->pid);
+	KVM_EVENT(3, "vm 0x%p created by pid %u", kvm, current->pid);
 
 	return 0;
 out_err:
@@ -3527,7 +3527,7 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
 	kvm_s390_destroy_adapters(kvm);
 	kvm_s390_clear_float_irqs(kvm);
 	kvm_s390_vsie_destroy(kvm);
-	KVM_EVENT(3, "vm 0x%pK destroyed", kvm);
+	KVM_EVENT(3, "vm 0x%p destroyed", kvm);
 }
 
 /* Section: vcpu related */
@@ -3648,7 +3648,7 @@ static int sca_switch_to_extended(struct kvm *kvm)
 
 	free_page((unsigned long)old_sca);
 
-	VM_EVENT(kvm, 2, "Switched to ESCA (0x%pK -> 0x%pK)",
+	VM_EVENT(kvm, 2, "Switched to ESCA (0x%p -> 0x%p)",
 		 old_sca, kvm->arch.sca);
 	return 0;
 }
@@ -4025,7 +4025,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
 			goto out_free_sie_block;
 	}
 
-	VM_EVENT(vcpu->kvm, 3, "create cpu %d at 0x%pK, sie block at 0x%pK",
+	VM_EVENT(vcpu->kvm, 3, "create cpu %d at 0x%p, sie block at 0x%p",
 		 vcpu->vcpu_id, vcpu, vcpu->arch.sie_block);
 	trace_kvm_s390_create_vcpu(vcpu->vcpu_id, vcpu, vcpu->arch.sie_block);
 

-- 
2.48.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH 2/2] KVM: s390: Don't use %pK through debug printing
  2025-02-17 13:13 ` [PATCH 2/2] KVM: s390: Don't use %pK through debug printing Thomas Weißschuh
@ 2025-02-25 12:56   ` Michael Mueller
  0 siblings, 0 replies; 6+ messages in thread
From: Michael Mueller @ 2025-02-25 12:56 UTC (permalink / raw)
  To: Thomas Weißschuh, Christian Borntraeger, Janosch Frank,
	Claudio Imbrenda, David Hildenbrand, Heiko Carstens,
	Vasily Gorbik, Alexander Gordeev, Sven Schnelle
  Cc: kvm, linux-s390, linux-kernel



On 17.02.25 14:13, Thomas Weißschuh wrote:
> Restricted pointers ("%pK") are only meant to be used when directly
> printing to a file from task context.
> Otherwise it can unintentionally expose security sensitive,
> raw pointer values.
> 
> Use regular pointer formatting instead.
> 
> Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>


I sucessfully ran our test suite after applying this patch.

Reviewed-by: Michael Mueller <mimu@linux.ibm.com>
Tested-by: Michael Mueller <mimu@linux.ibm.com>

> ---
>   arch/s390/kvm/intercept.c |  2 +-
>   arch/s390/kvm/interrupt.c |  8 ++++----
>   arch/s390/kvm/kvm-s390.c  | 10 +++++-----
>   3 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c
> index 610dd44a948b22945b0a35b760ded64bd44ef7cb..a06a000f196ce0066bfd21b0d914492a1796819a 100644
> --- a/arch/s390/kvm/intercept.c
> +++ b/arch/s390/kvm/intercept.c
> @@ -95,7 +95,7 @@ static int handle_validity(struct kvm_vcpu *vcpu)
>   
>   	vcpu->stat.exit_validity++;
>   	trace_kvm_s390_intercept_validity(vcpu, viwhy);
> -	KVM_EVENT(3, "validity intercept 0x%x for pid %u (kvm 0x%pK)", viwhy,
> +	KVM_EVENT(3, "validity intercept 0x%x for pid %u (kvm 0x%p)", viwhy,
>   		  current->pid, vcpu->kvm);
>   
>   	/* do not warn on invalid runtime instrumentation mode */
> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
> index 07ff0e10cb7f5c0294bf85f1d65d1eb124698705..c0558f05400732b2fe6911c1ef58f86b62364770 100644
> --- a/arch/s390/kvm/interrupt.c
> +++ b/arch/s390/kvm/interrupt.c
> @@ -3161,7 +3161,7 @@ void kvm_s390_gisa_clear(struct kvm *kvm)
>   	if (!gi->origin)
>   		return;
>   	gisa_clear_ipm(gi->origin);
> -	VM_EVENT(kvm, 3, "gisa 0x%pK cleared", gi->origin);
> +	VM_EVENT(kvm, 3, "gisa 0x%p cleared", gi->origin);
>   }
>   
>   void kvm_s390_gisa_init(struct kvm *kvm)
> @@ -3178,7 +3178,7 @@ void kvm_s390_gisa_init(struct kvm *kvm)
>   	gi->timer.function = gisa_vcpu_kicker;
>   	memset(gi->origin, 0, sizeof(struct kvm_s390_gisa));
>   	gi->origin->next_alert = (u32)virt_to_phys(gi->origin);
> -	VM_EVENT(kvm, 3, "gisa 0x%pK initialized", gi->origin);
> +	VM_EVENT(kvm, 3, "gisa 0x%p initialized", gi->origin);
>   }
>   
>   void kvm_s390_gisa_enable(struct kvm *kvm)
> @@ -3219,7 +3219,7 @@ void kvm_s390_gisa_destroy(struct kvm *kvm)
>   		process_gib_alert_list();
>   	hrtimer_cancel(&gi->timer);
>   	gi->origin = NULL;
> -	VM_EVENT(kvm, 3, "gisa 0x%pK destroyed", gisa);
> +	VM_EVENT(kvm, 3, "gisa 0x%p destroyed", gisa);
>   }
>   
>   void kvm_s390_gisa_disable(struct kvm *kvm)
> @@ -3468,7 +3468,7 @@ int __init kvm_s390_gib_init(u8 nisc)
>   		}
>   	}
>   
> -	KVM_EVENT(3, "gib 0x%pK (nisc=%d) initialized", gib, gib->nisc);
> +	KVM_EVENT(3, "gib 0x%p (nisc=%d) initialized", gib, gib->nisc);
>   	goto out;
>   
>   out_unreg_gal:
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index ebecb96bacce7d75563bd3a130a7cc31869dc254..9e427ba3aed42edf617d6625b5bcaba8f43dc464 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -1020,7 +1020,7 @@ static int kvm_s390_set_mem_control(struct kvm *kvm, struct kvm_device_attr *att
>   		}
>   		mutex_unlock(&kvm->lock);
>   		VM_EVENT(kvm, 3, "SET: max guest address: %lu", new_limit);
> -		VM_EVENT(kvm, 3, "New guest asce: 0x%pK",
> +		VM_EVENT(kvm, 3, "New guest asce: 0x%p",
>   			 (void *) kvm->arch.gmap->asce);
>   		break;
>   	}
> @@ -3464,7 +3464,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
>   		kvm_s390_gisa_init(kvm);
>   	INIT_LIST_HEAD(&kvm->arch.pv.need_cleanup);
>   	kvm->arch.pv.set_aside = NULL;
> -	KVM_EVENT(3, "vm 0x%pK created by pid %u", kvm, current->pid);
> +	KVM_EVENT(3, "vm 0x%p created by pid %u", kvm, current->pid);
>   
>   	return 0;
>   out_err:
> @@ -3527,7 +3527,7 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
>   	kvm_s390_destroy_adapters(kvm);
>   	kvm_s390_clear_float_irqs(kvm);
>   	kvm_s390_vsie_destroy(kvm);
> -	KVM_EVENT(3, "vm 0x%pK destroyed", kvm);
> +	KVM_EVENT(3, "vm 0x%p destroyed", kvm);
>   }
>   
>   /* Section: vcpu related */
> @@ -3648,7 +3648,7 @@ static int sca_switch_to_extended(struct kvm *kvm)
>   
>   	free_page((unsigned long)old_sca);
>   
> -	VM_EVENT(kvm, 2, "Switched to ESCA (0x%pK -> 0x%pK)",
> +	VM_EVENT(kvm, 2, "Switched to ESCA (0x%p -> 0x%p)",
>   		 old_sca, kvm->arch.sca);
>   	return 0;
>   }
> @@ -4025,7 +4025,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
>   			goto out_free_sie_block;
>   	}
>   
> -	VM_EVENT(vcpu->kvm, 3, "create cpu %d at 0x%pK, sie block at 0x%pK",
> +	VM_EVENT(vcpu->kvm, 3, "create cpu %d at 0x%p, sie block at 0x%p",
>   		 vcpu->vcpu_id, vcpu, vcpu->arch.sie_block);
>   	trace_kvm_s390_create_vcpu(vcpu->vcpu_id, vcpu, vcpu->arch.sie_block);
>   
> 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 1/2] KVM: s390: Don't use %pK through tracepoints
  2025-02-17 13:13 ` [PATCH 1/2] KVM: s390: Don't use %pK through tracepoints Thomas Weißschuh
@ 2025-02-25 13:08   ` Michael Mueller
  0 siblings, 0 replies; 6+ messages in thread
From: Michael Mueller @ 2025-02-25 13:08 UTC (permalink / raw)
  To: Thomas Weißschuh, Christian Borntraeger, Janosch Frank,
	Claudio Imbrenda, David Hildenbrand, Heiko Carstens,
	Vasily Gorbik, Alexander Gordeev, Sven Schnelle
  Cc: kvm, linux-s390, linux-kernel



On 17.02.25 14:13, Thomas Weißschuh wrote:
> Restricted pointers ("%pK") are not meant to be used through TP_format().
> It can unintentionally expose security sensitive, raw pointer values.
> 
> Use regular pointer formatting instead.
> 
> Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

Reviewed-by: Michael Mueller <mimu@linux.ibm.com>

> ---
>   arch/s390/kvm/trace-s390.h | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/s390/kvm/trace-s390.h b/arch/s390/kvm/trace-s390.h
> index 9ac92dbf680dbbe7703dd63945968b1cda46cf13..9e28f165c114caab99857ed3b53edc6ed5045dfa 100644
> --- a/arch/s390/kvm/trace-s390.h
> +++ b/arch/s390/kvm/trace-s390.h
> @@ -56,7 +56,7 @@ TRACE_EVENT(kvm_s390_create_vcpu,
>   		    __entry->sie_block = sie_block;
>   		    ),
>   
> -	    TP_printk("create cpu %d at 0x%pK, sie block at 0x%pK",
> +	    TP_printk("create cpu %d at 0x%p, sie block at 0x%p",
>   		      __entry->id, __entry->vcpu, __entry->sie_block)
>   	);
>   
> @@ -255,7 +255,7 @@ TRACE_EVENT(kvm_s390_enable_css,
>   		    __entry->kvm = kvm;
>   		    ),
>   
> -	    TP_printk("enabling channel I/O support (kvm @ %pK)\n",
> +	    TP_printk("enabling channel I/O support (kvm @ %p)\n",
>   		      __entry->kvm)
>   	);
>   
> 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 0/2] KVM: s390: Don't use %pK through debug printing or tracepoints
  2025-02-17 13:13 [PATCH 0/2] KVM: s390: Don't use %pK through debug printing or tracepoints Thomas Weißschuh
  2025-02-17 13:13 ` [PATCH 1/2] KVM: s390: Don't use %pK through tracepoints Thomas Weißschuh
  2025-02-17 13:13 ` [PATCH 2/2] KVM: s390: Don't use %pK through debug printing Thomas Weißschuh
@ 2025-02-27 16:04 ` Janosch Frank
  2 siblings, 0 replies; 6+ messages in thread
From: Janosch Frank @ 2025-02-27 16:04 UTC (permalink / raw)
  To: Thomas Weißschuh, Christian Borntraeger, Claudio Imbrenda,
	David Hildenbrand, Heiko Carstens, Vasily Gorbik,
	Alexander Gordeev, Sven Schnelle
  Cc: kvm, linux-s390, linux-kernel

On 2/17/25 2:13 PM, Thomas Weißschuh wrote:
> Restricted pointers ("%pK") are only meant to be used when directly
> printing to a file from task context.
> Otherwise it can unintentionally expose security sensitive, raw pointer values.
> 
> Use regular pointer formatting instead.


Thanks, picked!



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2025-02-27 16:04 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-02-17 13:13 [PATCH 0/2] KVM: s390: Don't use %pK through debug printing or tracepoints Thomas Weißschuh
2025-02-17 13:13 ` [PATCH 1/2] KVM: s390: Don't use %pK through tracepoints Thomas Weißschuh
2025-02-25 13:08   ` Michael Mueller
2025-02-17 13:13 ` [PATCH 2/2] KVM: s390: Don't use %pK through debug printing Thomas Weißschuh
2025-02-25 12:56   ` Michael Mueller
2025-02-27 16:04 ` [PATCH 0/2] KVM: s390: Don't use %pK through debug printing or tracepoints Janosch Frank

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox