From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from lb3-smtp-cloud3.xs4all.net ([194.109.24.30]:58603 "EHLO lb3-smtp-cloud3.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752382AbcEAWEs (ORCPT ); Sun, 1 May 2016 18:04:48 -0400 Subject: Re: 4.6 regression: deadlock in exynos fimc_md_probe() To: Mauro Carvalho Chehab References: <57262BAD.2020704@xs4all.nl> <572631F8.1020705@xs4all.nl> <57263234.1060400@xs4all.nl> Cc: Marek Szyprowski , Sakari Ailus , Linux Media Mailing List From: Hans Verkuil Message-ID: <57267D79.7090800@xs4all.nl> Date: Mon, 2 May 2016 00:04:41 +0200 MIME-Version: 1.0 In-Reply-To: <57263234.1060400@xs4all.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org List-ID: Oh never mind, Marek posted a patch for this on Thursday which I didn't notice. Mauro, these two patches: [PATCH 1/2] media: exynos4-is: fix deadlock on driver probe [PATCH 2/2] media: s3c-camif: fix deadlock on driver probe() should be fasttracked for 4.6. Hans On 05/01/2016 06:43 PM, Hans Verkuil wrote: > On 05/01/2016 06:42 PM, Hans Verkuil wrote: >> I'm adding Sakari since this problem was introduced in his commit 0c426c472b5585ed6e59160359c979506d45ae49: >> "media: Always keep a graph walk large enough around". > > And now adding linux-media as well. Sorry about that. > > Hans > >> >> Regards, >> >> Hans >> >> On 05/01/2016 06:15 PM, Hans Verkuil wrote: >>> Hi Mauro, >>> >>> While testing an unrelated patch series for the exynos4 using kernel 4.6 I >>> came across this deadlock that caused the boot sequence to hang (I'm using >>> an exynos4 Odroid U3): >>> >>> ============================================= >>> [ INFO: possible recursive locking detected ] >>> 4.6.0-rc5-odroid #987 Not tainted >>> --------------------------------------------- >>> swapper/0/1 is trying to acquire lock: >>> (&mdev->graph_mutex){+.+.+.}, at: [] media_device_register_entity+0x78/0x1e8 >>> >>> but task is already holding lock: >>> (&mdev->graph_mutex){+.+.+.}, at: [] fimc_md_probe+0x22c/0xac0 >>> >>> other info that might help us debug this: >>> Possible unsafe locking scenario: >>> >>> CPU0 >>> ---- >>> lock(&mdev->graph_mutex); >>> lock(&mdev->graph_mutex); >>> >>> *** DEADLOCK *** >>> >>> May be due to missing lock nesting notation >>> >>> 4 locks held by swapper/0/1: >>> #0: (&dev->mutex){......}, at: [] __driver_attach+0x58/0xcc >>> #1: (&dev->mutex){......}, at: [] __driver_attach+0x68/0xcc >>> #2: (&mdev->graph_mutex){+.+.+.}, at: [] fimc_md_probe+0x22c/0xac0 >>> #3: (&dev->mutex){......}, at: [] fimc_md_probe+0x2fc/0xac0 >>> >>> stack backtrace: >>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc5-odroid #987 >>> Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) >>> Backtrace: >>> [] (dump_backtrace) from [] (show_stack+0x18/0x1c) >>> r7:c0d1c9a4 r6:c0d1c9a4 r5:200001d3 r4:00000000 >>> [] (show_stack) from [] (dump_stack+0xb0/0xdc) >>> [] (dump_stack) from [] (__lock_acquire+0x19bc/0x1dcc) >>> r9:ee880000 r8:c1516a7c r7:c14dc9ec r6:c0e99058 r5:c0e99058 r4:c0e99058 >>> [] (__lock_acquire) from [] (lock_acquire+0x78/0x98) >>> r10:eefad144 r9:eea95044 r8:ee880000 r7:00000001 r6:00000000 r5:60000153 >>> r4:00000000 >>> [] (lock_acquire) from [] (mutex_lock_nested+0x70/0x4c0) >>> r7:c14dc9ec r6:c05d96d4 r5:00000000 r4:ee2bdcac >>> [] (mutex_lock_nested) from [] (media_device_register_entity+0x78/0x1e8) >>> r10:eefad144 r9:eea95044 r8:ee2bdc44 r7:ee2bdcac r6:ee2bd910 r5:00000000 >>> r4:ee30d4d0 >>> [] (media_device_register_entity) from [] (v4l2_device_register_subdev+0xa4/0x174) >>> r8:ee30d010 r7:eefad4ac r6:00000000 r5:ee2bdd90 r4:ee30d4d0 >>> [] (v4l2_device_register_subdev) from [] (fimc_md_probe+0x544/0xac0) >>> r7:eefad4ac r6:eea95000 r5:ee30d4d0 r4:ee2bd810 >>> [] (fimc_md_probe) from [] (platform_drv_probe+0x54/0xb8) >>> r10:00000116 r9:00000000 r8:c0d36da4 r7:fffffdfb r6:c0d36da4 r5:eea94c10 >>> r4:eea94c10 >>> [] (platform_drv_probe) from [] (driver_probe_device+0x21c/0x2c8) >>> r7:00000000 r6:c151c298 r5:c151c290 r4:eea94c10 >>> [] (driver_probe_device) from [] (__driver_attach+0xc8/0xcc) >>> r9:c0d52000 r8:00000000 r7:00000000 r6:eea94c44 r5:c0d36da4 r4:eea94c10 >>> [] (__driver_attach) from [] (bus_for_each_dev+0x70/0xa4) >>> r7:00000000 r6:c04aecf8 r5:c0d36da4 r4:00000000 >>> [] (bus_for_each_dev) from [] (driver_attach+0x24/0x28) >>> r6:c0d26af8 r5:eea76c80 r4:c0d36da4 >>> [] (driver_attach) from [] (bus_add_driver+0x1a8/0x220) >>> [] (bus_add_driver) from [] (driver_register+0x80/0x100) >>> r7:edd74d80 r6:c0d05a90 r5:c0c1c83c r4:c0d36da4 >>> [] (driver_register) from [] (__platform_driver_register+0x48/0x50) >>> r5:c0c1c83c r4:c0d05a90 >>> [] (__platform_driver_register) from [] (fimc_md_init+0x34/0x40) >>> [] (fimc_md_init) from [] (do_one_initcall+0x98/0x1e4) >>> [] (do_one_initcall) from [] (kernel_init_freeable+0x164/0x208) >>> r8:00000006 r7:c0c34858 r6:c0c00608 r5:c0c34850 r4:c0d52000 >>> [] (kernel_init_freeable) from [] (kernel_init+0x10/0x11c) >>> r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0899c74 >>> r4:00000000 >>> [] (kernel_init) from [] (ret_from_fork+0x14/0x24) >>> r5:c0899c74 r4:00000000 >>> >>> Commenting out 'mutex_lock(&fmd->media_dev.graph_mutex);' in fimc_md_probe() >>> makes it boot again, but I'm not 100% certain that's correct. >>> >>> Can you take a look? >>> >>> Thanks! >>> >>> Hans >>> > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >