On Wed, May 31, 2023 at 02:55:35PM +0100, 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? ;-) > Might I suggest FOLL_FOLL? As we are essentially 'following' the page once 'pinned'. We could differentiate between what is currently FOLL_GET and FOLL_PIN by using FOLL_FOLL and FOLL_FOLL_FOLL. Patch series coming soon... > > 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 >
