1. 28 Sep, 2011 5 commits
  2. 27 Sep, 2011 17 commits
  3. 26 Sep, 2011 18 commits
    • Trond Myklebust's avatar
      VFS: Fix the remaining automounter semantics regressions · 815d405c
      Trond Myklebust authored
      The concensus seems to be that system calls such as stat() etc should
      not trigger an automount.  Neither should the l* versions.
      This patch therefore adds a LOOKUP_AUTOMOUNT flag to tag those lookups
      that _should_ trigger an automount on the last path element.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      [ Edited to leave out the cases that are already covered by LOOKUP_OPEN,
        LOOKUP_DIRECTORY and LOOKUP_CREATE - all of which also fundamentally
        force automounting for their own reasons   - Linus ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Linus Torvalds's avatar
      vfs pathname lookup: Add LOOKUP_AUTOMOUNT flag · d94c177b
      Linus Torvalds authored
      Since we've now turned around and made LOOKUP_FOLLOW *not* force an
      automount, we want to add the ability to force an automount event on
      lookup even if we don't happen to have one of the other flags that force
      Most cases will never want to use this, since you'd normally want to
      delay automounting as long as possible, which usually implies
      LOOKUP_OPEN (when we open a file or directory, we really cannot avoid
      the automount any more).
      But Trond argued sufficiently forcefully that at a minimum bind mounting
      a file and quotactl will want to force the automount lookup.  Some other
      cases (like nfs_follow_remote_path()) could use it too, although
      LOOKUP_DIRECTORY would work there as well.
      This commit just adds the flag and logic, no users yet, though.  It also
      doesn't actually touch the LOOKUP_NO_AUTOMOUNT flag that is related, and
      was made irrelevant by the same change that made us not follow on
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Ian Kent <raven@themaw.net>
      Cc: Jeff Layton <jlayton@redhat.com>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Greg KH <gregkh@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Linus Torvalds's avatar
      Merge branch 'samsung-fixes-3' of git://github.com/kgene/linux-samsung · 858b1814
      Linus Torvalds authored
      * 'samsung-fixes-3' of git://github.com/kgene/linux-samsung:
        ARM: EXYNOS4: Rename sclk_cam clocks for FIMC driver
        ARM: S5PV210: Rename sclk_cam clocks for FIMC media driver
        ARM: S5P: fix incorrect loop iterator usage on gpio-interrupt
        ARM: S3C2443: Fix bit-reset in setrate of clk_armdiv
    • Sylwester Nawrocki's avatar
      ARM: EXYNOS4: Rename sclk_cam clocks for FIMC driver · 00aaad22
      Sylwester Nawrocki authored
      The sclk_cam clocks are now controlled by the top level FIMC media
      device driver bound to "s5p-fimc-md" platform device.
      Rename sclk_cam clocks so they accessible by the corresponding
      Signed-off-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: default avatarKukjin Kim <kgene.kim@samsung.com>
    • Sylwester Nawrocki's avatar
      ARM: S5PV210: Rename sclk_cam clocks for FIMC media driver · 83427c23
      Sylwester Nawrocki authored
      The sclk_cam clocks are now controlled by the top level FIMC media
      device driver bound to "s5p-fimc-md" platform device.
      Rename sclk_cam clocks so they accessible by the corresponding
      Signed-off-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: default avatarKukjin Kim <kgene.kim@samsung.com>
    • Linus Torvalds's avatar
      Merge branch 'hwmon-for-linus' of git://github.com/groeck/linux · ef82bdc5
      Linus Torvalds authored
      * 'hwmon-for-linus' of git://github.com/groeck/linux:
        hwmon: (coretemp) remove struct platform_data * parameter from create_core_data()
        hwmon: (coretemp) constify static data
        hwmon: (coretemp) don't use kernel assigned CPU number as platform device ID
        hwmon: (ds620) Fix handling of negative temperatures
        hwmon: (w83791d) rename prototype parameter from 'register' to 'reg'
        hwmon: (coretemp) Don't use threshold registers for tempX_max
        hwmon: (coretemp) Let the user force TjMax
        hwmon: (coretemp) Drop duplicate function get_pkg_tjmax
    • Linus Torvalds's avatar
      Merge branch 'kvm-updates/3.1' of git://github.com/avikivity/kvm · 231e58e7
      Linus Torvalds authored
      * 'kvm-updates/3.1' of git://github.com/avikivity/kvm:
        KVM: x86 emulator: fix Src2CL decode
        KVM: MMU: fix incorrect return of spte
    • Linus Torvalds's avatar
      Merge branch 'fixes' of http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm · a2b49102
      Linus Torvalds authored
      * 'fixes' of http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm:
        ARM: 7099/1: futex: preserve oldval in SMP __futex_atomic_op
        ARM: dma-mapping: free allocated page if unable to map
        ARM: fix vmlinux.lds.S discarding sections
        ARM: nommu: fix warning with checksyscalls.sh
        ARM: 7091/1: errata: D-cache line maintenance operation by MVA may not succeed
    • Mohammed Shafi Shajakhan's avatar
      ath9k: Fix a dma warning/memory leak · ba542385
      Mohammed Shafi Shajakhan authored
      proper dma_unmapping and freeing of skb's has to be done in the rx
      cleanup for EDMA chipsets when the device is unloaded and this also
      seems to address the following warning which shows up occasionally when
      the device is unloaded
      	Call Trace:
      	[<c0148cd2>] warn_slowpath_common+0x72/0xa0
      	[<c03b669c>] ? dma_debug_device_change+0x19c/0x200
      	[<c03b669c>] ? dma_debug_device_change+0x19c/0x200
      	[<c0148da3>] warn_slowpath_fmt+0x33/0x40
      	[<c03b669c>] dma_debug_device_change+0x19c/0x200
      	[<c0657f12>] notifier_call_chain+0x82/0xb0
      	[<c0171370>] __blocking_notifier_call_chain+0x60/0x90
      	[<c01713bf>] blocking_notifier_call_chain+0x1f/0x30
      	[<c044f594>] __device_release_driver+0xa4/0xc0
      	[<c044f647>] driver_detach+0x97/0xa0
      	[<c044e65c>] bus_remove_driver+0x6c/0xe0
      	[<c029af0b>] ? sysfs_addrm_finish+0x4b/0x60
      	[<c0450109>] driver_unregister+0x49/0x80
      	[<c0299f54>] ? sysfs_remove_file+0x14/0x20
      	[<c03c3ab2>] pci_unregister_driver+0x32/0x80
      	[<f92c2162>] ath_pci_exit+0x12/0x20 [ath9k]
      	[<f92c8467>] ath9k_exit+0x17/0x36 [ath9k]
      	[<c06523cd>] ? mutex_unlock+0xd/0x10
      	[<c018e27f>] sys_delete_module+0x13f/0x200
      	[<c02139bb>] ? sys_munmap+0x4b/0x60
      	[<c06547c5>] ? restore_all+0xf/0xf
      	[<c0657a20>] ? spurious_fault+0xe0/0xe0
      	[<c01832f4>] ? trace_hardirqs_on_caller+0xf4/0x180
      	[<c065b863>] sysenter_do_call+0x12/0x38
      	 ---[ end trace 16e1c1521c06bcf9 ]---
      	Mapped at:
      	[<c03b7938>] debug_dma_map_page+0x48/0x120
      	[<f92ba3e8>] ath_rx_init+0x3f8/0x4b0 [ath9k]
      	[<f92b5ae4>] ath9k_init_device+0x4c4/0x7b0 [ath9k]
      	[<f92c2813>] ath_pci_probe+0x263/0x330 [ath9k]
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Larry Finger's avatar
      rtlwifi: rtl8192cu: Fix unitialized struct · 831d8547
      Larry Finger authored
      Driver rtl8192cu assigns a new struct rtl_tcb_desc object, but fails to
      clear it.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@kernel.org>  [2.6.39+]
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      iwlagn: fix dangling scan request · 6c80c39d
      Johannes Berg authored
      If iwl_scan_initiate() fails for any reason,
      priv->scan_request and priv->scan_vif are left
      dangling. This can lead to a crash later when
      iwl_bg_scan_completed() tries to run a pending
      scan request.
      In practice, this seems to be very rare due to
      the STATUS_SCANNING check earlier. That check,
      however, is wrong -- it should allow a scan to
      be queued when a reset/roc scan is going on.
      When a normal scan is already going on, a new
      one can't be issued by mac80211, so that code
      can be removed completely. I introduced this
      bug when adding off-channel support in commit
      Cc: stable@kernel.org [3.0]
      Reported-by: default avatarPeng Yan <peng.yan@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Rafael J. Wysocki's avatar
      PM / Clocks: Do not acquire a mutex under a spinlock · e8b364b8
      Rafael J. Wysocki authored
      Commit b7ab83ed
       (PM: Use spinlock instead of mutex in clock
      management functions) introduced a regression causing clocks_mutex
      to be acquired under a spinlock.  This happens because
      pm_clk_suspend() and pm_clk_resume() call pm_clk_acquire() under
      pcd->lock, but pm_clk_acquire() executes clk_get() which causes
      clocks_mutex to be acquired.  Similarly, __pm_clk_remove(),
      executed under pcd->lock, calls clk_put(), which also causes
      clocks_mutex to be acquired.
      To fix those problems make pm_clk_add() call pm_clk_acquire(), so
      that pm_clk_suspend() and pm_clk_resume() don't have to do that.
      Change pm_clk_remove() and pm_clk_destroy() to separate
      modifications of the pcd->clock_list list from the actual removal of
      PM clock entry objects done by __pm_clk_remove().
      Reported-and-tested-by: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
    • James Bottomley's avatar
      [SCSI] 3w-9xxx: fix iommu_iova leak · 96067723
      James Bottomley authored
      Following reports on the list, it looks like the 3e-9xxx driver will leak dma
      mappings every time we get a transient queueing error back from the card.
      This is because it maps the sg list in the routine that sends the command, but
      doesn't unmap again in the transient failure path (even though the command is
      sent back to the block layer).  Fix by unmapping before returning the status.
      Reported-by: default avatarChris Boot <bootc@bootc.net>
      Tested-by: default avatarChris Boot <bootc@bootc.net>
      Acked-by: default avatarAdam Radford <aradford@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
    • Neil Horman's avatar
      [SCSI] cxgb3i: convert cdev->l2opt to use rcu to prevent NULL dereference · e48f129c
      Neil Horman authored
      This oops was reported recently:
      d:mon> e
      cpu 0xd: Vector: 300 (Data Access) at [c0000000fd4c7120]
          pc: d00000000076f194: .t3_l2t_get+0x44/0x524 [cxgb3]
          lr: d000000000b02108: .init_act_open+0x150/0x3d4 [cxgb3i]
          sp: c0000000fd4c73a0
         msr: 8000000000009032
         dar: 0
       dsisr: 40000000
        current = 0xc0000000fd640d40
        paca    = 0xc00000000054ff80
          pid   = 5085, comm = iscsid
      d:mon> t
      [c0000000fd4c7450] d000000000b02108 .init_act_open+0x150/0x3d4 [cxgb3i]
      [c0000000fd4c7500] d000000000e45378 .cxgbi_ep_connect+0x784/0x8e8 [libcxgbi]
      [c0000000fd4c7650] d000000000db33f0 .iscsi_if_rx+0x71c/0xb18
      [c0000000fd4c7740] c000000000370c9c .netlink_data_ready+0x40/0xa4
      [c0000000fd4c77c0] c00000000036f010 .netlink_sendskb+0x4c/0x9c
      [c0000000fd4c7850] c000000000370c18 .netlink_sendmsg+0x358/0x39c
      [c0000000fd4c7950] c00000000033be24 .sock_sendmsg+0x114/0x1b8
      [c0000000fd4c7b50] c00000000033d208 .sys_sendmsg+0x218/0x2ac
      [c0000000fd4c7d70] c00000000033f55c .sys_socketcall+0x228/0x27c
      [c0000000fd4c7e30] c0000000000086a4 syscall_exit+0x0/0x40
      --- Exception: c01 (System Call) at 00000080da560cfc
      The root cause was an EEH error, which sent us down the offload_close path in
      the cxgb3 driver, which in turn sets cdev->l2opt to NULL, without regard for
      upper layer driver (like the cxgbi drivers) which might have execution contexts
      in the middle of its use. The result is the oops above, when t3_l2t_get attempts
      to dereference L2DATA(cdev)->nentries in arp_hash right after the EEH error handler sets it to NULL.
      The fix is to prevent the setting of the NULL pointer until after there are no
      further users of it.  The t3cdev->l2opt pointer is now converted to be an rcu
      pointer and the L2DATA macro is now called under the protection of the
      rcu_read_lock().  When the EEH error path:
      Is exectured, setting of that l2opt pointer to NULL, is now gated on an rcu
      quiescence point, preventing, allowing L2DATA callers to safely check for a NULL
      pointer without concern that the underlying data will be freeded before the
      pointer is dereferenced.
      This has been tested by the reporter and shown to fix the reproted oops
      [nhorman: fix up unitinialised variable reported by Dan Carpenter]
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Reviewed-by: default avatarKaren Xie <kxie@chelsio.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
    • Thomas Pfaff's avatar
      ALSA: usb-audio: Check for possible chip NULL pointer before clearing probing flag · 61a6a108
      Thomas Pfaff authored
      Before clearing the probing flag in the error exit path, check that the
      chip pointer is not NULL.
      Signed-off-by: default avatarThomas Pfaff <tpfaff@gmx.net>
      Cc: <stable@kernel.org> [2.6.39+]
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Takashi Iwai's avatar
      ALSA: hda/realtek - Don't detect LO jack when identical with HP · e0d32e33
      Takashi Iwai authored
      The spec->autocfg.line_out_pins[] may contain the same pins as hp_pins[]
      depending on the configuration.  When they are identical, detecting the
      line_jack_present flag screws up the auto-mute because alc_line_automute()
      is called unconditionally at initialization while it won't be triggered
      by unsol events, thus the old line_jack_present flag is kept for the
      whole run.
      For fixing this buggy behavior, the driver needs to check whether the
      line-outs are really individual, and skip if same as headphone jacks.
      Reference: https://bugzilla.novell.com/show_bug.cgi?id=716104
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Will Deacon's avatar
      ARM: 7099/1: futex: preserve oldval in SMP __futex_atomic_op · df77abca
      Will Deacon authored
      The SMP implementation of __futex_atomic_op clobbers oldval with the
      status flag from the exclusive store. This causes it to always read as
      zero when performing the FUTEX_OP_CMP_* operation.
      This patch updates the ARM __futex_atomic_op implementations to take a
      tmp argument, allowing us to store the strex status flag without
      overwriting the register containing oldval.
      Cc: stable@kernel.org
      Reported-by: default avatarMinho Ban <mhban@samsung.com>
      Reviewed-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
    • Takashi Iwai's avatar
      ALSA: hda/realtek - Avoid bogus HP-pin assignment · 5fe6e015
      Takashi Iwai authored
      When the headphone pin is assigned as primary output to line_out_pins[],
      the automatic HP-pin assignment by ASSID must be suppressed.  Otherwise
      a wrong pin might be assigned to the headphone and breaks the auto-mute.
      Reference: https://bugzilla.novell.com/show_bug.cgi?id=716104
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Cc: <stable@kernel.org>