From: Andrew Morton <akpm@linux-foundation.org>
To: Mel Gorman <mel@csn.ul.ie>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
jens.axboe@oracle.com, liml@rtr.ca, lkml@rtr.ca, matthew@wil.cx,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-mm@kvack.org, Matt Mackall <mpm@selenic.com>
Subject: Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?
Date: Fri, 14 Dec 2007 18:02:06 -0800 [thread overview]
Message-ID: <20071214180206.e0325503.akpm@linux-foundation.org> (raw)
In-Reply-To: <20071215010940.GB28613@csn.ul.ie>
On Sat, 15 Dec 2007 01:09:41 +0000 Mel Gorman <mel@csn.ul.ie> wrote:
> On (13/12/07 14:29), Andrew Morton didst pronounce:
> > > The simple way seems to be to malloc a large area, touch every page and
> > > then look at the physical pages assigned ... they now mostly seem to be
> > > descending in physical address.
> > >
> >
> > OIC. -mm's /proc/pid/pagemap can be used to get the pfn's...
> >
>
> I tried using pagemap to verify the patch but it triggered BUG_ON
> checks. Perhaps I am using the interface wrong but I would still not
> expect it to break in this fashion. I tried 2.6.24-rc4-mm1, 2.6.24-rc5-mm1,
> 2.6.24-rc5 with just the maps4 patches applied and 2.6.23 with maps4 patches
> applied. Each time I get errors like this;
>
> [ 90.108315] BUG: sleeping function called from invalid context at include/asm/uaccess_32.h:457
> [ 90.211227] in_atomic():1, irqs_disabled():0
> [ 90.262251] no locks held by showcontiguous/2814.
> [ 90.318475] Pid: 2814, comm: showcontiguous Not tainted 2.6.24-rc5 #1
> [ 90.395344] [<c010522a>] show_trace_log_lvl+0x1a/0x30
> [ 90.456948] [<c0105bb2>] show_trace+0x12/0x20
> [ 90.510173] [<c0105eee>] dump_stack+0x6e/0x80
> [ 90.563409] [<c01205b3>] __might_sleep+0xc3/0xe0
> [ 90.619765] [<c02264fd>] copy_to_user+0x3d/0x60
> [ 90.675153] [<c01b3e9c>] add_to_pagemap+0x5c/0x80
> [ 90.732513] [<c01b43e8>] pagemap_pte_range+0x68/0xb0
> [ 90.793010] [<c0175ed2>] walk_page_range+0x112/0x210
> [ 90.853482] [<c01b47c6>] pagemap_read+0x176/0x220
> [ 90.910863] [<c0182dc4>] vfs_read+0x94/0x150
> [ 90.963058] [<c01832fd>] sys_read+0x3d/0x70
> [ 91.014219] [<c0104262>] syscall_call+0x7/0xb
>
> ...
>
> Just using cp to read the file is enough to cause problems but I included
> a very basic program below that produces the BUG_ON checks. Is this a known
> issue or am I using the interface incorrectly?
I'd say you're using it correctly but you've found a hitherto unknown bug.
On i386 highmem machines with CONFIG_HIGHPTE (at least) pte_offset_map()
takes kmap_atomic(), so pagemap_pte_range() can't do copy_to_user() as it
presently does.
Drat.
Still, that shouldn't really disrupt the testing which you're doing. You
could disable CONFIG_HIGHPTE to shut it up.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-12-15 2:02 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20071213185326.GQ26334@parisc-linux.org>
[not found] ` <4761821F.3050602@rtr.ca>
[not found] ` <20071213192633.GD10104@kernel.dk>
[not found] ` <4761883A.7050908@rtr.ca>
[not found] ` <476188C4.9030802@rtr.ca>
[not found] ` <20071213193937.GG10104@kernel.dk>
[not found] ` <47618B0B.8020203@rtr.ca>
[not found] ` <20071213195350.GH10104@kernel.dk>
[not found] ` <20071213200219.GI10104@kernel.dk>
[not found] ` <476190BE.9010405@rtr.ca>
[not found] ` <20071213200958.GK10104@kernel.dk>
2007-12-13 22:02 ` QUEUE_FLAG_CLUSTER: not working in 2.6.24 ? Andrew Morton
2007-12-13 22:15 ` James Bottomley
2007-12-13 22:29 ` Andrew Morton
2007-12-13 22:33 ` Mark Lord
2007-12-13 23:13 ` Mark Lord
2007-12-14 0:05 ` Mark Lord
2007-12-14 0:30 ` Mark Lord
2007-12-14 0:37 ` Andrew Morton
2007-12-14 0:42 ` Mark Lord
2007-12-14 0:46 ` [PATCH] fix page_alloc for larger I/O segments (improved) Mark Lord
2007-12-14 0:57 ` James Bottomley
2007-12-14 1:11 ` Andrew Morton
2007-12-14 2:23 ` Mark Lord
2007-12-14 17:42 ` Mel Gorman
2007-12-14 18:07 ` Mark Lord
2007-12-16 21:56 ` Mel Gorman
2007-12-14 18:13 ` Matthew Wilcox
2007-12-14 18:30 ` Mark Lord
2007-12-20 22:37 ` Matthew Wilcox
2007-12-14 0:47 ` QUEUE_FLAG_CLUSTER: not working in 2.6.24 ? Mark Lord
2007-12-14 11:50 ` Mel Gorman
2007-12-14 13:57 ` Mark Lord
2007-12-14 0:40 ` [PATCH] fix page_alloc for larger I/O segments Mark Lord
2007-12-14 1:03 ` Andrew Morton
2007-12-14 4:00 ` Matthew Wilcox
2007-12-15 1:09 ` QUEUE_FLAG_CLUSTER: not working in 2.6.24 ? Mel Gorman
2007-12-15 2:02 ` Andrew Morton [this message]
2007-12-15 5:55 ` Matt Mackall
2007-12-16 21:55 ` Mel Gorman
2007-12-17 19:24 ` Randy Dunlap
2007-12-18 2:42 ` Matt Mackall
2007-12-13 22:17 ` Jens Axboe
2007-12-13 22:02 ` VM allocates pages in reverse order again Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071214180206.e0325503.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=jens.axboe@oracle.com \
--cc=liml@rtr.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lkml@rtr.ca \
--cc=matthew@wil.cx \
--cc=mel@csn.ul.ie \
--cc=mpm@selenic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).