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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Apr 26, 2021 at 09:49:13AM +0200, Jan Beulich wrote:
> On 23.04.2021 16:37, 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.
> > 
> > While there drop the checks for the accessibility of one struct
> > frame_head beyond the current one: it's not clear why it's needed and
> > all the hypnoses point to dropping such check being harmless. The
> 
> DYM "hypotheses"?

Yes, sorry, selected the wrong spell checker suggestion I guess.

> 
> > worse that could happen is that a failure happens later if data past
> > frame_head is attempted to be fetched, albeit I'm not able to spot any
> > such access.
> > 
> > Also drop the explicit truncation of the head pointer in the 32bit
> > case as all callers already pass a zero extended value. The first
> > value being rsp from the guest registers,
> 
> While I know I'm guilty of splitting hair saying so, I'd like to point
> out that I'm unaware of guarantees that the upper halves of GPRs are
> zero after a switch from compat to 64-bit mode. With this I'm also
> unconvinced there are guarantees that the %rsp stored into a stack
> frame is actually guaranteed to be zero-extended. Nevertheless I'm not
> meaning this remark to keep the change from going in as is - for all
> practical purposes what you say is presumably true.

Also, given the context of this code (oprofile backtrace generation),
I'm unsure what issues could arise from not using a zero extended
value for a guest in 32bit mode apart from a failure to obtain the
backtrace itself.

> What I would consider nice though is if the two remaining if() could
> be corrected for coding style: Adjacent code is already inconsistent,
> so taking the opportunity to move it a little in the right direction
> would seem desirable to me. (I would suggest doing so myself while
> committing, but because I don't fully agree with dropping the 2-frame
> checks described further up without properly understanding why they're
> there, I'd like to not put my name on this change in any way, not even
> just as committer. But I guess Andrew or Wei or whoever ends up
> committing this could do so, as long as they agree of course.)

OK, I can add the 2-frame checks back in, I certainly don't have that
strong opinion and the resulting code will be better just by dropping
the usage of the compat layer even if we decide to keep those
checks.

Let me prepare a new version.

Thanks, Roger.