Andy Lutomirski luto@kernel.org writes:
On Jul 23, 2020, at 1:22 PM, Thomas Gleixner tglx@linutronix.de wrote: Andy Lutomirski luto@amacapital.net writes:
My suggestion is to enlarge pt_regs. The save and restore logic can probably be in C, but pt_regs is the logical place to put a register that is saved and restored across all entries.
Kinda, but that still sucks because schedule from #PF will get it wrong unless you do extra nasties.
This seems like we’re reinventing the wheel. PKRS is not fundamentally different from, say, RSP. If we want to save it across exceptions, we save it on entry and context-switch-out and restore it on exit and context-switch-in.
It's fundamentally different from RSP because it has state (refcount) attached, which RSP clearly has not. If you get rid of the state then yes.
Whoever does this work will have the delightful job of figuring out whether BPF thinks that the layout of pt_regs is ABI and, if so, fixing the resulting mess.
The fact the new fields will go at the beginning of pt_regs will make this an entertaining prospect.
Good luck with all of that.
We can always cheat like this:
struct real_pt_regs { unsigned long pkrs; struct pt_regs regs; };
and pass a pointer to regs around. What BPF doesn't know about can't hurt it.
Yes, but that's the easy part of the problem :)
Thanks,
tglx