- 22 Oct, 2009 40 commits
-
-
Greg Kroah-Hartman authored
Signed-off-by:Greg Kroah-Hartman <gregkh@suse.de>
-
Linus Torvalds authored
commit c8e33141 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 e043e42b ("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=14388Reported-and-tested-by:
Frédéric Meunier <fredlwm@gmail.com> Reported-and-tested-by:
Boyan <btanastasov@yahoo.co.uk> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Paul Fulghum <paulkf@microgate.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Johannes Berg authored
commit fbc44bf7 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 <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Jay Sternberg authored
commit 2facba76 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 <jay.e.sternberg@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit b8430e1b 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 <ben@pc-doctor.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Darren Salt authored
commit 0af49167 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=21928Signed-off-by:
Darren Salt <linux@youmustbejoking.demon.co.uk> Signed-off-by:
-
Neil Brown authored
commit 83db93f4 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 <jgranado@redhat.com> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Michal Schmidt authored
commit d8e180dc 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 <mschmidt@redhat.com> Acked-by:
David Howells <dhowells@redhat.com> Acked-by:
Serge Hallyn <serue@us.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Takashi Iwai authored
commit 18c40784 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 <shep@alum.mit.edu> Cc: Jean Delvare <khali@linux-fr.org> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Jean Delvare authored
commit 18669eab 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=14293Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Jean Delvare authored
commit 6f6b35e1 upstream. If i2c device probing fails, then there is no driver to dereference after calling i2c_new_device(). Stop assuming that probing will always succeed, to avoid NULL pointer dereferences. We have an easier access to the driver anyway. Signed-off-by:
-
Jean Delvare authored
commit 05576a1e upstream. Signed-off-by:
Riku Voipio <riku.voipio@iki.fi> Signed-off-by:
-
Alexander Duyck authored
commit a825e00c upstream. There appears to have been a mixup in the max supported jumbo frame size between 82574 and 82583 which ended up disabling jumbo frames on the 82574 as a result. This patch swaps the two so that this issue is resolved. This patch fixes http://bugzilla.kernel.org/show_bug.cgi?id=14261Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
-
Philipp Reisner authored
(cherry picked from commit 30efa3f76813b17445bc5a2e443ae9731518566b) Signed-off-by:
Philipp Reisner <philipp.reisner@linbit.com> Signed-off-by:
-
Philipp Reisner authored
(cherry picked from commit 0179065b13b354cc0b940e7a632a65ec0448beff) Signed-off-by:
-
Philipp Reisner authored
(cherry picked from commit dbbb3431228784612848a1ec6061c78b4b708b5c) Signed-off-by:
-
Philipp Reisner authored
(cherry picked from commit 93136335f9ad7a98b92eacda1b43dccbf063cd07) Signed-off-by:
-
Philipp Reisner authored
(cherry picked from commit f4b5129f5e838942f759c2637967441cf4a98c20) Signed-off-by:
Lars Ellenberg <lars.ellenberg@linbit.com> Acked-by:
Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by:
-
Philipp Reisner authored
commit 7069331d upstream Signed-off-by:
-
Philipp Reisner authored
(cherry picked from commit 5491c43845dae6c68cb4edbcf2e2dde9a32a863d) Signed-off-by:
-
Marcel Holtmann authored
commit edad6388 upstream. The core exports the hci_conn_hold_device() and hci_conn_put_device() functions for device reference of connections. Use this to ensure that the uevents from the parent are send after the child ones. Based on a report by Brian Rogers <brian@xyzw.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Marcel Holtmann authored
commit 9eba32b8 upstream. The device model itself has no real usable reference counting at the moment and this causes problems if parents are deleted before their children. The device model itself handles the memory details of this correctly, but the uevent order is not consistent. This causes various problems for systems like HAL or even X. So until device_put() does a proper cleanup, the device for Bluetooth connection will be protected with an extra reference counting to ensure the correct order of uevents when connections are terminated. This is not an automatic feature. Higher Bluetooth layers like HIDP or BNEP should grab this new reference to ensure that their uevents are send before the ones from the parent device. Based on a report by Brian Rogers <brian@xyzw.org> Signed-off-by:
-
Marcel Holtmann authored
commit 364f6351 upstream. Currently the HID subsystem will create HIDRAW devices for the transport driver, but it will not disconnect them. Until the HID subsytem gets fixed, ensure that HIDRAW and HIDDEV devices are disconnected when the Bluetooth HID device gets removed. Based on a patch from Brian Rogers <brian@xyzw.org> Signed-off-by:
-
Rajiv Andrade authored
commit 15d031c3 upstream. The previously sent patch: http://marc.info/?l=tpmdd-devel&m=125208945007834&w=2 Had its first hunk cropped when merged, submitting only this first hunk again. Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Cc: Debora Velarde <debora@linux.vnet.ibm.com> Cc: Marcel Selhorst <m.selhorst@sirrix.com> Cc: James Morris <jmorris@namei.org> Signed-off-by:
Rajiv Andrade <srajiv@linux.vnet.ibm.com> Acked-by:
Mimi Zohar <zohar@us.ibm.com> Tested-by:
-
Jason Gunthorpe authored
commit 0afd9056 upstream. Signed-off-by:
-
Darren Hart authored
commit 0729e196 upstream. PI futexes do not use the same plist_node_empty() test for wakeup. It was possible for the waiter (in futex_wait_requeue_pi()) to set TASK_INTERRUPTIBLE after the waker assigned the rtmutex to the waiter. The waiter would then note the plist was not empty and call schedule(). The task would not be found by any subsequeuent futex wakeups, resulting in a userspace hang. By moving the setting of TASK_INTERRUPTIBLE to before the call to queue_me(), the race with the waker is eliminated. Since we no longer call get_user() from within queue_me(), there is no need to delay the setting of TASK_INTERRUPTIBLE until after the call to queue_me(). The FUTEX_LOCK_PI operation is not affected as futex_lock_pi() relies entirely on the rtmutex code to handle schedule() and wakeup. The requeue PI code is affected because the waiter starts as a non-PI waiter and is woken on a PI futex. Remove the crusty old comment about holding spinlocks() across get_user() as we no longer do that. Correct the locking statement with a description of why the test is performed. Signed-off-by:
Darren Hart <dvhltc@us.ibm.com> Acked-by:
Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Dinakar Guniguntala <dino@in.ibm.com> Cc: John Stultz <johnstul@us.ibm.com> LKML-Reference: <20090922053038.8717.97838.stgit@Aeon> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Darren Hart authored
commit 84bc4af5 upstream. There is currently no check to ensure that userspace uses the same futex requeue target (uaddr2) in futex_requeue() that the waiter used in futex_wait_requeue_pi(). A mismatch here could very unexpected results as the waiter assumes it either wakes on uaddr1 or uaddr2. We could detect this on wakeup in the waiter, but the cleanup is more intense after the improper requeue has occured. This patch stores the waiter's expected requeue target in a new requeue_pi_key pointer in the futex_q which futex_requeue() checks prior to attempting to do a proxy lock acquistion or a requeue when requeue_pi=1. If they don't match, return -EINVAL from futex_requeue, aborting the requeue of any remaining waiters. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
David Woodhouse authored
commit 0815565a upstream. Yet another reason why trusting this stuff to the BIOS was a bad idea. The HP DC7900 BIOS reports an iommu at an address which just returns all ones, when VT-d is disabled in the BIOS. Fix up the missing iounmap in the error paths while we're at it. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Cc: Arto Jantunen <viiru@debian.org> Signed-off-by:
-
Sam Ravnborg authored
commit 51b563fc upstream. Albin Tonnerre <albin.tonnerre@free-electrons.com> reported: Bash 4 filters out variables which contain a dot in them. This happends to be the case of CPPFLAGS_vmlinux.lds. This is rather unfortunate, as it now causes build failures when using SHELL=/bin/bash to compile, or when bash happens to be used by make (eg when it's /bin/sh) Remove the common definition of CPPFLAGS_vmlinux.lds by pushing relevant stuff to either Makefile.build or the arch specific kernel/Makefile where we build the linker script. This is also nice cleanup as we move the information out where it is used. Notes for the different architectures touched: arm - we use an already exported symbol cris - we use a config symbol aleady available [Not build tested] mips - the jiffies complexity has moved to vmlinux.lds.S where we need it. Added a few variables to CPPFLAGS - they are only used by the linker script. [Not build tested] powerpc - removed assignment that is not needed [not build tested] sparc - simplified it using $(BITS) um - introduced a few new exported variables to deal with this xtensa - added options to CPP invocation [not build tested] Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jeff Dike <jdike@addtoit.com> Cc: Chris Zankel <chris@zankel.net> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Alan Stern authored
commit f1a0743b upstream. This patch (as1294) fixes a problem that has plagued users for several kernel releases. Some USB mass-storage devices don't return any sense data when they encounter certain kinds of errors. The SCSI layer interprets this to mean that the operation should be retried, and the same thing happens -- over and over again with no limit. In some circumstances (such as when a bus reset occurs) that is the right thing to do, but not here. The patch checks for this condition (a transport failure with no sense data) and changes the result code to DID_ERROR and the sense code to Hardware Error. This does get only a limited number of retries, and so the command will fail relatively quickly instead of getting stuck in an infinite loop. This fixes a large part of Bugzilla #14118. Signed-off-by:
Mantas Mikulenas <grawity@gmail.com> Signed-off-by:
-
Joris van Rantwijk authored
commit 63a96095 upstream. The generic usbserial driver in Linux 2.6.31 halts its receiving channel in response to throttle requests from the line discipline. Unfortunately it drops the contents of the first URB received after throttling takes effect. This patch corrects that problem. Signed-off-by:
Joris van Rantwijk <jorispubl@xs4all.nl> Acked-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Éric Piel authored
commit 6f88139e upstream. In the Dell inspiron mini 10, the GPS is connected via a cp2102. This patch adds detection of this USB device. (I haven't managed to use the GPS under Linux yet, though) Signed-off-by:
Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by:
-
Alan Stern authored
commit 06bad89d upstream. This patch (as1293) fixes a problem with the ipaq serial driver. It tries to bind to all the interfaces, even those that don't have enough endpoints. The symptom is an invalid memory reference and oops when the device is plugged in. Signed-off-by:
Matthias Geissert <geissert@mathematik.tu-darmstadt.de> Tested-by:
Tilman Schmidt <tilman@imap.cc> Signed-off-by:
-
Peter Magdina authored
commit 75f47214 upstream. Signed-off-by:
Peter Magdina <peter@magdina.sk> Signed-off-by:
-
Alan Stern authored
commit a4720c65 upstream. This patch (as1295) fixes a recently-added bug in the USB serial core. If certain kinds of errors occur during probing, the core may call a serial driver's release method without previously calling the attach method. This causes some drivers (io_ti in particular) to perform an invalid memory access. The patch adds a new flag to keep track of whether or not attach has been called. Signed-off-by:
Jean-Denis Girard <jd.girard@sysnux.pf> Signed-off-by:
-
Johan Hovold authored
commit ba6b702f upstream. This patch fixes a regression introduced in 39892da4. Signed-off-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Johan Hovold authored
commit 9388e2e7 upstream. Fix regression introduced by commit d4fc4a7b (tty: Fix the PL2303 private methods for sysrq). Signed-off-by:
-
Johan Hovold authored
commit cc01f17d upstream. - Re-structure read processing. - Kill obsolete work queue and always push to tty in completion handler. - Use tty_insert_flip_string instead of per character push when possible. - Fix stalled-read regression in 2.6.31 by using urb status to determine when port is closed rather than port count. - Fix race with open/close by checking ASYNCB_INITIALIZED in unthrottle. - Kill private rx_flag and lock and use throttle flags in usb_serial_port instead. Signed-off-by:
-
Johan Hovold authored
commit e63e278b upstream. Remove superfluous error checks in completion handler: - No need to check private data and urb pointers as we check urb-status before dereferencing priv (which is not freed until urb has been killed on close). - No need to check tty as it is checked again when processing. - No need to check urb->number_of_packets on bulk urb. Note that both private data and tty are checked again before processing (possibly from work queue which also is cancelled on close). Signed-off-by:
-
Johan Hovold authored
commit 63b00612 upstream. Remove unused rx_byte counter which is never exposed as noted by Alan Cox. Signed-off-by:
-
