Re: mtd: kernel BUG at arch/x86/mm/pat.c:279!

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

On Sat, 2012-09-29 at 17:11 +0100, David Woodhouse wrote:
> 
> That check seems to have been missing from David's commit 402d3265 in
> which he introduced the mtd_mmap() operation, and wasn't fixed in commit
> dd02b67d5 where Anatolij fixed things to actually *work* in the MMU code
> path. This should fix it:

> +               if (map->phys == NO_XIP)
> +                       return -EINVAL; 

Hm, but there's another problem. That 'map' variable is pulled from
mtd->priv but there's a clue in the name 'priv'.... it isn't guaranteed
to *be* a device that goes through the map abstraction.

Anatolij? Your patch dd02b67d5 might have worked on your test case, but
it fails disgracefully in any of the cases where it *isn't* expected to
work.

I think it needs to use mtd_unmapped_area() on the device in question
just like the !CONFIG_MMU code path does, and avoid grubbing around in
things that it shouldn't be looking at directly.

David, you made mtd_unmapped_area() return the *virtual* address... but
there's no reason that couldn't have been the physical address, right?
You were only using it in the !CONFIG_MMU case anyway, where they're
equal.

In the meantime, I think the quick fix is just to disable mtdchar_mmap
in the CONFIG_MMU case. It was broken from the moment David introduced
it, and Anatolij's fix was insufficient. I'll do that.

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]