public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pete Wyckoff <pw@osc.edu>
To: Dan Maas <dmaas@dcine.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: forcibly unmap pages in driver?
Date: Tue, 5 Jun 2001 19:31:34 -0400	[thread overview]
Message-ID: <20010605193134.B8037@bigger.osc.edu> (raw)
In-Reply-To: <04ea01c0ed67$ad3f38f0$0701a8c0@morph> <20010605182120.F23799@osc.edu> <078d01c0ee15$8072b960$0701a8c0@morph>
In-Reply-To: <078d01c0ee15$8072b960$0701a8c0@morph>; from dmaas@dcine.com on Tue, Jun 05, 2001 at 07:15:45PM -0400

dmaas@dcine.com said:
> My driver uses a variable-size DMA buffer that it shares with user-space; I
> provide an ioctl() to choose the buffer size and allocate the buffer. Say
> the user program chooses a large buffer size, and mmap()s the entire buffer.
> 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 - it might still have the large buffer mapped.
> What should I do here?
> 
> An easy solution would to allocate the largest possible buffer as my driver
> is loaded, even if not all of it will be exposed to user-space. I don't
> really like this choice because the buffer needs to be pinned in memory, and
> the largest useful buffer size is very big (several tens of MB). Maybe I
> should disallow more than one buffer allocation per open() of the device...
> But the memory mapping will stay around even after close(), correct? I'd
> hate to have to keep the buffer around until my driver module is unloaded.

I see.  Your explanation makes sense, and close won't affect the mmap
(unless you explicitly trigger it in the driver, which you should).
Other drivers deal with this; you may want to go grepping for do_munmap
and see how they handle it.

[ > pw@osc.edu said: ]
> > However, do_munmap() will call zap_page_range() for you and take care of
> > cache and TLB flushing if you're going to do this in the kernel.
> 
> I'm not sure if I could use do_munmap() -- how will I know if the user
> program has called munmap() already, and then mmap()ed something else in the
> same place? Then I'd be killing the wrong mapping...

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).

The less elegant way of doing this is to put in your userspace API some
conditions which say:  if you do the following:

    open(fd);
    ioctl(fd, give_me_the_buf);
    munmap(some_or_all_of_the_buf);
    buf2 = mmap(...);
    close(fd);  /* or ioctl(fd, shrink_the_buf); */
    buf2[27] = 3;

you will be killed with a sigbus.  I.e. don't manually munmap the
region.

		-- Pete

  reply	other threads:[~2001-06-05 23:32 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 [this message]
2001-06-06  0:13       ` Dan Maas
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=20010605193134.B8037@bigger.osc.edu \
    --to=pw@osc.edu \
    --cc=dmaas@dcine.com \
    --cc=linux-kernel@vger.kernel.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