Just an update to my situation... I've implemented my idea of clearing the
associated PTE's when I need to free the DMA buffer, then re-filling them in
nopage(). This seems to work fine; if the user process tries anything fishy,
it gets a SIGBUS instead of accessing the old mapping.
I
On Tue, 5 Jun 2001, Pete Wyckoff wrote:
> [EMAIL PROTECTED] said:
> > user-space program is still running. I need to remove the user-space
> > mapping -- otherwise the user process would still have access to the
> > now-freed pages. I need an inverse of remap_page_range().
>
> That seems a bit
On Tue, 5 Jun 2001, Pete Wyckoff wrote:
[EMAIL PROTECTED] said:
user-space program is still running. I need to remove the user-space
mapping -- otherwise the user process would still have access to the
now-freed pages. I need an inverse of remap_page_range().
That seems a bit perverse.
Just an update to my situation... I've implemented my idea of clearing the
associated PTE's when I need to free the DMA buffer, then re-filling them in
nopage(). This seems to work fine; if the user process tries anything fishy,
it gets a SIGBUS instead of accessing the old mapping.
I
>> 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,
[EMAIL PROTECTED] 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()
> That seems a bit perverse. How will the poor userspace program know
> not to access the pages you have yanked away from it? If you plan
> to kill it, better to do that directly. If you plan to signal it
> that the mapping is gone, it can just call munmap() itself.
Thanks Pete. I will
[EMAIL PROTECTED] said:
> I am writing a device driver that, like many others, exposes a shared memory
> region to user-space via mmap(). The region is allocated with vmalloc(), the
> pages are marked reserved, and the user-space mapping is implemented with
> remap_page_range().
>
> In my
[EMAIL PROTECTED] said:
I am writing a device driver that, like many others, exposes a shared memory
region to user-space via mmap(). The region is allocated with vmalloc(), the
pages are marked reserved, and the user-space mapping is implemented with
remap_page_range().
In my driver, I
That seems a bit perverse. How will the poor userspace program know
not to access the pages you have yanked away from it? If you plan
to kill it, better to do that directly. If you plan to signal it
that the mapping is gone, it can just call munmap() itself.
Thanks Pete. I will explain
[EMAIL PROTECTED] 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
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.
I am writing a device driver that, like many others, exposes a shared memory
region to user-space via mmap(). The region is allocated with vmalloc(), the
pages are marked reserved, and the user-space mapping is implemented with
remap_page_range().
In my driver, I may have to free the underlying
I am writing a device driver that, like many others, exposes a shared memory
region to user-space via mmap(). The region is allocated with vmalloc(), the
pages are marked reserved, and the user-space mapping is implemented with
remap_page_range().
In my driver, I may have to free the underlying
14 matches
Mail list logo
