Skip to content

L
linux
Switch branch/tag
  1. 15 Feb, 2010 24 commits
  3. 12 Feb, 2010 5 commits
  5. 11 Feb, 2010 1 commit
  7. 10 Feb, 2010 1 commit
  9. 07 Feb, 2010 1 commit
    • Linus Torvalds's avatar
      Fix race in tty_fasync() properly · 80e1e823
      Linus Torvalds authored 
      This reverts commit 70362511 ("tty: fix race in tty_fasync") and
commit b04da8bf ("fnctl: f_modown should call write_lock_irqsave/
restore") that tried to fix up some of the fallout but was incomplete.

It turns out that we really cannot hold 'tty->ctrl_lock' over calling
__f_setown, because not only did that cause problems with interrupt
disables (which the second commit fixed), it also causes a potential
ABBA deadlock due to lock ordering.

Thanks to Tetsuo Handa for following up on the issue, and running
lockdep to show the problem.  It goes roughly like this:

 - f_getown gets filp->f_owner.lock for reading without interrupts
   disabled, so an interrupt that happens while that lock is held can
   cause a lockdep chain from f_owner.lock -> sighand->siglock.

 - at the same time, the tty->ctrl_lock -> f_owner.lock chain that
   commit 70362511 introduced, together with the pre-existing
   sighand->siglock -> tty->ctrl_lock chain means that we have a lock
   dependency the other way too.

So instead of extending tty->ctrl_lock over the whole __f_setown() call,
we now just take a reference to the 'pid' structure while holding the
lock, and then release it after having done the __f_setown.  That still
guarantees that 'struct pid' won't go away from under us, which is all
we really ever needed.
Reported-and-tested-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
Acked-by: default avatarAmérico Wang <xiyou.wangcong@gmail.com>
Cc: stable@kernel.org
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      80e1e823
  11. 06 Feb, 2010 4 commits
  13. 05 Feb, 2010 4 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 · 9d9c3a51
      Linus Torvalds authored 
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
  ASoC: pandora: Add APLL supply to fix audio output
  ALSA: ice1724 - aureon - fix wm8770 volume offset
  ALSA: cosmetic: make hda intel interrupt name consistent with others
  ALSA: hda - Delay switching to polling mode if an interrupt was missing
  ALSA: ctxfi - fix PTP address initialization
      9d9c3a51
    • Jean Delvare's avatar
      hwmon: (w83781d) Request I/O ports individually for probing · b0bcdd3c
      Jean Delvare authored 
      Different motherboards have different PNP declarations for
W83781D/W83782D chips. Some declare the whole range of I/O ports (8
ports), some declare only the useful ports (2 ports at offset 5) and
some declare fancy ranges, for example 4 ports at offset 4. To
properly handle all cases, request all ports individually for probing.
After we have determined that we really have a W83781D or W83782D
chip, the useful port range will be requested again, as a single
block.

I did not see a board which needs this yet, but I know of one for lm78
driver and I'd like to keep the logic of these two drivers in sync.
Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org
      b0bcdd3c
    • Jean Delvare's avatar
      hwmon: (lm78) Request I/O ports individually for probing · 197027e6
      Jean Delvare authored 
      Different motherboards have different PNP declarations for LM78/LM79
chips. Some declare the whole range of I/O ports (8 ports), some
declare only the useful ports (2 ports at offset 5) and some declare
fancy ranges, for example 4 ports at offset 4. To properly handle all
cases, request all ports individually for probing. After we have
determined that we really have an LM78 or LM79 chip, the useful port
range will be requested again, as a single block.

This fixes the driver on the Olivetti M3000 DT 540, at least.
Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org
      197027e6
    • Ray Copeland's avatar
      hwmon: (adt7462) Wrong ADT7462_VOLT_COUNT · 85f8d3e5
      Ray Copeland authored 
      The #define ADT7462_VOLT_COUNT is wrong, it should be 13 not 12. All the 
for loops that use this as a limit count are of the typical form, "for 
(n = 0; n < ADT7462_VOLT_COUNT; n++)", so to loop through all voltages 
w/o missing the last one it is necessary for the count to be one greater 
than it is.  (Specifically, you will miss the +1.5V 3GPIO input with count 
= 12 vs. 13.)
Signed-off-by: default avatarRay Copeland <ray.copeland@aprius.com>
Acked-by: default avatar"Darrick J. Wong" <djwong@us.ibm.com>
Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org
      85f8d3e5
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7