linux/fs/sysfs, branch v3.13

sysfs: give different locking key to regular and bin files

2013-12-08T05:22:00Z

027a485d12e0 ("sysfs: use a separate locking class for open files depending on mmap") assigned different lockdep key to sysfs_open_file->mutex depending on whether the file implements mmap or not in an attempt to avoid spurious lockdep warning caused by merging of regular and bin file paths. While this restored some of the original behavior of using different locks (at least lockdep is concerned) for the different clases of files. The restoration wasn't full because now the lockdep key assignment depends on whether the file has mmap or not instead of whether it's a regular file or not. This means that bin files which don't implement mmap will get assigned the same lockdep class as regular files. This is problematic because file_operations for bin files still implements the mmap file operation and checking whether the sysfs file actually implements mmap happens in the file operation after grabbing @sysfs_open_file->mutex. We still end up adding locking dependency from mmap locking to sysfs_open_file->mutex to the regular file mutex which triggers spurious circular locking warning. Fix it by restoring the original behavior fully by differentiating lockdep key by whether the file is regular or bin, instead of the existence of mmap. Signed-off-by: Tejun Heo Reported-by: Dave Jones Link: http://lkml.kernel.org/g/20131203184324.GA11320@redhat.com Signed-off-by: Greg Kroah-Hartman

Revert "sysfs: handle duplicate removal attempts in sysfs_remove_group()"

2013-11-27T17:44:55Z

This reverts commit 54d71145a4548330313ca664a4a009772fe8b7dd. The root cause of these "inverted" sysfs removals have now been found, so there is no need for this patch. Keep this functionality around so that this type of error doesn't show up in driver code again. Cc: Mika Westerberg Cc: Rafael J. Wysocki Cc: Tejun Heo Signed-off-by: Greg Kroah-Hartman

sysfs: use a separate locking class for open files depending on mmap

2013-11-23T18:52:13Z

The following two commits implemented mmap support in the regular file path and merged bin file support into the regular path. 73d9714627ad ("sysfs: copy bin mmap support from fs/sysfs/bin.c to fs/sysfs/file.c") 3124eb1679b2 ("sysfs: merge regular and bin file handling") After the merge, the following commands trigger a spurious lockdep warning. "test-mmap-read" simply mmaps the file and dumps the content. $ cat /sys/block/sda/trace/act_mask $ test-mmap-read /sys/devices/pci0000\:00/0000\:00\:03.0/resource0 4096 ====================================================== [ INFO: possible circular locking dependency detected ] 3.12.0-work+ #378 Not tainted ------------------------------------------------------- test-mmap-read/567 is trying to acquire lock: (&of->mutex){+.+.+.}, at: [] sysfs_bin_mmap+0x4f/0x120 but task is already holding lock: (&mm->mmap_sem){++++++}, at: [] vm_mmap_pgoff+0x49/0xa0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&mm->mmap_sem){++++++}: ... -> #2 (sr_mutex){+.+.+.}: ... -> #1 (&bdev->bd_mutex){+.+.+.}: ... -> #0 (&of->mutex){+.+.+.}: ... other info that might help us debug this: Chain exists of: &of->mutex --> sr_mutex --> &mm->mmap_sem Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_sem); lock(sr_mutex); lock(&mm->mmap_sem); lock(&of->mutex); *** DEADLOCK *** 1 lock held by test-mmap-read/567: #0: (&mm->mmap_sem){++++++}, at: [] vm_mmap_pgoff+0x49/0xa0 stack backtrace: CPU: 3 PID: 567 Comm: test-mmap-read Not tainted 3.12.0-work+ #378 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 ffffffff81ed41a0 ffff880009441bc8 ffffffff81611ad2 ffffffff81eccb80 ffff880009441c08 ffffffff8160f215 ffff880009441c60 ffff880009c75208 0000000000000000 ffff880009c751e0 ffff880009c75208 ffff880009c74ac0 Call Trace: [] dump_stack+0x4e/0x7a [] print_circular_bug+0x2b0/0x2bf [] __lock_acquire+0x1a3a/0x1e60 [] lock_acquire+0x9a/0x1d0 [] mutex_lock_nested+0x67/0x3f0 [] sysfs_bin_mmap+0x4f/0x120 [] mmap_region+0x3b3/0x5b0 [] do_mmap_pgoff+0x34e/0x3d0 [] vm_mmap_pgoff+0x6a/0xa0 [] SyS_mmap_pgoff+0xbe/0x250 [] SyS_mmap+0x22/0x30 [] system_call_fastpath+0x16/0x1b This happens because one file nests sr_mutex, which nests mm->mmap_sem under it, under of->mutex while mmap implementation naturally nests of->mutex under mm->mmap_sem. The warning is false positive as of->mutex is per open-file and the two paths belong to two different files. This warning didn't trigger before regular and bin file supports were merged because only bin file supported mmap and the other side of locking happened only on regular files which used equivalent but separate locking. It'd be best if we give separate locking classes per file but we can't easily do that. Let's differentiate on ->mmap() for now. Later we'll add explicit file operations struct and can add per-ops lockdep key there. Signed-off-by: Tejun Heo Reported-by: Dave Jones Signed-off-by: Greg Kroah-Hartman

