commit a82a9bfebc74862798a3f6949fe6f6a959c1fd4e Author: Greg Kroah-Hartman Date: Thu May 15 08:00:12 2008 -0700 Linux 2.6.25.4 commit 15c2419876173c417a119b5665ecc62520e50a6c Author: Dan Williams Date: Tue May 13 19:10:11 2008 +0000 md: fix raid5 'repair' operations commit c8894419acf5e56851de9741c5047bebd78acd1f upstream Date: Mon, 12 May 2008 14:02:12 -0700 Subject: md: fix raid5 'repair' operations commit bd2ab67030e9116f1e4aae1289220255412b37fd "md: close a livelock window in handle_parity_checks5" introduced a bug in handling 'repair' operations. After a repair operation completes we clear the state bits tracking this operation. However, they are cleared too early and this results in the code deciding to re-run the parity check operation. Since we have done the repair in memory the second check does not find a mismatch and thus does not do a writeback. Test results: $ echo repair > /sys/block/md0/md/sync_action $ cat /sys/block/md0/md/mismatch_cnt 51072 $ echo repair > /sys/block/md0/md/sync_action $ cat /sys/block/md0/md/mismatch_cnt 0 (also fix incorrect indentation) Tested-by: George Spelvin Acked-by: NeilBrown Signed-off-by: Dan Williams Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 69ad365afb26fa2ac1bdb4b166b6cc231251edd8 Author: Maciej W. Rozycki Date: Tue May 13 19:10:10 2008 +0000 rtc: rtc_time_to_tm: use unsigned arithmetic commit 945185a69daa457c4c5e46e47f4afad7dcea734f upstream Date: Mon, 12 May 2008 14:02:24 -0700 Subject: rtc: rtc_time_to_tm: use unsigned arithmetic The input argument to rtc_time_to_tm() is unsigned as well as are members of the output structure. However signed arithmetic is used within for calculations leading to incorrect results for input values outside the signed positive range. If this happens the time of day returned is out of range. Found the problem when fiddling with the RTC and the driver where year was set to an unexpectedly large value like 2070, e.g.: rtc0: setting system clock to 2070-01-01 1193046:71582832:26 UTC (3155760954) while it should be: rtc0: setting system clock to 2070-01-01 00:15:54 UTC (3155760954) Changing types to unsigned fixes the problem. [akpm@linux-foundation.org: remove old-fashioned `register' keyword] Signed-off-by: Maciej W. Rozycki Cc: Alessandro Zummo Cc: David Brownell Cc: Dmitri Vorobiev Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6cbde20dcd3ea3df46ac545d59fc4da6b1e9487a Author: James Bottomley Date: Tue May 13 19:10:24 2008 +0000 SCSI: aha152x: fix init suspiciously returned 1, it should follow 0/-E convention commit ad2fa42d044b98469449880474a9662fb689f7f9 upstream Reported-by: Frank de Jong > [1.] One line summary of the problem: > linux-2.6.25.3, aha152x'->init suspiciously returned 1, it should > follow 0/-E convention. The module / driver works okay. Unloading the > module is impossible. The driver is apparently returning 0 on failure and 1 on success. That's a bit unfortunate. Fix it by altering to -ENODEV and 0. Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 22f995e70a88761b1f15cb0bec8eb79ccf7e0a60 Author: James Bottomley Date: Tue May 13 19:10:15 2008 +0000 SCSI: aha152x: Fix oops on module removal commit 64976a0387835a7ac61bbe2a99b27ccae34eac5d upstream Reported-by: Frank de Jong > after trying to unload the module: > BUG: unable to handle kernel paging request at 00100100 > IP: [] :aha152x:aha152x_exit+0x47/0x6a > *pde = 00000000 > Oops: 0000 [#1] PREEMPT SMP > Modules linked in: aha152x(-) w83781d hwmon_vid tun ne 8390 bonding > usb_storage snd_usb_audio snd_usb_lib snd_rawmidi pwc snd_seq_device > compat_ioctl32 snd_hwdep videodev v4l1_compat 3c59x mii intel_agp > agpgart snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd > > Pid: 2837, comm: rmmod Not tainted (2.6.25.3 #1) > EIP: 0060:[] EFLAGS: 00210212 CPU: 0 > EIP is at aha152x_exit+0x47/0x6a [aha152x] > EAX: 00000001 EBX: 000ffdc4 ECX: f7c517a8 EDX: 00000001 > ESI: 00000000 EDI: 00000003 EBP: e7880000 ESP: e7881f58 > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > Process rmmod (pid: 2837, ti=e7880000 task=f27eb580 task.ti=e7880000) > Stack: fba03700 c01419d2 31616861 00783235 e795ee70 c0157709 b7f24000 e79ae000 > c0158271 ffffffff b7f25000 e79ae004 e795e370 b7f25000 e795e37c e795e370 > 009ae000 fba03700 00000880 e7881fa8 00000000 bf93ec20 bf93ec20 c0102faa > Call Trace: > [] sys_delete_module+0x112/0x1a0 > [] remove_vma+0x39/0x50 > [] do_munmap+0x181/0x1f0 > [] sysenter_past_esp+0x5f/0x85 > [] rsc_parse+0x0/0x3c0 The problem is that the driver calls aha152x_release() under a list_for_each_entry(). Unfortunately, aha152x_release() deletes from the list in question. Fix this by using list_for_each_entry_safe(). Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit bfee08b351f67cf73aa87dce89aa56c0987b609c Author: Mike Christie Date: Tue May 13 19:10:25 2008 +0000 SCSI: libiscsi regression in 2.6.25: fix setting of recv timer commit c8611f975403dd20e6503aff8aded5dcb718f75b upstream If the ping tmo is longer than the recv tmo then we could miss a window where we were supposed to check the recv tmo. This happens because the ping code will set the next timeout for the ping timeout, and if the ping executes quickly there will be a long chunk of time before the timer wakes up again. This patch has the ping processing code kick off a recv tmo check when getting a nop in response to our ping. Signed-off-by: Mike Christie Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 0383bf8c3b248f928e3df05f78466a2e96169f10 Author: Mike Christie Date: Tue May 13 19:10:30 2008 +0000 SCSI: libiscsi regression in 2.6.25: fix nop timer handling commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream The following patch fixes a bug in the iscsi nop processing. The target sends iscsi nops to ping the initiator and the initiator has to send nops to reply and can send nops to ping the target. In 2.6.25 we moved the nop processing to the kernel to handle problems when the userspace daemon is not up, but the target is pinging us, and to handle when scsi commands timeout, but the transport may be the cause (we can send a nop to check the transport). When we added this code we added a bug where if the transport timer wakes at the exact same time we are supposed to check for a nop timeout we drop the session instead of checking the transport. This patch checks if a iscsi ping is outstanding and if the ping has timed out, to determine if we need to signal a connection problem. Signed-off-by: Mike Christie Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 76188088d6cbef84417e0a762c68de5801cb135c Author: Jeremy Higdon Date: Tue May 13 19:10:09 2008 +0000 SCSI: qla1280: Fix queue depth problem commit af5741c6de4f4a1d8608b0f00867c77cb7123635 upstream The qla1280 driver was ANDing the output value of mailbox register 0 with (1 << target-number) to determine whether to enable queueing on the target in question. But mailbox register 0 has the status code for the mailbox command (in this case, Set Target Parameters). Potential values are: /* * ISP mailbox command complete status codes */ So clearly that is in error. I can't think what the author of that line was looking for in a mailbox register, so I just eliminated the AND. flag is used later in the function, and I think that the later usage was also wrong, though it was used to set values that aren't used. Oh well, an overhaul of this driver is not what I want to do now -- just a bugfix. After the fix, I found that my disks were getting a queue depth of 255, which is far too many. Most SCSI disks are limited to 32 or 64. In any case, there's no point, queueing up a bunch of commands to the adapter that will just result in queue full or starve other targets from being issued commands due to running out of internal memory. So I dropped default queue depth to 32 (from which 1 is subtracted elsewhere, giving net of 31). I tested with a Seagate ST336753LC, and results look good, so I'm satisfied with this patch. Signed-off-by: Jeremy Higdon Acked-by: Jes Sorensen Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 05d5b6cf37de1a9ceb873b770de113861a5b3df9 Author: Ivan Vecera Date: Sun May 11 11:00:53 2008 +0200 r8169: fix oops in r8169_get_mac_version commit 21e197f231343201368338603cb0909a13961bac upstream. r8169_get_mac_version crashes when it meets an unknown MAC due to tp->pci_dev not being set. Initialize it early. Signed-off-by: Ivan Vecera Acked-by: Francois Romieu Signed-off-by: Greg Kroah-Hartman commit fa5c104c2465470dc316bf211257f9e67e0ba602 Author: Roel Kluin <12o3l@tiscali.nl> Date: Sun May 11 10:59:44 2008 +0200 r8169: fix past rtl_chip_info array size for unknown chipsets commit cee60c377de6d9d10f0a2876794149bd79a15020 upstream. 'i' is unsigned. Signed-off-by: Roel Kluin <12o3l@tiscali.nl> Acked-by: Francois Romieu Signed-off-by: Greg Kroah-Hartman commit cfa4a0793f4bc4a6ab83657612b88b266d43b5ab Author: Leonardo Chiquitto Date: Tue Apr 22 16:02:03 2008 -0300 USB: airprime: unlock mutex instead of trying to lock it again commit 21ae1dd1d4948968ad2d923c5e104d38fb35b4e4 upstream The following patch fixes a [probable] copy & paste mistake in airprime.c. Instead of unlocking an acquired mutex, the actual code tries to lock it again. Signed-off-by: Leonardo Chiquitto Signed-off-by: Greg Kroah-Hartman commit 7d33036198e7c7e0c298dc447aa355f18840120b Author: David S. Miller Date: Sat May 10 00:31:28 2008 -0700 sparc32: Don't twiddle PT_DTRACE in exec. [ Upstream commit: c07c6053c41f736711ed856aa377007078c7c396 ] That bit isn't used on this platform. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b6c84db1836c4af6c84d2e6d69c060354ff0d9e0 Author: David S. Miller Date: Sun May 11 19:35:21 2008 -0700 sparc: Fix debugger syscall restart interactions. [ This is a 2.6.25 backport of upstream changeset 28e6103665301ce60634e8a77f0b657c6cc099de with sparc32 build fixes from Robert Reif ] So, forever, we've had this ptrace_signal_deliver implementation which tries to handle all of the nasties that can occur when the debugger looks at a process about to take a signal. It's meant to address all of these issues inside of the kernel so that the debugger need not be mindful of such things. Problem is, this doesn't work. The idea was that we should do the syscall restart business first, so that the debugger captures that state. Otherwise, if the debugger for example saves the child's state, makes the child execute something else, then restores the saved state, we won't handle the syscall restart properly because we lose the "we're in a syscall" state. The code here worked for most cases, but if the debugger actually passes the signal through to the child unaltered, it's possible that we would do a syscall restart when we shouldn't have. In particular this breaks the case of debugging a process under a gdb which is being debugged by yet another gdb. gdb uses sigsuspend to wait for SIGCHLD of the inferior, but if gdb itself is being debugged by a top-level gdb we get a ptrace_stop(). The top-level gdb does a PTRACE_CONT with SIGCHLD to let the inferior gdb see the signal. But ptrace_signal_deliver() assumed the debugger would cancel out the signal and therefore did a syscall restart, because the return error was ERESTARTNOHAND. Fix this by simply making ptrace_signal_deliver() a nop, and providing a way for the debugger to control system call restarting properly: 1) Report a "in syscall" software bit in regs->{tstate,psr}. It is set early on in trap entry to a system call and is fully visible to the debugger via ptrace() and regsets. 2) Test this bit right before doing a syscall restart. We have to do a final recheck right after get_signal_to_deliver() in case the debugger cleared the bit during ptrace_stop(). 3) Clear the bit in trap return so we don't accidently try to set that bit in the real register. As a result we also get a ptrace_{is,clear}_syscall() for sparc32 just like sparc64 has. M68K has this same exact bug, and is now the only other user of the ptrace_signal_deliver hook. It needs to be fixed in the same exact way as sparc. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 385a8d8adfdd806bda12128c3744b564ec112293 Author: David S. Miller Date: Mon May 12 16:33:33 2008 -0700 sparc: Fix mremap address range validation. Just like mmap, we need to validate address ranges regardless of MAP_FIXED. sparc{,64}_mmap_check()'s flag argument is unused, remove. Based upon a report and preliminary patch by Jan Lieskovsky Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7b361918258d2477d046af7710a518fda99adffa Author: David S. Miller Date: Sat May 10 21:11:23 2008 -0700 sparc: Fix ptrace() detach. [ Upstream commit: 986bef854fab44012df678a5b51817d5274d3ca1 ] Forever we had a PTRACE_SUNOS_DETACH which was unconditionally recognized, regardless of the personality of the process. Unfortunately, this value is what ended up in the GLIBC sys/ptrace.h header file on sparc as PTRACE_DETACH and PT_DETACH. So continue to recognize this old value. Luckily, it doesn't conflict with anything we actually care about. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 613398c3eeeacc658cca08b9637f93ece509a3e1 Author: Jean Delvare Date: Mon May 12 16:21:24 2008 +0200 i2c-piix4: Blacklist two mainboards commit c2fc54fcd340cbee47510aa84c346aab3440ba09 upstream We had a report that running sensors-detect on a Sapphire AM2RD790 motherbord killed the CPU. While the exact cause is still unknown, I'd rather play it safe and prevent any access to the SMBus on that machine by not letting the i2c-piix4 driver attach to the SMBus host device on that machine. Also blacklist a similar board made by DFI. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit d4b128ea3a055225b248383ad3eb0d6248aaec23 Author: Vaidyanathan Srinivasan Date: Sun May 11 04:20:09 2008 +0000 x86: sysfs cpu?/topology is empty in 2.6.25 (32-bit Intel system) commit 5c3a121d52b30a1e53cdaa802fa1965fcd243164 upstream System topology on intel based system needs to be exported for non-numa case as well. All parts of asm-i386/topology.h has come under #ifdef CONFIG_NUMA after the merge to asm-x86/topology.h /sys/devices/system/cpu/cpu?/topology/* is populated based on ENABLE_TOPO_DEFINES The sysfs cpu topology is not being populated on my dual socket dual core xeon 5160 processor based (x86 32 bit) system. CONFIG_NUMA is not set in my case yet the topology is relevant and useful. irqbalance daemon application depends on topology to build the cpus and package list and it fails on Fedora9 beta since the sysfs topology was not being populated in the 2.6.25 kernel. I am not sure if it was intentional to not define ENABLE_TOPO_DEFINES for non-numa systems. This fix has been tested on the above mentioned dual core, dual socket system. Signed-off-by: Vaidyanathan Srinivasan Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 0bd377504a5c62a307159a70320dab55382bf622 Author: Tejun Heo Date: Tue May 13 17:23:38 2008 +0900 ata_piix: verify SIDPR access before enabling it commit cb6716c879ecf49e2af344926c6a476821812061 upstream On certain configurations (certain macbooks), even though all the conditions for SIDPR access described in the datasheet are met, actually reading those registers just returns 0 and have no effect on write. Verify SIDPR is actually working before enabling it. This is reported by Ryan Roth in bz#10512. Signed-off-by: Tejun Heo Cc: Ryan Roth Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 6f01b186b0b6a97707dfa547b03cfadc54a045f1 Author: Arnaud Ebalard Date: Tue May 13 13:39:16 2008 +0200 {nfnetlink, ip, ip6}_queue: fix skb_over_panic when enlarging packets [NETFILTER]: {nfnetlink,ip,ip6}_queue: fix skb_over_panic when enlarging packets From: Arnaud Ebalard Upstream commit 9a732ed6d: While reinjecting *bigger* modified versions of IPv6 packets using libnetfilter_queue, things work fine on a 2.6.24 kernel (2.6.22 too) but I get the following on recents kernels (2.6.25, trace below is against today's net-2.6 git tree): skb_over_panic: text:c04fddb0 len:696 put:632 head:f7592c00 data:f7592c00 tail:0xf7592eb8 end:0xf7592e80 dev:eth0 ------------[ cut here ]------------ invalid opcode: 0000 [#1] PREEMPT Process sendd (pid: 3657, ti=f6014000 task=f77c31d0 task.ti=f6014000) Stack: c071e638 c04fddb0 000002b8 00000278 f7592c00 f7592c00 f7592eb8 f7592e80 f763c000 f6bc5200 f7592c40 f6015c34 c04cdbfc f6bc5200 00000278 f6015c60 c04fddb0 00000020 f72a10c0 f751b420 00000001 0000000a 000002b8 c065582c Call Trace: [] ? nfqnl_recv_verdict+0x1c0/0x2e0 [] ? skb_put+0x3c/0x40 [] ? nfqnl_recv_verdict+0x1c0/0x2e0 [] ? nfnetlink_rcv_msg+0xf5/0x160 [] ? nfnetlink_rcv_msg+0x1e/0x160 [] ? nfnetlink_rcv_msg+0x0/0x160 [] ? netlink_rcv_skb+0x77/0xa0 [] ? nfnetlink_rcv+0x1c/0x30 [] ? netlink_unicast+0x243/0x2b0 [] ? memcpy_fromiovec+0x4a/0x70 [] ? netlink_sendmsg+0x1c6/0x270 [] ? sock_sendmsg+0xc4/0xf0 [] ? set_next_entity+0x1d/0x50 [] ? autoremove_wake_function+0x0/0x40 [] ? __wake_up_common+0x3e/0x70 [] ? n_tty_receive_buf+0x34f/0x1280 [] ? __wake_up+0x68/0x70 [] ? copy_from_user+0x37/0x70 [] ? verify_iovec+0x2c/0x90 [] ? sys_sendmsg+0x10a/0x230 [] ? __dequeue_entity+0x2a/0xa0 [] ? set_next_entity+0x1d/0x50 [] ? pty_write+0x47/0x60 [] ? tty_default_put_char+0x1b/0x20 [] ? __wake_up+0x49/0x70 [] ? tty_ldisc_deref+0x39/0x90 [] ? tty_write+0x1a0/0x1b0 [] ? sys_socketcall+0x7f/0x260 [] ? sysenter_past_esp+0x6a/0x91 [] ? snd_intel8x0m_probe+0x270/0x6e0 ======================= Code: 00 00 89 5c 24 14 8b 98 9c 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 50 89 4c 24 04 c7 04 24 38 e6 71 c0 89 44 24 08 e8 c4 46 c5 ff <0f> 0b eb fe 55 89 e5 56 89 d6 53 89 c3 83 ec 0c 8b 40 50 39 d0 EIP: [] skb_over_panic+0x5c/0x60 SS:ESP 0068:f6015bf8 Looking at the code, I ended up in nfq_mangle() function (called by nfqnl_recv_verdict()) which performs a call to skb_copy_expand() due to the increased size of data passed to the function. AFAICT, it should ask for 'diff' instead of 'diff - skb_tailroom(e->skb)'. Because the resulting sk_buff has not enough space to support the skb_put(skb, diff) call a few lines later, this results in the call to skb_over_panic(). The patch below asks for allocation of a copy with enough space for mangled packet and the same amount of headroom as old sk_buff. While looking at how the regression appeared (e2b58a67), I noticed the same pattern in ipq_mangle_ipv6() and ipq_mangle_ipv4(). The patch corrects those locations too. Tested with bigger reinjected IPv6 packets (nfqnl_mangle() path), things are ok (2.6.25 and today's net-2.6 git tree). Signed-off-by: Arnaud Ebalard Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cc26d4771032bd678e38b89c7ae065d003ce23e1 Author: Philip Craig Date: Tue May 13 13:39:13 2008 +0200 nf_conntrack: padding breaks conntrack hash on ARM [NETFILTER]: nf_conntrack: padding breaks conntrack hash on ARM Upstream commit 443a70d50: commit 0794935e "[NETFILTER]: nf_conntrack: optimize hash_conntrack()" results in ARM platforms hashing uninitialised padding. This padding doesn't exist on other architectures. Fix this by replacing NF_CT_TUPLE_U_BLANK() with memset() to ensure everything is initialised. There were only 4 bytes that NF_CT_TUPLE_U_BLANK() wasn't clearing anyway (or 12 bytes on ARM). Signed-off-by: Philip Craig Signed-off-by: Patrick McHardy Signed-off-by: Greg Kroah-Hartman commit c5bf357f053bef23cd44ef700f8eceba71ce7328 Author: Sam Ravnborg Date: Sat May 10 20:07:32 2008 +0100 x86: use defconfigs from x86/configs/* commit b9b39bfba5b0de3418305f01cfa7bc55a16004e1 upstream x86: use defconfigs from x86/configs/* Daniel Drake reported: In 2.6.23, if you unpacked a kernel source tarball and then ran "make menuconfig" you'd be presented with this message: # using defaults found in arch/i386/defconfig and the default options would be set. The same thing in 2.6.24 does not give you any "using defaults" message, and the default config options within menuconfig are rather blank (e.g. no PCI support). You can work around this by explicitly running "make defconfig" before menuconfig, but it would be nice to have the behaviour the way it was for 2.6.23 (and the way it still is for other archs). Fixed by adding a x86 specific defconfig list to Kconfig. Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=10470 Tested-by: Daniel Drake Signed-off-by: Sam Ravnborg Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 15e31ad310ec9b245849ec6952c22217167cdf4a Author: Oliver Hartkopp Date: Thu May 8 02:49:55 2008 -0700 can: Fix can_send() handling on dev_queue_xmit() failures [ Upstream commit: c2ab7ac225e29006b7117d6a9fe8f3be8d98b0c2 ] The tx packet counting and the local loopback of CAN frames should only happen in the case that the CAN frame has been enqueued to the netdevice tx queue successfully. Thanks to Andre Naujoks for reporting this issue. Signed-off-by: Oliver Hartkopp Signed-off-by: Urs Thuermann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f96e856cd870007bb8f344e62eff228eba3f6989 Author: Chris Wright Date: Mon May 5 13:50:24 2008 -0700 dccp: return -EINVAL on invalid feature length [ Upstream commit: 19443178fbfbf40db15c86012fc37df1a44ab857 ] dccp_feat_change() validates length and on error is returning 1. This happens to work since call chain is checking for 0 == success, but this is returned to userspace, so make it a real error value. Signed-off-by: Chris Wright Acked-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dbfda7d328029421c1126423646e602c553ea2a2 Author: Julian Anastasov Date: Tue Apr 29 03:21:23 2008 -0700 ipvs: fix oops in backup for fwmark conn templates [ Upstream commit: 2ad17defd596ca7e8ba782d5fc6950ee0e99513c ] Fixes bug http://bugzilla.kernel.org/show_bug.cgi?id=10556 where conn templates with protocol=IPPROTO_IP can oops backup box. Result from ip_vs_proto_get() should be checked because protocol value can be invalid or unsupported in backup. But for valid message we should not fail for templates which use IPPROTO_IP. Also, add checks to validate message limits and connection state. Show state NONE for templates using IPPROTO_IP. Fix tested and confirmed by L0op8ack Signed-off-by: Julian Anastasov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 781ce5ffe1ff6b5b288575d4d42f46cb7a25b175 Author: Patrick McHardy Date: Thu May 8 01:13:31 2008 -0700 macvlan: Fix memleak on device removal/crash on module removal [ Upstream commit: 7312096454b6cd71267eaa3d0efb408e449e9ff3 ] As noticed by Ben Greear, macvlan crashes the kernel when unloading the module. The reason is that it tries to clean up the macvlan_port pointer on the macvlan device itself instead of the underlying device. A non-NULL pointer is taken as indication that the macvlan_handle_frame_hook is valid, when receiving the next packet on the underlying device it tries to call the NULL hook and crashes. Clean up the macvlan_port on the correct device to fix this. Signed-off-by; Patrick McHardy Tested-by: Ben Greear Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 734bf48fe5276f319464fd30dc4a046a29d2b94a Author: Jarek Poplawski Date: Sat May 3 20:46:29 2008 -0700 sch_htb: remove from event queue in htb_parent_to_leaf() [ Upstream commit: 3ba08b00e0d8413d79be9cab8ec085ceb6ae6fd6 ] There is lack of removing a class from the event queue while changing from parent to leaf which can cause corruption of this rb tree. This patch fixes a bug introduced by my patch: "sch_htb: turn intermediate classes into leaves" commit: 160d5e10f87b1dc88fd9b84b31b1718e0fd76398. Many thanks to Jan 'yanek' Bortl for finding a way to reproduce this rare bug and narrowing the test case, which made possible proper diagnosing. This patch is recommended for all kernels starting from 2.6.20. Reported-and-tested-by: Jan 'yanek' Bortl Signed-off-by: Jarek Poplawski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 428984c1c0dcbbb5b1409c4407f05f349e883681 Author: David S. Miller Date: Thu May 1 01:14:27 2008 -0700 serial: Fix sparc driver name strings. [ Upstream commit: b53e5216e5f73330bffae93b42dceb94e361f4c0 ] They were all "serial" so if multiple of these drivers registered, we'd trigger sysfs directory creation errors: [ 1.695793] proc_dir_entry 'serial' already registered [ 1.695839] Call Trace: [ 1.831891] [00000000004f2534] create_proc_entry+0x7c/0x98 [ 1.833608] [00000000004f3a58] proc_tty_register_driver+0x40/0x70 [ 1.833663] [0000000000594700] tty_register_driver+0x1fc/0x208 [ 1.835371] [00000000005aade4] uart_register_driver+0x134/0x16c [ 1.841762] [00000000005ac274] sunserial_register_minors+0x34/0x68 [ 1.841818] [00000000007db2a4] sunsu_init+0xf8/0x150 [ 1.867697] [00000000007c62a4] kernel_init+0x190/0x330 [ 1.939147] [0000000000426cf8] kernel_thread+0x38/0x48 [ 1.939198] [00000000006a0d90] rest_init+0x18/0x5c Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ed040a11b798aa4302013988cbca99160c5f7bc6 Author: David S. Miller Date: Fri Apr 25 02:12:05 2008 -0700 SPARC64: Fix args to 64-bit sys_semctl() via sys_ipc(). [ Upstream commit: 020cfb05f2c594c778537159bd45ea5efb0c5e0d ] Second and third arguments were swapped for whatever reason. Reported by Tom Callaway. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a5f56179c861a23a2f08409711926ff812f30d38 Author: David S. Miller Date: Sat Apr 26 02:19:18 2008 -0700 sparc64: Fix wedged irq regression. [ Upstream commit: 92aa3573c9cd58fe0bcd1c52c9fd8f5708785917 ] Kernel bugzilla 10273 As reported by Jos van der Ende, ever since commit 5a606b72a4309a656cd1a19ad137dc5557c4b8ea ("[SPARC64]: Do not ACK an INO if it is disabled or inprogress.") sun4u interrupts can get stuck. What this changset did was add the following conditional to the various IRQ chip ->enable() handlers on sparc64: if (unlikely(desc->status & (IRQ_DISABLED|IRQ_INPROGRESS))) return; which is correct, however it means that special care is needed in the ->enable() method. Specifically we must put the interrupt into IDLE state during an enable, or else it might never be sent out again. Setting the INO interrupt state to IDLE resets the state machine, the interrupt input to the INO is retested by the hardware, and if an interrupt is being signalled by the device, the INO moves back into TRANSMIT state, and an interrupt vector is sent to the cpu. The two sun4v IRQ chip handlers were already doing this properly, only sun4u got it wrong. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8f84dbc5ad1a37fe14a771f756beaa02b04401e6 Author: David S. Miller Date: Thu May 1 01:12:40 2008 -0700 sparc64: Stop creating dummy root PCI host controller devices. [ Upstream commit: 86d8337618e69573b5ccd3553f800944e843cae7 ] It just creates confusion, errors, and bugs. For one thing, this can cause dup sysfs or procfs nodes to get created: [ 1.198015] proc_dir_entry '00.0' already registered [ 1.198036] Call Trace: [ 1.198052] [00000000004f2534] create_proc_entry+0x7c/0x98 [ 1.198092] [00000000005719e4] pci_proc_attach_device+0xa4/0xd4 [ 1.198126] [00000000007d991c] pci_proc_init+0x64/0x88 [ 1.198158] [00000000007c62a4] kernel_init+0x190/0x330 [ 1.198183] [0000000000426cf8] kernel_thread+0x38/0x48 [ 1.198210] [00000000006a0d90] rest_init+0x18/0x5c Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b94377177b13fd73a75b0a7cc4e5f5ea4912b71d Author: David S. Miller Date: Wed May 7 16:21:28 2008 -0700 sparc: Fix fork/clone/vfork system call restart. [ Upstream commit: 1e38c126c9252b612697e34f43b1b3371c8ee31d ] We clobber %i1 as well as %i0 for these system calls, because they give two return values. Therefore, on error, we have to restore %i1 properly or else the restart explodes since it uses the wrong arguments. This fixes glibc's nptl/tst-eintr1.c testcase. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 742de58a7b519a51ea77153b6e053223eb6ccbaf Author: David S. Miller Date: Wed May 7 18:54:05 2008 -0700 sparc: Fix SA_ONSTACK signal handling. [ Upstream commit: dc5dc7e6d71ca9fd1ea01a1418150af3b2937489 ] We need to be more liberal about the alignment of the buffer given to us by sigaltstack(). The user should not need to be mindful of all of the alignment constraints we have for the stack frame. This mirrors how we handle this situation in clone() as well. Also, we align the stack even in non-SA_ONSTACK cases so that signals due to bad stack alignment can be delivered properly. This makes such errors easier to debug and recover from. Finally, add the sanity check x86 has to make sure we won't overflow the signal stack. This fixes glibc testcases nptl/tst-cancel20.c and nptl/tst-cancelx20.c Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 970a75dcfa7fd55dd911830d8772dbbf471c154d Author: Robert Reif Date: Thu Apr 24 03:37:51 2008 -0700 sparc: sunzilog uart order [ Upstream commit: 227739bf4c110bbd02d0c0f13b272c32de406e4c ] I have a sparcstation 20 clone with a lot of on board serial ports. The serial core code assumes that uarts are assigned contiguously and that may not be the case when there are multiple zs devices present. This patch insures that uart chips are placed in front of keyboard/mouse chips in the port table. ffd37420: ttyS0 at MMIO 0xf1100000 (irq = 44) is a zs (ESCC) Console: ttyS0 (SunZilog zs0) console [ttyS0] enabled ffd37420: ttyS1 at MMIO 0xf1100004 (irq = 44) is a zs (ESCC) ffd37500: Keyboard at MMIO 0xf1000000 (irq = 44) is a zs ffd37500: Mouse at MMIO 0xf1000004 (irq = 44) is a zs ffd3c5c0: ttyS2 at MMIO 0xf1100008 (irq = 44) is a zs (ESCC) ffd3c5c0: ttyS3 at MMIO 0xf110000c (irq = 44) is a zs (ESCC) ffd3c6a0: ttyS4 at MMIO 0xf1100010 (irq = 44) is a zs (ESCC) ffd3c6a0: ttyS5 at MMIO 0xf1100014 (irq = 44) is a zs (ESCC) ffd3c780: ttyS6 at MMIO 0xf1100018 (irq = 44) is a zs (ESCC) ffd3c780: ttyS7 at MMIO 0xf110001c (irq = 44) is a zs (ESCC) Signed-off-by: Robert Reif Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b0af3e580c2d2213dad67075d55f980ebbad29dc Author: YOSHIFUJI Hideaki Date: Sat Apr 26 22:24:10 2008 -0700 XFRM: AUDIT: Fix flowlabel text format ambibuity. [ Upstream commit: 27a27a2158f4fe56a29458449e880a52ddee3dc4 ] Flowlabel text format was not correct and thus ambiguous. For example, 0x00123 or 0x01203 are formatted as 0x123. This is not what audit tools want. Signed-off-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 45fa78357eab3287b5c39f2d983b91150b3f4bd8 Author: Alan Stern Date: Thu May 8 14:21:22 2008 -0400 OHCI: fix regression upon awakening from hibernation commit 43bbb7e015c4380064796c5868b536437b165615 in upstream Drivers in the ohci-hcd family should perform certain tasks whenever their controller device is resumed. These include checking for loss of power during suspend, turning on port power, and enabling interrupt requests. Until now these jobs have been carried out when the root hub is resumed, not when the controller is. Many drivers work around the resulting awkwardness by automatically resuming their root hub whenever the controller is resumed. But this is wasteful and unnecessary. In 2.6.25, ohci-pci doesn't even do that. After waking up from hibernation, it simply leaves the controller in a RESET state, which is useless. To simplify the situation, this patch (as1066b) adds a new core routine, ohci_finish_controller_resume(), which can be used by all the OHCI-variant drivers. They can call the new routine instead of resuming their root hubs. And ohci-pci.c can call it instead of using its own special-purpose handler. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 2a57a7ee4005e63d1239b349aa8167093d93a11f Author: Tetsuo Handa Date: Thu May 8 21:06:17 2008 +0000 serial: access after NULL check in uart_flush_buffer() commit 55d7b68996a5064f011d681bca412b6281d2f711 upstream I noticed that static void uart_flush_buffer(struct tty_struct *tty) { struct uart_state *state = tty->driver_data; struct uart_port *port = state->port; unsigned long flags; /* * This means you called this function _after_ the port was * closed. No cookie for you. */ if (!state || !state->info) { WARN_ON(1); return; } is too late for checking state != NULL. Signed-off-by: Tetsuo Handa Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7075314222eeb1adb2a16dbab88c3534d72cc50b Author: Samuel Thibault Date: Thu May 8 21:06:15 2008 +0000 vt: fix canonical input in UTF-8 mode commit c1236d31a1b9fc018b85e15a3e58e3601ddc90ae upstream For e.g. proper TTY canonical support, IUTF8 termios flag has to be set as appropriate. Linux used to not care about setting that flag for VT TTYs. This patch fixes that by activating it according to the current mode of the VT, and sets the default value according to the vt.default_utf8 parameter. Signed-off-by: Samuel Thibault Cc: Willy Tarreau Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a138a8e6172bc013d93348df5c5b9f79c0d021c0 Author: Albert Comerma Date: Sat Mar 29 21:35:57 2008 -0300 V4L/DVB (7473): PATCH for various Dibcom based devices patch 6ca8f0b97473dcef3a754bab5239dcfcdd00b244 upstream This patch introduces support for dvb-t for the following DiBcom based cards: - Terratec Cinergy HT USB XE (USB-ID: 0ccd:0058) - Terratec Cinergy HT Express (USB-ID: 0ccd:0060) - Pinnacle 320CX (USB-ID: 2304:022e) - Pinnacle PCTV72e (USB-ID: 2304:0236) - Pinnacle PCTV73e (USB-ID: 2304:0237) - Yuan EC372S (USB-ID: 1164:1edc) Signed-off-by: Hans-Frieder Vogt Signed-off-by: Felix Apitzsch Signed-off-by: Antti Palosaari Signed-off-by: Albert Comerma Signed-off-by: Patrick Boettcher Signed-off-by: Mauro Carvalho Chehab Cc: Michel Morisot Signed-off-by: Greg Kroah-Hartman