On Mon, 25 Jun 2007, Hugh Dickins wrote:
> Please reread mails of the last 20 hours. Your "ARM fix" may or may not
> be a good thing, I don't know. But it had nothing to do with this oops,
> which (we believe) came from a kmalloc in drivers/mmc/core/sd.c. There
> are likely to be many other
On Mon, 25 Jun 2007, Hugh Dickins wrote:
Please reread mails of the last 20 hours. Your ARM fix may or may not
be a good thing, I don't know. But it had nothing to do with this oops,
which (we believe) came from a kmalloc in drivers/mmc/core/sd.c. There
are likely to be many other drivers
On Mon, 25 Jun 2007, Christoph Lameter wrote:
> On Mon, 25 Jun 2007, Hugh Dickins wrote:
>
> > > The "sometimes we have kmalloced buffers" locations need to be fixed.
> >
> > I've said enough, I'd better leave it to others to deter you or not
> > from fiddling around pointlessly here.
>
> Are
On Mon, 25 Jun 2007, Hugh Dickins wrote:
> > The "sometimes we have kmalloced buffers" locations need to be fixed.
>
> I've said enough, I'd better leave it to others to deter you or not
> from fiddling around pointlessly here.
Are there any locations left after the two fixes to pa-risc and
On Mon, 25 Jun 2007, Christoph Lameter wrote:
> On Mon, 25 Jun 2007, Hugh Dickins wrote:
> >
> > I didn't claim that flush_dcache_page(virt_to_page(virt)) is not expected
> > to work. I claim that flush_dcache_page is expected to be a noop rather
> > than an oops on a kmalloced page.
>
> There
On Mon, 25 Jun 2007, Hugh Dickins wrote:
> > > PageSlab to avoid oopsing on page->mapping.
> >
> > It is definitely intended to work. Otherwise we would not have code
> > like this:
> >
> > [EMAIL PROTECTED]:~/linux-2.6$ find . -name "*.c" | xargs grep
> > "flush_dcache_page"|grep virt
> >
On Mon, 25 Jun 2007, Christoph Lameter wrote:
> On Mon, 25 Jun 2007, Hugh Dickins wrote:
>
> > > In many situations the page struct passed to flush_dcache_page is
> > > simply used to calculate the virtual address. So its mostly harmless.
> > > Trouble starts when page attributes like the mapping
On Mon, 25 Jun 2007, Hugh Dickins wrote:
> > In many situations the page struct passed to flush_dcache_page is
> > simply used to calculate the virtual address. So its mostly harmless.
> > Trouble starts when page attributes like the mapping is used.
>
> Mostly harmless indeed. I don't
On Mon, 25 Jun 2007, Christoph Lameter wrote:
> On Mon, 25 Jun 2007, Hugh Dickins wrote:
>
> > And I now rather think that needs to stay, not be replaced by the
> > VM_BUG_ON Christoph was proposing for 2.6.23 (which earlier I acked).
> >
> > Christoph responded to my page_mapping patch by
On Mon, 25 Jun 2007, Hugh Dickins wrote:
> And I now rather think that needs to stay, not be replaced by the
> VM_BUG_ON Christoph was proposing for 2.6.23 (which earlier I acked).
>
> Christoph responded to my page_mapping patch by looking at arch/arm,
> and there finding a kmalloc in
Hugh Dickins :
On Sun, 24 Jun 2007, Russell King wrote:
On Sun, Jun 24, 2007 at 11:24:16AM +0100, Hugh Dickins wrote:
On Sun, 24 Jun 2007, Russell King wrote:
On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
Please forward the original problem report.
Done.
Okay, that seems to
Hugh Dickins :
On Sun, 24 Jun 2007, Russell King wrote:
On Sun, Jun 24, 2007 at 11:24:16AM +0100, Hugh Dickins wrote:
On Sun, 24 Jun 2007, Russell King wrote:
On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
Please forward the original problem report.
Done.
Okay, that seems to
On Mon, 25 Jun 2007, Hugh Dickins wrote:
And I now rather think that needs to stay, not be replaced by the
VM_BUG_ON Christoph was proposing for 2.6.23 (which earlier I acked).
Christoph responded to my page_mapping patch by looking at arch/arm,
and there finding a kmalloc in
On Mon, 25 Jun 2007, Christoph Lameter wrote:
On Mon, 25 Jun 2007, Hugh Dickins wrote:
And I now rather think that needs to stay, not be replaced by the
VM_BUG_ON Christoph was proposing for 2.6.23 (which earlier I acked).
Christoph responded to my page_mapping patch by looking at
On Mon, 25 Jun 2007, Hugh Dickins wrote:
In many situations the page struct passed to flush_dcache_page is
simply used to calculate the virtual address. So its mostly harmless.
Trouble starts when page attributes like the mapping is used.
Mostly harmless indeed. I don't understand why
On Mon, 25 Jun 2007, Christoph Lameter wrote:
On Mon, 25 Jun 2007, Hugh Dickins wrote:
In many situations the page struct passed to flush_dcache_page is
simply used to calculate the virtual address. So its mostly harmless.
Trouble starts when page attributes like the mapping is used.
On Mon, 25 Jun 2007, Hugh Dickins wrote:
PageSlab to avoid oopsing on page-mapping.
It is definitely intended to work. Otherwise we would not have code
like this:
[EMAIL PROTECTED]:~/linux-2.6$ find . -name *.c | xargs grep
flush_dcache_page|grep virt
On Mon, 25 Jun 2007, Christoph Lameter wrote:
On Mon, 25 Jun 2007, Hugh Dickins wrote:
I didn't claim that flush_dcache_page(virt_to_page(virt)) is not expected
to work. I claim that flush_dcache_page is expected to be a noop rather
than an oops on a kmalloced page.
There are no
On Mon, 25 Jun 2007, Hugh Dickins wrote:
The sometimes we have kmalloced buffers locations need to be fixed.
I've said enough, I'd better leave it to others to deter you or not
from fiddling around pointlessly here.
Are there any locations left after the two fixes to pa-risc and arm?
If
On Mon, 25 Jun 2007, Christoph Lameter wrote:
On Mon, 25 Jun 2007, Hugh Dickins wrote:
The sometimes we have kmalloced buffers locations need to be fixed.
I've said enough, I'd better leave it to others to deter you or not
from fiddling around pointlessly here.
Are there any
On Sun, 24 Jun 2007, Russell King wrote:
> On Sun, Jun 24, 2007 at 11:24:16AM +0100, Hugh Dickins wrote:
> > On Sun, 24 Jun 2007, Russell King wrote:
> > > On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
> > >
> > > Please forward the original problem report.
> >
> > Done.
>
>
On Sun, Jun 24, 2007 at 11:24:16AM +0100, Hugh Dickins wrote:
> On Sun, 24 Jun 2007, Russell King wrote:
> > On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
> > > I'm quite happy with this approach for 2.6.23-rc, along with your ARM
> > > dma_map patch which (if I understood aright)
On Sun, 24 Jun 2007, Russell King wrote:
> On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
> > I'm quite happy with this approach for 2.6.23-rc, along with your ARM
> > dma_map patch which (if I understood aright) rmk approved.
>
> I didn't approve it. Please re-read my reply -
On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
> On Fri, 22 Jun 2007, Christoph Lameter wrote:
> >
> > Add VM_BUG_ON in case someone uses page_mapping on a slab page
> >
> > Detect slab objects being passed to the page oriented functions of the VM.
> >
> > It is not sufficient to
On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
On Fri, 22 Jun 2007, Christoph Lameter wrote:
Add VM_BUG_ON in case someone uses page_mapping on a slab page
Detect slab objects being passed to the page oriented functions of the VM.
It is not sufficient to simply
On Sun, 24 Jun 2007, Russell King wrote:
On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
I'm quite happy with this approach for 2.6.23-rc, along with your ARM
dma_map patch which (if I understood aright) rmk approved.
I didn't approve it. Please re-read my reply - there are
On Sun, Jun 24, 2007 at 11:24:16AM +0100, Hugh Dickins wrote:
On Sun, 24 Jun 2007, Russell King wrote:
On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
I'm quite happy with this approach for 2.6.23-rc, along with your ARM
dma_map patch which (if I understood aright) rmk
On Sun, 24 Jun 2007, Russell King wrote:
On Sun, Jun 24, 2007 at 11:24:16AM +0100, Hugh Dickins wrote:
On Sun, 24 Jun 2007, Russell King wrote:
On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
Please forward the original problem report.
Done.
Okay, that seems to
* From: Christoph Lameter
* Newsgroups: linux.kernel,linux.ports.arm.kernel
* Date: Fri, 22 Jun 2007 13:15:19 -0700 (PDT)
>
> Here is the corresponding PA-RISC piece. Its as straightforward as
> the other one since the only way to make this work properly in the past
> was if the sizes passed to
* From: Christoph Lameter
* Newsgroups: linux.kernel,linux.ports.arm.kernel
* Date: Fri, 22 Jun 2007 13:15:19 -0700 (PDT)
Here is the corresponding PA-RISC piece. Its as straightforward as
the other one since the only way to make this work properly in the past
was if the sizes passed to the
On Fri, 22 Jun 2007, Hugh Dickins wrote:
> On Fri, 22 Jun 2007, Christoph Lameter wrote:
> >
> > We need to fix any remaining weird slab object uses right now. Your check
> > leaves a lot of holes open. 2.6.22 removes all other such strange slab
> > uses in other arches. It would be
On Fri, 22 Jun 2007, Christoph Lameter wrote:
>
> We need to fix any remaining weird slab object uses right now. Your check
> leaves a lot of holes open. 2.6.22 removes all other such strange slab
> uses in other arches. It would be inconsistent if we left these things in
> ARM (and maybe
On Fri, Jun 22, 2007 at 09:40:45AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 22 Jun 2007, Hugh Dickins wrote:
> >
> > On Thu, 21 Jun 2007, Christoph Lameter wrote:
> >
> > > Maybe this will address the issue on ARM?
> >
> > Looks like it would indeed address the immediate issue on ARM -
> >
Here is the corresponding PA-RISC piece. Its as straightforward as
the other one since the only way to make this work properly in the past
was if the sizes passed to the dma alloc functions are page size based.
PA-RISC: Use page allocator instead of slab allocator.
Slab pages obtained via
On Fri, 22 Jun 2007, Hugh Dickins wrote:
> Acked-by: Hugh Dickins <[EMAIL PROTECTED]>
> (immediately after 2.6.22, accompanied by your ARM patch)
We need to fix any remaining weird slab object uses right now. Your check
leaves a lot of holes open. 2.6.22 removes all other such strange slab
On Fri, 22 Jun 2007, Christoph Lameter wrote:
> On Fri, 22 Jun 2007, Hugh Dickins wrote:
>
> > I'm quite happy with this approach for 2.6.23-rc, along with your ARM
> > dma_map patch which (if I understood aright) rmk approved. Except,
> > haven't you misplaced that VM_BUG_ON between an if and
On Fri, 22 Jun 2007, Hugh Dickins wrote:
> I'm quite happy with this approach for 2.6.23-rc, along with your ARM
> dma_map patch which (if I understood aright) rmk approved. Except,
> haven't you misplaced that VM_BUG_ON between an if and its else?
Right.
> And I'd much prefer you to make it
On Fri, 22 Jun 2007, Christoph Lameter wrote:
>
> Add VM_BUG_ON in case someone uses page_mapping on a slab page
>
> Detect slab objects being passed to the page oriented functions of the VM.
>
> It is not sufficient to simply return NULL because the functions calling
> page_mapping may depend
Add VM_BUG_ON in case someone uses page_mapping on a slab page
Detect slab objects being passed to the page oriented functions of the VM.
It is not sufficient to simply return NULL because the functions calling
page_mapping may depend on other items of the page_struct also to be setup
properly.
On Fri, 22 Jun 2007, Linus Torvalds wrote:
> > Looks like it would indeed address the immediate issue on ARM -
> > IF they've no particular reason to be using kmalloc there.
>
> I think the right thing to do is do both of these things. I already
> applied Hugh's patch - it seemed like a total
On Fri, 22 Jun 2007, Hugh Dickins wrote:
>
> On Thu, 21 Jun 2007, Christoph Lameter wrote:
>
> > Maybe this will address the issue on ARM?
>
> Looks like it would indeed address the immediate issue on ARM -
> IF they've no particular reason to be using kmalloc there.
I think the right thing
Nicolas Ferre :
Marc Pignat :
please use this patch, sorry for the later
My eyes are too tired or this patch is the same as the previous one :-\
Indeed, my eyes where too tired ;-) Sorry for the trouble.
--
Nicolas Ferre
-
To unsubscribe from this list: send the line "unsubscribe
On Fri, Jun 22, 2007 at 05:26:33AM +0100, Hugh Dickins wrote:
> On Thu, 21 Jun 2007, Christoph Lameter wrote:
> > On Thu, 21 Jun 2007, Hugh Dickins wrote:
> >
> > > > The oops seems to occur after a page unmapping using dma_unmap_page()
> > > > followed
> > > > by a flush_dcache_page() (in
On Fri, Jun 22, 2007 at 05:26:33AM +0100, Hugh Dickins wrote:
On Thu, 21 Jun 2007, Christoph Lameter wrote:
On Thu, 21 Jun 2007, Hugh Dickins wrote:
The oops seems to occur after a page unmapping using dma_unmap_page()
followed
by a flush_dcache_page() (in
Nicolas Ferre :
Marc Pignat :
please use this patch, sorry for the later
My eyes are too tired or this patch is the same as the previous one :-\
Indeed, my eyes where too tired ;-) Sorry for the trouble.
--
Nicolas Ferre
-
To unsubscribe from this list: send the line unsubscribe
On Fri, 22 Jun 2007, Linus Torvalds wrote:
Looks like it would indeed address the immediate issue on ARM -
IF they've no particular reason to be using kmalloc there.
I think the right thing to do is do both of these things. I already
applied Hugh's patch - it seemed like a total
On Fri, 22 Jun 2007, Hugh Dickins wrote:
On Thu, 21 Jun 2007, Christoph Lameter wrote:
Maybe this will address the issue on ARM?
Looks like it would indeed address the immediate issue on ARM -
IF they've no particular reason to be using kmalloc there.
I think the right thing to do is
Add VM_BUG_ON in case someone uses page_mapping on a slab page
Detect slab objects being passed to the page oriented functions of the VM.
It is not sufficient to simply return NULL because the functions calling
page_mapping may depend on other items of the page_struct also to be setup
properly.
On Fri, 22 Jun 2007, Christoph Lameter wrote:
Add VM_BUG_ON in case someone uses page_mapping on a slab page
Detect slab objects being passed to the page oriented functions of the VM.
It is not sufficient to simply return NULL because the functions calling
page_mapping may depend on
On Fri, 22 Jun 2007, Hugh Dickins wrote:
I'm quite happy with this approach for 2.6.23-rc, along with your ARM
dma_map patch which (if I understood aright) rmk approved. Except,
haven't you misplaced that VM_BUG_ON between an if and its else?
Right.
And I'd much prefer you to make it an
On Fri, 22 Jun 2007, Christoph Lameter wrote:
On Fri, 22 Jun 2007, Hugh Dickins wrote:
I'm quite happy with this approach for 2.6.23-rc, along with your ARM
dma_map patch which (if I understood aright) rmk approved. Except,
haven't you misplaced that VM_BUG_ON between an if and its else?
On Fri, 22 Jun 2007, Hugh Dickins wrote:
Acked-by: Hugh Dickins [EMAIL PROTECTED]
(immediately after 2.6.22, accompanied by your ARM patch)
We need to fix any remaining weird slab object uses right now. Your check
leaves a lot of holes open. 2.6.22 removes all other such strange slab
uses in
Here is the corresponding PA-RISC piece. Its as straightforward as
the other one since the only way to make this work properly in the past
was if the sizes passed to the dma alloc functions are page size based.
PA-RISC: Use page allocator instead of slab allocator.
Slab pages obtained via
On Fri, Jun 22, 2007 at 09:40:45AM -0700, Linus Torvalds wrote:
On Fri, 22 Jun 2007, Hugh Dickins wrote:
On Thu, 21 Jun 2007, Christoph Lameter wrote:
Maybe this will address the issue on ARM?
Looks like it would indeed address the immediate issue on ARM -
IF they've no
On Fri, 22 Jun 2007, Christoph Lameter wrote:
We need to fix any remaining weird slab object uses right now. Your check
leaves a lot of holes open. 2.6.22 removes all other such strange slab
uses in other arches. It would be inconsistent if we left these things in
ARM (and maybe PA-RISC).
On Fri, 22 Jun 2007, Hugh Dickins wrote:
On Fri, 22 Jun 2007, Christoph Lameter wrote:
We need to fix any remaining weird slab object uses right now. Your check
leaves a lot of holes open. 2.6.22 removes all other such strange slab
uses in other arches. It would be inconsistent if we
On Thu, 21 Jun 2007, Christoph Lameter wrote:
> On Fri, 22 Jun 2007, Hugh Dickins wrote:
>
> > However... what gives you confidence that flush_dcache_page is
> > never applied to other slab pages?
>
> Flush dcache page is supposed to run on pages not objects of varying
> length. It is suprising
On Fri, 22 Jun 2007, Hugh Dickins wrote:
> But PA-RISC also has a function called flush_dcache_page, which uses
> page_mapping and expects a struct address_space * from it. If that
> can ever be get applied to a SLOB page (which is not so clear as in
> the ARM case, but cannot easily be ruled
On Fri, 22 Jun 2007, Hugh Dickins wrote:
> You keep on forcing the outside world to revolve around your needs
> within slub.c: that is a good way to keep slub lean, and may be
> justified; but it's at least questionable to be enforcing such
> restrictions years after people have grown accustomed
On Thu, 21 Jun 2007, Christoph Lameter wrote:
> On Thu, 21 Jun 2007, Hugh Dickins wrote:
>
> > Seems a little odd that it's gone throughout 2.6.22-rc unnoticed
> > until now - nobody else trying SLUB on ARM or PA-RISC yet perhaps.
>
> The impact is only on a subset of ARM machines.
>
> PA_RISC?
On Fri, 22 Jun 2007, Hugh Dickins wrote:
> However... what gives you confidence that flush_dcache_page is
> never applied to other slab pages?
Flush dcache page is supposed to run on pages not objects of varying
length. It is suprising that this has not lead to earlier problems.
Objects
On Thu, 21 Jun 2007, Christoph Lameter wrote:
> Maybe this will address the issue on ARM?
Looks like it would indeed address the immediate issue on ARM -
IF they've no particular reason to be using kmalloc there.
However... what gives you confidence that flush_dcache_page is
never applied to
On Thu, 21 Jun 2007, Christoph Lameter wrote:
> On Thu, 21 Jun 2007, Hugh Dickins wrote:
>
> > > The oops seems to occur after a page unmapping using dma_unmap_page()
> > > followed
> > > by a flush_dcache_page() (in at91mci_post_dma_read()).
>
> Was the page allocated using slab calls?
You've
On Thu, 21 Jun 2007, Hugh Dickins wrote:
> Seems a little odd that it's gone throughout 2.6.22-rc unnoticed
> until now - nobody else trying SLUB on ARM or PA-RISC yet perhaps.
The impact is only on a subset of ARM machines.
PA_RISC? It looks like they run their own flushing function for byte
Maybe this will address the issue on ARM?
ARM: Allocate dma pages via the page allocator and not via the slab allocator
Slab allocations are not guaranteed to be page aligned and slab allocators
may use the page structs for their own purposes. Using the page allocator
yields a properly aligned
On Thu, 21 Jun 2007, Hugh Dickins wrote:
> > The oops seems to occur after a page unmapping using dma_unmap_page()
> > followed
> > by a flush_dcache_page() (in at91mci_post_dma_read()).
Was the page allocated using slab calls?
> Seems a little odd that it's gone throughout 2.6.22-rc unnoticed
On Thu, 21 Jun 2007, Nicolas Ferre wrote:
>
> While debugging a Linux driver on my ARM platform (AT91), I switched on the
> 2.6.22-rc5 kernel. While reconfiguring it I selected CONFIG_SLUB as a SLAB
> allocator.
>
> The sd/mmc driver I tried to run is vanilla driver which never, until now,
>
Marc Pignat :
please use this patch, sorry for the later
My eyes are too tired or this patch is the same as the previous one :-\
Cheers,
--
Nicolas Ferre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
please use this patch, sorry for the later
Regards
Marc
--- drivers/mmc/host/at91_mci.c-2.6.22-rc5.orig 2007-06-21 16:27:31.0
+0200
+++ drivers/mmc/host/at91_mci.c-2.6.22-rc5 2007-06-21 16:42:48.0
+0200
@@ -164,7 +164,7 @@ static inline void at91mci_sg_to_dma(str
Hello Nicolas!
Good news!
I think I've found the problem, this seems to work (tested with SLUB and SLAB).
If you're in the cleanup stage, I think the whole kmap and kunmap can be in the
'if (cpu_is_at91rm9200())',
we have no reason to kmap data we don't touch :-D
Regards
Marc
---
Hello,
While debugging a Linux driver on my ARM platform
(AT91), I switched on the 2.6.22-rc5 kernel. While
reconfiguring it I selected CONFIG_SLUB as a SLAB allocator.
The sd/mmc driver I tried to run is vanilla driver
which never, until now, produces Oops (at91_mci.c).
The oops seems to
Hello,
While debugging a Linux driver on my ARM platform
(AT91), I switched on the 2.6.22-rc5 kernel. While
reconfiguring it I selected CONFIG_SLUB as a SLAB allocator.
The sd/mmc driver I tried to run is vanilla driver
which never, until now, produces Oops (at91_mci.c).
The oops seems to
please use this patch, sorry for the later
Regards
Marc
--- drivers/mmc/host/at91_mci.c-2.6.22-rc5.orig 2007-06-21 16:27:31.0
+0200
+++ drivers/mmc/host/at91_mci.c-2.6.22-rc5 2007-06-21 16:42:48.0
+0200
@@ -164,7 +164,7 @@ static inline void at91mci_sg_to_dma(str
Hello Nicolas!
Good news!
I think I've found the problem, this seems to work (tested with SLUB and SLAB).
If you're in the cleanup stage, I think the whole kmap and kunmap can be in the
'if (cpu_is_at91rm9200())',
we have no reason to kmap data we don't touch :-D
Regards
Marc
---
Marc Pignat :
please use this patch, sorry for the later
My eyes are too tired or this patch is the same as the previous one :-\
Cheers,
--
Nicolas Ferre
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Thu, 21 Jun 2007, Nicolas Ferre wrote:
While debugging a Linux driver on my ARM platform (AT91), I switched on the
2.6.22-rc5 kernel. While reconfiguring it I selected CONFIG_SLUB as a SLAB
allocator.
The sd/mmc driver I tried to run is vanilla driver which never, until now,
produces
On Thu, 21 Jun 2007, Hugh Dickins wrote:
The oops seems to occur after a page unmapping using dma_unmap_page()
followed
by a flush_dcache_page() (in at91mci_post_dma_read()).
Was the page allocated using slab calls?
Seems a little odd that it's gone throughout 2.6.22-rc unnoticed
until
Maybe this will address the issue on ARM?
ARM: Allocate dma pages via the page allocator and not via the slab allocator
Slab allocations are not guaranteed to be page aligned and slab allocators
may use the page structs for their own purposes. Using the page allocator
yields a properly aligned
On Thu, 21 Jun 2007, Hugh Dickins wrote:
Seems a little odd that it's gone throughout 2.6.22-rc unnoticed
until now - nobody else trying SLUB on ARM or PA-RISC yet perhaps.
The impact is only on a subset of ARM machines.
PA_RISC? It looks like they run their own flushing function for byte
On Thu, 21 Jun 2007, Christoph Lameter wrote:
On Thu, 21 Jun 2007, Hugh Dickins wrote:
The oops seems to occur after a page unmapping using dma_unmap_page()
followed
by a flush_dcache_page() (in at91mci_post_dma_read()).
Was the page allocated using slab calls?
You've found yes
On Thu, 21 Jun 2007, Christoph Lameter wrote:
Maybe this will address the issue on ARM?
Looks like it would indeed address the immediate issue on ARM -
IF they've no particular reason to be using kmalloc there.
However... what gives you confidence that flush_dcache_page is
never applied to
On Fri, 22 Jun 2007, Hugh Dickins wrote:
However... what gives you confidence that flush_dcache_page is
never applied to other slab pages?
Flush dcache page is supposed to run on pages not objects of varying
length. It is suprising that this has not lead to earlier problems.
Objects allocated
On Fri, 22 Jun 2007, Hugh Dickins wrote:
You keep on forcing the outside world to revolve around your needs
within slub.c: that is a good way to keep slub lean, and may be
justified; but it's at least questionable to be enforcing such
restrictions years after people have grown accustomed to
On Thu, 21 Jun 2007, Christoph Lameter wrote:
On Thu, 21 Jun 2007, Hugh Dickins wrote:
Seems a little odd that it's gone throughout 2.6.22-rc unnoticed
until now - nobody else trying SLUB on ARM or PA-RISC yet perhaps.
The impact is only on a subset of ARM machines.
PA_RISC? It looks
On Fri, 22 Jun 2007, Hugh Dickins wrote:
But PA-RISC also has a function called flush_dcache_page, which uses
page_mapping and expects a struct address_space * from it. If that
can ever be get applied to a SLOB page (which is not so clear as in
the ARM case, but cannot easily be ruled out
On Thu, 21 Jun 2007, Christoph Lameter wrote:
On Fri, 22 Jun 2007, Hugh Dickins wrote:
However... what gives you confidence that flush_dcache_page is
never applied to other slab pages?
Flush dcache page is supposed to run on pages not objects of varying
length. It is suprising that
86 matches
Mail list logo
