Re: [PATCH v4 0/4] Bugfix for of_match_node ordering

On Thu, Feb 20, 2014 at 8:39 AM, Sachin Kamat [off-list ref] wrote:

Hi Grant,

I observe the following boot failure with today's (next-20140220) linux-next
tree on Exynos based boards with the default exynos_defconfig.

Ugh, nested locking. that is not good. Kevin's patch looks correct and
I'll merge it in. I'm a little disturbed though that you're the only
one who has reported problems. Looking at what it does I would expect
pretty much every SMP platform for freak out about this, but I've
heard nothing from the powerpc guys.

I'll merge in the fix of course, but I'd like to know what I'm missing.

g.

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x900
[    0.000000] Linux version 3.14.0-rc3-next-20140220 (sachin@linaro)
(gcc version 4.8.2 20130805 (prerelease) (crosstool-NG linaro-1.
13.1-4.8-2013.08 - Linaro GCC 2013.08) ) #1132 SMP PREEMPT Thu Feb 20
13:49:27 IST 2014
[    0.000000] CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[    0.000000] Machine model: Insignal Origen evaluation board based
on Exynos4210
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] CPU EXYNOS4210 (id 0x43210011)
[    0.000000] On node 0 totalpages: 258048
[    0.000000]   Normal zone: 1520 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 190464 pages, LIFO batch:31
[    0.000000]   HighMem zone: 528 pages used for memmap
[    0.000000]   HighMem zone: 67584 pages, LIFO batch:15
[    0.000000] BUG: spinlock recursion on CPU#0, swapper/0
[    0.000000]  lock: devtree_lock+0x0/0x10, .magic: dead4ead, .owner:
swapper/0, .owner_cpu: 0
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
3.14.0-rc3-next-20140220 #1132
[    0.000000] [<c0013e9c>] (unwind_backtrace) from [<c0011250>]
(show_stack+0x10/0x14)
[    0.000000] [<c0011250>] (show_stack) from [<c0386740>]
(dump_stack+0x7c/0xbc)
[    0.000000] [<c0386740>] (dump_stack) from [<c005501c>]
(do_raw_spin_lock+0x188/0x18c)
[    0.000000] [<c005501c>] (do_raw_spin_lock) from [<c038b614>]
(_raw_spin_lock_irqsave+0x20/0x28)
[    0.000000] [<c038b614>] (_raw_spin_lock_irqsave) from [<c02de37c>]
(of_find_property+0x20/0x4c)
[    0.000000] [<c02de37c>] (of_find_property) from [<c02df110>]
(__of_device_is_compatible+0xb4/0x110)
[    0.000000] [<c02df110>] (__of_device_is_compatible) from
[<c02df22c>] (of_find_compatible_node+0x4c/0x7c)
[    0.000000] [<c02df22c>] (of_find_compatible_node) from
[<c04cedf4>] (exynos_firmware_init+0x18/0x7c)
[    0.000000] [<c04cedf4>] (exynos_firmware_init) from [<c04caef0>]
(setup_arch+0x860/0x898)
[    0.000000] [<c04caef0>] (setup_arch) from [<c04c7820>]
(start_kernel+0x80/0x3dc)
[    0.000000] [<c04c7820>] (start_kernel) from [<40008074>] (0x40008074)
[    0.000000] BUG: spinlock lockup suspected on CPU#0, swapper/0
[    0.000000]  lock: devtree_lock+0x0/0x10, .magic: dead4ead, .owner:
swapper/0, .owner_cpu: 0
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
3.14.0-rc3-next-20140220 #1132
[    0.000000] [<c0013e9c>] (unwind_backtrace) from [<c0011250>]
(show_stack+0x10/0x14)
[    0.000000] [<c0011250>] (show_stack) from [<c0386740>]
(dump_stack+0x7c/0xbc)
[    0.000000] [<c0386740>] (dump_stack) from [<c0054fac>]
(do_raw_spin_lock+0x118/0x18c)
[    0.000000] [<c0054fac>] (do_raw_spin_lock) from [<c038b614>]
(_raw_spin_lock_irqsave+0x20/0x28)
[    0.000000] [<c038b614>] (_raw_spin_lock_irqsave) from [<c02de37c>]
(of_find_property+0x20/0x4c)
[    0.000000] [<c02de37c>] (of_find_property) from [<c02df110>]
(__of_device_is_compatible+0xb4/0x110)
[    0.000000] [<c02df110>] (__of_device_is_compatible) from
[<c02df22c>] (of_find_compatible_node+0x4c/0x7c)
[    0.000000] [<c02df22c>] (of_find_compatible_node) from
[<c04cedf4>] (exynos_firmware_init+0x18/0x7c)
[    0.000000] [<c04cedf4>] (exynos_firmware_init) from [<c04caef0>]
(setup_arch+0x860/0x898)
[    0.000000] [<c04caef0>] (setup_arch) from [<c04c7820>]
(start_kernel+0x80/0x3dc)
[    0.000000] [<c04c7820>] (start_kernel) from [<40008074>] (0x40008074)

Regards,
Sachin



On 19 February 2014 19:44, Grant Likely [off-list ref] wrote:

quoted

Hi all,

I've taken Kevin's latest rework and done even more rework on it. :-) I
didn't quite like how it was looking so I rolled his scoring code
directly into __of_device_is_compatible() so that the function always
returns a score in a way that is still compatible with the existing
users (ie. non-zero == successful match). This eliminates the need for a
separate pscore argument and it also let me roll the type and name
checks into the same function. I'm a lot happier with it overall and it
makes for a slightly smaller number of lines of code changed. Please
take a look and give it a spin. This is basically a bug fix so I'll need
to push it out to Linus in the near future.

Acks and Tested-bys would be particularly appreciated.

Thanks,
g.

Kevin Hao (2):
        Revert "of: search the best compatible match first in __of_match_node()"
        of: reimplement the matching method for __of_match_node()

Grant Likely (2):
        of: Move testcase FDT data into drivers/of
        of: Add self test for of_match_node()


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