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  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, 14 Nov 2013 14:41:16 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: sysfs_bin_mmap lockdep trace.

hey,

On Wed, Nov 13, 2013 at 08:10:43PM +0000, Al Viro wrote:
> On Wed, Nov 13, 2013 at 01:45:38PM -0500, Dave Jones wrote:
> > Al, is this one also known ? Also seen on v3.12-7033-g42a2d923cc34
> 
> Umm...  I've seen something like that reported after sysfs merge went in
> (right after 3.12), but I hadn't looked into details.
> 
> > -> #3 (&mm->mmap_sem){++++++}:
> 
> 	[sr_block_ioctl() grabs sr_mutex and does copy_from_user() under it]
> 
> > -> #2 (sr_mutex){+.+.+.}:
> 	[sr_block_open() grabs sr_mutex under ->bd_mutex]
> 
> > -> #1 (&bdev->bd_mutex){+.+.+.}:
> 	[sysfs_blk_trace_attr_show() grabs ->bd_mutex and is called under
> sysfs_open_file ->mutex]
> 
> > -> #0 (&of->mutex){+.+.+.}:
> 	[sysfs_open_file ->mutex is grabbed by ->mmap()]
> 
> Cute...  AFAICS, it came from "sysfs: copy bin mmap support from fs/sysfs/bin.c
> to fs/sysfs/file.c".  The first impression is that sysfs_bin_mmap() is
> checking for battr->mmap too late, but I'm not sure whether we need of->mutex
> to stabilize it...  Tejun, any comments?

Hmmm... so this is a false positive from regular and bin file paths
being merged.  There was a sysfs regular file which grabbed sr_mutex
while holding sysfs mutex and only bin files supported mmap which of
course nest under mmap_sem.  As the two paths were separate and using
separate locks, this deadlock scenario didn't trigger.  Now that the
two paths are merged, lockdep considers the two paths to be using the
same mutex (they're per-file so still actually separate) and generates
this warning.  The easiest way out would be giving different lock
subclasses to files w/ and w/o mmap method.  I'll think more about it.

Thanks.

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

Powered by blists - more mailing lists