On Tue, Dec 15, 2020 at 06:09:02PM -0800, Andy Lutomirski wrote:
On Tue, Dec 15, 2020 at 5:32 PM Ira Weiny ira.weiny@intel.com wrote:
On Fri, Dec 11, 2020 at 02:14:28PM -0800, Andy Lutomirski wrote:
On Mon, Nov 23, 2020 at 10:10 PM ira.weiny@intel.com wrote:
IOW we have:
struct extended_pt_regs { bool rcu_whatever; other generic fields here; struct arch_extended_pt_regs arch_regs; struct pt_regs regs; };
and arch_extended_pt_regs has unsigned long pks;
and instead of passing a pointer to irqentry_state_t to the generic entry/exit code, we just pass a pt_regs pointer. And we have a little accessor like:
struct extended_pt_regs *extended_regs(struct pt_regs *) { return container_of(...); }
And we tell eBPF that extended_pt_regs is NOT ABI, and we will change it whenever we feel like just to keep you on your toes, thank you very much.
Does this seem reasonable?
Conceptually yes. But I'm failing to see how this implementation can be made generic for the generic fields. The pks fields, assuming they stay x86 specific, would be reasonable to add in PUSH_AND_CLEAR_REGS. But the rcu/lockdep field is generic. Wouldn't we have to modify every architecture to add space for the rcu/lockdep bool?
If not, where is a generic place that could be done? Basically I'm missing how the effective stack structure can look like this:
struct extended_pt_regs { bool rcu_whatever; other generic fields here; struct arch_extended_pt_regs arch_regs; struct pt_regs regs; };
It seems more reasonable to make it look like:
#ifdef CONFIG_ARCH_HAS_SUPERVISOR_PKEYS struct extended_pt_regs { unsigned long pkrs; struct pt_regs regs; }; #endif
And leave the rcu/lockdep bool passed by value as before (still in C).
We could certainly do this,
I'm going to start with this basic support. Because I have 0 experience in most of these architectures.
but we could also allocate some generic space. PUSH_AND_CLEAR_REGS would get an extra instruction like:
subq %rsp, $GENERIC_PTREGS_SIZE
or however this should be written. That field would be defined in asm-offsets.c. And yes, all the generic-entry architectures would need to get onboard.
What do you mean by 'generic-entry' architectures? I thought they all used the generic entry code?
Regardless I would need to start another thread on this topic with any of those architecture maintainers to see what the work load would be for this. I don't think I can do it on my own.
FWIW I think it is a bit unfair to hold up the PKS support in x86 for making these generic fields part of the stack frame. So perhaps that could be made a follow on to the PKS series?
If we wanted to be fancy, we could split the generic area into initialize-to-zero and uninitialized for debugging purposes, but that might be more complication than is worthwhile.
Ok, agreed, but this is step 3 or 4 at the earliest.
Ira