linux/drivers/char, branch v2.6.34.12

tty: fix warning in synclink driver

2012-05-17T15:21:38Z

commit dc98d9650891661a20842a8eef9e76536046d897 upstream. During builds I see the following warning - CC [M] drivers/char/pcmcia/synclink_cs.o drivers/char/pcmcia/synclink_cs.c:2194: warning: ‘mgslpc_get_icount’ defined but not used The function is a callback meant to be assigned to get_icount (added during 0587102cf). Fix accordingly. Signed-off-by: Andres Salomon Acked-by: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker

nozomi: Fix warning from the previous TIOCGCOUNT changes

2012-05-17T15:21:38Z

commit 68e29655cc51761d60d5f27b2738816a5b13e415 upstream. Just remove a now unused variable Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker

tty: icount changeover for other main devices

2012-05-17T15:21:37Z

commit 0587102cf9f427c185bfdeb2cef41e13ee0264b1 upstream. Again basically cut and paste Convert the main driver set to use the hooks for GICOUNT Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker

tty: Make tiocgicount a handler

2012-05-17T15:21:37Z

commit d281da7ff6f70efca0553c288bb883e8605b3862 upstream. Dan Rosenberg noted that various drivers return the struct with uncleared fields. Instead of spending forever trying to stomp all the drivers that get it wrong (and every new driver) do the job in one place. This first patch adds the needed operations and hooks them up, including the needed USB midlayer and serial core plumbing. Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker

net: Compute protocol sequence numbers and fragment IDs using MD5.

2012-05-17T15:21:27Z

commit 6e5714eaf77d79ae1c8b47e3e040ff5411b717ec upstream. Computers have become a lot faster since we compromised on the partial MD4 hash which we use currently for performance reasons. MD5 is a much safer choice, and is inline with both RFC1948 and other ISS generators (OpenBSD, Solaris, etc.) Furthermore, only having 24-bits of the sequence number be truly unpredictable is a very serious limitation. So the periodic regeneration and 8-bit counter have been removed. We compute and use a full 32-bit sequence number. For ipv6, DCCP was found to use a 32-bit truncated initial sequence number (it needs 43-bits) and that is fixed here as well. Reported-by: Dan Kaminsky Tested-by: Willy Tarreau Signed-off-by: David S. Miller [PG: diffstat vs. 6e5714 differs, since no secure_ipv6_id to delete in 34] Signed-off-by: Paul Gortmaker

TTY: ldisc, do not close until there are readers

2012-05-17T15:20:57Z

commit 92f6fa09bd453ffe3351fa1f1377a1b7cfa911e6 upstream. We restored tty_ldisc_wait_idle in 100eeae2c5c (TTY: restore tty_ldisc_wait_idle). We used it in the ldisc changing path to fix the case where there are tasks in n_tty_read waiting for data and somebody tries to change ldisc. Similar to the case above, there may be also tasks waiting in n_tty_read while hangup is performed. As 65b770468e98 (tty-ldisc: turn ldisc user count into a proper refcount) removed the wait-until-idle from all paths, hangup path won't wait for them to disappear either now. So add it back even to the hangup path. There is a difference, we need uninterruptible sleep as there is obviously HUP signal pending. So tty_ldisc_wait_idle now sleeps without possibility to be interrupted. This is what original tty_ldisc_wait_idle did. After the wait idle reintroduction (100eeae2c5c), we have had interruptible sleeps for the ldisc changing path. But as there is a 5s timeout anyway, we don't allow it to be interrupted from now on. It's not worth the added complexity of deciding what kind of sleep we want. Before 65b770468e98 tty_ldisc_release was called also from tty_ldisc_release. It is called from tty_release, so I don't think we need to restore that one. This is nicely reproducible after constifying the timing when drivers/tty/n_tty.c is patched as follows ("TTY: ntty, add one more sanity check" patch is needed to actually see it explode): %% -1548,6 +1549,7 @@ static int n_tty_open(struct tty_struct *tty) /* These are ugly. Currently a malloc failure here can panic */ if (!tty->read_buf) { + msleep(100); tty->read_buf = kzalloc(N_TTY_BUF_SIZE, GFP_KERNEL); if (!tty->read_buf) return -ENOMEM; %% -1785,6 +1788,7 @@ do_it_again: break; } timeout = schedule_timeout(timeout); + msleep(20); continue; } __set_current_state(TASK_RUNNING); ===== With a process: ===== while (1) { int fd = open(argv[1], O_RDWR); read(fd, buf, sizeof(buf)); close(fd); } ===== and its child: ===== setsid(); while (1) { int fd = open(tty, O_RDWR|O_NOCTTY); ioctl(fd, TIOCSCTTY, 1); vhangup(); close(fd); usleep(100 * (10 + random() % 1000)); } ===== EOF ===== References: https://bugzilla.novell.com/show_bug.cgi?id=693374 References: https://bugzilla.novell.com/show_bug.cgi?id=694509 Signed-off-by: Jiri Slaby Cc: Alan Cox Cc: Linus Torvalds Signed-off-by: Greg Kroah-Hartman [PG: account for char --> tty file rename post 2.6.34] Signed-off-by: Paul Gortmaker

