On 11/15/21 20:47, Harish Mara wrote:
Background:
On older kernel?s, we could have our device driver create char devices and
implement file_operations and vm_operations for open, release, mmap, fault
etc. The driver allocates memory (128KB, order 5) as compound pages.
The user application would then map/mmap these device files to perform
read/write operations.
On recent kernels, this creates problems when the user space maps multiple
128KB chunks that exceed 2MB. This would sometime result in bad page
getting mapped to the user space process. Almost always we see ?Bad page
map? errors during munmap because the map count is going below 0.
It looks like the culprit is zap_pte_range(), which calls
page_remove_rmap() with the compound_flag = false. As a result, instead of
decrementing the compound_mapcount for the page the page->_mapcount is
decremented causing a lot of bad page errors.
Questions:
Is this the right usage of compound pages? I.e can I allocate compound
pages in my kernel driver to be mapped to char device file by a user
process?
If yes, then why does it fail on latest kernel when the mmap-ed size
exceeds 2MB?
If no, why was it working on the older kernels? If it worked then,
shouldn?t it work now?
What is special about map size being greater than 2MB to trigger this?
Should compound pages be used for Anonymous purposes only?
Hi.
It would certainly help if you could isolate when this behavior started
. Which version x.y.z version works ? And which one fail ?