sysfs: handle duplicate removal attempts in sysfs_remove_group()

2013-11-23T18:52:13Z

Commit bcdde7e221a8 (sysfs: make __sysfs_remove_dir() recursive) changed the behavior so that directory removals will be done recursively. This means that the sysfs group might already be removed if its parent directory has been removed. The current code outputs warnings similar to following log snippet when it detects that there is no group for the given kobject: WARNING: CPU: 0 PID: 4 at fs/sysfs/group.c:214 sysfs_remove_group+0xc6/0xd0() sysfs group ffffffff81c6f1e0 not found for kobject 'host7' Modules linked in: CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 3.12.0+ #13 Hardware name: /D33217CK, BIOS GKPPT10H.86A.0042.2013.0422.1439 04/22/2013 Workqueue: kacpi_hotplug acpi_hotplug_work_fn 0000000000000009 ffff8801002459b0 ffffffff817daab1 ffff8801002459f8 ffff8801002459e8 ffffffff810436b8 0000000000000000 ffffffff81c6f1e0 ffff88006d440358 ffff88006d440188 ffff88006e8b4c28 ffff880100245a48 Call Trace: [] dump_stack+0x45/0x56 [] warn_slowpath_common+0x78/0xa0 [] warn_slowpath_fmt+0x47/0x50 [] ? sysfs_get_dirent_ns+0x49/0x70 [] sysfs_remove_group+0xc6/0xd0 [] dpm_sysfs_remove+0x3e/0x50 [] device_del+0x40/0x1b0 [] device_unregister+0xd/0x20 [] scsi_remove_host+0xba/0x110 [] ata_host_detach+0xc6/0x100 [] ata_pci_remove_one+0x18/0x20 [] pci_device_remove+0x28/0x60 [] __device_release_driver+0x64/0xd0 [] device_release_driver+0x1e/0x30 [] bus_remove_device+0xf7/0x140 [] device_del+0x121/0x1b0 [] pci_stop_bus_device+0x94/0xa0 [] pci_stop_bus_device+0x3b/0xa0 [] pci_stop_bus_device+0x3b/0xa0 [] pci_stop_and_remove_bus_device+0xd/0x20 [] trim_stale_devices+0x73/0xe0 [] trim_stale_devices+0xbb/0xe0 [] trim_stale_devices+0xbb/0xe0 [] acpiphp_check_bridge+0x7e/0xd0 [] hotplug_event+0xcd/0x160 [] hotplug_event_work+0x25/0x60 [] acpi_hotplug_work_fn+0x17/0x22 [] process_one_work+0x17a/0x430 [] worker_thread+0x119/0x390 [] ? manage_workers.isra.25+0x2a0/0x2a0 [] kthread+0xcd/0xf0 [] ? kthread_create_on_node+0x180/0x180 [] ret_from_fork+0x7c/0xb0 [] ? kthread_create_on_node+0x180/0x180 On this particular machine I see ~16 of these message during Thunderbolt hot-unplug. Fix this in similar way that was done for sysfs_remove_one() by checking if the parent directory has already been removed and bailing out early. Signed-off-by: Mika Westerberg Acked-by: Rafael J. Wysocki Acked-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman

