Re: can device drivers return non-ram via vm_ops->nopage?

[Andrew Morton <akpm@osdl.org>]

Andrea Arcangeli <andrea@suse.de> wrote:
>
> On Sat, Mar 20, 2004 at 06:40:22AM -0800, William Lee Irwin III wrote:
> > On Sat, Mar 20, 2004 at 02:30:25PM +0100, Andrea Arcangeli wrote:
> > > Anyways returning to the non-ram returned by ->nopage see the below
> > > email exchange with Jens. the bug triggering of course is the
> > > BUG_ON(!pfn_valid(page_to_pfn(new_page))).
> > > If we want to return non-ram, we could, but I believe we should change
> > > the API to return a pfn not a page_t * if we want to.
> > 
> > This would be very helpful for other reasons also. There's a general
> > API issue with drivers that want or need to do this. The one I've
> 
> I'm afraid I'll have to teach ->nopage how to deal with non-ram with
> this page_t API too (changing it to pfn sounds too intrusive in the
> short term), it seems to me that alsa can return non-ram (in the nopage
> callback there's a virt_to_page on some iomm region), and changing alsa
> to use remap_file_pages sounds too intrusive too. 

I had a check in a valid pfn in page_add_rmap() for several weeks before I
actually removed the test.  The debug check never triggered.  But looking
at the code I don't see why not.  Weird.

fyi, we don't need the check in page_referenced() and try_to_unmap()
because do_no_page() does not place pages on the LRU.  It is the ->nopage
implementation which is responsible for that.  Presumably the ALSA driver
was not adding the "page" to the LRU.

I agree that ->nopage implementations should not be doing what that driver
is doing.  ->nopage is defined to return a page*: it's crazy to be
returning someting from there which isn't covered by mem_map[].

I just don't think it's important enough to be able to cope with
non-mem_map[] "memory" in do_no_page(), so I agree that requiring ->mmap()
to synchronously instantiate the pte's and retaining the debug check in
do_no_page() is a good idea.