On Fri, Jan 10, 2020 at 06:28:00PM +0000, Catalin Marinas wrote: > On Wed, Dec 11, 2019 at 03:41:58PM +0000, Mark Brown wrote: > > /* Additional SPSR bits not exposed in the UABI */ > > +#define PSR_BTYPE_SHIFT 10 > > + > > #define PSR_IL_BIT (1 << 20) > > > > +/* Convenience names for the values of PSTATE.BTYPE */ > > +#define PSR_BTYPE_NONE (0b00 << PSR_BTYPE_SHIFT) > > +#define PSR_BTYPE_JC (0b01 << PSR_BTYPE_SHIFT) > > +#define PSR_BTYPE_C (0b10 << PSR_BTYPE_SHIFT) > > +#define PSR_BTYPE_J (0b11 << PSR_BTYPE_SHIFT) > Would these be better placed in the uapi/ptrace.h? Seems reasonable, they might be useful to virt stuff and they're part of the architecture so it's not like we might change them. > > + /* > > + * BTI note: > > + * The architecture does not guarantee that SPSR.BTYPE is zero > > + * on taking an SVC, so we could return to userspace with a > > + * non-zero BTYPE after the syscall. > On page 2580 of the ARM ARM there is a statement that "any instruction > other than BR, ..." sets BTYPE to 0. Wouldn't SVC fall into the same > category? I think what Dave was referring to there is that (unless I'm misreading things) that section of the ARM says that BTYPE is set at the end of the execution of the instruction but since SVC is specified as generating an exception that means that when we enter the kernel the instruction won't have ended yet and we still have the BTYPE from the previous instruction. > Reviewed-by: Catalin Marinas <catalin.marinas@xxxxxxx> Thanks.
Attachment:
signature.asc
Description: PGP signature
