From: "zenek blus" <zenblu@wp.pl>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Calling vm_ops->open from a driver / reusing vma memory with vm_ops in other drivers
Date: Mon, 06 Sep 2010 06:49:41 +0200 [thread overview]
Message-ID: <4c8472e5c36922.92225774@wp.pl> (raw)
Hello,
I have the following problem:
Driver A has a custom mmap() implementation and assigns own vm_ops to a
created vma.
The process which called mmap() passes the resulting userspace address
to another
driver, driver B.
Driver B would then like to increment usage count on that memory for a
duration of
some operation, i.e. call vm_ops->open(). It can find_vma() for the
userspace address
it was given and call vm_ops->open() on found vma. It can then call
vm_ops->close()
when finished.
The problem here though is that the found vm_area_struct (and the
userspace address
for that matter) might not be valid anymore by the time driver B wants
to call close().
There can be three possibilities here:
a) vm_area_struct used for open() is still present and can be reused for
close()
- that looks ok, but storing a pointer to that vma is risky, driver B
has no way to
know whether the pointer is still valid.
b) some other vm_area_structs are still present, but driver B has no
knowledge
about them - so it does not have anything to pass to close().
c) no vm_area_structs remain, but since we called open() before, driver
A is still
waiting for driver B to call close(); driver B does not have anything to
pass to
close() and there is nothing in the system that could be passed to it
anyway.
I don't suppose copying aside the whoe vm_area_struct used for open()
call and passing
it back to close() is a good idea. Is there any way to do this? Or maybe
I have it all
wrong?
Thank you,
Zenek
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
reply other threads:[~2010-09-06 4:49 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=4c8472e5c36922.92225774@wp.pl \
--to=zenblu@wp.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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