On 26.4.2023 11.41, Lorenzo Stoakes wrote:
On Wed, Apr 26, 2023 at 10:30:03AM +0300, Mika Penttilä wrote:
[snip]
The issue is how dirtying works. Typically for a dirty-tracking mapping the
kernel makes the mapping read-only, then when a write fault occurs,
writenotify is called and the folio is marked dirty. This way the file
system knows which files to writeback, then after writeback it 'cleans'
them, restoring the read-only mapping and relying on the NEXT write marking
write notifying and marking the folio dirty again.
I know how the dirty tracking works :). And gup itself actually triggers the
_first_ fault on a read only pte.
I'm sure you don't mean to, but this comes off as sarcastic, 'I know how X
works :)' is not a helpful comment. However, equally apologies if I seemed
patronising, not intentional, I am just trying to be as clear as possible,
which always risks sounding that way :)
Absolutely didn't mean that way, and thanks for being clear here!
Regardless, this is a very good point! I think I was a little too implicit
in the whole 'at any time the kernel chooses to write to this writenotify
won't happen', and you are absolutely right in that we are not clear enough
about that.
So the problem is accessing the page after that, somewehere in future. I
think this is something you should write on the description. Because,
technically, GUP itself works and does invoke the write notify. So the
misleading part is you say in the description it doesn't. While you mean a
later write, from a driver or such, doesn't.
Ack, agreed this would be a useful improvement. Will fix on next spin!
Yes thanks, think so, at least found myself going thru and wondering
what's wrong with the gup code itself, and not the later usage scenario...
[snip]
--Mika
