Re: [PATCH v2 6/8] arm64: stacktrace: remove stack type from fp translator

Mark Rutland
2022-08-08T12:15:55Z

On Mon, Aug 08, 2022 at 12:55:35PM +0100, Will Deacon wrote:
> On Fri, Aug 05, 2022 at 01:45:20PM +0100, Mark Rutland wrote:

> > /*
> > * kvm_nvhe_stack_kern_va - Convert KVM nVHE HYP stack addresses to a kernel VAs
> > *
> > @@ -34,27 +62,31 @@
> > * Returns true on success and updates @addr to its corresponding kernel VA;
> > * otherwise returns false.
> > */
> > -static bool kvm_nvhe_stack_kern_va(unsigned long *addr,
> > - enum stack_type type)
> > +static bool kvm_nvhe_stack_kern_va(unsigned long *addr)
> > {
> > struct kvm_nvhe_stacktrace_info *stacktrace_info;
> > unsigned long hyp_base, kern_base, hyp_offset;
> > + struct stack_info stack;
> >
> > stacktrace_info = this_cpu_ptr_nvhe_sym(kvm_stacktrace_info);
> >
> > - switch (type) {
> > - case STACK_TYPE_HYP:
> > + stack = stackinfo_get_hyp();
> > + if (stackinfo_on_stack(&stack, *addr, 1)) {
> > kern_base = (unsigned long)*this_cpu_ptr(&kvm_arm_hyp_stack_page);
> > hyp_base = (unsigned long)stacktrace_info->stack_base;
> > - break;
> > - case STACK_TYPE_OVERFLOW:
> > + goto found;
> > + }
> > +
> > + stack = stackinfo_get_overflow();
> > + if (stackinfo_on_stack(&stack, *addr, 1)) {
>
> Why is '1' the appropriate size for these two checks, given that addr points
> at an unsigned long?

That's a fair point.

My original rationale was that this was equivalent to the existing bheaviour,
since the range has arleady been checked, but I agree it's not nice, and won't
be right later in the series.

I'll adjust this to take an explicit size argument; the existing caller can
pass in sizeof(unsigned long), and it can be reused for other sized objects in
future.

Thanks,
Mark.