On 5/22/23 16:50, Alistair Popple wrote:
...
Again from include/linux/mmu_notifier.h, not implementing the start()/end() hooks
is perfectly valid. And AFAICT, the existing invalidate_range() hook is pretty
much a perfect fit for what you want to achieve.
Right, I didn't take that approach because it doesn't allow an event
type to be passed which would allow them to be filtered on platforms
which don't require this.
I had also assumed the invalidate_range() callbacks were allowed to
sleep, hence couldn't be called under PTL. That's certainly true of mmu
interval notifier callbacks, but Catalin reminded me that calls such as
ptep_clear_flush_notify() already call invalidate_range() callback under
PTL so I guess we already assume drivers don't sleep in their
invalidate_range() callbacks. I will update the comments to reflect
This line of reasoning feels very fragile. The range notifiers generally
do allow sleeping. They are using srcu (sleepable RCU) protection, btw.
The fact that existing callers are calling these under PTL just means
that so far, that has sorta worked. And yes, we can probably make this
all work. That's not really the ideal way to deduce the API rules, though,
and it would be good to clarify what they really are.
Aside from those use cases, I don't see anything justifying a "not allowed
to sleep" rule for .invalidate_range(), right?
thanks,
--
John Hubbard
NVIDIA
