linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Harish Mara" <Harish.Mara@ibm.com>
To: linux-kernel <linux-kernel@vger.kernel.org>
Cc: "Aniket Kulkarni" <aniket.kulkarni@us.ibm.com>,
	"Rajshekar Iyer" <iyerr@us.ibm.com>,
	"Pawan Powar" <ppowar@us.ibm.com>,
	ask@linux.vnet.ibm.com
Subject: Question regarding map count for compound pages
Date: Fri, 12 Nov 2021 16:33:47 -0400	[thread overview]
Message-ID: <OFC84A937E.DCF95A5F-ON0025878A.0080F49D-8525878B.0070F4CB@ibm.com> (raw)

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?


                 reply	other threads:[~2021-11-12 20:33 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OFC84A937E.DCF95A5F-ON0025878A.0080F49D-8525878B.0070F4CB@ibm.com \
    --to=harish.mara@ibm.com \
    --cc=aniket.kulkarni@us.ibm.com \
    --cc=ask@linux.vnet.ibm.com \
    --cc=iyerr@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ppowar@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).