There are important reasons why the current API revokes write permission on the pages that it loans out. uvm_loan() returns a page array, so technically the kernel could map them read-write if it wanted to. But the idea is that everyone has a read-only-but-COW view so that if the owner of the page modifies it, it gets a new copy of the page so that that loanee has a stable view. It was designed to mirror the semantics of e.g. write(2). In the case of the pipe code, it appears the sender blocks until the receiver has read the entire loaned region, so this is mitigated a bit (in theory, with your suggested change, it could be possible for some other thread in the sending process to scribble the loaned buffer, but this wouldn’t really be any different than in the non-direct-but-blocked case, because you never know how much as been uiomove()’d into the kernel at any given point, only that once the write() call returns that the kernel owns whatever data was written and expects it not to change). I suppose I don’t really object to the change so long as there’s an explicit behavior choice in the loan API. Huh, I just noticed that sosend() has the page loaning support there disabled in the MULTIPROCESSOR case. That’s a bummer. -- thorpej
|