- 09 May, 2011 40 commits
-
-
Abhijith Das authored
commit 8b421601 upstream. HighMem pages on i686 do not get mapped to the buffer_heads and this was causing a NULL pointer dereference when we were trying to memset page buffers to zero. We now use zero_user() that kmaps the page and directly manipulates page data. This patch also fixes a boundary condition that was incorrect. Signed-off-by:
Abhi Das <adas@redhat.com> Signed-off-by:
Steven Whitehouse <swhiteho@redhat.com> [Adjusted to apply to 2.6.32 by dann frazier <dannf@debian.org>] Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Abhijith Das authored
commit 7e619bc3 upstream. This is the upstream fix for this bug. This patch differs from the RHEL5 fix (Red Hat bz #555754) which simply writes to the 8-byte value field of the quota. In upstream quota code, we're required to write the entire quota (88 bytes) which can be split across a page boundary. We check for such quotas, and read/write the two parts from/to the corresponding pages holding these parts. With this patch, I don't see the bug anymore using the reproducer in Red Hat bz 555754. I successfully ran a couple of simple tests/mounts/ umounts and it doesn't seem like this patch breaks anything else. Signed-off-by:
-
Steven Whitehouse authored
commit 1e72c0f7 upstream. Both of these functions contained confusing and in one case duplicate code. This patch adds a new check in do_glock() so that we report -ENOENT if we are asked to sync a quota entry which doesn't exist. Due to the previous patch this is now reported correctly to userspace. Also there are a few new comments, and I hope that the code is easier to understand now. Signed-off-by:
-
Alan Stern authored
commit 834e2312 upstream. USB: teach "devices" file about Wireless and SuperSpeed USB The /sys/kernel/debug/usb/devices file doesn't know about Wireless or SuperSpeed USB. This patch (as1416b) teaches it, and updates the Documentation/usb/proc_sub_info.txt file accordingly. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: David Vrabel <david.vrabel@csr.com> CC: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Alan Stern authored
commit 7aba8d01 upstream. This patch (as1364) avoids enabling remote wakeup by default on all non-root-hub USB devices. Individual drivers or userspace will have to enable it wherever it is needed, such as for keyboards or network interfaces. Note: This affects only system sleep, not autosuspend. External hubs will continue to relay wakeup requests received from downstream through their upstream port, even when remote wakeup is not enabled for the hub itself. Disabling remote wakeup on a hub merely prevents it from generating wakeup requests in response to connect, disconnect, and overcurrent events. Signed-off-by:
-
Dan Streetman authored
commit 16985408 upstream. Currently a non-root-hub USB device's wakeup settings are initialized when the device is set to a configured state using device_init_wakeup(), but this is not correct as wakeup is split into "capable" (can_wakeup) and "enabled" (should_wakeup). The settings should be initialized instead in the device initialization (usb_new_device) with the "capable" setting disabled and the "enabled" setting enabled. The "capable" setting should be set based on the device being configured or unconfigured, and "enabled" setting set based on the sysfs power/wakeup control. This patch retains the sysfs power/wakeup setting of a non-root-hub USB device over a USB device re-configuration, which can happen (for example) after a suspend/resume cycle. Signed-off-by:
Dan Streetman <ddstreet@ieee.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Florian Schilhabel authored
commit 15d93ed0 upstream. This patch adds some device ids. The list of supported devices was extracted from realteks driver package. (0x050d, 0x815F) and (0x0df6, 0x004b) are not in the official list of supported devices and may not work correctly. In case of problems with these, they should probably be removed from the list. Signed-off-by:
Florian Schilhabel <florian.c.schilhabel@googlemail.com> Signed-off-by:
-
Florian Schilhabel authored
commit 60b42de3 upstream. This patch removes some device-ids. The list of unsupported devices was extracted from realteks driver package. removed IDs are: (0x0bda, 0x8192) (0x0bda, 0x8709) (0x07aa, 0x0043) (0x050d, 0x805E) (0x0df6, 0x0031) (0x1740, 0x9201) (0x2001, 0x3301) (0x5a57, 0x0290) These devices are _not_ rtl819su based. Signed-off-by:
-
Ben Hutchings authored
commit 41a38d9e upstream. The current code creates directories in procfs named after interfaces, but doesn't handle renaming. This can result in name collisions and consequent WARNINGs. It also means that the interface name cannot reliably be used to remove the directory - in fact the current code doesn't even try, and always uses "wlan0"! Since the name of a proc_dir_entry is embedded in it, use that when removing it. Add a netdev notifier to catch interface renaming, and remove and re-add the directory at this point. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Ben Hutchings authored
commit 9a3dfa05 upstream. Currently various resources may be leaked in case of an error. Signed-off-by:
-
Florian Schilhabel authored
commit 199ef62a upstream. added 2 checks for skb == NULL. plus cosmetics Signed-off-by:
-
Éric Piel authored
commit 7f29f17b upstream. According to the Dell/Ubuntu driver, what was previously observed as "jumpy cursor" corresponds to the hardware sending incorrect data for the first two reports of a one touch finger. So let's use the same workaround as in the other driver. Also, detect another firmware version with the same behaviour, as in the other driver. Signed-off-by:
Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> [bwh: Adjust for 2.6.32] Signed-off-by:
-
Dmitry Torokhov authored
commit a083632e upstream. Apparently there are Elantech touchpads that report non-zero in the 2nd byte of their signature. Adjust the detection routine so that if 2nd byte is zero and 3rd byte contains value that is not a valid report rate, we still assume that signature is valid. Tested-by:
-
Dmitry Torokhov authored
commit 504e8bee upstream. Apparently all 3 bytes returned by ETP_FW_VERSION_QUERY are significant and should be taken into account when matching hardware version/features. Tested-by:
-
Florian Ragwitz authored
commit e938fbfd upstream. In older versions of the elantech hardware/firmware those bits always were unset, so it didn't actually matter, but newer versions seem to use those high bits for something else, screwing up the coordinates we report to the input layer for those devices. Signed-off-by:
Florian Ragwitz <rafl@debian.org> Signed-off-by:
-
Florian Ragwitz authored
commit f81bc788 upstream. Apparently hardware vendors now ship elantech touchpads with different version magic. This options allows for them to be tested easier with the current driver in order to add their magic to the whitelist later. Signed-off-by:
-
Florian Ragwitz authored
commit 225c61aa upstream. The check determining whether device should use 4- or 6-byte packets was trying to compare firmware with 2.48, but was failing on majors greater than 2. The new check ensures that versions like 4.1 are checked properly. Signed-off-by:
-
Dmitry Torokhov authored
commit c7a1f3cc upstream. Elantech touchpads work in absolute mode and do not generate relative events so they should not be advertising them. Signed-off-by:
-
Takashi Iwai authored
commit 5f57d67d upstream. The new type of touchpads can be detected via a new query command 0x0c. The clickpad flags are in cap[0]:4 and cap[1]:0 bits. When the device is detected, the driver now reports only the left button as the supported buttons so that X11 driver can detect that the device is Clickpad. A Clickpad device gives the button events only as the middle button. The kernel driver morphs to the left button. The real handling of Clickpad is done rather in X driver side. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Ben Hutchings authored
commit b3ccbb24 upstream. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Ben Hutchings authored
commit 866691a2 upstream. Signed-off-by:
-
Ben Hutchings authored
commit 8489992e upstream. Signed-off-by:
-
Ben Hutchings authored
commit 36c04a61 upstream. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Ben Hutchings authored
commit b9721d5a upstream. Signed-off-by:
-
Ben Hutchings authored
commit 34336ec0 upstream. Replace run-time string formatting with preprocessor string manipulation. Signed-off-by:
Divy Le Ray <divy@chelsio.com> Signed-off-by:
-
Ben Hutchings authored
commit 45229b42 upstream. Replace run-time string formatting with preprocessor string manipulation. Signed-off-by:
Eilon Greenstein <eilong@broadcom.com> Signed-off-by:
-
Dhananjay Phadke authored
commit 7e8e5d97 upstream. Add MODULE_FIRMWARE hints for various firmware file types, required by different chip revisions. Signed-off-by:
Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by:
-
Timo Warns authored
commit c340b1d6 upstream. The kernel automatically evaluates partition tables of storage devices. The code for evaluating LDM partitions (in fs/partitions/ldm.c) contains a bug that causes a kernel oops on certain corrupted LDM partitions. A kernel subsystem seems to crash, because, after the oops, the kernel no longer recognizes newly connected storage devices. The patch validates the value of vblk_size. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
Timo Warns <warns@pre-sense.de> Cc: Eugene Teo <eugeneteo@kernel.sg> Cc: Harvey Harrison <harvey.harrison@gmail.com> Cc: Richard Russon <rich@flatcap.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dave Jones authored
commit c6914a6f upstream. We can get here with a NULL socket argument passed from userspace, so we need to handle it accordingly. Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Sachin Prabhu authored
commit 1574dff8 upstream. An open on a NFS4 share using the O_CREAT flag on an existing file for which we have permissions to open but contained in a directory with no write permissions will fail with EACCES. A tcpdump shows that the client had set the open mode to UNCHECKED which indicates that the file should be created if it doesn't exist and encountering an existing flag is not an error. Since in this case the file exists and can be opened by the user, the NFS server is wrong in attempting to check create permissions on the parent directory. The patch adds a conditional statement to check for create permissions only if the file doesn't exist. Signed-off-by:
Sachin S. Prabhu <sprabhu@redhat.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Jim Bos authored
commit 22d3243d upstream. The fix in commit 6b4e81db ("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 <jim876@xs4all.nl> Acked-by:
Jakub Jelinek <jakub@redhat.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by:
-
Jim Bos authored
commit 6b4e81db 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:
-
Dan Rosenberg authored
commit 0f22072a upstream. When CONFIG_OABI_COMPAT is set, the wrapper for semtimedop does not bound the nsops argument. A sufficiently large value will cause an integer overflow in allocation size, followed by copying too much data into the allocated buffer. Fix this by restricting nsops to SEMOPM. Untested. Signed-off-by:
Dan Rosenberg <drosenberg@vsecurity.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Eric W. Biederman authored
commit a05d2ad1 upstream. This fixes the following oops discovered by Dan Aloni: > Anyway, the following is the output of the Oops that I got on the > Ubuntu kernel on which I first detected the problem > (2.6.37-12-generic). The Oops that followed will be more useful, I > guess. >[ 5594.669852] BUG: unable to handle kernel NULL pointer dereference > at (null) > [ 5594.681606] IP: [<ffffffff81550b7b>] unix_dgram_recvmsg+0x1fb/0x420 > [ 5594.687576] PGD 2a05d067 PUD 2b951067 PMD 0 > [ 5594.693720] Oops: 0002 [#1] SMP > [ 5594.699888] last sysfs file: The bug was that unix domain sockets use a pseduo packet for connecting and accept uses that psudo packet to get the socket. In the buggy seqpacket case we were allowing unconnected sockets to call recvmsg and try to receive the pseudo packet. That is always wrong and as of commit 7361c36c the pseudo packet had become enough different from a normal packet that the kernel started oopsing. Do for seqpacket_recv what was done for seqpacket_send in 2.5 and only allow it on connected seqpacket sockets. Tested-by:
Dan Aloni <dan@aloni.org> Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Boris Ostrovsky authored
commit e20a2d20 upstream. Older AMD K8 processors (Revisions A-E) are affected by erratum 400 (APIC timer interrupts don't occur in C states greater than C1). This, for example, means that X86_FEATURE_ARAT flag should not be set for these parts. This addresses regression introduced by commit b87cf80a ("x86, AMD: Set ARAT feature on AMD processors") where the system may become unresponsive until external interrupt (such as keyboard input) occurs. This results, for example, in time not being reported correctly, lack of progress on the system and other lockups. Reported-by:
Joerg-Volker Peetz <jvpeetz@web.de> Tested-by:
Borislav Petkov <borislav.petkov@amd.com> Signed-off-by:
Boris Ostrovsky <Boris.Ostrovsky@amd.com> Link: http://lkml.kernel.org/r/1304113663-6586-1-git-send-email-ostr@amd64.orgSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Alan Stern authored
commit cee6a262 upstream. This patch (as1460) fixes a regression in the usbip driver caused by the new check for Transaction Translators in USB-2 hubs. The root hub registered by vhci_hcd needs to have the has_tt flag set, because it can connect to low- and full-speed devices as well as high-speed devices. Signed-off-by:
Nikola Ciprich <nikola.ciprich@linuxbox.cz> Signed-off-by:
-
Chris Ball authored
commit 0c9c99a7 upstream. It seems that under certain circumstances the sdhci_tasklet_finish() call can be entered with mrq set to NULL, causing the system to crash with a NULL pointer de-reference. Seen on S3C6410 system. Based on a patch by Dimitris Papastamos. Reported-by:
Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Ben Dooks authored
commit b7b4d342 upstream. It seems that under certain circumstances that the sdhci_tasklet_finish() call can be entered with mrq->cmd set to NULL, causing the system to crash with a NULL pointer de-reference. Unable to handle kernel NULL pointer dereference at virtual address 00000000 PC is at sdhci_tasklet_finish+0x34/0xe8 LR is at sdhci_tasklet_finish+0x24/0xe8 Seen on S3C6410 system. Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Chris Ball authored
commit 9fdcdbb0 upstream. If pci_ioremap_bar() fails during probe, we "goto release;" and free the host, but then we return 0 -- which tells sdhci_pci_probe() that the probe succeeded. Since we think the probe succeeded, when we unload sdhci we'll go to sdhci_pci_remove_slot() and it will try to dereference slot->host, which is now NULL because we freed it in the error path earlier. The patch simply sets ret appropriately, so that sdhci_pci_probe() will detect the failure immediately and bail out. Signed-off-by:
-
James Bottomley authored
commit 86cbfb56 upstream. SCSI uses request_queue->queuedata == NULL as a signal that the queue is dying. We set this state in the sdev release function. However, this allows a small window where we release the last reference but haven't quite got to this stage yet and so something will try to take a reference in scsi_request_fn and oops. It's very rare, but we had a report here, so we're pushing this as a bug fix The actual fix is to set request_queue->queuedata to NULL in scsi_remove_device() before we drop the reference. This causes correct automatic rejects from scsi_request_fn as people who hold additional references try to submit work and prevents anything from getting a new reference to the sdev that way. Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
