From: "Dan Maas" <dmaas@dcine.com>
To: "Pete Wyckoff" <pw@osc.edu>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: forcibly unmap pages in driver?
Date: Tue, 5 Jun 2001 20:13:51 -0400 [thread overview]
Message-ID: <008001c0ee1d$90f1ec90$0701a8c0@morph> (raw)
In-Reply-To: <04ea01c0ed67$ad3f38f0$0701a8c0@morph> <20010605182120.F23799@osc.edu> <078d01c0ee15$8072b960$0701a8c0@morph> <20010605193134.B8037@bigger.osc.edu>
>> Later, the program calls the ioctl() again to set a smaller
>> buffer size, or closes the file descriptor. At this point
>> I'd like to shrink the buffer or free it completely. But I
>> can't assume that the program will be nice and munmap() the
>> region for me
> Look at drivers/char/drm, for example. At mmap time they allocate a
> vm_ops to the address space. With that you catch changes to the vma
> structure initiated by a user mmap, munmap, etc. You could also
> dynamically map the pages in using the nopage method (optional).
OK I think I have a solution... Whenever I need to re-allocate or free the
DMA buffer, I could set all of the user's corresponding page table entries
to deny all access. Then I'd get a page fault on the next access to the
buffer, and inside nopage() I could update the user's mapping or send a
SIGBUS as appropriate (hmm, just like restoring a file mapping that was
thrown away)... So I just have to figure out how to find the user's page
table entries that are pointing to the DMA buffer.
Regards,
Dan
next prev parent reply other threads:[~2001-06-06 0:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-05 2:31 forcibly unmap pages in driver? Dan Maas
2001-06-05 22:21 ` Pete Wyckoff
2001-06-05 23:15 ` Dan Maas
2001-06-05 23:31 ` Pete Wyckoff
2001-06-06 0:13 ` Dan Maas [this message]
2001-06-06 8:07 ` Martin Diehl
[not found] <fa.fk487iv.1d2ksb0@ifi.uio.no>
[not found] ` <fa.f3ckgov.ti0mb3@ifi.uio.no>
2001-06-07 3:46 ` Dan Maas
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='008001c0ee1d$90f1ec90$0701a8c0@morph' \
--to=dmaas@dcine.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pw@osc.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.