linux-kernel - Re: Remove BKL from FAT/VFAT/MSDOS (v1) (was Re: Fw: Regression caused by bf726e "semaphore: fix,")

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 May 2008 13:45:37 -0700
From:	"Tony Luck" <tony.luck@...el.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"OGAWA Hirofumi" <hirofumi@...l.parknet.co.jp>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	corbet@....net
Subject: Re: Remove BKL from FAT/VFAT/MSDOS (v1) (was Re: Fw: Regression caused by bf726e "semaphore: fix,")

I'm seeing a process hang running a kernel built from the linux-next tree
with tag next-20080529 The problem commit looks to be:
35e447fc2fa408df8af2c8735f83a90cafe651ff

"Replace BKL with superblock lock in fat/msdos/vfat"

This causes a lockup when overwriting an existing file
on a vfat filesystem.  E.g. for me (where there already
exists a vmlinux.gz file in the target directory):

# cp --force vmlinux.gz /boot/efi/efi/redhat/

Stack trace looks like this:
Call Trace:
 [<a000000100712550>] schedule+0x11f0/0x1380
                                sp=e0000001bd55fc30 bsp=e0000001bd5510b8
 [<a000000100714cb0>] __mutex_lock_slowpath+0x2d0/0x520
                                sp=e0000001bd55fc50 bsp=e0000001bd551060
 [<a000000100714f20>] mutex_lock+0x20/0x40
                                sp=e0000001bd55fc80 bsp=e0000001bd551040
 [<a0000001001367d0>] lock_super+0x30/0x60
                                sp=e0000001bd55fc80 bsp=e0000001bd551020
 [<a00000010028ca30>] fat_truncate+0xb0/0x640^M
                                sp=e0000001bd55fc80 bsp=e0000001bd550fa0
 [<a0000001000fd930>] vmtruncate+0x1f0/0x260
                                sp=e0000001bd55fce0 bsp=e0000001bd550f70
 [<a000000100164250>] inode_setattr+0x50/0x320
                                sp=e0000001bd55fcf0 bsp=e0000001bd550f38
 [<a00000010028d520>] fat_setattr+0x4c0/0x580
                                sp=e0000001bd55fcf0 bsp=e0000001bd550ed0
 [<a0000001001648e0>] notify_change+0x3c0/0x620
                                sp=e0000001bd55fd10 bsp=e0000001bd550e70
 [<a00000010012fe00>] do_truncate+0xc0/0x120
                                sp=e0000001bd55fd30 bsp=e0000001bd550e30
 [<a0000001001494c0>] may_open+0x340/0x3a0
                                sp=e0000001bd55fd80 bsp=e0000001bd550de0
 [<a000000100149c60>] do_filp_open+0x740/0x11c0
                                sp=e0000001bd55fd80 bsp=e0000001bd550d18
 [<a000000100132470>] do_sys_open+0x90/0x1c0
                                sp=e0000001bd55fe30 bsp=e0000001bd550cc8
 [<a0000001001325f0>] sys_open+0x50/0x80
                                sp=e0000001bd55fe30 bsp=e0000001bd550c70

Looking at fat_setattr() I see it calls lock_super() at the start and releases
it at the end.  In between is the call to inode_setattr() ... which calls
down through inode_setattr() and vmtruncate() to fat_truncate() ...
which calls lock_super() again. Deadlock.

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/