On 31.05.23 15:55, David Howells wrote:
David Hildenbrand <david@xxxxxxxxxx> wrote:
Yes, it would be clearer if we would be using "pinned" now only for FOLL_PIN
You're not likely to get that. "To pin" is too useful a verb that gets used
in other contexts too. For that reason, I think FOLL_PIN was a poor choice of
name:-/. I guess the English language has got somewhat overloaded. Maybe
FOLL_PEG? ;-)
You're probably right. FOLL_PIN and all around that is "get me an
additional reference on the page and make sure I can DMA it without any
undesired side-effects".
FOLL_PIN_DMA would have been clearer (and matches
folio_maybe_dma_pinned() ) ... but then, there are some use cases where
want the same semantics but not actually perform DMA, but simply
read/write via the directmap (e.g., vmsplice, some io_uring cases).
Sure, one could say that they behave like DMA: access page content at
any time.
Saying a page is pinned (additional refcount) and having a pincount of 0
or does indeed cause confusion.
... but once we start renaming FOLL_PIN, pincount, ... we also have to
rename pin_user_pages() and friends, and things get nasty.
and everything else is simply "taking a temporary reference on the page".
Excluding refs taken with pins, many refs are more permanent than pins as, so
far as I'm aware, pins only last for the duration of an I/O operation.
I was more thinking along the lines of FOLL_GET vs. FOLL_PIN. Once we
consider any references we might have on a page, things get more tricky
indeed.
"Note that the refcount of any zero_pages returned among the pinned pages will
not be incremented, and unpin_user_page() will similarly not decrement it."
That's not really right (although it happens to be true), because we're
talking primarily about the pin counter, not the refcount - and they may be
separate.
In any case (FOLL_PIN/FOLL_GET) you increment/decrement the refcount. If we
have a separate pincount, we increment/decrement the refcount by 1 when
(un)pinning.
FOLL_GET isn't relevant here - only FOLL_PIN. Yes, as it happens, we count a
ref if we count a pin, but that's kind of irrelevant; what matters is that the
effect must be undone with un-PUP.
The point I was trying to make is that we always modify the refcount,
and in some cases (FOLL_PIN on order > 0) also the pincount.
But if you define "pins" as "additional reference", we're on the same page.
It would be nice not to get a ref on the zero page in FOLL_GET, but I don't
think we can do that yet. Too many places assume that GUP will give them a
ref they can release later via ordinary methods.
No we can't I'm afraid.
--
Thanks,
David / dhildenb
