* Bunch of machines are not booting in next again, GPIO regression?
@ 2016-02-17 19:27 Tony Lindgren
2016-02-17 19:55 ` Josh Cartwright
0 siblings, 1 reply; 6+ messages in thread
From: Tony Lindgren @ 2016-02-17 19:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Looks like ff2b13592299 ("gpio: make the gpiochip a real device")
broke booting on all omaps, and probably other machines too according
to this:
https://kernelci.org/boot/all/job/next/kernel/next-20160217/
So far we've gone from 1 failed machine with next-20160216 to
18 failed machines with next-20160217.
The error I'm getting on omaps is below with debug_ll enable,
any ideas?
Regards,
Tony
8< -----------------------
Unable to handle kernel paging request at virtual address d1ba37bc
pgd = c0004000
[d1ba37bc] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4-next-20160217 #1024
Hardware name: Nokia RX-51 board
task: ce0a8d40 ti: ce0aa000 task.ti: ce0aa000
PC is at kfree+0x50/0x144
LR is@kfree+0x34/0x144
pc : [<c026d690>] lr : [<c026d674>] psr: 20000093
sp : ce0abc88 ip : ce0abbf7 fp : 00000000
r10: c0837794 r9 : ce1c0c00 r8 : ce1b30a4
r7 : c0cbf824 r6 : a0000013 r5 : ab51ab30 r4 : ce1c0c10
r3 : d1ba37a8 r2 : cfa8c000 r1 : 00000000 r0 : ab51ab30
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 80004019 DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xce0aa218)
Stack: (0xce0abc88 to 0xce0ac000)
bc80: ce1c0c10 ce1bfe00 ce1bfe00 ce1b30a4 ce1b30a4 ce1c0c00
bca0: c0837794 c04632e4 ce1b3010 00000000 ce1c0c08 c04f873c 00000000 ce0abcc8
bcc0: c0498560 c09c9f94 00000000 ce1c0c08 c0770730 ce0a8d40 00000001 60000013
bce0: ce1bd010 c018a838 ce1c0c08 ce1bd0a0 00000004 c0770730 00000000 ce1b3010
bd00: ce1916d0 00000000 ce1b30a4 ce1bd010 cfdb137c c0837794 00000000 c049db40
bd20: c149646c c14964b8 ce0a8d40 ce1bd010 ce1bd010 ce1bd010 c0c80c9c fffffdfb
bd40: 00000000 00000000 00000000 c04fe394 ce1bd010 c14964b0 c14964b8 c0c80c9c
bd60: 00000000 c04fca7c 00000000 ce0abda0 c04fcbcc 00000001 00000000 c149646c
bd80: 00000000 c04fae50 ce0b38d4 ce19fed4 ce1bd010 ce1bd044 c0c898e0 c04fc790
bda0: ce1bd010 00000001 c0c8a308 ce1bd018 ce1bd010 c0c898e0 00000000 c04fbc6c
bdc0: ce1bd018 ce1bd010 ce1b5010 c04f9f78 00000000 00000000 00000000 00000001
bde0: ce1bd000 ce1bd010 ce1b5010 cfdb13cc 00000000 ce1b5010 00000000 c05f6f28
be00: 00000000 cfdb137c c0b58048 00000001 c0b61f30 c05f7048 00000000 ce0a92e0
be20: c05f3ec0 60000013 c0c9ec18 c0b58048 00000001 c0b61f30 60000013 c0c9ec18
be40: c0b58048 cfdb137c cfd8275c c0b58048 00000001 c0b61f30 ce1b5010 00000000
be60: 00000000 c05f70a4 00000001 ce0a92e0 c05f3ec0 60000013 c0c9ec18 c0b61f30
be80: c0b58048 00000000 60000013 c0c9ec18 c0b61f30 cfd8275c cfd8176c c0b61f30
bea0: c0b58048 00000000 00000001 c0b4f858 c0b00594 c05f7228 00000001 c05f4928
bec0: c0b581b0 c0b61f30 c0c06950 ce1b13c0 c0b037f8 00000000 00000000 c0b138fc
bee0: c0c06950 c0b134fc c0c06950 c0b03814 c0c06950 c01018b0 c0c3f04c 60000013
bf00: ce0a92e8 00000000 00000000 00000006 ce0a8d40 00000000 cfdff1a7 0000009f
bf20: c082b75c c0155590 ce0a8d40 c0980c40 c0a3d9ac 00000000 00000003 00000003
bf40: c0b684a0 00000003 00000003 c0b4f844 0000009f c0cc4000 c0cc4000 c0b4f858
bf60: c0b00594 c0b00ef0 00000003 00000003 00000000 c0b00594 c5804050 c0b685b4
bf80: c076a14c 00000000 c076a14c 00000000 00000000 00000000 00000000 00000000
bfa0: 00000000 c076a154 00000000 c0107970 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 1ea05404 55c61c1d
[<c026d690>] (kfree) from [<c04632e4>] (kobject_set_name_vargs+0x7c/0xa4)
[<c04632e4>] (kobject_set_name_vargs) from [<c04f873c>] (dev_set_name+0x24/0x34)
[<c04f873c>] (dev_set_name) from [<c0498560>] (gpiochip_add_data+0x9c/0x76c)
[<c0498560>] (gpiochip_add_data) from [<c049db40>] (omap_gpio_probe+0x2d4/0x690)
[<c049db40>] (omap_gpio_probe) from [<c04fe394>] (platform_drv_probe+0x4c/0xb0)
[<c04fe394>] (platform_drv_probe) from [<c04fca7c>] (driver_probe_device+0x208/0x2c0)
[<c04fca7c>] (driver_probe_device) from [<c04fae50>] (bus_for_each_drv+0x64/0x98)
[<c04fae50>] (bus_for_each_drv) from [<c04fc790>] (__device_attach+0xb0/0x118)
[<c04fc790>] (__device_attach) from [<c04fbc6c>] (bus_probe_device+0x88/0x90)
[<c04fbc6c>] (bus_probe_device) from [<c04f9f78>] (device_add+0x348/0x568)
[<c04f9f78>] (device_add) from [<c05f6f28>] (of_platform_device_create_pdata+0x80/0xb8)
[<c05f6f28>] (of_platform_device_create_pdata) from [<c05f7048>] (of_platform_bus_create+0xdc/0x18c)
[<c05f7048>] (of_platform_bus_create) from [<c05f70a4>] (of_platform_bus_create+0x138/0x18c)
[<c05f70a4>] (of_platform_bus_create) from [<c05f7228>] (of_platform_populate+0x5c/0xac)
[<c05f7228>] (of_platform_populate) from [<c0b138fc>] (pdata_quirks_init+0x54/0x74)
[<c0b138fc>] (pdata_quirks_init) from [<c0b134fc>] (omap_generic_init+0x10/0x1c)
[<c0b134fc>] (omap_generic_init) from [<c0b03814>] (customize_machine+0x1c/0x40)
[<c0b03814>] (customize_machine) from [<c01018b0>] (do_one_initcall+0x80/0x1dc)
[<c01018b0>] (do_one_initcall) from [<c0b00ef0>] (kernel_init_freeable+0x218/0x2ec)
[<c0b00ef0>] (kernel_init_freeable) from [<c076a154>] (kernel_init+0x8/0xf4)
[<c076a154>] (kernel_init) from [<c0107970>] (ret_from_fork+0x14/0x24)
Code: e1a00005 e5922000 e0833183 e0823103 (e5932014)
---[ end trace ebca4d029d5eaa4e ]---
^ permalink raw reply [flat|nested] 6+ messages in thread* Bunch of machines are not booting in next again, GPIO regression? 2016-02-17 19:27 Bunch of machines are not booting in next again, GPIO regression? Tony Lindgren @ 2016-02-17 19:55 ` Josh Cartwright 2016-02-17 20:13 ` Michael Welling 0 siblings, 1 reply; 6+ messages in thread From: Josh Cartwright @ 2016-02-17 19:55 UTC (permalink / raw) To: linux-arm-kernel On Wed, Feb 17, 2016 at 11:27:55AM -0800, Tony Lindgren wrote: > Hi Linus, > > Looks like ff2b13592299 ("gpio: make the gpiochip a real device") > broke booting on all omaps, and probably other machines too according > to this: > > https://kernelci.org/boot/all/job/next/kernel/next-20160217/ > > So far we've gone from 1 failed machine with next-20160216 to > 18 failed machines with next-20160217. > > The error I'm getting on omaps is below with debug_ll enable, > any ideas? Hey Tony- Looks like the newly allocated gpio_device object isn't zeroed, confusing dev_set_name. Can you give this a try? Josh diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index d8511cd..59f0045 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -435,7 +435,7 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data) * First: allocate and populate the internal stat container, and * set up the struct device. */ - gdev = kmalloc(sizeof(*gdev), GFP_KERNEL); + gdev = kzalloc(sizeof(*gdev), GFP_KERNEL); if (!gdev) return -ENOMEM; gdev->dev.bus = &gpio_bus_type; -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/a380e06e/attachment.sig> ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Bunch of machines are not booting in next again, GPIO regression? 2016-02-17 19:55 ` Josh Cartwright @ 2016-02-17 20:13 ` Michael Welling 2016-02-17 20:22 ` Tony Lindgren 0 siblings, 1 reply; 6+ messages in thread From: Michael Welling @ 2016-02-17 20:13 UTC (permalink / raw) To: linux-arm-kernel On Wed, Feb 17, 2016 at 01:55:43PM -0600, Josh Cartwright wrote: > On Wed, Feb 17, 2016 at 11:27:55AM -0800, Tony Lindgren wrote: > > Hi Linus, > > > > Looks like ff2b13592299 ("gpio: make the gpiochip a real device") > > broke booting on all omaps, and probably other machines too according > > to this: > > > > https://kernelci.org/boot/all/job/next/kernel/next-20160217/ > > > > So far we've gone from 1 failed machine with next-20160216 to > > 18 failed machines with next-20160217. > > > > The error I'm getting on omaps is below with debug_ll enable, > > any ideas? > > Hey Tony- > > Looks like the newly allocated gpio_device object isn't zeroed, > confusing dev_set_name. Can you give this a try? > > Josh > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > index d8511cd..59f0045 100644 > --- a/drivers/gpio/gpiolib.c > +++ b/drivers/gpio/gpiolib.c > @@ -435,7 +435,7 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data) > * First: allocate and populate the internal stat container, and > * set up the struct device. > */ > - gdev = kmalloc(sizeof(*gdev), GFP_KERNEL); > + gdev = kzalloc(sizeof(*gdev), GFP_KERNEL); > if (!gdev) > return -ENOMEM; > gdev->dev.bus = &gpio_bus_type; As you can see by my post on the GPIO mailing list, a boot failure was occurring on the Dragonboard 410C: http://permalink.gmane.org/gmane.linux.kernel.gpio/14360 With the above patch the board now boots. Good catch. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Bunch of machines are not booting in next again, GPIO regression? 2016-02-17 20:13 ` Michael Welling @ 2016-02-17 20:22 ` Tony Lindgren 2016-02-17 22:44 ` Josh Cartwright 0 siblings, 1 reply; 6+ messages in thread From: Tony Lindgren @ 2016-02-17 20:22 UTC (permalink / raw) To: linux-arm-kernel * Michael Welling <mwelling@ieee.org> [160217 12:13]: > On Wed, Feb 17, 2016 at 01:55:43PM -0600, Josh Cartwright wrote: > > On Wed, Feb 17, 2016 at 11:27:55AM -0800, Tony Lindgren wrote: > > > Hi Linus, > > > > > > Looks like ff2b13592299 ("gpio: make the gpiochip a real device") > > > broke booting on all omaps, and probably other machines too according > > > to this: > > > > > > https://kernelci.org/boot/all/job/next/kernel/next-20160217/ > > > > > > So far we've gone from 1 failed machine with next-20160216 to > > > 18 failed machines with next-20160217. > > > > > > The error I'm getting on omaps is below with debug_ll enable, > > > any ideas? > > > > Hey Tony- > > > > Looks like the newly allocated gpio_device object isn't zeroed, > > confusing dev_set_name. Can you give this a try? > > > > Josh > > > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > > index d8511cd..59f0045 100644 > > --- a/drivers/gpio/gpiolib.c > > +++ b/drivers/gpio/gpiolib.c > > @@ -435,7 +435,7 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data) > > * First: allocate and populate the internal stat container, and > > * set up the struct device. > > */ > > - gdev = kmalloc(sizeof(*gdev), GFP_KERNEL); > > + gdev = kzalloc(sizeof(*gdev), GFP_KERNEL); > > if (!gdev) > > return -ENOMEM; > > gdev->dev.bus = &gpio_bus_type; > > As you can see by my post on the GPIO mailing list, a boot failure > was occurring on the Dragonboard 410C: > http://permalink.gmane.org/gmane.linux.kernel.gpio/14360 > > With the above patch the board now boots. Good catch. Yup fixes the issue for me too. Thanks, Tony ^ permalink raw reply [flat|nested] 6+ messages in thread
* Bunch of machines are not booting in next again, GPIO regression? 2016-02-17 20:22 ` Tony Lindgren @ 2016-02-17 22:44 ` Josh Cartwright 2016-02-18 18:55 ` Linus Walleij 0 siblings, 1 reply; 6+ messages in thread From: Josh Cartwright @ 2016-02-17 22:44 UTC (permalink / raw) To: linux-arm-kernel On Wed, Feb 17, 2016 at 12:22:25PM -0800, Tony Lindgren wrote: > * Michael Welling <mwelling@ieee.org> [160217 12:13]: > > On Wed, Feb 17, 2016 at 01:55:43PM -0600, Josh Cartwright wrote: > > > On Wed, Feb 17, 2016 at 11:27:55AM -0800, Tony Lindgren wrote: > > > > Hi Linus, > > > > > > > > Looks like ff2b13592299 ("gpio: make the gpiochip a real device") > > > > broke booting on all omaps, and probably other machines too according > > > > to this: > > > > > > > > https://kernelci.org/boot/all/job/next/kernel/next-20160217/ > > > > > > > > So far we've gone from 1 failed machine with next-20160216 to > > > > 18 failed machines with next-20160217. > > > > > > > > The error I'm getting on omaps is below with debug_ll enable, > > > > any ideas? > > > > > > Hey Tony- > > > > > > Looks like the newly allocated gpio_device object isn't zeroed, > > > confusing dev_set_name. Can you give this a try? > > > > > > Josh > > > > > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > > > index d8511cd..59f0045 100644 > > > --- a/drivers/gpio/gpiolib.c > > > +++ b/drivers/gpio/gpiolib.c > > > @@ -435,7 +435,7 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data) > > > * First: allocate and populate the internal stat container, and > > > * set up the struct device. > > > */ > > > - gdev = kmalloc(sizeof(*gdev), GFP_KERNEL); > > > + gdev = kzalloc(sizeof(*gdev), GFP_KERNEL); > > > if (!gdev) > > > return -ENOMEM; > > > gdev->dev.bus = &gpio_bus_type; > > > > As you can see by my post on the GPIO mailing list, a boot failure > > was occurring on the Dragonboard 410C: > > http://permalink.gmane.org/gmane.linux.kernel.gpio/14360 > > > > With the above patch the board now boots. Good catch. > > Yup fixes the issue for me too. Linus- Here's a properly cooked patch. Otherwise, feel free to squash it in if it's easier for you. Josh -- 8< -- Subject: [PATCH] gpio: use kzalloc to allocate gpio_device The use of kmalloc() to allocate the gpio_device leaves the contained struct device object in an unknown state. Calling dev_set_name() on a struct device of unknown state can trigger the free() of an invalid pointer, as seen in the following backtrace (collected by Tony Lindgren): kfree kobject_set_name_vargs dev_set_name gpiochip_add_data omap_gpio_probe platform_drv_probe ... Reported-by: Michael Welling <mwelling@ieee.org> Reported-by: Tony Lindgren <tony@atomide.com> Tested-by: Michael Welling <mwelling@ieee.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Josh Cartwright <joshc@ni.com> --- drivers/gpio/gpiolib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index d8511cd..59f0045 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -435,7 +435,7 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data) * First: allocate and populate the internal stat container, and * set up the struct device. */ - gdev = kmalloc(sizeof(*gdev), GFP_KERNEL); + gdev = kzalloc(sizeof(*gdev), GFP_KERNEL); if (!gdev) return -ENOMEM; gdev->dev.bus = &gpio_bus_type; -- 2.7.0 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Bunch of machines are not booting in next again, GPIO regression? 2016-02-17 22:44 ` Josh Cartwright @ 2016-02-18 18:55 ` Linus Walleij 0 siblings, 0 replies; 6+ messages in thread From: Linus Walleij @ 2016-02-18 18:55 UTC (permalink / raw) To: linux-arm-kernel On Wed, Feb 17, 2016 at 11:44 PM, Josh Cartwright <joshc@ni.com> wrote: > Here's a properly cooked patch. Otherwise, feel free to squash it in if > it's easier for you. > > -- 8< -- > Subject: [PATCH] gpio: use kzalloc to allocate gpio_device Patch applied, of course. Big hugs and thanks for fixing my stupid mistake! N?ras, Linus Walleij ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-02-18 18:55 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-02-17 19:27 Bunch of machines are not booting in next again, GPIO regression? Tony Lindgren 2016-02-17 19:55 ` Josh Cartwright 2016-02-17 20:13 ` Michael Welling 2016-02-17 20:22 ` Tony Lindgren 2016-02-17 22:44 ` Josh Cartwright 2016-02-18 18:55 ` Linus Walleij
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).