On Sun, Sep 20, 2020 at 08:23:26AM +0200, Thomas Gleixner wrote:
On Sat, Sep 19 2020 at 12:37, Daniel Vetter wrote:
On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter daniel@ffwll.ch wrote:
I think it should be the case, but I want to double check: Will copy_*_user be allowed within a kmap_temporary section? This would allow us to ditch an absolute pile of slowpaths.
(coffee just kicked in) copy_*_user is ofc allowed, but if you hit a page fault you get a short read/write. This looks like it would remove the need to handle these in a slowpath, since page faults can now be served in this new kmap_temporary sections. But this sounds too good to be true, so I'm wondering what I'm missing.
In principle we could allow pagefaults, but not with the currently proposed interface which can be called from any context. Obviously if called from atomic context it can't handle user page faults.
Yeah that's clear, but does the implemention need to disable pagefaults unconditionally?
In theory we could make a variant which does not disable pagefaults, but that's what kmap() already provides.
Currently we have a bunch of code which roughly does
kmap_atomic(); copy_*_user(); kunmap_atomic();
if (short_copy_user) { kmap(); copy_*_user(remaining_stuff); kunmap(); }
And the only reason is that kmap is a notch slower, hence the fastpath. If we get a kmap which is fast and allows pagefaults (only in contexts that allow pagefaults already ofc) then we can ditch a pile of kmap users.
Cheers, Daniel