On Wed, Feb 12, 2020 at 6:41 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Also, vm_insert_page() does
>
> if (!page_count(page))
> return -EINVAL;
>
> and this was not carried over into vm_insert_pages(). How come?
Sounds like that was just a mistake.
> I don't know what that test does - it was added by Linus in the
> original commit a145dd411eb28c83. It's only been 15 years so I'm sure
> he remembers ;)
Oh, sure.
No, I have absolutely no memory of the details, but I think the commit
message is actually the big hint: the difference between
vm_insert_page() and some of the more random "insert any pdf" cases we
have is exactly that:
The page you insert needs to be a nice clean kernel allocation, so you
can't insert arbitrary page mappings with this, but that's not what
people want.
thing. The comment above it also kind of hints at it.
We *historically* had interfaces to insert random reserved pages (for
IO mappings, but also the zero page etc), but the whole point of that
vm_insert_page() is that it's now an interface for drivers to insert
the pages they maintain into the page tables.
But that also means that we very much didn't allow just random pages
accessed by doing pfn lookups (that might not be in use at all).
Is "page_count()" a great test? No. But it's at least _a_ test of
that. No reserved pages or other magic need apply.
Linus