i8k: Avoid lahf in 64-bit code

2012-05-17T15:20:38Z

commit bc1f419c76a2d6450413ce4349f4e4a07be011d5 upstream. i8k uses lahf to read the flag register in 64-bit code; early x86-64 CPUs, however, lack this instruction and we get an invalid opcode exception at runtime. Use pushf to load the flag register into the stack instead. Signed-off-by: Luca Tettamanti Reported-by: Jeff Rickman Tested-by: Jeff Rickman Tested-by: Harry G McGavran Jr Cc: Massimo Dal Zotto Signed-off-by: Jean Delvare Signed-off-by: Paul Gortmaker

Fix gcc 4.5.1 miscompiling drivers/char/i8k.c (again)

2012-03-14T14:57:31Z

commit 22d3243de86bc92d874abb7c5b185d5c47aba323 upstream. The fix in commit 6b4e81db2552 ("i8k: Tell gcc that *regs gets clobbered") to work around the gcc miscompiling i8k.c to add "+m (*regs)" caused register pressure problems and a build failure. Changing the 'asm' statement to 'asm volatile' instead should prevent that and works around the gcc bug as well, so we can remove the "+m". [ Background on the gcc bug: a memory clobber fails to mark the function the asm resides in as non-pure (aka "__attribute__((const))"), so if the function does nothing else that triggers the non-pure logic, gcc will think that that function has no side effects at all. As a result, callers will be mis-compiled. Adding the "+m" made gcc see that it's not a pure function, and so does "asm volatile". The problem was never really the need to mark "*regs" as changed, since the memory clobber did that part - the problem was just a bug in the gcc "pure" function analysis - Linus ] Signed-off-by: Jim Bos Acked-by: Jakub Jelinek Cc: Andi Kleen Cc: Andreas Schwab Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker

i8k: Tell gcc that *regs gets clobbered

2012-03-14T14:57:31Z

commit 6b4e81db2552bad04100e7d5ddeed7e848f53b48 upstream. More recent GCC caused the i8k driver to stop working, on Slackware compiler was upgraded from gcc-4.4.4 to gcc-4.5.1 after which it didn't work anymore, meaning the driver didn't load or gave total nonsensical output. As it turned out the asm(..) statement forgot to mention it modifies the *regs variable. Credits to Andi Kleen and Andreas Schwab for providing the fix. Signed-off-by: Jim Bos Cc: Andi Kleen Cc: Andreas Schwab Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker

char/tpm: Fix unitialized usage of data buffer

2012-03-14T14:57:03Z

commit 1309d7afbed112f0e8e90be9af975550caa0076b upstream. This patch fixes information leakage to the userspace by initializing the data buffer to zero. Reported-by: Peter Huewe Signed-off-by: Peter Huewe Signed-off-by: Marcel Selhorst [ Also removed the silly "* sizeof(u8)". If that isn't 1, we have way deeper problems than a simple multiplication can fix. - Linus ] Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker