Date: Sun, 22 Jun 2003 16:04:31 -0700
From: Andrew Morton <akpm@digeo.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] page cache readahead implemented?
Message-Id: <20030622160431.3e94369b.akpm@digeo.com>
In-Reply-To: <Pine.LNX.4.44.0306222314500.1177-100000@localhost.localdomain>
References: <20030622114159.1ebbc236.akpm@digeo.com>
	<Pine.LNX.4.44.0306222314500.1177-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1125
Lines: 30

Hugh Dickins <hugh@veritas.com> wrote:
>
> On Sun, 22 Jun 2003, Andrew Morton wrote:
> > Hugh Dickins <hugh@veritas.com> wrote:
> > >
> > > do_mmap_pgoff's PROT_EXEC do_page_cache_readahead assumes that is
> > >  implemented for all mappings, but not all filesystems provide ->readpage.
> > 
> > Which filesystems?
> 
> No prize for guessing it was tmpfs I found the problem with.

Yeah, the usual blot on the kernelscape.

> Am I reading alloc_inode correctly, that the default it gives is
> an empty_aops with NULL readpage, but a backing_dev_info with non-0
> ra_pages?  How does your do_mmap_pgoff fare on a PROT_EXEC mapping
> of one of those mmaping device drivers?

Probably explodes?  I'm not particularly serious about that change - it
can be done in userspace.

Is the do_mmap_pgoff() hack the only offender?  If so it would be better to
localise the test in there too.

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