Revert "sysfs: drop kobj_ns_type handling"

2013-11-07T11:47:28Z

This reverts commit cb26a311578e67769e92a39a0a63476533cb7e12. It mysteriously causes NetworkManager to not find the wireless device for me. As far as I can tell, Tejun *meant* for this commit to not make any semantic changes, but there clearly are some. So revert it, taking into account some of the calling convention changes that happened in this area in subsequent commits. Cc: Tejun Heo Cc: Greg Kroah-Hartman Signed-off-by: Linus Torvalds

sysfs: rename sysfs_assoc_lock and explain what it's about

2013-11-01T19:13:37Z

sysfs_assoc_lock is an odd piece of locking. In general, whoever owns a kobject is responsible for synchronizing sysfs operations and sysfs proper assumes that, for example, removal won't race with any other operation; however, this doesn't work for symlinking because an entity performing symlink doesn't usually own the target kobject and thus has no control over its removal. sysfs_assoc_lock synchronizes symlink operations against kobj->sd disassociation so that symlink code doesn't end up dereferencing already freed sysfs_dirent by racing with removal of the target kobject. This is quite obscure and the generic name of the lock and lack of comments make it difficult to understand its role. Let's rename it to sysfs_symlink_target_lock and add comments explaining what's going on. Signed-off-by: Tejun Heo Reported-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

sysfs: use generic_file_llseek() for sysfs_file_operations

2013-11-01T19:13:37Z

13c589d5b0ac6 ("sysfs: use seq_file when reading regular files") converted regular sysfs files to use seq_file. The commit substituted generic_file_llseek() with seq_lseek() for llseek implementation. Before the change, all regular sysfs files were allowed to seek to any position in [0, PAGE_SIZE] as the file size is always PAGE_SIZE and generic_file_llseek() allows any seeking inside the range under file size; however, seq_lseek()'s behavior is different. It traverses the output by repeatedly invoking ->show() until it reaches the target offset or traversal indicates EOF. As seq_files are fully dynamic and may not end at all, it doesn't support seeking from the end (SEEK_END). Apparently, there are userland tools which uses SEEK_END to discover the buffer size to use and the switch to seq_lseek() disturbs them as SEEK_END fails with -EINVAL. The only benefits of using seq_lseek() instead of generic_file_llseek() are * Early failure. If traversing to certain file position should fail, seq_lseek() will report such failures on lseek(2) instead of the following read/write operations. * EOF detection. While SEEK_END is not supported, SEEK_SET/CUR + large offset can be used to detect eof - eof at the time of the seek anyway as the file size may change dynamically. Both aren't necessary for sysfs or prospect kernfs users. Revert to genefic_file_llseek() and preserve the original behavior. Signed-off-by: Tejun Heo Reported-by: Heiko Carstens Link: https://lkml.kernel.org/r/20131031114358.GA5551@osiris Tested-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

sysfs: return correct error code on unimplemented mmap()

2013-10-30T17:21:39Z

Both POSIX.1-2008 and Linux Programmer's Manual have a dedicated return error code for a case, when a file doesn't support mmap(), it's ENODEV. This change replaces overloaded EINVAL with ENODEV in a situation described above for sysfs binary files. Signed-off-by: Vladimir Zapolskiy Signed-off-by: Greg Kroah-Hartman

sysfs: separate out dup filename warning into a separate function

2013-10-29T22:12:07Z

Separate out sysfs_warn_dup() out of sysfs_add_one(). This will help separating out the core sysfs functionalities into kernfs so that it can be used by non-sysfs users too. This doesn't make any functional changes. Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman

sysfs: move sysfs_hash_and_remove() to fs/sysfs/dir.c

2013-10-29T22:12:07Z

Most removal related logic is implemented in fs/sysfs/dir.c. Move sysfs_hash_and_remove() to fs/sysfs/dir.c so that __sysfs_remove() doesn't have to be public. This is pure relocation. Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman