linux, branch v2.6.31.5

Linux 2.6.31.5

2009-10-22T22:57:56Z

Signed-off-by: Greg Kroah-Hartman

tty: Make flush_to_ldisc() locking more robust

2009-10-22T22:12:01Z

commit c8e33141911bf8fe87dc6c92793b9a59b2be0130 upstream. The locking logic in this function is extremely subtle, and it broke when we started doing potentially concurrent 'flush_to_ldisc()' calls in commit e043e42bdb66885b3ac10d27a01ccb9972e2b0a3 ("pty: avoid forcing 'low_latency' tty flag"). The code in flush_to_ldisc() used to set 'tty->buf.head' to NULL, with the intention that this would then cause any other concurrent calls to not do anything (locking note: we have to drop the buf.lock over the call to ->receive_buf that can block, which is why we can have concurrency here at all in the first place). It also used to set the TTY_FLUSHING bit, which would then cause any concurrent 'tty_buffer_flush()' to not free all the tty buffers and clear 'tty->buf.tail'. And with 'buf.head' being NULL, and 'buf.tail' being non-NULL, new data would never touch 'buf.head'. Does that sound a bit too subtle? It was. If another concurrent call to 'flush_to_ldisc()' were to come in, the NULL buf.head would indeed cause it to not process the buffer list, but it would still clear TTY_FLUSHING afterwards, making the buffer protection against 'tty_buffer_flush()' no longer work. So this clears it all up. We depend purely on TTY_FLUSHING for handling re-entrancy, and stop playing games with the buffer list entirely. In fact, the buffer list handling is now robust enough that we could probably stop doing the whole "protect against 'tty_buffer_flush()'" thing entirely. However, Alan also points out that we would probably be better off simplifying the locking even further, and just take the tty ldisc_mutex around all the buffer flushing calls. That seems like a good idea, but in the meantime this is a conceptually minimal fix (with the patch itself being bigger than required just to clean the code up and make it readable). This fixes keyboard trouble under X: http://bugzilla.kernel.org/show_bug.cgi?id=14388 Reported-and-tested-by: Frédéric Meunier Reported-and-tested-by: Boyan Cc: Alan Cox Cc: Paul Fulghum Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

mac80211: fix vlan and optimise RX

2009-10-22T22:12:01Z

commit fbc44bf7177dfd61381da55405550b693943a432 upstream. When receiving data frames, we can send them only to the interface they belong to based on transmitting station (this doesn't work for probe requests). Also, don't try to handle other frames for AP_VLAN at all since those interface should only receive data. Additionally, the transmit side must check that the station we're sending a frame to is actually on the interface we're transmitting on, and not transmit packets to functions that live on other interfaces, so validate that as well. Another bug fix is needed in sta_info.c where in the VLAN case when adding/removing stations we overwrite the sdata variable we still need. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

iwlwifi: incorrect method used for finding valid OTP blocks

2009-10-22T22:12:00Z

commit 2facba769d7f9e563cf706de709074a2d20f1bba upstream. The address stored in the next link address is a word address but when reading the OTP blocks, a byte address is used. Also if the blocks are full and the last link pointer is not zero, then none of the blocks are valid so return an error. The algorithm is simply valid blocks have a next address and that address's contents is zero. Using the wrong address for the next link address gets arbitrary data, obviously. In cases seen, the first block is considered valid when it is not. If the block has in fact been invalidated there may be old data or there may be no data, bad data, or partial data, there is no way of telling. Without this patch it is possible that a device with valid OTP data is unable to work. Signed-off-by: Jay Sternberg Signed-off-by: Reinette Chatre Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

usb-storage: Workaround devices with bogus sense size

2009-10-22T22:12:00Z

commit b8430e1b82b7e514d76a88eb70a7d8831d50df1e upstream. usb-storage: Workaround devices with bogus sense size Some devices, such as Huawei E169, advertise more than the standard amount of sense data, causing us to set US_FL_SANE_SENSE, assuming they support it. However, they subsequently fail the request sense with that size. This works around it generically. When a sense request fails due to a device returning an error, US_FL_SANE_SENSE was set, and that sense request used a larger sense size, we retry with a smaller size before giving up. Based on an original patch by Ben Efros Signed-off-by: Benjamin Herrenschmidt Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

Staging: rt2860sta: prevent a panic when disabling when associated

2009-10-22T22:11:59Z

commit 0af49167b1e5ba154e90d2c454bf4624ee47df80 upstream. This fixes a panic which is triggered when the hardware "disappears" from beneath the driver, i.e. when wireless is toggled off via Fn-F2 on various EeePC models. Ref. bug report http://bugzilla.kernel.org/show_bug.cgi?id=13390 panic http://bugzilla.kernel.org/attachment.cgi?id=21928 Signed-off-by: Darren Salt Signed-off-by: Greg Kroah-Hartman

sysfs: Allow sysfs_notify_dirent to be called from interrupt context.

2009-10-22T22:11:59Z

commit 83db93f4de2d9ae441a491d1dc61c2204f0195de upstream. sysfs_notify_dirent is a simple atomic operation that can be used to alert user-space that new data can be read from a sysfs attribute. Unfortunately it cannot currently be called from non-process context because of its use of spin_lock which is sometimes taken with interrupts enabled. So change all lockers of sysfs_open_dirent_lock to disable interrupts, thus making sysfs_notify_dirent safe to be called from non-process context (as drivers/md does in md_safemode_timeout). sysfs_get_open_dirent is (documented as being) only called from process context, so it uses spin_lock_irq. Other places use spin_lock_irqsave. The usage for sysfs_notify_dirent in md_safemode_timeout was introduced in 2.6.28, so this patch is suitable for that and more recent kernels. Reported-by: Joel Andres Granados Signed-off-by: NeilBrown Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman

bsdacct: switch credentials for writing to the accounting file

2009-10-22T22:11:59Z

commit d8e180dcd5bbbab9cd3ff2e779efcf70692ef541 upstream. When process accounting is enabled, every exiting process writes a log to the account file. In addition, every once in a while one of the exiting processes checks whether there's enough free space for the log. SELinux policy may or may not allow the exiting process to stat the fs. So unsuspecting processes start generating AVC denials just because someone enabled process accounting. For these filesystem operations, the exiting process's credentials should be temporarily switched to that of the process which enabled accounting, because it's really that process which wanted to have the accounting information logged. Signed-off-by: Michal Schmidt Acked-by: David Howells Acked-by: Serge Hallyn Signed-off-by: Andrew Morton Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman

ALSA: Don't assume i2c device probing always succeeds

2009-10-22T22:11:58Z

commit 18c4078489fe064cc0ed08be3381cf2f26657f5f upstream. The client->driver pointer can be NULL when i2c-device probing fails in i2c_new_device(). This patch adds the NULL checks for client->driver and return the error instead of blind assumption of driver availability. Reported-by: Tim Shepard Cc: Jean Delvare Cc: Johannes Berg Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

i2c: Hide probe errors caused by ACPI resource conflicts

2009-10-22T22:11:58Z

commit 18669eabde2ff5fc446e72e043f0539059763438 upstream. When an ACPI resource conflict is detected, error messages are already printed by ACPI. There's no point in causing the driver core to print more error messages, so return one of the error codes for which no message is printed. This fixes bug #14293: http://bugzilla.kernel.org/show_bug.cgi?id=14293 Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman