linux-toradex.git/drivers/char, branch v2.6.27.50

amd64-agp: Probe unknown AGP devices the right way

2010-08-02T17:18:50+00:00

commit 6fd024893911dcb51b4a0aa71971db5ba38f7071 upstream.

The current initialisation code probes 'unsupported' AGP devices
simply by calling its own probe function.  It does not lock these
devices or even check whether another driver is already bound to
them.

We must use the device core to manage this.  So if the specific
device id table didn't match anything and agp_try_unsupported=1,
switch the device id table and call driver_attach() again.

Signed-off-by: Ben Hutchings 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

ipmi: handle run_to_completion properly in deliver_recv_msg()

2010-07-05T18:08:44+00:00

commit a747c5abc329611220f16df0bb4cf0ca4a7fdf0c upstream.

If run_to_completion flag is set, it means that we are running in a
single-threaded mode, and thus no locks are held.

This fixes a deadlock when IPMI notifier is being called during panic.

Signed-off-by: Jiri Kosina 
Acked-by: Corey Minyard 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

tty: release_one_tty() forgets to put pids

2010-05-26T21:27:06+00:00

commit 6da8d866d0d39e9509ff826660f6a86a6757c966 upstream.

release_one_tty(tty) can be called when tty still has a reference
to pgrp/session. In this case we leak the pid.

Signed-off-by: Oleg Nesterov 
Reported-by: Catalin Marinas 
Reported-and-tested-by: Tetsuo Handa 
Acked-by: Linus Torvalds 
Acked-by: Eric W. Biederman 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

drivers/char/mem.c: avoid OOM lockup during large reads from /dev/zero

2010-04-01T22:52:21+00:00

commit 730c586ad5228c339949b2eb4e72b80ae167abc4 upstream.

While running 20 parallel instances of dd as follows:

  #!/bin/bash
  for i in `seq 1 20`; do
           dd if=/dev/zero of=/export/hda3/dd_$i bs=1073741824 count=1 &
  done
  wait

on a 16G machine, we noticed that rather than just killing the processes,
the entire kernel went down.  Stracing dd reveals that it first does an
mmap2, which makes 1GB worth of zero page mappings.  Then it performs a
read on those pages from /dev/zero, and finally it performs a write.

The machine died during the reads.  Looking at the code, it was noticed
that /dev/zero's read operation had been changed by
557ed1fa2620dc119adb86b34c614e152a629a80 ("remove ZERO_PAGE") from giving
zero page mappings to actually zeroing the page.

The zeroing of the pages causes physical pages to be allocated to the
process.  But, when the process exhausts all the memory that it can, the
kernel cannot kill it, as it is still in the kernel mode allocating more
memory.  Consequently, the kernel eventually crashes.

To fix this, I propose that when a fatal signal is pending during
/dev/zero read operation, we simply return and let the user process die.

Signed-off-by: Salman Qazi 
Cc: Nick Piggin 
Signed-off-by: Andrew Morton 
[ Modified error return and comment trivially.  - Linus]
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Fix race in tty_fasync() properly

2010-04-01T22:52:16+00:00

commit 80e1e823989ec44d8e35bdfddadbddcffec90424 upstream.

This reverts commit 703625118069 ("tty: fix race in tty_fasync") and
commit b04da8bfdfbb ("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 703625118069 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: Tetsuo Handa 
Acked-by: Greg Kroah-Hartman 
Acked-by: Américo Wang 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

tty: fix race in tty_fasync

2010-01-28T23:20:28+00:00

commit 703625118069f9f8960d356676662d3db5a9d116 upstream.

We need to keep the lock held over the call to __f_setown() to
prevent a PID race.

Thanks to Al Viro for pointing out the problem, and to Travis for
making us look here in the first place.

Cc: Eric W. Biederman 
Cc: Al Viro 
Cc: Alan Cox 
Cc: Linus Torvalds 
Cc: Tavis Ormandy 
Cc: Jeff Dike 
Cc: Julien Tinnes 
Cc: Matt Mackall 
Signed-off-by: Greg Kroah-Hartman

tty: Mark generic_serial users as BROKEN

2009-11-10T00:52:18+00:00

commit 412145947adfca60a4b5b4893fbae82dffa25edd upstream.

There isn't much else I can do with these. I can find no hardware for any
of them and no users. The code is broken.

Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

TPM: Fixup boot probe timeout for tpm_tis driver

2009-09-24T15:47:30+00:00

commit ec57935837a78f9661125b08a5d08b697568e040 upstream.

When probing the device in tpm_tis_init the call request_locality
uses timeout_a, which wasn't being initalized until after
request_locality. This results in request_locality falsely timing
out if the chip is still starting. Move the initialization to before
request_locality.

This probably only matters for embedded cases (ie mine), a BIOS likely
gets the TPM into a state where this code path isn't necessary.

Signed-off-by: Jason Gunthorpe 
Acked-by: Rajiv Andrade 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

Remove low_latency flag setting from nozomi and mxser drivers

2009-09-09T03:17:49+00:00

commit 4d8d4d251df8eaaa3dae71c8cfa7fbf4510d967d upstream

[ cebbert@redhat.com: backport to 2.6.27 ]

Remove low_latency flag setting from nozomi and mxser drivers

The kernel oopses if this flag is set.

[and neither driver should set it as they call tty_flip_buffer_push from IRQ
 paths so have always been buggy]

Signed-off-by: Chuck Ebbert 
Signed-off-by: Alan Cox 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

pcmcia/cm4000: fix lock imbalance

2009-07-02T23:32:02+00:00

commit 69ae59d7d8df14413cf0a97b3e372d7dc8352563 upstream.

Don't return from switch/case, break instead, so that we unlock BKL.

Signed-off-by: Jiri Slaby 
Signed-off-by: Alan Cox 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman