Date: Sat, 20 Mar 2004 21:28:50 +0100
From: Andrea Arcangeli <andrea@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: wli@holomorphy.com, linux-kernel@vger.kernel.org, torvalds@osdl.org
Subject: Re: can device drivers return non-ram via vm_ops->nopage?
Message-ID: <20040320202850.GH9009@dualathlon.random>
References: <20040320133025.GH9009@dualathlon.random> <20040320144022.GC2045@holomorphy.com> <20040320150621.GO9009@dualathlon.random> <20040320121345.2a80e6a0.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040320121345.2a80e6a0.akpm@osdl.org>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1729
Lines: 37

On Sat, Mar 20, 2004 at 12:13:45PM -0800, Andrew Morton wrote:
> 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

yes I've noticed.

> 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 may have been wrong about that sorry, it's still not certain though,
but I had a bug in the code that would mistake a sigbus for a page_t
outside the mem_map, so it could have been a sigbus not a non-ram page.

Also in the meantime I noticed with NUMA it's impossible to handle
non-ram correctly in ->nopage, at least if using the current
page_to_pfn.

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

I agree, I reistantiated the debug check because we cannot handle
non-ram from there if it's numa (actually discontigmem). If alsa uses
non-ram pages it must be fixed, but I've an hope it was a sigbus
trouble. We'll know more in a few more hours.

(btw, Martin definitely triggered the sigbus with numa, the 0x3()
dereference was a the page_t address to read page->flags >> 24)

it's good to have reminded the API cannot handle non-ram.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/