On Wed, Oct 9, 2019 at 1:06 PM Thomas HellstrÃm (VMware)It's not so much arguing but rather trying to understand your concerns and your perception of what the final code should look like.
<thomas_os@xxxxxxxxxxxx> wrote:
On 10/9/19 9:20 PM, Linus Torvalds wrote:It's not about what you're trying to achieve.
Don't you get it? There *is* no PTE level if you didn't split.Hmm, This paragraph makes me think we have very different perceptions about what I'm trying to achieve.
It's about the actual code.
You cannot do that
- split_huge_pmd(walk->vma, pmd, addr);it's insane.
+ if (!ops->pmd_entry)
+ split_huge_pmd(walk->vma, pmd, addr);
You *have* to call split_huge_pmd() if you're doing to call the
pte_entry() function.
I don't understand why you are arguing. This is not about "feelings"
and "intentions" or about "trying to achieve".
This is about cold hard "you can't do that", and this is now the third
time I tell you _why_ you can't do that: you can't walk the last level
if you don't _have_ a last level. You have to split the pmd to do so.
End of story.
No, it's typically a NOP, since the hugepmd should be read-only. Write-enabled huge pages are split in fault().
I wanted the pte level to *only* get called for *pre-existing* pte entries.Again, I told you what the solution was.
But the fact is, it's not what your other code even wants or does.
Seriously. You have two cases you care about in your callbacks
- an actual hugepmd. This is an ERROR for you and you do a huge
WARN_ON() for it to let people know.
Well, this is not what we want to do, and the reason we have the patch in the first place.
- regular pages. This is what your other code actually handles.
So for the hugepomd case, you have two choices:
- handle it by splitting and deal with the regular pages: "return 0;"
- actually error out: "return -EINVAL".