linux-kernel - Re: Question about memory mapping mechanism

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0703090138470.25365@kepler.fjfi.cvut.cz>
Date:	Fri, 9 Mar 2007 01:52:18 +0100 (CET)
From:	Martin Drab <drab@...ler.fjfi.cvut.cz>
To:	Robert Hancock <hancockr@...w.ca>
cc:	hugh@...itas.com, linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Question about memory mapping mechanism

On Thu, 8 Mar 2007, Robert Hancock wrote:

> Martin Drab wrote:
> > Hi,
> > 
> > I'm writing a driver for a sampling device that is constantly delivering a
> > relatively high amount of data (about 16 MB/s) and I need to deliver the
> > data to the user-space ASAP. To prevent data loss I create a queue of
> > buffers (consisting of few pages each) which are more or less directly
> > filled by the device and then mapped to the user-space via mmap().
> > 
> > The thing is that I'd like to prevent kernel to swap these pages out,
> > because then I may loose some data when they are not available in time for
> > the next round.
> 
> It would likely be easier to just mlock this buffer from the userspace
> application, rather than trying to achieve this in the driver..

Well yes, but it is the kernel that needs to have it guaranteed and 
especially on the buffers that aren't currently mmapped to user-space, but 
are free to be filled with data from the device. And generally we can not 
rely on an application to do the mlock(), I guess. If the application 
wouldn't do it and if it would happen that some of the buffers would be 
swapped out, we may end up with a page fault within an interrupt.

And besides, I guess the mlock() is effective only as long as the pages 
are really mapped into the user-space. Since when they are then unmapped 
by munmap(2) when the application have read the data, their VMA eventually 
seizes to exist and the mlock() protection would be gone anyway. Right?

We need a permanent protection. But perhaps artificially increasing the 
page's reference count via get_page() upon allocation, instead of setting 
the PG_reserved bit, would do. (If I got it right.)

Martin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/