commit 13cbe0fb40b67a9551455b2d7fe6eac3f5e9e18d Author: Greg Kroah-Hartman Date: Wed Aug 14 22:57:16 2013 -0700 Linux 3.4.58 commit 03bca23ea4b01bf4fecbe6b66ae36a2a3e08c009 Author: Joshua Zhu Date: Sat Jan 5 13:29:57 2013 +0800 perf tools: Add anonymous huge page recognition commit d0528b5d71faf612014dd7672e44225c915344b2 upstream. Judging anonymous memory's vm_area_struct, perf_mmap_event's filename will be set to "//anon" indicating this vma belongs to anonymous memory. Once hugepage is used, vma's vm_file points to hugetlbfs. In this way, this vma will not be regarded as anonymous memory by is_anon_memory() in perf user space utility. Signed-off-by: Joshua Zhu Cc: Akihiro Nagai Cc: Andi Kleen Cc: David Ahern Cc: Ingo Molnar Cc: Jiri Olsa Cc: Joshua Zhu Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Vinson Lee Link: http://lkml.kernel.org/r/1357363797-3550-1-git-send-email-zhu.wen-jie@hp.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 7a0117d324b902737efa1ce7e26052d475b6649b Author: NeilBrown Date: Thu Nov 8 16:09:37 2012 -0800 vfs: d_obtain_alias() needs to use "/" as default name. commit b911a6bdeef5848c468597d040e3407e0aee04ce upstream. NFS appears to use d_obtain_alias() to create the root dentry rather than d_make_root. This can cause 'prepend_path()' to complain that the root has a weird name if an NFS filesystem is lazily unmounted. e.g. if "/mnt" is an NFS mount then { cd /mnt; umount -l /mnt ; ls -l /proc/self/cwd; } will cause a WARN message like WARNING: at /home/git/linux/fs/dcache.c:2624 prepend_path+0x1d7/0x1e0() ... Root dentry has weird name <> to appear in kernel logs. So change d_obtain_alias() to use "/" rather than "" as the anonymous name. Signed-off-by: NeilBrown Cc: Trond Myklebust Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Al Viro [bwh: Backported to 3.2: use named initialisers instead of QSTR_INIT()] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 4bcdbddd845a9c5bba705e949d9d3f6d9461eb96 Author: Arnd Bergmann Date: Thu Mar 14 15:21:36 2013 +0100 SCSI: nsp32: use mdelay instead of large udelay constants commit b497ceb964a80ebada3b9b3cea4261409039e25a upstream. ARM cannot handle udelay for more than 2 miliseconds, so we should use mdelay instead for those. Signed-off-by: Arnd Bergmann Acked-by: GOTO Masanori Cc: YOKOTA Hiroshi Cc: "James E.J. Bottomley" Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 99593eb7ca1dd9bfaa431d96e009eda23f001ace Author: Andrew Vagin Date: Fri Aug 2 21:16:43 2013 +0400 tracing: Fix fields of struct trace_iterator that are zeroed by mistake commit ed5467da0e369e65b247b99eb6403cb79172bcda upstream. tracing_read_pipe zeros all fields bellow "seq". The declaration contains a comment about that, but it doesn't help. The first field is "snapshot", it's true when current open file is snapshot. Looks obvious, that it should not be zeroed. The second field is "started". It was converted from cpumask_t to cpumask_var_t (v2.6.28-4983-g4462344), in other words it was converted from cpumask to pointer on cpumask. Currently the reference on "started" memory is lost after the first read from tracing_read_pipe and a proper object will never be freed. The "started" is never dereferenced for trace_pipe, because trace_pipe can't have the TRACE_FILE_ANNOTATE options. Link: http://lkml.kernel.org/r/1375463803-3085183-1-git-send-email-avagin@openvz.org Signed-off-by: Andrew Vagin Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 65280b8ed1cca78ff7fe63ecfdb0fff87fe184a3 Author: Oleg Nesterov Date: Fri Jul 26 17:12:56 2013 +0200 debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs) commit 776164c1faac4966ab14418bb0922e1820da1d19 upstream. debugfs_remove_recursive() is wrong, 1. it wrongly assumes that !list_empty(d_subdirs) means that this dir should be removed. This is not that bad by itself, but: 2. if d_subdirs does not becomes empty after __debugfs_remove() it gives up and silently fails, it doesn't even try to remove other entries. However ->d_subdirs can be non-empty because it still has the already deleted !debugfs_positive() entries. 3. simple_release_fs() is called even if __debugfs_remove() fails. Suppose we have dir1/ dir2/ file2 file1 and someone opens dir1/dir2/file2. Now, debugfs_remove_recursive(dir1/dir2) succeeds, and dir1/dir2 goes away. But debugfs_remove_recursive(dir1) silently fails and doesn't remove this directory. Because it tries to delete (the already deleted) dir1/dir2/file2 again and then fails due to "Avoid infinite loop" logic. Test-case: #!/bin/sh cd /sys/kernel/debug/tracing echo 'p:probe/sigprocmask sigprocmask' >> kprobe_events sleep 1000 < events/probe/sigprocmask/id & echo -n >| kprobe_events [ -d events/probe ] && echo "ERR!! failed to rm probe" And after that it is not possible to create another probe entry. With this patch debugfs_remove_recursive() skips !debugfs_positive() files although this is not strictly needed. The most important change is that it does not try to make ->d_subdirs empty, it simply scans the whole list(s) recursively and removes as much as possible. Link: http://lkml.kernel.org/r/20130726151256.GC19472@redhat.com Acked-by: Greg Kroah-Hartman Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 8b45ff80d9d6e641e2518eddad76aafdadc8dc92 Author: Julius Werner Date: Tue Jul 30 19:51:20 2013 -0700 usb: core: don't try to reset_device() a port that got just disconnected commit 481f2d4f89f87a0baa26147f323380e31cfa7c44 upstream. The USB hub driver's event handler contains a check to catch SuperSpeed devices that transitioned into the SS.Inactive state and tries to fix them with a reset. It decides whether to do a plain hub port reset or call the usb_reset_device() function based on whether there was a device attached to the port. However, there are device/hub combinations (found with a JetFlash Transcend mass storage stick (8564:1000) on the root hub of an Intel LynxPoint PCH) which can transition to the SS.Inactive state on disconnect (and stay there long enough for the host to notice). In this case, above-mentioned reset check will call usb_reset_device() on the stale device data structure. The kernel will send pointless LPM control messages to the no longer connected device address and can even cause several 5 second khubd stalls on some (buggy?) host controllers, before finally accepting the device's fate amongst a flurry of error messages. This patch makes the choice of reset dependent on the port status that has just been read from the hub in addition to the existence of an in-kernel data structure for the device, and only proceeds with the more extensive reset if both are valid. Signed-off-by: Julius Werner Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 3fbcb7f97cd2770e5d65490b57460844fb704f01 Author: Chen Gang Date: Fri Jul 19 09:01:36 2013 +0800 cifs: extend the buffer length enought for sprintf() using commit 057d6332b24a4497c55a761c83c823eed9e3f23b upstream. For cifs_set_cifscreds() in "fs/cifs/connect.c", 'desc' buffer length is 'CIFSCREDS_DESC_SIZE' (56 is less than 256), and 'ses->domainName' length may be "255 + '\0'". The related sprintf() may cause memory overflow, so need extend related buffer enough to hold all things. It is also necessary to be sure of 'ses->domainName' must be less than 256, and define the related macro instead of hard code number '256'. Signed-off-by: Chen Gang Reviewed-by: Jeff Layton Reviewed-by: Shirish Pargaonkar Reviewed-by: Scott Lovenberg Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6cd45319625bfc226c3d52bdafd3e1f5d7e04a67 Author: Piotr Sarna Date: Thu Aug 8 23:02:24 2013 -0400 ext4: fix mount/remount error messages for incompatible mount options commit 6ae6514b33f941d3386da0dfbe2942766eab1577 upstream. Commit 5688978 ("ext4: improve handling of conflicting mount options") introduced incorrect messages shown while choosing wrong mount options. First of all, both cases of incorrect mount options, "data=journal,delalloc" and "data=journal,dioread_nolock" result in the same error message. Secondly, the problem above isn't solved for remount option: the mismatched parameter is simply ignored. Moreover, ext4_msg states that remount with options "data=journal,delalloc" succeeded, which is not true. To fix it up, I added a simple check after parse_options() call to ensure that data=journal and delalloc/dioread_nolock parameters are not present at the same time. Signed-off-by: Piotr Sarna Acked-by: Bartlomiej Zolnierkiewicz Signed-off-by: Kyungmin Park Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit a57425e942b49e729a62ccb4d420ae7c83762fe2 Author: Amit Shah Date: Mon Jul 29 14:23:21 2013 +0930 virtio: console: return -ENODEV on all read operations after unplug commit 96f97a83910cdb9d89d127c5ee523f8fc040a804 upstream. If a port gets unplugged while a user is blocked on read(), -ENODEV is returned. However, subsequent read()s returned 0, indicating there's no host-side connection (but not indicating the device went away). This also happened when a port was unplugged and the user didn't have any blocking operation pending. If the user didn't monitor the SIGIO signal, they won't have a chance to find out if the port went away. Fix by returning -ENODEV on all read()s after the port gets unplugged. write() already behaves this way. Signed-off-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 183c6a6b4ec8efa1a862b07eb4523d8781ae3e44 Author: Amit Shah Date: Mon Jul 29 14:21:32 2013 +0930 virtio: console: fix raising SIGIO after port unplug commit 92d3453815fbe74d539c86b60dab39ecdf01bb99 upstream. SIGIO should be sent when a port gets unplugged. It should only be sent to prcesses that have the port opened, and have asked for SIGIO to be delivered. We were clearing out guest_connected before calling send_sigio_to_port(), resulting in a sigio not getting sent to processes. Fix by setting guest_connected to false after invoking the sigio function. Signed-off-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 9f92fafcadb619514dbab90882ddfe60245572cd Author: Amit Shah Date: Mon Jul 29 14:20:29 2013 +0930 virtio: console: clean up port data immediately at time of unplug commit ea3768b4386a8d1790f4cc9a35de4f55b92d6442 upstream. We used to keep the port's char device structs and the /sys entries around till the last reference to the port was dropped. This is actually unnecessary, and resulted in buggy behaviour: 1. Open port in guest 2. Hot-unplug port 3. Hot-plug a port with the same 'name' property as the unplugged one This resulted in hot-plug being unsuccessful, as a port with the same name already exists (even though it was unplugged). This behaviour resulted in a warning message like this one: -------------------8<--------------------------------------- WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xc9/0x130() (Not tainted) Hardware name: KVM sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:04.0/virtio0/virtio-ports/vport0p1' Call Trace: [] ? warn_slowpath_common+0x87/0xc0 [] ? warn_slowpath_fmt+0x46/0x50 [] ? sysfs_add_one+0xc9/0x130 [] ? create_dir+0x68/0xb0 [] ? sysfs_create_dir+0x39/0x50 [] ? kobject_add_internal+0xb9/0x260 [] ? kobject_add_varg+0x38/0x60 [] ? kobject_add+0x44/0x70 [] ? get_device_parent+0xf4/0x1d0 [] ? device_add+0xc9/0x650 -------------------8<--------------------------------------- Instead of relying on guest applications to release all references to the ports, we should go ahead and unregister the port from all the core layers. Any open/read calls on the port will then just return errors, and an unplug/plug operation on the host will succeed as expected. This also caused buggy behaviour in case of the device removal (not just a port): when the device was removed (which means all ports on that device are removed automatically as well), the ports with active users would clean up only when the last references were dropped -- and it would be too late then to be referencing char device pointers, resulting in oopses: -------------------8<--------------------------------------- PID: 6162 TASK: ffff8801147ad500 CPU: 0 COMMAND: "cat" #0 [ffff88011b9d5a90] machine_kexec at ffffffff8103232b #1 [ffff88011b9d5af0] crash_kexec at ffffffff810b9322 #2 [ffff88011b9d5bc0] oops_end at ffffffff814f4a50 #3 [ffff88011b9d5bf0] die at ffffffff8100f26b #4 [ffff88011b9d5c20] do_general_protection at ffffffff814f45e2 #5 [ffff88011b9d5c50] general_protection at ffffffff814f3db5 [exception RIP: strlen+2] RIP: ffffffff81272ae2 RSP: ffff88011b9d5d00 RFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff880118901c18 RCX: 0000000000000000 RDX: ffff88011799982c RSI: 00000000000000d0 RDI: 3a303030302f3030 RBP: ffff88011b9d5d38 R8: 0000000000000006 R9: ffffffffa0134500 R10: 0000000000001000 R11: 0000000000001000 R12: ffff880117a1cc10 R13: 00000000000000d0 R14: 0000000000000017 R15: ffffffff81aff700 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #6 [ffff88011b9d5d00] kobject_get_path at ffffffff8126dc5d #7 [ffff88011b9d5d40] kobject_uevent_env at ffffffff8126e551 #8 [ffff88011b9d5dd0] kobject_uevent at ffffffff8126e9eb #9 [ffff88011b9d5de0] device_del at ffffffff813440c7 -------------------8<--------------------------------------- So clean up when we have all the context, and all that's left to do when the references to the port have dropped is to free up the port struct itself. Reported-by: chayang Reported-by: YOGANANTH SUBRAMANIAN Reported-by: FuXiangChun Reported-by: Qunfang Zhang Reported-by: Sibiao Luo Signed-off-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 9c040cbf67c54c0eb67ebdc0424cfadd3d7a2a7a Author: Amit Shah Date: Mon Jul 29 14:17:13 2013 +0930 virtio: console: fix race in port_fops_open() and port unplug commit 671bdea2b9f210566610603ecbb6584c8a201c8c upstream. Between open() being called and processed, the port can be unplugged. Check if this happened, and bail out. A simple test script to reproduce this is: while true; do for i in $(seq 1 100); do echo $i > /dev/vport0p3; done; done; This opens and closes the port a lot of times; unplugging the port while this is happening triggers the bug. Signed-off-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit d0bfaacabec9c87b739c31662eaa96af0d1b404c Author: Amit Shah Date: Mon Jul 29 14:16:13 2013 +0930 virtio: console: fix race with port unplug and open/close commit 057b82be3ca3d066478e43b162fc082930a746c9 upstream. There's a window between find_port_by_devt() returning a port and us taking a kref on the port, where the port could get unplugged. Fix it by taking the reference in find_port_by_devt() itself. Problem reported and analyzed by Mateusz Guzik. Reported-by: Mateusz Guzik Signed-off-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit b9ea0ce26ce42ee37891ede0ff6c0162005d53cb Author: Curt Brune Date: Thu Aug 8 12:11:03 2013 -0700 hwmon: (adt7470) Fix incorrect return code check commit 93d783bcca69bfacc8dc739d8a050498402587b5 upstream. In adt7470_write_word_data(), which writes two bytes using i2c_smbus_write_byte_data(), the return codes are incorrectly AND-ed together when they should be OR-ed together. The return code of i2c_smbus_write_byte_data() is zero for success. The upshot is only the first byte was ever written to the hardware. The 2nd byte was never written out. I noticed that trying to set the fan speed limits was not working correctly on my system. Setting the fan speed limits is the only code that uses adt7470_write_word_data(). After making the change the limit settings work and the alarms work also. Signed-off-by: Curt Brune Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit b2fea70a4a26d2946b470affd5582d7916be93ab Author: Theodore Ts'o Date: Fri Jul 26 15:15:46 2013 -0400 ext4: make sure group number is bumped after a inode allocation race commit a34eb503742fd25155fd6cff6163daacead9fbc3 upstream. When we try to allocate an inode, and there is a race between two CPU's trying to grab the same inode, _and_ this inode is the last free inode in the block group, make sure the group number is bumped before we continue searching the rest of the block groups. Otherwise, we end up searching the current block group twice, and we end up skipping searching the last block group. So in the unlikely situation where almost all of the inodes are allocated, it's possible that we will return ENOSPC even though there might be free inodes in that last block group. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 3b8d21f4237f7ef442314feec300cdbce72592b5 Author: Sumit.Saxena@lsi.com Date: Tue Jul 16 02:26:05 2013 +0530 SCSI: megaraid_sas: megaraid_sas driver init fails in kdump kernel commit 6431f5d7c6025f8b007af06ea090de308f7e6881 upstream. Problem: When Hardware IOMMU is on, megaraid_sas driver initialization fails in kdump kernel with LSI MegaRAID controller(device id-0x73). Actually this issue needs fix in firmware, but for firmware running in field, this driver fix is proposed to resolve the issue. At firmware initialization time, if firmware does not come to ready state, driver will reset the adapter and retry for firmware transition to ready state unconditionally(not only executed for kdump kernel). Signed-off-by: Sumit Saxena Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 7eee85fd4e70561e15f1794581a9c4d641776718 Author: Martin K. Petersen Date: Tue Jul 30 22:58:34 2013 -0400 SCSI: Don't attempt to send extended INQUIRY command if skip_vpd_pages is set commit 7562523e84ddc742fe1f9db8bd76b01acca89f6b upstream. If a device has the skip_vpd_pages flag set we should simply fail the scsi_get_vpd_page() call. Signed-off-by: Martin K. Petersen Acked-by: Alan Stern Tested-by: Stuart Foster Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman