linux/drivers/char, branch v2.6.32.29

tpm_tis: Use timeouts returned from TPM

2011-02-17T23:37:11Z

commit 9b29050f8f75916f974a2d231ae5d3cd59792296 upstream. The current TPM TIS driver in git discards the timeout values returned from the TPM. The check of the response packet needs to consider that the return_code field is 0 on success and the size of the expected packet is equivalent to the header size + u32 length indicator for the TPM_GetCapability() result + 3 timeout indicators of type u32. I am also adding a sysfs entry 'timeouts' showing the timeouts that are being used. Signed-off-by: Stefan Berger Tested-by: Guillaume Chazarain Signed-off-by: Rajiv Andrade Signed-off-by: Greg Kroah-Hartman

TPM: Long default timeout fix

2011-02-17T23:37:11Z

commit c4ff4b829ef9e6353c0b133b7adb564a68054979 upstream. If duration variable value is 0 at this point, it's because chip->vendor.duration wasn't filled by tpm_get_timeouts() yet. This patch sets then the lowest timeout just to give enough time for tpm_get_timeouts() to further succeed. This fix avoids long boot times in case another entity attempts to send commands to the TPM when the TPM isn't accessible. Signed-off-by: Rajiv Andrade Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman

hvc_iucv: allocate memory buffers for IUCV in zone DMA

2011-02-17T23:36:52Z

commit 91a970d9889c7d6f451ee91ed361d0f0119d3778 upstream. The device driver must allocate memory for IUCV buffers with GFP_DMA, because IUCV cannot address memory above 2GB (31bit addresses only). Because the IUCV ignores the higher bits of the address, sending and receiving IUCV data with this driver might cause memory corruptions. Signed-off-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky Cc: maximilian attems

hvc_console: Fix race between hvc_close and hvc_remove, again

2011-01-07T22:43:12Z

commit 320718ee074acce5ffced6506cb51af1388942aa upstream. I don't claim to understand the tty layer, but it seems like hvc_open and hvc_close should be balanced in their kref reference counting. Right now we get a kref every call to hvc_open: if (hp->count++ > 0) { tty_kref_get(tty); <----- here spin_unlock_irqrestore(&hp->lock, flags); hvc_kick(); return 0; } /* else count == 0 */ tty->driver_data = hp; hp->tty = tty_kref_get(tty); <------ or here if hp->count was 0 But hvc_close has: tty_kref_get(tty); if (--hp->count == 0) { ... /* Put the ref obtained in hvc_open() */ tty_kref_put(tty); ... } tty_kref_put(tty); Since the outside kref get/put balance we only do a single kref_put when count reaches 0. The patch below changes things to call tty_kref_put once for every hvc_close call, and with that my machine boots fine. Signed-off-by: Anton Blanchard Acked-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman

hvc_console: Fix race between hvc_close and hvc_remove

2011-01-07T22:43:12Z

commit e74d098c66543d0731de62eb747ccd5b636a6f4c upstream. Alan pointed out a race in the code where hvc_remove is invoked. The recent virtio_console work is the first user of hvc_remove(). Alan describes it thus: The hvc_console assumes that a close and remove call can't occur at the same time. In addition tty_hangup(tty) is problematic as tty_hangup is asynchronous itself.... So this can happen hvc_close hvc_remove hung up ? - no lock tty = hp->tty unlock lock hp->tty = NULL unlock notify del kref_put the hvc struct close completes tty is destroyed tty_hangup dead tty tty->ops will be NULL NULL->... This patch adds some tty krefs and also converts to using tty_vhangup(). Reported-by: Alan Cox Signed-off-by: Amit Shah CC: Alan Cox CC: linuxppc-dev@ozlabs.org CC: Rusty Russell Signed-off-by: Greg Kroah-Hartman

TTY: Fix error return from tty_ldisc_open()

2011-01-07T22:43:01Z

The backported version of "TTY: ldisc, fix open flag handling" in 2.6.32.27 causes tty_ldisc_open() to return 0 on error. Fix that. Signed-off-by: Ben Hutchings Cc: Jiri Slaby Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman

TTY: ldisc, fix open flag handling

2010-12-09T21:26:47Z

