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 dri
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 th
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?
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 a
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
> > ./d
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 understan
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 lookin
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 dma_alloc_
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 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
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) r
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 - ther
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
* 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 t
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 inconsisten
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-RI
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
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 kma
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
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 it
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:
>
> 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 o
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 no
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
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 linux-ke
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 at91mc
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 out
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 t
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 allocate
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 oth
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
r
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 p
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,
> prod
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 inf
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
--- drivers/mmc
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
43 matches
Mail list logo
