[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86/oprofile: remove compat accessors usage from backtrace


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 23 Apr 2021 15:51:14 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FmFvbmj2re7gSkY5LQiY53/AQqEKEF1QrBZ/XaB/qpw=; b=oPU1fJl/EMRqNQ4onICUmR3T0IWgsoC9/a8I0IQJwS6QVN0ioRXPRnVfgcNmBrdxeOY4eVTjcwj+m9qICmqBHQdR5g7syJ6SD36gdBluUYasObInRNcYPHexkDmY+56G128WaIKZs3HKitAh7pNM9506mehVnUFA7opkL8MTMpv5okbwiEjsaZ6qbBSJXvqyvtvYHuD8pImEjOFctyc3/YXjqGab64NYr1KDaoWrJ0nsq/PPTNOcN85efwLzL6obQRKCp8tJazba1HJuv3PqV896GrV9Z6cAq4stVnHsrvLJhSXUtH8e8nDQSsZ9ueBfQEyioq5Gpl5Yh/W14GRx6A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dM8kMuS7bzYZpQLZ5YPuVXddZQWXHB3DiCnoBTJFsInhoSU7mJuqahauKOwdq/WarziR2wiJ3Ce7GdspbNuHjh1/f3JKfrkbmt2oFqw/9DkXZR/Lqobnr+4tPIj3FNawwbwfme4I/1+nJwcOIYOVv6n6/HicDTRLjqBeZotoa++ijrzqvS1ir0ye0kyclybdQ+IZfKR63pkALuqTJ5U5kcvj7zCH5n5+8kKojAv/Y/p9MyUuXuPZs4TkIzHq7eV1U1gXT1zEdaPducAAXz764G1eiYYyKifNg4H34Uazhxc04Fva7KocwxUKeB2kkqUwtf1YmDujI7XMUP3yxXGTpQ==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 23 Apr 2021 13:51:27 +0000
  • Ironport-hdrordr: A9a23:LahlBaDnOm+fJMblHej3sceALOonbusQ8zAX/mpaICY1TuWzkc eykPMHkSLugDEKV3063fyGMq+MQXTTnKQFhLU5F7GkQQXgpS+UPJhvhLGSoQHINiXi+odmtZ tIXLN5DLTLYmRSqebfzE2GH807wN+BmZrFuc77w212RQ9nL4FMhj0JbjqzKUF9SAlYCZdRLv P1jKd6jgGtZGgNaYCDDmQFNtKzwOHjro7sYhINGnccmWqzpA6vgYSVLzGomj0EVSlU+Kwv9W jenxbZ6q2vv+qg5R/YymPJ45l8iOHszdZoAsuKhsIJLC6EsG2VTbUkfaaNtDc0s+mz6FAssd XFrhs6Jf1p52ncZX64rHLWqm/d7Ao=
  • Ironport-sdr: +8tgCfwlES+dhLKNE6QFYglt205fRmPGyOucG3OC9aQy3A94rEx8a4KzucpEMeH8ELbn94iRdQ 7erKGsS6BKnW5c0xy6z3ppiiS91ToP7AUN7bQyjX5Z+yBqZnUM15+kakCiqv3/rEpWVvnIqe2v EHw52s/ik+Dk/vYpBWjaUTGQRIRLCTeWmhAB5IY2YAMTrlpyCvLXHrNTAM/krDfaxPOTEx3VvP RlXLF+0fZQvY30UyZmqjZwvrywXaEnPWo917T8pGO2sVM2fWbfJzqY2StPjtwsiWbcB2NQEK/l MAg=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Apr 23, 2021 at 02:53:14PM +0200, Jan Beulich wrote:
> On 23.04.2021 14:35, Roger Pau Monne wrote:
> > Remove the unneeded usage of the compat layer to copy frame pointers
> > from guest address space. Instead just use raw_copy_from_guest.
> > 
> > Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > ---
> > Just build tested. Note sure I'm missing something, since using the
> > compat layer here was IMO much more complicated than just using the
> > raw accessors.
> 
> The main reason, I suppose, was that raw_copy_*() aren't supposed to
> be used directly.
> 
> > @@ -59,34 +56,17 @@ dump_guest_backtrace(struct vcpu *vcpu, const struct 
> > frame_head *head,
> >  {
> >      frame_head_t bufhead;
> >  
> > -#ifdef CONFIG_COMPAT
> >      if ( is_32bit_vcpu(vcpu) )
> >      {
> > -        DEFINE_COMPAT_HANDLE(frame_head32_t);
> > -        __compat_handle_const_frame_head32_t guest_head =
> > -            { .c = (unsigned long)head };
> 
> You're losing the truncation to 32 bits here.

I didn't think it was relevant here, as value should already have the
high bits zeroed?

One being the rbp from the guest cpu registers and the other a
recursive call using bufhead.ebp.

> >          frame_head32_t bufhead32;
> >  
> > -        /* Also check accessibility of one struct frame_head beyond */
> > -        if (!compat_handle_okay(guest_head, 2))
> > -            return 0;
> 
> If you intentionally remove this and ...
> 
> > -        if (__copy_from_compat(&bufhead32, guest_head, 1))
> > +        if (raw_copy_from_guest(&bufhead32, head, sizeof(bufhead32)))
> >              return 0;
> >          bufhead.ebp = (struct frame_head *)(unsigned long)bufhead32.ebp;
> >          bufhead.ret = bufhead32.ret;
> >      }
> > -    else
> > -#endif
> > -    {
> > -        XEN_GUEST_HANDLE_PARAM(const_frame_head_t) guest_head =
> > -            const_guest_handle_from_ptr(head, frame_head_t);
> > -
> > -        /* Also check accessibility of one struct frame_head beyond */
> > -        if (!guest_handle_okay(guest_head, 2))
> > -            return 0;
> 
> ... this, then you should justify why these aren't needed anymore
> (or maybe were never really needed). They've been put there for a
> purpose, I'm sure, even if I'm unclear about what one it was/is.

I've been doing some archaeology on Linux and I'm still not sure why
this is required. Linux copies two frame_head{32,}_t elements, so we
could follow suit and do the same - albeit I won't be able to provide
a reasoning myself as to why this is required, the second element
seems to be completely unused.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.