On Tue, Mar 16, 2021 at 12:26:05PM -0700, Linus Torvalds wrote: > Note that the above very intentionally does allow the "we can go over > the limit" case for another reason: we still have that regular > *unconditional* get_page(), that has a "I absolutely need a temporary > ref to this page, but I know it's not some long-term thing that a user > can force". That's not only our traditional model, but it's something > that some kernel code simply does need, so it's a good feature in > itself. That might be less of an issue for ucounts, but for pages, we > somethines do have "I need to take a ref to this page just for my own > use while I then drop the page lock and do something else". Right, get_page() has a whole other set of requirements. :) I just couldn't find the "we _must_ to get a reference to ucounts" code path, so I was scratching my head. > And it's possible that "refcount_t" could use that exact same model, > and actually then offer that option that ucounts wants, of a "try to > get a refcount, but if we have too many refcounts, then never mind, I > can just return an error to user space instead". Yeah, if there starts to be more of these cases, I think it'd be a nice addition. And with the recent performance work Will Deacon did on refcount_t, I think any general performance concerns are met now. But I'd love to just leave refcount_t alone until we can really show a need for an API change. :P -- Kees Cook
