diff options
| author | Andrew Morton <akpm@digeo.com> | 2003-02-05 16:58:38 -0800 |
|---|---|---|
| committer | Linus Torvalds <torvalds@home.transmeta.com> | 2003-02-05 16:58:38 -0800 |
| commit | 8b5111ec625859a3a56f04598fd85e89622228a5 (patch) | |
| tree | 0d8efc95e1ab0c5982bd4040883862e4401ae8aa /include/linux | |
| parent | 08a1cc4eb53dd834ddfcda3d70b0def5ed15f747 (diff) | |
[PATCH] Fix hugetlbfs faults
If the underlying mapping was truncated and someone references the
now-unmapped memory the kernel will enter handle_mm_fault() and will start
instantiating PAGE_SIZE pte's inside the hugepage VMA. Everything goes
generally pear-shaped.
So trap this in handle_mm_fault(). It adds no overhead to non-hugepage
builds.
Another possible fix would be to not unmap the huge pages at all in truncate
- just anonymise them.
But I think we want full ftruncate semantics for hugepages for management
purposes.
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions
