From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D047CC5AE59 for ; Thu, 5 Jun 2025 09:40:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51F2B6B0570; Thu, 5 Jun 2025 05:40:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F5956B0572; Thu, 5 Jun 2025 05:40:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 40AED6B0575; Thu, 5 Jun 2025 05:40:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1F4696B0570 for ; Thu, 5 Jun 2025 05:40:11 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6EC3D1601D4 for ; Thu, 5 Jun 2025 09:40:10 +0000 (UTC) X-FDA: 83520850980.29.061DFE4 Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf04.hostedemail.com (Postfix) with ESMTP id 4894440015 for ; Thu, 5 Jun 2025 09:40:08 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=gMwwkrhg; spf=pass (imf04.hostedemail.com: domain of pmladek@suse.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=pmladek@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749116408; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KM55FHiiGw0ty5Vw0ggnMJ0P//GMDx7Mh10xK2QVjHM=; b=zddZLKijU8G/9ct2N+R754U00cHRLRuo0U6AaxIeNbCqmohl99EWYG2UJTCJg2Slg/FRmS nt2TV5g9F0RxEWDqEkffe1kHmwDPaLrvRWvpyR5/NNGjwjq8TTYvwbj3BJcpZP2RYvcKv6 MpVRQOSncEJjXDde1IiZZnDC0PUT4vE= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=gMwwkrhg; spf=pass (imf04.hostedemail.com: domain of pmladek@suse.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=pmladek@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749116408; a=rsa-sha256; cv=none; b=516Wv5FQcS5LgjJS7oupPPuOMGEjO3UaO3IDiwrdK94L3TZfJ+XAzPnTTl/wLFTbUWKAWt wMMBPA1/SnOszxA8bYOZz4WLiG/2I9pJP8AbmKECCKtBWNw0EY8VNPTgR2IXET3p2wZbd5 ettCkM6/wV00KIQGD+IzrET0wPce8Kg= Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-60461fc88d7so1470907a12.0 for ; Thu, 05 Jun 2025 02:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1749116407; x=1749721207; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=KM55FHiiGw0ty5Vw0ggnMJ0P//GMDx7Mh10xK2QVjHM=; b=gMwwkrhgk2jGufwlFl4DNKuCsm2fn5gDeMZZHonnJllraNcPFZW3mhsyj6yzBiNFA6 GIG30V73VzybC9uo8OACXgIdMElWKuRb/tYLbvkbhD1JpnOlXyKLIbclBT0FMKsBJBnd 52kR7Zin7hQfF7DSpHffd4FJPyg4fplKGliGK6J63HnKcbx71u9VxW1AMz3GV84FbOZc N4PULA7LNzZBweTtnRvF53c2MYCMrP2XMTspvi830O0oLefbAEznvMzLW7XGa1ic4N6v NmUfAkZrSVOCnsk3N/Ont2Z5kGIylo5pcW4KBOdMZJFnAjtGmzLEsvHjemnYcmxR/9+/ +bKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749116407; x=1749721207; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KM55FHiiGw0ty5Vw0ggnMJ0P//GMDx7Mh10xK2QVjHM=; b=kHTf5sZON3tBjiU4JWh3y1C74ffjxDk6gvCGdm3kxen3srmUkxylTMy1IXQ69dm8CZ +k8MpXyVWJKG9vVZURx/UL8qmgQG50ja7AGAXPOxzCw0kE+aebQBYTQuKe0z46Kol1h6 nme3aNfb7ZwZWigVHutpXuHm+OV/H4CyR8uHrsVs5kl7EtMksCx0CSNq/c3np86uFBdS zJxmMmpcKsBlFem8XmVW7ctxfoR/OCZueyQcIU/gPTzFqJPOjgdDWRvAoC1xn9ZmzRzm qTtWvdKIWQX6Wjn6ONmy6rA+/RUfgV/yxZkrwRK39S1Qm/6hssayL6yFB9RsBTq6VY0X TU2Q== X-Forwarded-Encrypted: i=1; AJvYcCWcYuihZj3w1vCuhMiu+g2KdcUWB91jVbgTT29M+DJGt4dBWlQxM/KMv/6flWOIAJnArf7ug5IpsQ==@kvack.org X-Gm-Message-State: AOJu0Yxn2qpO0r2j++kFsIrv6Bq+quDPHhG2MQ9rWLgso+udvDcS85+U k7l0kIwMp7zF03iOCNiz/WXdpB5DzHSBZcfKkT9qgzuDA9C5tzgOtU6TKnbbaIC9dec= X-Gm-Gg: ASbGncsEXQmGc8LzqkirXwbSTT7JjixRQ+Tmc/nU1bTBMu09a91mq67WLySRRQyYxbD rtoeheplWLkSs9wDhzEouVkizuO21ryuOAnaAuN7ZK0h7clXM1GNNoJWiIMosEoErw1Q9vBVrsR n0tbczkp30XESPGSdET3l0daC4vmcDR2LexjTQV7zXMoFLqiRzvz0p5cNnaoNLsY/BqhcC/qap+ 33VllK6uLJn+2pU0zKGwhZJshfpVRegyEDjIRpU/9dhB1Yun5BwadNX8sgsrWwDqGo7Gh9m+hKz wfixuKm7OQLySBnxYBxJT9zi04fn/1S2TxVp9UALJrYxL32gCHKPCg== X-Google-Smtp-Source: AGHT+IEXAjvH2zAlv9GtYKAcrlRuefB5G0wPoME06kubs8x8USrSVlKV/uqYoLN1zCBBu1d/yvPWvA== X-Received: by 2002:a17:907:d644:b0:ad2:2fe3:7074 with SMTP id a640c23a62f3a-addf8c87b91mr542476566b.14.1749116406549; Thu, 05 Jun 2025 02:40:06 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ada5d82d773sm1243900166b.61.2025.06.05.02.40.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Jun 2025 02:40:06 -0700 (PDT) Date: Thu, 5 Jun 2025 11:40:04 +0200 From: Petr Mladek To: Vlastimil Babka Cc: syzbot , Liam.Howlett@oracle.com, akpm@linux-foundation.org, jannh@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lorenzo.stoakes@oracle.com, pfalcato@suse.de, syzkaller-bugs@googlegroups.com, Suren Baghdasaryan , Peter Zijlstra , John Ogness Subject: Re: [syzbot] [mm?] possible deadlock in __vma_start_write Message-ID: References: <68387feb.a70a0220.29d4a0.0830.GAE@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 4894440015 X-Stat-Signature: 4juj77rd73wfy6wwftidbch4giyeuidx X-Rspam-User: X-HE-Tag: 1749116408-899114 X-HE-Meta: U2FsdGVkX1/0ra1fiufFvjaKf950E6jyUcA3Iir0ZySNpNjIcTrpVuemkjvLmnF2E8IrcnKyRpR3j60ysYsNO40Ui/Tg8I/PwbZTtZwqGjrpKSOLrCWTSRJNLhKO5zBClNQvqg4fmdrX6aEyuqXEthvWNg7lxqmsTjtf9LhhoTl1deFpyBQbCuhj0n6sQKryVIDUaYmpiTYANsTSoKxa6LbtUAyXDF14JkxTvz9xUVhl7DjTOKd+6RoS5R082H0zZ+yZVZw0W990cwgCVLdZad7eX/M5WZe6IUUl4NAvWk+fBL4y0WAnlCTPxC1UirkXyHvlAU53SE+GNBUMHfFfG37gbGNz3AGB5pGQ3PIZwJFbg+NSPM5QvIFptTHC9cJaB3tINE3MdbFTZLj8QeNtTEEzq16v0N1Bdsudw7w+ByWDgemVUaf5Cmnf1eIN+BEPNbU33OX+9oekxrLlJLA/GwgAoT1w/DpQ2Hg5749Z9h3eGpV9LFjVYRwna0mD1Ng3MFWaulB/jYV3OG5rAvMQb7y2H4EJec8TzJDXE2gUP85bWdeAvlLtfqdnS87cweLdqz2jc/d9cICWz519bosrCKKTbw/nvcu75sxb4nW0ZNIu/iv2aRNAs94rEaW5kHHulfRTLbgUVCMwS15In+AX4J/bHWNxkZ1k0x2RjHd5yhC64rLizC9Fvh51dtBHxM/g9IdPZD70r8QVIf8nf/LNzBGjuRZw9E6QWsVGeqJ5czcOfgaQyJXLSY3OlhOWYfztWPYrUPW/UopJXjXpKemVRLow1r2ky3QFjwyZ7n0MHG2mCufTWdhcb1/472HOI7SQmuaxxzDgy39SmBTNscFuMLsGISovl9xFkH3slZ44WfnwB/qCYyQ5gqHtEmLe6T7Rza5Sy6eOMhS2O1GA3tLjSK0to2zaFLU7P/jpFJeVblpxvoWEsWLM0U9av+NvUNaD2Pxaaq1KWdwvUXL4kzT nQcNLZp/ 0oNPMkuvhvf2F4DumgED7S2EZ0wlB1ZIHr45fI4y29KQRdgnkd5MqUqy/V7PhBgBsjdarqPX5mOATQNshLXd76KYn1vDb1kssvxWFcMq274jH3RqvFZdlxKPHeD4mu6ho/Jeu0t7j6C2+1jmIRzvquxmFIow/0wuUinCzWNo+/Nn6XjjX5A424Opy1yxrTOl7jo/tVpyJfYNVXOVGTFE5JOU6M7oSDwoHwP9TWcU6ELtp7YKYGxyx3HGND6y0iPIk++g0MpltGM87Nc/9jfsGfn0U50CVwOjEx60sf+EGP+ppVUfnk+zuwo/FX3ooupDjnjvsxiB0Kn+DBwpMC1fAT96S8TcmvPdmk3T2CGf0zAML3IcXXpoSrqfqNA7UpIOOB9bvxyqKMu7iBiMCScbrq7UbsK8knvHehp2ZzDc/5h8RVTb8hSE8hMzcXFmNjiLyrNS0mRjjZsm5axYnKX1x6gS0p+8U8r5FRpsmn+6ljDz2H5GLsVGWn24ANyOcoBB22J6MJPaX63WYRwgZTBnljPtFmvkrVeorxP6PQ27JFtwV7y3361kN/Fcj9DU7Z5yKBOIV5MEvDkH/jCWOBpBfdz8Rlx+fKNv/PMP9zdlUC+s6DuCKoyhKK5TXcN3UrEXUw8pMKqW7fTRMRqf25BJoZ9gsiIFIUFQaGFgTuJFAPAznDxWXf6Y743Xegk0Pj3MxSPTJAgBObzTtZNrJ/7oHCcSu+1xAO2fNCXsGHqBowlM+8yZNZFa3U73NG13UKLFpq07i2JSgBdf/VWOnggE0NA2dxOUh1kAZcoU8H75csRE1toD9V9gHTyaU8UvnXQeNxpg6EcJ76k0UIBK+YFXfe4vV0ZFcZ01kGCrZHnWEnIGU3Vk2wY9aQ+4f4dCWwtMdB3n11wEFYdg/IBfyJ2uja0YlYhTFUrt8gw8CfuVsE4mDzhSaK1kcTXcJe4GCDQOgLoOs X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed 2025-06-04 09:52:24, Vlastimil Babka wrote: > On 5/29/25 17:40, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: d7fa1af5b33e Merge branch 'for-next/core' into for-kernelci > > git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci > > console output: https://syzkaller.appspot.com/x/log.txt?x=12bbdad4580000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=89c13de706fbf07a > > dashboard link: https://syzkaller.appspot.com/bug?extid=23de6daeb71241d36a18 > > compiler: Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6 > > userspace arch: arm64 > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > Downloadable assets: > > disk image: https://storage.googleapis.com/syzbot-assets/da97ad659b2c/disk-d7fa1af5.raw.xz > > vmlinux: https://storage.googleapis.com/syzbot-assets/659e123552a8/vmlinux-d7fa1af5.xz > > kernel image: https://storage.googleapis.com/syzbot-assets/6ec5dbf4643e/Image-d7fa1af5.gz.xz > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+23de6daeb71241d36a18@syzkaller.appspotmail.com > > > > SQUASHFS error: zstd decompression failed, data probably corrupt > > SQUASHFS error: Failed to read block 0x60: -5 > > ====================================================== > > WARNING: possible circular locking dependency detected > > 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 Not tainted > > ------------------------------------------------------ > > syz.1.261/8150 is trying to acquire lock: > > ffff0000d7ffcbc8 (vm_lock){++++}-{0:0}, at: __vma_start_write+0x34/0x158 mm/memory.c:6497 > > > > but task is already holding lock: > > ffff0000d572df50 (&mm->mmap_lock){++++}-{4:4}, at: mmap_write_lock include/linux/mmap_lock.h:128 [inline] > > ffff0000d572df50 (&mm->mmap_lock){++++}-{4:4}, at: exit_mmap+0x200/0xbec mm/mmap.c:1292 > > > > which lock already depends on the new lock. > > > > > > the existing dependency chain (in reverse order) is: > > > > -> #6 (&mm->mmap_lock){++++}-{4:4}: > > __might_fault+0xc4/0x124 mm/memory.c:7151 > > drm_mode_get_lease_ioctl+0x2bc/0x53c drivers/gpu/drm/drm_lease.c:673 > > drm_ioctl_kernel+0x238/0x310 drivers/gpu/drm/drm_ioctl.c:796 > > drm_ioctl+0x65c/0xa5c drivers/gpu/drm/drm_ioctl.c:893 > > vfs_ioctl fs/ioctl.c:51 [inline] > > __do_sys_ioctl fs/ioctl.c:906 [inline] > > __se_sys_ioctl fs/ioctl.c:892 [inline] > > __arm64_sys_ioctl+0x14c/0x1c4 fs/ioctl.c:892 > > __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] > > invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 > > el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 > > do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 > > el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 > > el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 > > el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 > > > > -> #5 (&dev->mode_config.idr_mutex){+.+.}-{4:4}: > > __mutex_lock_common+0x1d0/0x2190 kernel/locking/mutex.c:601 > > __mutex_lock kernel/locking/mutex.c:746 [inline] > > mutex_lock_nested+0x2c/0x38 kernel/locking/mutex.c:798 > > __drm_mode_object_add+0xa8/0x1f0 drivers/gpu/drm/drm_mode_object.c:47 > > drm_framebuffer_init+0x14c/0x2bc drivers/gpu/drm/drm_framebuffer.c:875 > > drm_gem_fb_init drivers/gpu/drm/drm_gem_framebuffer_helper.c:82 [inline] > > drm_gem_fb_init_with_funcs+0xa60/0xda4 drivers/gpu/drm/drm_gem_framebuffer_helper.c:202 > > drm_gem_fb_create_with_funcs drivers/gpu/drm/drm_gem_framebuffer_helper.c:245 [inline] > > drm_gem_fb_create+0x84/0xd4 drivers/gpu/drm/drm_gem_framebuffer_helper.c:286 > > drm_internal_framebuffer_create+0xfcc/0x19dc drivers/gpu/drm/drm_framebuffer.c:304 > > drm_mode_addfb2+0xac/0x2a0 drivers/gpu/drm/drm_framebuffer.c:338 > > drm_client_buffer_addfb drivers/gpu/drm/drm_client.c:386 [inline] > > drm_client_framebuffer_create+0x2d0/0x55c drivers/gpu/drm/drm_client.c:428 > > drm_fbdev_shmem_driver_fbdev_probe+0x180/0x70c drivers/gpu/drm/drm_fbdev_shmem.c:151 > > drm_fb_helper_single_fb_probe drivers/gpu/drm/drm_fb_helper.c:1649 [inline] > > __drm_fb_helper_initial_config_and_unlock+0xf94/0x159c drivers/gpu/drm/drm_fb_helper.c:1829 > > drm_fb_helper_initial_config+0x3c/0x58 drivers/gpu/drm/drm_fb_helper.c:1916 > > drm_fbdev_client_hotplug+0x154/0x22c drivers/gpu/drm/clients/drm_fbdev_client.c:52 > > drm_client_register+0x13c/0x1d4 drivers/gpu/drm/drm_client.c:140 > > drm_fbdev_client_setup+0x194/0x3d0 drivers/gpu/drm/clients/drm_fbdev_client.c:159 > > drm_client_setup+0x78/0x140 drivers/gpu/drm/clients/drm_client_setup.c:39 > > vkms_create drivers/gpu/drm/vkms/vkms_drv.c:218 [inline] > > vkms_init+0x4b8/0x5ac drivers/gpu/drm/vkms/vkms_drv.c:242 > > do_one_initcall+0x250/0x990 init/main.c:1257 > > do_initcall_level+0x154/0x214 init/main.c:1319 > > do_initcalls+0x84/0xf4 init/main.c:1335 > > do_basic_setup+0x8c/0xa0 init/main.c:1354 > > kernel_init_freeable+0x2dc/0x444 init/main.c:1567 > > kernel_init+0x24/0x1dc init/main.c:1457 > > ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847 > > > > -> #4 (&helper->lock){+.+.}-{4:4}: > > __mutex_lock_common+0x1d0/0x2190 kernel/locking/mutex.c:601 > > __mutex_lock kernel/locking/mutex.c:746 [inline] > > mutex_lock_nested+0x2c/0x38 kernel/locking/mutex.c:798 > > __drm_fb_helper_restore_fbdev_mode_unlocked+0x74/0x198 drivers/gpu/drm/drm_fb_helper.c:228 > > drm_fb_helper_set_par+0xa4/0x108 drivers/gpu/drm/drm_fb_helper.c:1359 > > fbcon_init+0xe4c/0x1d18 drivers/video/fbdev/core/fbcon.c:1112 > > visual_init+0x27c/0x540 drivers/tty/vt/vt.c:1011 > > do_bind_con_driver+0x7b8/0xdd8 drivers/tty/vt/vt.c:3831 > > do_take_over_console+0x824/0x97c drivers/tty/vt/vt.c:4397 > > do_fbcon_takeover+0x158/0x25c drivers/video/fbdev/core/fbcon.c:548 > > do_fb_registered drivers/video/fbdev/core/fbcon.c:2989 [inline] > > fbcon_fb_registered+0x354/0x4c8 drivers/video/fbdev/core/fbcon.c:3009 > > do_register_framebuffer drivers/video/fbdev/core/fbmem.c:449 [inline] > > register_framebuffer+0x44c/0x5ec drivers/video/fbdev/core/fbmem.c:515 > > __drm_fb_helper_initial_config_and_unlock+0x103c/0x159c drivers/gpu/drm/drm_fb_helper.c:1851 > > drm_fb_helper_initial_config+0x3c/0x58 drivers/gpu/drm/drm_fb_helper.c:1916 > > drm_fbdev_client_hotplug+0x154/0x22c drivers/gpu/drm/clients/drm_fbdev_client.c:52 > > drm_client_register+0x13c/0x1d4 drivers/gpu/drm/drm_client.c:140 > > drm_fbdev_client_setup+0x194/0x3d0 drivers/gpu/drm/clients/drm_fbdev_client.c:159 > > drm_client_setup+0x78/0x140 drivers/gpu/drm/clients/drm_client_setup.c:39 > > vkms_create drivers/gpu/drm/vkms/vkms_drv.c:218 [inline] > > vkms_init+0x4b8/0x5ac drivers/gpu/drm/vkms/vkms_drv.c:242 > > do_one_initcall+0x250/0x990 init/main.c:1257 > > do_initcall_level+0x154/0x214 init/main.c:1319 > > do_initcalls+0x84/0xf4 init/main.c:1335 > > do_basic_setup+0x8c/0xa0 init/main.c:1354 > > kernel_init_freeable+0x2dc/0x444 init/main.c:1567 > > kernel_init+0x24/0x1dc init/main.c:1457 > > ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847 I just wanted to better understand what was going on here ;-) Let me share my thoughts. First, the deadlock might happen only when all these (or similar) code paths might be called in parallel. The two backtraces, right above, are from initcalls. It is possible that the code path in the 1st backtrace can't be called before the device is initialized. So, it is possible that the deadlock can't happen in the real life. I guess that this is the reason why people say that the deadlock is very unlikely. Second. if we wanted to remove the cyclic dependency then we would need to break the chain somewhere. I am not familiar with th fbcon code. But my guess is that we take console_lock() here to prevent using the graphical console by printk() while we are switching the driver behind the console. I am afraid that we might have similar problem even after removing console_lock. It just would be replaced by another tty-specific lock or so. Just an idea. A solution would be to temporary pause the related console. I mean to do something like: diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index ac3c99ed92d1..12ec99b69068 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -3002,14 +3002,14 @@ int fbcon_fb_registered(struct fb_info *info) int ret; if (!lockless_register_fb) - console_lock(); + pause_tty_console(); else atomic_inc(&ignore_console_lock_warning); ret = do_fb_registered(info); if (!lockless_register_fb) - console_unlock(); + unpause_tty_console(); else atomic_dec(&ignore_console_lock_warning); Where pause_tty_console()/unpause_tty_console() would just set a flag or manipulate a counter in struct console. The trick is that do_fb_registered() could then be called without console_lock(). I hope that it might broke the chain. Is it worth investigating this approach? Does it make any sense? Best Regards, Petr