commit 3f7153e947a301a5567cb50866479006575757e5 Author: Greg Kroah-Hartman Date: Wed Nov 21 09:30:59 2007 -0800 Linux 2.6.22.14 commit 2cfa048e27d6e9029e2b3ac9a93b27ec29967256 Author: Jean Delvare Date: Fri Nov 16 10:37:55 2007 +0100 i2c/eeprom: Recognize VGN as a valid Sony Vaio name prefix patch 8b925a3dd8a4d7451092cb9aa11da727ba69e0f0 in mainline. Recent (i.e. 2005 and later) Sony Vaio laptops have names beginning with VGN rather than PCG. Update the eeprom driver so that it recognizes these. Why this matters: the eeprom driver hides private data from the EEPROMs it recognizes as Vaio EEPROMs (passwords, serial number...) so if the driver fails to recognize a Vaio EEPROM as such, the private data is exposed to the world. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 327bec37455d35156b72b4fdbec1d1403c8a2a92 Author: Jean Delvare Date: Fri Nov 16 10:34:17 2007 +0100 i2c/eeprom: Hide Sony Vaio serial numbers patch 0f2cbd38aa377e30df3b7602abed69464d1970aa in mainline. The sysfs interface to DMI data takes care to not make the system serial number and UUID world-readable, presumably due to privacy concerns. For consistency, we should not let the eeprom driver export these same strings to the world on Sony Vaio laptops. Instead, only make them readable by root, as we already do for BIOS passwords. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit f67444f10f4e30864fa7b431d88588de87c92980 Author: Jean Delvare Date: Fri Nov 16 10:24:36 2007 +0100 i2c-pasemi: Fix NACK detection patch be8a1f7cd4501c3b4b32543577a33aee6d2193ac in mainline. Turns out we don't actually check the status to see if there was a device out there to talk to, just if we had a timeout when doing so. Add the proper check, so we don't falsly think there are devices on the bus that are not there, etc. Signed-off-by: Olof Johansson Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 2e95672cd8684beddb2390ed5212ac50e1fd0dae Author: Mark Fasheh Date: Wed Nov 14 13:33:27 2007 -0800 ocfs2: fix write() performance regression ocfs2: fix write() performance regression patch 4e9563fd55ff4479f2b118d0757d121dd0cfc39c in mainline. On file systems which don't support sparse files, Ocfs2_map_page_blocks() was reading blocks on appending writes. This caused write performance to suffer dramatically. Fix this by detecting an appending write on a nonsparse fs and skipping the read. Signed-off-by: Mark Fasheh Signed-off-by: Greg Kroah-Hartman commit 0b81a81aecb120cff349eec24c2553e88c94991c Author: Tony Battersby Date: Tue Oct 16 22:29:52 2007 +0200 ide: fix serverworks.c UDMA regression patch 0c824b51b338c808de650b440ba5f9f4a725f7fc in mainline. The patch described by the following excerpt from ChangeLog-2.6.22 makes it impossible to use UDMA on a Tyan S2707 motherboard (SvrWks CSB5): commit 2d5eaa6dd744a641e75503232a01f52d0768884c Author: Bartlomiej Zolnierkiewicz Date: Thu May 10 00:01:08 2007 +0200 ide: rework the code for selecting the best DMA transfer mode (v3) ... This one-line patch against 2.6.23 fixes the problem. Signed-off-by: Tony Battersby Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit d1eb63c36f6476c83af56aab06bec0680b9de459 Author: Karsten Keil Date: Thu Oct 18 03:04:31 2007 -0700 i4l: fix random freezes with AVM B1 drivers patch 9713d9e650045f7f2afd81d58a068827be306993 in mainline. This fix the same issue which was debbuged for the C4 controller for the B1 versions. The capilib_ function modify or traverse a linked list without locking. This patch extends the existing locking to the calls of these function to prevent access to a list which is in the middle of a modification. Signed-off-by: Karsten Keil Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0778a8974c2a8088cece925034edad871afde9a9 Author: Karsten Keil Date: Thu Oct 18 03:04:32 2007 -0700 i4l: Fix random hard freeze with AVM c4 card patch 1ccfd63367c1a6aaf8b33943f18856dde85f2f0b in mainline. The patch - Includes the call to capilib_data_b3_req in the spinlock. This routine in turn calls the offending mq_enqueue routine that triggered the freeze if not locked. This should also fix other indicators of incosistent capilib_msgidqueue list, that trigger messages like: Oct 5 03:05:57 BERL0 kernel: kcapi: msgid 3019 ncci 0x30301 not on queue that we saw several times a day (usually several in a row). - Fixes all occurrences of c4_dispatch_tx to be called with active spinlock, there were some instances where no lock was active. Mostly these are in very infrequently called routines, so the additional performance penalty is minimal. Signed-off-by: Karsten Keil Signed-off-by: Rainer Brestan Signed-off-by: Ralf Schlatterbeck Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0afc57fe16f55c446f7d421f84e3c7cf0a938777 Author: Alan Stern Date: Fri Oct 12 15:19:14 2007 -0700 USB: mutual exclusion for EHCI init and port resets patch 32fe01985aa2cb2562f6fc171e526e279abe10db in mainline. This patch (as999) fixes a problem that sometimes shows up when host controller driver modules are loaded in the wrong order. If ehci-hcd happens to initialize an EHCI controller while the companion OHCI or UHCI controller is in the middle of a port reset, the reset can fail and the companion may get very confused. The patch adds an rw-semaphore and uses it to keep EHCI initialization and port resets mutually exclusive. Signed-off-by: Alan Stern Acked-by: David Brownell Cc: David Miller Cc: Dely L Sy Signed-off-by: Greg Kroah-Hartman commit 12a245310134c88936581be7be9d08afc847120f Author: Jiri Kosina Date: Sat Oct 20 00:05:19 2007 +0200 USB: usbserial - fix potential deadlock between write() and IRQ patch acd2a847e7fee7df11817f67dba75a2802793e5d in mainline. USB: usbserial - fix potential deadlock between write() and IRQ usb_serial_generic_write() doesn't disable interrupts when taking port->lock, and could therefore deadlock with usb_serial_generic_read_bulk_callback() being called from interrupt, taking the same lock. Fix it. Signed-off-by: Jiri Kosina Acked-by: Larry Finger Cc: Marcin Slusarz Signed-off-by: Greg Kroah-Hartman commit 9c560a68b8e6bbec2608cc4dac0b5c8028e0c255 Author: Frank Seidel Date: Fri Nov 9 19:44:40 2007 +0100 USB: kobil_sct: trivial backport to fix libct Backport of a patch by Alan Cox in the kernel tree with commit 94d0f7eac77a84da2cee41b8038796891f75f09e Original comments: USB: kobil_sct: Rework driver No hardware but this driver is currently totally broken so we can't make it much worse. Remove all tbe broken invalid termios handling and replace it with a proper set_termios method. Frank's comments: Without this patch the userspace libct (to access the cardreader) segfaults. Signed-off-by: Frank Seidel Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman commit dd2ee9fbafad8ec8b5f5c0b325d149c168b42155 Author: HighPoint Linux Team Date: Tue Oct 16 14:28:24 2007 -0700 hptiop: avoid buffer overflow when returning sense data patch 0fec02c93f60fb44ba3a24a0d3e4a52521d34d3f in mainline. avoid buffer overflow when returning sense data. With current adapter firmware the driver is working but future firmware updates may return sense data larger than 96 bytes, causing overflow on scp->sense_buffer and a kernel crash. This fix should be backported to earlier kernels. Signed-off-by: HighPoint Linux Team Signed-off-by: James Bottomley Signed-off-by: Andrew Morton Acked-by: Matthew Wilcox Signed-off-by: Greg Kroah-Hartman commit 5120a468e1b3a7d01bb043884ed377ff1c0cc653 Author: Manfred Spraul Date: Wed Oct 17 21:52:33 2007 +0200 forcedeth msi bugfix patch a7475906bc496456ded9e4b062f94067fb93057a in mainline. pci_enable_msi() replaces the INTx irq number in pci_dev->irq with the new MSI irq number. The forcedeth driver did not update the copy in netdevice->irq and parts of the driver used the stale copy. See bugzilla.kernel.org, bug 9047. The patch - updates netdevice->irq - replaces all accesses to netdevice->irq with pci_dev->irq. The patch is against 2.6.23.1. IMHO suitable for both 2.6.23 and 2.6.24 Signed-off-by: Manfred Spraul Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 05fa45dfe7e4fae1601568064e666b946cf9c308 Author: Takashi Iwai Date: Mon Oct 15 14:37:11 2007 +0200 ALSA: hda-codec - Add array terminator for dmic in STAC codec patch f6e9852ad05fa28301c83d4e2b082620de010358 in mainline. [ALSA] hda-codec - Add array terminator for dmic in STAC codec Reported by Jan-Marek Glogowski. The dmic array is passed to snd_hda_parse_pin_def_config() and should be zero-terminated. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 51303d2171ec5bdf448f820ccec0224e854e61df Author: Takashi Iwai Date: Tue Oct 16 14:26:32 2007 +0200 ALSA: hdsp - Fix zero division patch 2a3988f6d2c5be9d02463097775d1c66a8290527 in mainline. Fix zero-division bug in the calculation dds offset. Signed-off-by: Takashi Iwai Signed-off-by: Jaroslav Kysela Cc: Maarten Bressers Cc: gentoo kernel Signed-off-by: Greg Kroah-Hartman commit 6c7ad737a3134d1b778bf60e7e4b323d662dfadd Author: Herbert Xu Date: Tue Nov 13 02:48:28 2007 -0800 Fix crypto_alloc_comp() error checking. [IPSEC]: Fix crypto_alloc_comp error checking [ Upstream commit: 4999f3621f4da622e77931b3d33ada6c7083c705 ] The function crypto_alloc_comp returns an errno instead of NULL to indicate error. So it needs to be tested with IS_ERR. This is based on a patch by Vicenç Beltran Querol. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3040f0698e8504e91603ddaea777107d68f91c99 Author: Radu Rendec Date: Tue Nov 13 00:09:56 2007 -0800 Fix endianness bug in U32 classifier. changeset 543821c6f5dea5221426eaf1eac98b100249c7ac in mainline. [PKT_SCHED] CLS_U32: Fix endianness problem with u32 classifier hash masks. While trying to implement u32 hashes in my shaping machine I ran into a possible bug in the u32 hash/bucket computing algorithm (net/sched/cls_u32.c). The problem occurs only with hash masks that extend over the octet boundary, on little endian machines (where htonl() actually does something). Let's say that I would like to use 0x3fc0 as the hash mask. This means 8 contiguous "1" bits starting at b6. With such a mask, the expected (and logical) behavior is to hash any address in, for instance, 192.168.0.0/26 in bucket 0, then any address in 192.168.0.64/26 in bucket 1, then 192.168.0.128/26 in bucket 2 and so on. This is exactly what would happen on a big endian machine, but on little endian machines, what would actually happen with current implementation is 0x3fc0 being reversed (into 0xc03f0000) by htonl() in the userspace tool and then applied to 192.168.x.x in the u32 classifier. When shifting right by 16 bits (rank of first "1" bit in the reversed mask) and applying the divisor mask (0xff for divisor 256), what would actually remain is 0x3f applied on the "168" octet of the address. One could say is this can be easily worked around by taking endianness into account in userspace and supplying an appropriate mask (0xfc03) that would be turned into contiguous "1" bits when reversed (0x03fc0000). But the actual problem is the network address (inside the packet) not being converted to host order, but used as a host-order value when computing the bucket. Let's say the network address is written as n31 n30 ... n0, with n0 being the least significant bit. When used directly (without any conversion) on a little endian machine, it becomes n7 ... n0 n8 ..n15 etc in the machine's registers. Thus bits n7 and n8 would no longer be adjacent and 192.168.64.0/26 and 192.168.128.0/26 would no longer be consecutive. The fix is to apply ntohl() on the hmask before computing fshift, and in u32_hash_fold() convert the packet data to host order before shifting down by fshift. With helpful feedback from Jamal Hadi Salim and Jarek Poplawski. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2c41b3c3f54193a93284ca314784d1c6da39ecdc Author: David Miller Date: Tue Nov 13 00:02:56 2007 -0800 Fix error returns in sys_socketpair() patch bf3c23d171e35e6e168074a1514b0acd59cfd81a in mainline. [NET]: Fix error reporting in sys_socketpair(). If either of the two sock_alloc_fd() calls fail, we forget to update 'err' and thus we'll erroneously return zero in these cases. Based upon a report and patch from Rich Paul, and commentary from Chuck Ebbert. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d6eb5c86ed40fe57e411c4ee72b38d0a83642302 Author: Patrick McHardy Date: Tue Nov 13 03:03:00 2007 -0800 Fix netlink timeouts. [NETLINK]: Fix unicast timeouts [ Upstream commit: c3d8d1e30cace31fed6186a4b8c6b1401836d89c ] Commit ed6dcf4a in the history.git tree broke netlink_unicast timeouts by moving the schedule_timeout() call to a new function that doesn't propagate the remaining timeout back to the caller. This means on each retry we start with the full timeout again. ipc/mqueue.c seems to actually want to wait indefinitely so this behaviour is retained. Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2d23541246308b5d2867c6592ad2b09e9a1ae344 Author: Evgeniy Polyakov Date: Tue Nov 13 00:07:45 2007 -0800 Fix TEQL oops. [PKT_SCHED]: Fix OOPS when removing devices from a teql queuing discipline [ Upstream commit: 4f9f8311a08c0d95c70261264a2b47f2ae99683a ] tecl_reset() is called from deactivate and qdisc is set to noop already, but subsequent teql_xmit does not know about it and dereference private data as teql qdisc and thus oopses. not catch it first :) Signed-off-by: Evgeniy Polyakov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5263c68d8f067f8bc4f6dd8bfb4ceb547d60fe7c Author: Jozsef Kadlecsik Date: Mon Nov 5 12:37:55 2007 +0100 NETFILTER: nf_conntrack_tcp: fix connection reopening Upstream commits: 17311393 + bc34b841 merged together. Merge done by Patrick McHardy [NETFILTER]: nf_conntrack_tcp: fix connection reopening With your description I could reproduce the bug and actually you were completely right: the code above is incorrect. Somehow I was able to misread RFC1122 and mixed the roles :-(: When a connection is >>closed actively<<, it MUST linger in TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime). However, it MAY >>accept<< a new SYN from the remote TCP to reopen the connection directly from TIME-WAIT state, if it: [...] The fix is as follows: if the receiver initiated an active close, then the sender may reopen the connection - otherwise try to figure out if we hold a dead connection. Signed-off-by: Jozsef Kadlecsik Tested-by: Krzysztof Piotr Oledzki Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 79d84e19d774dd71757b9dff90179ae593eaf550 Author: Jan Kiszka Date: Wed Nov 14 17:00:08 2007 -0800 fix param_sysfs_builtin name length check patch 22800a2830ec07e7cc5c837999890ac47cc7f5de in mainline. Commit faf8c714f4508207a9c81cc94dafc76ed6680b44 caused a regression: parameter names longer than MAX_KBUILD_MODNAME will now be rejected, although we just need to keep the module name part that short. This patch restores the old behaviour while still avoiding that memchr is called with its length parameter larger than the total string length. Signed-off-by: Jan Kiszka Cc: Dave Young Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit fed521206dfc72e75c8307e7cde8475a65385d9d Author: Hugh Dickins Date: Mon Oct 29 14:37:20 2007 -0700 fix tmpfs BUG and AOP_WRITEPAGE_ACTIVATE patch 487e9bf25cbae11b131d6a14bdbb3a6a77380837 in mainline. It's possible to provoke unionfs (not yet in mainline, though in mm and some distros) to hit shmem_writepage's BUG_ON(page_mapped(page)). I expect it's possible to provoke the 2.6.23 ecryptfs in the same way (but the 2.6.24 ecryptfs no longer calls lower level's ->writepage). This came to light with the recent find that AOP_WRITEPAGE_ACTIVATE could leak from tmpfs via write_cache_pages and unionfs to userspace. There's already a fix (e423003028183df54f039dfda8b58c49e78c89d7 - writeback: don't propagate AOP_WRITEPAGE_ACTIVATE) in the tree for that, and it's okay so far as it goes; but insufficient because it doesn't address the underlying issue, that shmem_writepage expects to be called only by vmscan (relying on backing_dev_info capabilities to prevent the normal writeback path from ever approaching it). That's an increasingly fragile assumption, and ramdisk_writepage (the other source of AOP_WRITEPAGE_ACTIVATEs) is already careful to check wbc->for_reclaim before returning it. Make the same check in shmem_writepage, thereby sidestepping the page_mapped BUG also. Signed-off-by: Hugh Dickins Cc: Erez Zadok Reviewed-by: Pekka Enberg Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b2e5acb6fa62e0907b16ef5373cc3e8bb93c078b Author: Andrew Morton Date: Tue Oct 16 23:18:32 2007 -0700 writeback: don't propagate AOP_WRITEPAGE_ACTIVATE patch e423003028183df54f039dfda8b58c49e78c89d7 in mainline. This is a writeback-internal marker but we're propagating it all the way back to userspace!. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e8b00d71ad9f833cc4e002e3ad853d078f4bc2dc Author: Dave Johnson Date: Tue Oct 23 22:37:22 2007 +0200 x86: fix TSC clock source calibration error patch edaf420fdc122e7a42326fe39274c8b8c9b19d41 in mainline. I ran into this problem on a system that was unable to obtain NTP sync because the clock was running very slow (over 10000ppm slow). ntpd had declared all of its peers 'reject' with 'peer_dist' reason. On investigation, the tsc_khz variable was significantly incorrect causing xtime to run slow. After a reboot tsc_khz was correct so I did a reboot test to see how often the problem occurred: Test was done on a 2000 Mhz Xeon system. Of 689 reboots, 8 of them had unacceptable tsc_khz values (>500ppm): range of tsc_khz # of boots % of boots ---------------- ---------- ---------- < 1999750 0 0.000% 1999750 - 1999800 21 3.048% 1999800 - 1999850 166 24.128% 1999850 - 1999900 241 35.029% 1999900 - 1999950 211 30.669% 1999950 - 2000000 42 6.105% 2000000 - 2000000 0 0.000% 2000050 - 2000100 0 0.000% [...] 2000100 - 2015000 1 0.145% << BAD 2015000 - 2030000 6 0.872% << BAD 2030000 - 2045000 1 0.145% << BAD 2045000 < 0 0.000% The worst boot was 2032.577 Mhz, over 1.5% off! It appears that on rare occasions, mach_countup() is taking longer to complete than necessary. I suspect that this is caused by the CPU taking a periodic SMI interrupt right at the end of the 30ms calibration loop. This would cause the loop to delay while the SMI BIOS hander runs. The resulting TSC value is beyond what it actually should be resulting in a higher tsc_khz. The below patch makes native_calculate_cpu_khz() take the best (shortest duration, lowest khz) run of it's 3 calibration loops. If a SMI goes off causing a bad result (long duration, higher khz) it will be discarded. With the patch applied, 300 boots of the same system produce good results: range of tsc_khz # of boots % of boots ---------------- ---------- ---------- < 1999750 0 0.000% 1999750 - 1999800 30 10.000% 1999800 - 1999850 166 55.333% 1999850 - 1999900 89 29.667% 1999900 - 1999950 15 5.000% 1999950 < 0 0.000% Problem was found and tested against 2.6.18. Patch is against 2.6.22. Signed-off-by: Dave Johnson Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 52c7418eff50d66116b94c6e0a3cb08651dc49c3 Author: David Miller Date: Mon Nov 12 23:59:05 2007 -0800 Fix compat futex hangs. [FUTEX]: Fix address computation in compat code. [ Upstream commit: 3c5fd9c77d609b51c0bab682c9d40cbb496ec6f1 ] compat_exit_robust_list() computes a pointer to the futex entry in userspace as follows: (void __user *)entry + futex_offset 'entry' is a 'struct robust_list __user *', and 'futex_offset' is a 'compat_long_t' (typically a 's32'). Things explode if the 32-bit sign bit is set in futex_offset. Type promotion sign extends futex_offset to a 64-bit value before adding it to 'entry'. This triggered a problem on sparc64 running 32-bit applications which would lock up a cpu looping forever in the fault handling for the userspace load in handle_futex_death(). Compat userspace runs with address masking (wherein the cpu zeros out the top 32-bits of every effective address given to a memory operation instruction) so the sparc64 fault handler accounts for this by zero'ing out the top 32-bits of the fault address too. Since the kernel properly uses the compat_uptr interfaces, kernel side accesses to compat userspace work too since they will only use addresses with the top 32-bit clear. Because of this compat futex layer bug we get into the following loop when executing the get_user() load near the top of handle_futex_death(): 1) load from address '0xfffffffff7f16bd8', FAULT 2) fault handler clears upper 32-bits, processes fault for address '0xf7f16bd8' which succeeds 3) goto #1 I want to thank Bernd Zeimetz, Josip Rodin, and Fabio Massimo Di Nitto for their tireless efforts helping me track down this bug. Signed-off-by: David S. Miller Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 06283bea26adeb6dfa421419d2aa3979d63e50f1 Author: Christoph Lameter Date: Mon Nov 5 11:23:51 2007 -0800 SLUB: Fix memory leak by not reusing cpu_slab backport of 05aa345034de6ae9c77fb93f6a796013641d57d5 from Linus's tree. SLUB: Fix memory leak by not reusing cpu_slab Fix the memory leak that may occur when we attempt to reuse a cpu_slab that was allocated while we reenabled interrupts in order to be able to grow a slab cache. The per cpu freelist may contain objects and in that situation we may overwrite the per cpu freelist pointer loosing objects. This only occurs if we find that the concurrently allocated slab fits our allocation needs. If we simply always deactivate the slab then the freelist will be properly reintegrated and the memory leak will go away. Signed-off-by: Christoph Lameter Cc: Hugh Dickins Signed-off-by: Greg Kroah-Hartman