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? ;-) > 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. > >> "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. 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. David