commit 7f90cfc505d613f4faf096e0d84ffe99208057d9 upstream. When a concrete ldisc open fails in tty_ldisc_open, we forget to clear TTY_LDISC_OPEN. This causes a false warning on the next ldisc open: WARNING: at drivers/char/tty_ldisc.c:445 tty_ldisc_open+0x26/0x38() Hardware name: System Product Name Modules linked in: ... Pid: 5251, comm: a.out Tainted: G W 2.6.32-5-686 #1 Call Trace: [] ? warn_slowpath_common+0x5e/0x8a [] ? warn_slowpath_null+0xa/0xc [] ? tty_ldisc_open+0x26/0x38 [] ? tty_set_ldisc+0x218/0x304 ... So clear the bit when failing... Introduced in c65c9bc3efa (tty: rewrite the ldisc locking) back in 2.6.31-rc1. Signed-off-by: Jiri Slaby Cc: Alan Cox Reported-by: Sergey Lapin Tested-by: Sergey Lapin Signed-off-by: Greg Kroah-Hartman

tty_ldisc: Fix BUG() on hangup

2010-12-09T21:26:47Z

commit 1c95ba1e1de7edffc0c4e275e147f1a9eb1f81ae upstream. A kernel BUG when bluetooth rfcomm connection drop while the associated serial port is open is sometime triggered. It seems that the line discipline can disappear between the tty_ldisc_put and tty_ldisc_get. This patch fall back to the N_TTY line discipline if the previous discipline is not available anymore. Signed-off-by: Philippe Retornaz Acked-by: Alan Cox Signed-off-by: Greg Kroah-Hartman

TTY: restore tty_ldisc_wait_idle

2010-12-09T21:26:47Z

commit 100eeae2c5ce23b4db93ff320ee330ef1d740151 upstream. It was removed in 65b770468e98 (tty-ldisc: turn ldisc user count into a proper refcount), but we need to wait for last user to quit the ldisc before we close it in tty_set_ldisc. Otherwise weird things start to happen. There might be processes waiting in tty_read->n_tty_read on tty->read_wait for input to appear and at that moment, a change of ldisc is fatal. n_tty_close is called, it frees read_buf and the waiting process is still in the middle of reading and goes nuts after it is woken. Previously we prevented close to happen when others are in ldisc ops by tty_ldisc_wait_idle in tty_set_ldisc. But the commit above removed that. So revoke the change and test whether there is 1 user (=we), and allow the close then. We can do that without ldisc/tty locks, because nobody else can open the device due to TTY_LDISC_CHANGING bit set, so we in fact wait for everybody to leave. I don't understand why tty_ldisc_lock would be needed either when the counter is an atomic variable, so this is a lockless tty_ldisc_wait_idle. On the other hand, if we fail to wait (timeout or signal), we have to reenable the halted ldiscs, so we take ldisc lock and reuse the setup path at the end of tty_set_ldisc. Signed-off-by: Jiri Slaby Acked-by: Linus Torvalds Tested-by: Sebastian Andrzej Siewior LKML-Reference: <20101031104136.GA511@Chamillionaire.breakpoint.cc> LKML-Reference: <1287669539-22644-1-git-send-email-jslaby@suse.cz> Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman

tty: prevent DOS in the flush_to_ldisc

2010-12-09T21:26:46Z

commit e045fec48970df84647a47930fcf7a22ff7229c0 upstream. There's a small window inside the flush_to_ldisc function, where the tty is unlocked and calling ldisc's receive_buf function. If in this window new buffer is added to the tty, the processing might never leave the flush_to_ldisc function. This scenario will hog the cpu, causing other tty processing starving, and making it impossible to interface the computer via tty. I was able to exploit this via pty interface by sending only control characters to the master input, causing the flush_to_ldisc to be scheduled, but never actually generate any output. To reproduce, please run multiple instances of following code. - SNIP #define _XOPEN_SOURCE #include #include #include #include #include int main(int argc, char **argv) { int i, slave, master = getpt(); char buf[8192]; sprintf(buf, "%s", ptsname(master)); grantpt(master); unlockpt(master); slave = open(buf, O_RDWR); if (slave < 0) { perror("open slave failed"); return 1; } for(i = 0; i < sizeof(buf); i++) buf[i] = rand() % 32; while(1) { write(master, buf, sizeof(buf)); } return 0; } - SNIP The attached patch (based on -next tree) fixes this by checking on the tty buffer tail. Once it's reached, the current work is rescheduled and another could run. Signed-off-by: Jiri Olsa Acked-by: Alan Cox Signed-off-by: Greg Kroah-Hartman