linux, branch v3.10.7

Linux 3.10.7

2013-08-15T05:59:42Z

MIPS: Expose missing pci_io{map,unmap} declarations

2013-08-15T05:59:10Z

commit 78857614104a26cdada4c53eea104752042bf5a1 upstream. The GENERIC_PCI_IOMAP does not depend on CONFIG_PCI so move it to the CONFIG_MIPS symbol so it's always selected for MIPS. This fixes the missing pci_iomap declaration for MIPS. Moreover, the pci_iounmap function was not defined in the io.h header file if the CONFIG_PCI symbol is not set, but it should since MIPS is not using CONFIG_GENERIC_IOMAP. This fixes the following problem on a allyesconfig: drivers/net/ethernet/3com/3c59x.c:1031:2: error: implicit declaration of function 'pci_iomap' [-Werror=implicit-function-declaration] drivers/net/ethernet/3com/3c59x.c:1044:3: error: implicit declaration of function 'pci_iounmap' [-Werror=implicit-function-declaration] Signed-off-by: Markos Chandras Acked-by: Steven J. Hill Patchwork: https://patchwork.linux-mips.org/patch/5478/ Signed-off-by: Ralf Baechle Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

mtd: omap2: allow bulding as a module

2013-08-15T05:59:10Z

commit 930d800bded771b26d9944c47810829130ff7c8c upstream. The omap2 nand device driver calls into the the elm code, which can be a loadable module, and in that case it cannot be built-in itself. I can see no reason why the omap2 driver cannot also be a module, so let's make the option "tristate" in Kconfig to fix this allmodconfig build error: ERROR: "elm_config" [drivers/mtd/nand/omap2.ko] undefined! ERROR: "elm_decode_bch_error_page" [drivers/mtd/nand/omap2.ko] undefined! Signed-off-by: Arnd Bergmann Acked-by: Tony Lindgren Cc: David Woodhouse Cc: Artem Bityutskiy Cc: Afzal Mohammed Cc: Russell King Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

SCSI: nsp32: use mdelay instead of large udelay constants

2013-08-15T05:59:10Z

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

drm/radeon: always program the MC on startup

2013-08-15T05:59:10Z

commit 6fab3febf6d949b0a12b1e4e73db38e4a177a79e upstream. For r6xx+ asics. This mirrors the behavior of pre-r6xx asics. We need to program the MC even if something else in startup() fails. Failure to do so results in an unusable GPU. Based on a fix from: Mark Kettenis Signed-off-by: Alex Deucher [ rebased for 3.10 and dropped the drivers/gpu/drm/radeon/cik.c bit as it's 3.11 specific code / tmb ] Signed-off-by: Thomas Backlund Signed-off-by: Greg Kroah-Hartman

drm/radeon: only save UVD bo when we have open handles

2013-08-15T05:59:10Z

commit 4ad9c1c774c2af152283f510062094e768876f55 upstream. Otherwise just reinitialize from scratch on resume, and so make it more likely to succeed. v2: rebased for 3.10-stable tree Signed-off-by: Christian König Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix halting UVD

2013-08-15T05:59:10Z

commit 2858c00d2823c83acce2a1175dbabb2cebee8678 upstream. Removing the clock/power or resetting the VCPU can cause hangs if that happens in the middle of a register write. Stall the memory and register bus before putting the VCPU into reset. Keep it in reset when unloading the module or suspending. v2: rebased on 3.10-stable tree Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/i915: initialize gt_lock early with other spin locks

2013-08-15T05:59:10Z

commit 14c5cec5d0cd73e7e9d4fbea2bbfeea8f3ade871 upstream. commit 181d1b9e31c668259d3798c521672afb8edd355c Author: Daniel Vetter Date: Sun Jul 21 13:16:24 2013 +0200 drm/i915: fix up gt init sequence fallout moved dev_priv->gt_lock initialization after use. Do the initialization much earlier with other spin lock initializations. Reported-by: Sedat Dilek Signed-off-by: Jani Nikula Tested-by: Sedat Dilek Signed-off-by: Daniel Vetter Signed-off-by: Zhouping Liu Signed-off-by: Greg Kroah-Hartman

reiserfs: fix deadlock in umount

2013-08-15T05:59:10Z

commit 672fe15d091ce76d6fb98e489962e9add7c1ba4c upstream. Since remove_proc_entry() started to wait for IO in progress (i.e. since 2007 or so), the locking in fs/reiserfs/proc.c became wrong; if procfs read happens between the moment when umount() locks the victim superblock and removal of /proc/fs/reiserfs//*, we'll get a deadlock - read will wait for s_umount (in sget(), called by r_start()), while umount will wait in remove_proc_entry() for that read to finish, holding s_umount all along. Fortunately, the same change allows a much simpler race avoidance - all we need to do is remove the procfs entries in the very beginning of reiserfs ->kill_sb(); that'll guarantee that pointer to superblock will remain valid for the duration for procfs IO, so we don't need sget() to keep the sucker alive. As the matter of fact, we can get rid of the home-grown iterator completely, and use single_open() instead. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman

debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs)

2013-08-15T05:59:10Z

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