commit 82745b047c35da2d0b582f0e098bea573f250490 Author: Greg Kroah-Hartman Date: Mon Jun 16 13:24:36 2008 -0700 Linux 2.6.25.7 commit 6a8096e5c154cecbb2b2a25f4c0c9013b3372b03 Author: Dan Williams Date: Tue Jun 3 23:39:55 2008 -0400 mac80211: send association event on IBSS create patch 507b06d0622480f8026d49a94f86068bb0fd6ed6 upstream Otherwise userspace has no idea the IBSS creation succeeded. Signed-off-by: Dan Williams Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit dbeda1b14c51a1490d43975e506252cbe4964e21 Author: Roman Zippel Date: Fri Feb 29 05:09:02 2008 +0100 x86: fix recursive dependencies commit 823c248e7cc75b4f22da914b01f8e5433cff197e in mainline The proper dependency check uncovered a few dependency problems, the subarchitecture used a mixture of selects and depends on SMP and PCI dependency was messed up. Signed-off-by: Roman Zippel Signed-off-by: Ingo Molnar Signed-off-by: Ravikiran Thirumalai commit 69f24455cf25d776f8b19d06c7a43a8185fc633d Author: Arjan van de Ven Date: Tue May 20 09:53:52 2008 -0700 bttv: Fix a deadlock in the bttv driver commit 81b2dbcad86732ffc02bad87aa25c4651199fc77 in mainline. vidiocgmbuf() does this: mutex_lock(&fh->cap.vb_lock); retval = videobuf_mmap_setup(&fh->cap, gbuffers, gbufsize, V4L2_MEMORY_MMAP); and videobuf_mmap_setup() then just does mutex_lock(&q->vb_lock); ret = __videobuf_mmap_setup(q, bcount, bsize, memory); mutex_unlock(&q->vb_lock); which is an obvious double-take deadlock. This patch fixes this by having vidiocgmbuf() just call the __videobuf_mmap_setup function instead. Acked-by: Mauro Carvalho Chehab Reported-by: Koos Vriezen Signed-off-by: Arjan van de Ven Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c7559a1531958785bdc25363f8cde154011c0f9d Author: Sam Ravnborg Date: Sun May 25 23:03:18 2008 +0200 Kconfig: introduce ARCH_DEFCONFIG to DEFCONFIG_LIST commit 73531905ed53576d9e8707659a761e7046a60497 in mainline. init/Kconfig contains a list of configs that are searched for if 'make *config' are used with no .config present. Extend this list to look at the config identified by ARCH_DEFCONFIG. With this change we now try the defconfig targets last. This fixes a regression reported by: Linus Torvalds Signed-off-by: Sam Ravnborg Cc: Linus Torvalds Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Signed-off-by: Greg Kroah-Hartman commit 3f8c9c7e37568163e4a9d923286b8ca30a42bed6 Author: Arjan van de Ven Date: Fri May 23 13:04:49 2008 -0700 serial: fix enable_irq_wake/disable_irq_wake imbalance in serial_core.c commit 03a74dcc7eebe6edd778317e82fafdf71e68488c in mainline. enable_irq_wake() and disable_irq_wake() need to be balanced. However, serial_core.c calls these for different conditions during the suspend and resume functions... This is causing a regular WARN_ON() as found at http://www.kerneloops.org/search.php?search=set_irq_wake This patch makes the conditions for triggering the _wake enable/disable sequence identical. Signed-off-by: Arjan van de Ven Cc: Alan Cox Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0349d90da8f3cccf7800501dfd70819323fa8302 Author: Chris Wright Date: Fri Jun 6 21:26:02 2008 -0700 CPUFREQ: Fix format string bug. commit 326f6a5c9c9e1a62aec37bdc0c3f8d53adabe77b upstream Format string bug. Not exploitable, as this is only writable by root, but worth fixing all the same. From: Chris Wright Spotted-by: Ilja van Sprundel Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman commit 9b69cb3f98440c69faa39580f30afa77f94b7b08 Author: Marcin Slusarz Date: Tue Jun 10 21:37:02 2008 +0000 cifs: fix oops on mount when CONFIG_CIFS_DFS_UPCALL is enabled simple "mount -t cifs //xxx /mnt" oopsed on strlen of options http://kerneloops.org/guilty.php?guilty=cifs_get_sb&version=2.6.25-release&start=16711 \ 68&end=1703935&class=oops Signed-off-by: Marcin Slusarz Acked-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit c547cbac3ae2fe6689e764ba45f99b5733e506a9 Author: Aneesh Kumar K.V Date: Sun Jun 8 22:30:48 2008 +0200 m68k: Add ext2_find_{first,next}_bit() for ext4 commit 69c5ddf58a03da3686691ad2f293bc79fd977c10 upstream Add ext2_find_{first,next}_bit(), which are needed for ext4. They're derived out of the ext2_find_next_zero_bit found in the same file. Compile tested with crosstools [Reworked to preserve all symmetry with ext2_find_{first,next}_zero_bit()] This fixes http://bugzilla.kernel.org/show_bug.cgi?id=10393 Signed-off-by: Geert Uytterhoeven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bc5f3280dfe06b606f49a0eee13fede2cc7f5635 Author: Roland Dreier Date: Tue Jun 10 02:35:12 2008 +0000 IB/umem: Avoid sign problems when demoting npages to integer commit 8079ffa0e18baaf2940e52e0c118eef420a473a4 upstream On a 64-bit architecture, if ib_umem_get() is called with a size value that is so big that npages is negative when cast to int, then the length of the page list passed to get_user_pages(), namely min_t(int, npages, PAGE_SIZE / sizeof (struct page *)) will be negative, and get_user_pages() will immediately return 0 (at least since 900cf086, "Be more robust about bad arguments in get_user_pages()"). This leads to an infinite loop in ib_umem_get(), since the code boils down to: while (npages) { ret = get_user_pages(...); npages -= ret; } Fix this by taking the minimum as unsigned longs, so that the value of npages is never truncated. The impact of this bug isn't too severe, since the value of npages is checked against RLIMIT_MEMLOCK, so a process would need to have an astronomical limit or have CAP_IPC_LOCK to be able to trigger this, and such a process could already cause lots of mischief. But it does let buggy userspace code cause a kernel lock-up; for example I hit this with code that passes a negative value into a memory registartion function where it is promoted to a huge u64 value. Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 7a0c866aacab51afa7a6cbf6eccf5e1aa5fd64b9 Author: Ilpo Järvinen Date: Tue Jun 10 15:37:34 2008 -0700 tcp: Fix inconsistency source (CA_Open only when !tcp_left_out(tp)) [ upstream commit: 8aca6cb1179ed9bef9351028c8d8af852903eae2 ] It is possible that this skip path causes TCP to end up into an invalid state where ca_state was left to CA_Open while some segments already came into sacked_out. If next valid ACK doesn't contain new SACK information TCP fails to enter into tcp_fastretrans_alert(). Thus at least high_seq is set incorrectly to a too high seqno because some new data segments could be sent in between (and also, limited transmit is not being correctly invoked there). Reordering in both directions can easily cause this situation to occur. I guess we would want to use tcp_moderate_cwnd(tp) there as well as it may be possible to use this to trigger oversized burst to network by sending an old ACK with huge amount of SACK info, but I'm a bit unsure about its effects (mainly to FlightSize), so to be on the safe side I just currently fixed it minimally to keep TCP's state consistent (obviously, such nasty ACKs have been possible this far). Though it seems that FlightSize is already underestimated by some amount, so probably on the long term we might want to trigger recovery there too, if appropriate, to make FlightSize calculation to resemble reality at the time when the losses where discovered (but such change scares me too much now and requires some more thinking anyway how to do that as it likely involves some code shuffling). This bug was found by Brian Vowell while running my TCP debug patch to find cause of another TCP issue (fackets_out miscount). Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8af4f53dd282f803621c9c5d928e17eed65e0d76 Author: Ayaz Abdulla Date: Thu Jun 12 00:20:18 2008 +0000 forcedeth: msi interrupts commit 4db0ee176e256444695ee2d7b004552e82fec987 upstream Add a workaround for lost MSI interrupts. There is a race condition in the HW in which future interrupts could be missed. The workaround is to toggle the MSI irq mask. Added cleanup based on comments from Andrew Morton. Signed-off-by: Ayaz Abdulla Cc: Manfred Spraul Cc: Jeff Garzik Signed-off-by: Andrew Morton Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit eea341fa413396a3857386051f4a1f6e3a1d81bc Author: Krzysztof Helt Date: Fri Jun 13 02:40:28 2008 +0000 hgafb: resource management fix commit 630c270183133ac25bef8c8d726ac448df9b169a upstream Date: Thu, 12 Jun 2008 15:21:29 -0700 Subject: hgafb: resource management fix Release ports which are requested during detection which are not freed if there is no hga card. Otherwise there is a crash during cat /proc/ioports command. Signed-off-by: Krzysztof Helt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5f500e6d8fdce3de036859ee45c92ce8dd5b5b04 Author: Mike Miller Date: Fri Jun 13 02:40:19 2008 +0000 cciss: add new hardware support commit 24aac480e76c6f5d1391ac05c5e9c0eb9b0cd302 upstream Date: Thu, 12 Jun 2008 15:21:34 -0700 Subject: cciss: add new hardware support Add support for the next generation of HP Smart Array SAS/SATA controllers. Shipping date is late Fall 2008. Bump the driver version to 3.6.20 to reflect the new hardware support from patch 1 of this set. Signed-off-by: Mike Miller Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7c691016a6a9185f98700b91e041b0b4ceecba2b Author: Chuck Ebbert Date: Fri Jun 13 02:40:16 2008 +0000 mmc: wbsd: initialize tasklets before requesting interrupt commit cef33400d0349fb24b6f8b7dea79b66e3144fd8b upstream With CONFIG_DEBUG_SHIRQ set we will get an interrupt as soon as we allocate one. Tasklets may be scheduled in the interrupt handler but they will be initialized after the handler returns, causing a BUG() in kernel/softirq.c when they run. Should fix this Fedora bug report: https://bugzilla.redhat.com/show_bug.cgi?id=449817 Signed-off-by: Chuck Ebbert Acked-by: Pierre Ossman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 99d737e98d81762332242cc82e5604520842911a Author: Ilpo Järvinen Date: Tue May 13 02:54:19 2008 -0700 tcp FRTO: work-around inorder receivers [ upstream commit: 79d44516b4b178ffb6e2159c75584cfcfc097914 ] If receiver consumes segments successfully only in-order, FRTO fallback to conventional recovery produces RTO loop because FRTO's forward transmissions will always get dropped and need to be resent, yet by default they're not marked as lost (which are the only segments we will retransmit in CA_Loss). Price to pay about this is occassionally unnecessarily retransmitting the forward transmission(s). SACK blocks help a bit to avoid this, so it's mainly a concern for NewReno case though SACK is not fully immune either. This change has a side-effect of fixing SACKFRTO problem where it didn't have snd_nxt of the RTO time available anymore when fallback become necessary (this problem would have only occured when RTO would occur for two or more segments and ECE arrives in step 3; no need to figure out how to fix that unless the TODO item of selective behavior is considered in future). Signed-off-by: Ilpo Järvinen Reported-by: Damon L. Chesser Tested-by: Damon L. Chesser Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 59a16700219922a1b095abd76caa25fd4417470c Author: Ilpo Järvinen Date: Thu May 8 01:09:11 2008 -0700 tcp FRTO: SACK variant is errorneously used with NewReno [ upstream commit: 62ab22278308a40bcb7f4079e9719ab8b7fe11b5 ] Note: there's actually another bug in FRTO's SACK variant, which is the causing failure in NewReno case because of the error that's fixed here. I'll fix the SACK case separately (it's a separate bug really, though related, but in order to fix that I need to audit tp->snd_nxt usage a bit). There were two places where SACK variant of FRTO is getting incorrectly used even if SACK wasn't negotiated by the TCP flow. This leads to incorrect setting of frto_highmark with NewReno if a previous recovery was interrupted by another RTO. An eventual fallback to conventional recovery then incorrectly considers one or couple of segments as forward transmissions though they weren't, which then are not LOST marked during fallback making them "non-retransmittable" until the next RTO. In a bad case, those segments are really lost and are the only one left in the window. Thus TCP needs another RTO to continue. The next FRTO, however, could again repeat the same events making the progress of the TCP flow extremely slow. In order for these events to occur at all, FRTO must occur again in FRTOs step 3 while the key segments must be lost as well, which is not too likely in practice. It seems to most frequently with some small devices such as network printers that *seem* to accept TCP segments only in-order. In cases were key segments weren't lost, things get automatically resolved because those wrongly marked segments don't need to be retransmitted in order to continue. I found a reproducer after digging up relevant reports (few reports in total, none at netdev or lkml I know of), some cases seemed to indicate middlebox issues which seems now to be a false assumption some people had made. Bugzilla #10063 _might_ be related. Damon L. Chesser had a reproducable case and was kind enough to tcpdump it for me. With the tcpdump log it was quite trivial to figure out. Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 76ab0a7c88886400dd16870db65106215f3e4aa3 Author: Ilpo Järvinen Date: Tue May 13 02:53:26 2008 -0700 tcp FRTO: Fix fallback to conventional recovery [ upstream commit: a1c1f281b84a751fdb5ff919da3b09df7297619f ] It seems that commit 009a2e3e4ec ("[TCP] FRTO: Improve interoperability with other undo_marker users") run into another land-mine which caused fallback to conventional recovery to break: 1. Cumulative ACK arrives after FRTO retransmission 2. tcp_try_to_open sees zero retrans_out, clears retrans_stamp which should be kept like in CA_Loss state it would be 3. undo_marker change allowed tcp_packet_delayed to return true because of the cleared retrans_stamp once FRTO is terminated causing LossUndo to occur, which means all loss markings FRTO made are reverted. This means that the conventional recovery basically recovered one loss per RTT, which is not that efficient. It was quite unobvious that the undo_marker change broken something like this, I had a quite long session to track it down because of the non-intuitiviness of the bug (luckily I had a trivial reproducer at hand and I was also able to learn to use kprobes in the process as well :-)). This together with the NewReno+FRTO fix and FRTO in-order workaround this fixes Damon's problems, this and the first mentioned are enough to fix Bugzilla #10063. Signed-off-by: Ilpo Järvinen Reported-by: Damon L. Chesser Tested-by: Damon L. Chesser Tested-by: Sebastian Hyrwall Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 47478b42b8e74c2311674eda6700a0ced1509383 Author: Ilpo Järvinen Date: Wed Jun 4 12:07:44 2008 -0700 tcp: fix skb vs fack_count out-of-sync condition [ upstream commit: a6604471db5e7a33474a7f16c64d6b118fae3e74 ] This bug is able to corrupt fackets_out in very rare cases. In order for this to cause corruption: 1) DSACK in the middle of previous SACK block must be generated. 2) In order to take that particular branch, part or all of the DSACKed segment must already be SACKed so that we have that in cache in the first place. 3) The new info must be top enough so that fackets_out will be updated on this iteration. ...then fack_count is updated while skb wasn't, then we walk again that particular segment thus updating fack_count twice for a single skb and finally that value is assigned to fackets_out by tcp_sacktag_one. It is safe to call tcp_sacktag_one just once for a segment (at DSACK), no need to call again for plain SACK. Potential problem of the miscount are limited to premature entry to recovery and to inflated reordering metric (which could even cancel each other out in the most the luckiest scenarios :-)). Both are quite insignificant in worst case too and there exists also code to reset them (fackets_out once sacked_out becomes zero and reordering metric on RTO). This has been reported by a number of people, because it occurred quite rarely, it has been very evasive. Andy Furniss was able to get it to occur couple of times so that a bit more info was collected about the problem using a debug patch, though it still required lot of checking around. Thanks also to others who have tried to help here. This is listed as Bugzilla #10346. The bug was introduced by me in commit 68f8353b48 ([TCP]: Rewrite SACK block processing & sack_recv_cache use), I probably thought back then that there's need to scan that entry twice or didn't dare to make it go through it just once there. Going through twice would have required restoring fack_count after the walk but as noted above, I chose to drop the additional walk step altogether here. Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 11f814feeb526e7be8253452382ce299634540c3 Author: James Chapman Date: Mon Jun 9 13:35:41 2008 -0700 l2tp: Fix possible oops if transmitting or receiving when tunnel goes down [ upstream commit: 24b95685ffcdb3dc28f64b9e8af6ea3e8360fbc5 ] Some problems have been experienced in the field which cause an oops in the pppol2tp driver if L2TP tunnels fail while passing data. The pppol2tp driver uses private data that is referenced via the sk->sk_user_data of its UDP and PPPoL2TP sockets. This patch makes sure that the driver uses sock_hold() when it holds a reference to the sk pointer. This affects its sendmsg(), recvmsg(), getname(), [gs]etsockopt() and ioctl() handlers. Tested by ISP where problem was seen. System has been up 10 days with no oops since running this patch. Without the patch, an oops would occur every 1-2 days. Signed-off-by: James Chapman Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 42cd7667f27ebcf7c9aa3f814d8f0dd1aa1b39c1 Author: James Chapman Date: Mon Jun 9 13:34:39 2008 -0700 l2tp: Fix possible WARN_ON from socket code when UDP socket is closed [ upstream commit: 199f7d24ae59894243687a234a909f44a8724506 ] If an L2TP daemon closes a tunnel socket while packets are queued in the tunnel's reorder queue, a kernel warning is logged because the socket is closed while skbs are still referencing it. The fix is to purge the queue in the socket's release handler. WARNING: at include/net/sock.h:351 udp_lib_unhash+0x41/0x68() Pid: 12998, comm: openl2tpd Not tainted 2.6.25 #8 [] warn_on_slowpath+0x41/0x51 [] udp_lib_unhash+0x41/0x68 [] sk_common_release+0x23/0x90 [] udp_lib_close+0x8/0xa [] inet_release+0x42/0x48 [] sock_release+0x14/0x60 [] sock_close+0x29/0x30 [] __fput+0xad/0x15b [] fput+0x17/0x19 [] filp_close+0x50/0x5a [] sys_close+0x69/0x9f [] syscall_call+0x7/0xb Signed-off-by: James Chapman Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 413b0a22cad909f8cf86299ecf37d34df5d1eb38 Author: John Heffner Date: Tue Apr 29 03:13:52 2008 -0700 tcp: Limit cwnd growth when deferring for GSO [ upstream commit: 246eb2af060fc32650f07203c02bdc0456ad76c7 ] This fixes inappropriately large cwnd growth on sender-limited flows when GSO is enabled, limiting cwnd growth to 64k. [ Backport to 2.6.25 by replacing sk->sk_gso_max_size with 65536 -DaveM ] Signed-off-by: John Heffner Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 73c00341a340bda4aea6a5d765686e37d9f23441 Author: John Heffner Date: Tue Apr 29 03:13:02 2008 -0700 tcp: Allow send-limited cwnd to grow up to max_burst when gso disabled [ upstream commit: ce447eb91409225f8a488f6b7b2a1bdf7b2d884f ] This changes the logic in tcp_is_cwnd_limited() so that cwnd may grow up to tcp_max_burst() even when sk_can_gso() is false, or when sysctl_tcp_tso_win_divisor != 0. Signed-off-by: John Heffner Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 41308bd54a42725ec38924c09cc00e8a56022fef Author: Sridhar Samudrala Date: Wed May 21 16:42:20 2008 -0700 tcp: TCP connection times out if ICMP frag needed is delayed [ upstream commit: 7d227cd235c809c36c847d6a597956ad9e9d2bae ] We are seeing an issue with TCP in handling an ICMP frag needed message that is received after net.ipv4.tcp_retries1 retransmits. The default value of retries1 is 3. So if the path mtu changes and ICMP frag needed is lost for the first 3 retransmits or if it gets delayed until 3 retransmits are done, TCP doesn't update MSS correctly and continues to retransmit the orginal message until it timesout after tcp_retries2 retransmits. I am seeing this issue even with the latest 2.6.25.4 kernel. In tcp_retransmit_timer(), when retransmits counter exceeds tcp_retries1 value, the dst cache entry of the socket is reset. At this time, if we receive an ICMP frag needed message, the dst entry gets updated with the new MTU, but the TCP sockets dst_cache entry remains NULL. So the next time when we try to retransmit after the ICMP frag needed is received, tcp_retransmit_skb() gets called. Here the cur_mss value is calculated at the start of the routine with a NULL sk_dst_cache. Instead we should call tcp_current_mss after the rebuild_header that caches the dst entry with the updated mtu. Also the rebuild_header should be called before tcp_fragment so that skb is fragmented if the mss goes down. Signed-off-by: Sridhar Samudrala Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit ac1f91cebd455f1651b46fd933805536233a1a98 Author: Patrick McHardy Date: Mon Jun 9 11:42:44 2008 -0700 vlan: Correctly handle device notifications for layered VLAN devices [ upstream commit: 81d85346b3fcd8b3167eac8b5fb415a210bd4345 ] Commit 30688a9 ([VLAN]: Handle vlan devices net namespace changing) changed the device notifier to special-case notifications for VLAN devices, effectively disabling state propagation to underlying VLAN devices. This is needed for layered VLANs though, so restore the original behaviour. Signed-off-by: Patrick McHardy Acked-by: Pavel Emelyanov Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 85339198d7abe9edf5204381e0d756c773a739e8 Author: James Chapman Date: Mon May 19 14:10:01 2008 -0700 l2tp: avoid skb truesize bug if headroom is increased [ upstream commit: 090c48d3dd5ea90b37350334aaed9a93b0c1e0a1 ] A user reported seeing occasional bugs such as the following when using the L2TP driver. SKB BUG: Invalid truesize (272) len=72, sizeof(sk_buff)=208 When L2TP adds its header in the transmit path, it might need to increase the headroom of the skb. In some cases, the increased headroom trips a kernel bug when the skb is freed because the skb has grown beyond its truesize value. The fix is to increase the truesize by the amount of headroom added, after orphaning the skb. While here, fix a misleading comment. Thanks to Iouri Kharon for the initial report and testing the fix. Signed-off-by: James Chapman Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit f118d52421c0f803b89fb42dc6448cacbafbd8ee Author: Thomas Graf Date: Thu May 22 10:48:59 2008 -0700 netlink: Fix nla_parse_nested_compat() to call nla_parse() directly [ upstream commit: b9a2f2e450b0f770bb4347ae8d48eb2dea701e24 ] The purpose of nla_parse_nested_compat() is to parse attributes which contain a struct followed by a stream of nested attributes. So far, it called nla_parse_nested() to parse the stream of nested attributes which was wrong, as nla_parse_nested() expects a container attribute as data which holds the attribute stream. It needs to call nla_parse() directly while pointing at the next possible alignment point after the struct in the beginning of the attribute. With this patch, I can no longer reproduce the reported leftover warnings. Signed-off-by: Thomas Graf Acked-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 28cdf87938f6d470098c85d4f1694276dc85958d Author: Herbert Xu Date: Tue May 20 14:32:14 2008 -0700 ipsec: Use the correct ip_local_out function [ upstream commit: 1ac06e0306d0192a7a4d9ea1c9e06d355ce7e7d3 ] Because the IPsec output function xfrm_output_resume does its own dst_output call it should always call __ip_local_output instead of ip_local_output as the latter may invoke dst_output directly. Otherwise the return values from nf_hook and dst_output may clash as they both use the value 1 but for different purposes. When that clash occurs this can cause a packet to be used after it has been freed which usually leads to a crash. Because the offending value is only returned from dst_output with qdiscs such as HTB, this bug is normally not visible. Thanks to Marco Berizzi for his perseverance in tracking this down. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 58c1bcf7e5454a95ef8997f7c769361d687bfd82 Author: Patrick McHardy Date: Tue May 20 14:34:46 2008 -0700 net_sched: cls_api: fix return value for non-existant classifiers [ upstream commit: f2df824948d559ea818e03486a8583e42ea6ab37 ] cls_api should return ENOENT when the requested classifier doesn't exist. Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 6600b220d4e12ec47b4ffc710840c98940c1bb8e Author: David Woodhouse Date: Tue May 20 14:36:14 2008 -0700 net: Fix call to ->change_rx_flags(dev, IFF_MULTICAST) in dev_change_flags() [ upstream commit: 0e91796eb46e29edc791131c832a2232bcaed9dd ] Am I just being particularly dim today, or can the call to dev->change_rx_flags(dev, IFF_MULTICAST) in dev_change_flags() never happen? We've just set dev->flags = flags & IFF_MULTICAST, effectively. So the condition '(dev->flags ^ flags) & IFF_MULTICAST' is _never_ going to be true. Signed-off-by: David Woodhouse Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 5c1c9ddc6d50656beef56b03cf87510f1a01e5ef Author: David S. Miller Date: Wed May 21 17:05:34 2008 -0700 cassini: Only use chip checksum for ipv4 packets. [ upstream commit: b1443e2f6501f06930a162ff1ff08382a98bf23e ] According to David Monro, at least with Natsemi Saturn chips the cassini driver has some trouble with ipv6 checksums. Until we have more information about what's going on here, only use the chip checksums for ipv4. This workaround was suggested and tested by David. Update version and release date. Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 93218a8f95d09c71e18d6baed5f50a98974602e3 Author: Sam Ravnborg Date: Mon Jun 9 11:22:01 2008 -0700 can: Fix copy_from_user() results interpretation [ Upstream commit: 3f91bd420a955803421f2db17b2e04aacfbb2bb8 ] Both copy_to_ and _from_user return the number of bytes, that failed to reach their destination, not the 0/-EXXX values. Based on patch from Pavel Emelyanov Signed-off-by: Sam Ravnborg Acked-by: Oliver Hartkopp Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 0f624e67aa7cf66cf8477bb8b0d61750f4f94f4d Author: Dave Young Date: Sun Jun 1 23:50:52 2008 -0700 bluetooth: rfcomm_dev_state_change deadlock fix commit 537d59af73d894750cff14f90fe2b6d77fbab15b in mainline There's logic in __rfcomm_dlc_close: rfcomm_dlc_lock(d); d->state = BT_CLOSED; d->state_changed(d, err); rfcomm_dlc_unlock(d); In rfcomm_dev_state_change, it's possible that rfcomm_dev_put try to take the dlc lock, then we will deadlock. Here fixed it by unlock dlc before rfcomm_dev_get in rfcomm_dev_state_change. why not unlock just before rfcomm_dev_put? it's because there's another problem. rfcomm_dev_get/rfcomm_dev_del will take rfcomm_dev_lock, but in rfcomm_dev_add the lock order is : rfcomm_dev_lock --> dlc lock so I unlock dlc before the taken of rfcomm_dev_lock. Actually it's a regression caused by commit 1905f6c736cb618e07eca0c96e60e3c024023428 ("bluetooth : __rfcomm_dlc_close lock fix"), the dlc state_change could be two callbacks : rfcomm_sk_state_change and rfcomm_dev_state_change. I missed the rfcomm_sk_state_change that time. Thanks Arjan van de Ven for the effort in commit 4c8411f8c115def968820a4df6658ccfd55d7f1a ("bluetooth: fix locking bug in the rfcomm socket cleanup handling") but he missed the rfcomm_dev_state_change lock issue. Signed-off-by: Dave Young Acked-by: Marcel Holtmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8b1a1d515c3499d3bff3ccb58b76d351c8a466bd Author: Arjan van de Ven Date: Thu May 29 01:32:47 2008 -0700 bluetooth: fix locking bug in the rfcomm socket cleanup handling [ Upstream commit: 7dccf1f4e1696c79bff064c3770867cc53cbc71c ] in net/bluetooth/rfcomm/sock.c, rfcomm_sk_state_change() does the following operation: if (parent && sock_flag(sk, SOCK_ZAPPED)) { /* We have to drop DLC lock here, otherwise * rfcomm_sock_destruct() will dead lock. */ rfcomm_dlc_unlock(d); rfcomm_sock_kill(sk); rfcomm_dlc_lock(d); } } which is fine, since rfcomm_sock_kill() will call sk_free() which will call rfcomm_sock_destruct() which takes the rfcomm_dlc_lock()... so far so good. HOWEVER, this assumes that the rfcomm_sk_state_change() function always gets called with the rfcomm_dlc_lock() taken. This is the case for all but one case, and in that case where we don't have the lock, we do a double unlock followed by an attempt to take the lock, which due to underflow isn't going anywhere fast. This patch fixes this by moving the stragling case inside the lock, like the other usages of the same call are doing in this code. This was found with the help of the www.kerneloops.org project, where this deadlock was observed 51 times at this point in time: http://www.kerneloops.org/search.php?search=rfcomm_sock_destruct Signed-off-by: Arjan van de Ven Acked-by: Marcel Holtmann Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 0121f65abe268ba1cc3a3b9ece0a7467c20512d6 Author: Jarek Poplawski Date: Tue Jun 3 14:53:46 2008 -0700 ax25: Fix NULL pointer dereference and lockup. [ Upstream commit: 7dccf1f4e1696c79bff064c3770867cc53cbc71c ] There is only one function in AX25 calling skb_append(), and it really looks suspicious: appends skb after previously enqueued one, but in the meantime this previous skb could be removed from the queue. This patch Fixes it the simple way, so this is not fully compatible with the current method, but testing hasn't shown any problems. Signed-off-by: Ralf Baechle Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 7e9402be41bbaa44c56f995b2ebecb123ff5a251 Author: Kazunori MIYAZAWA Date: Wed May 21 13:26:11 2008 -0700 af_key: Fix selector family initialization. [ upstream commit: 4da5105687e0993a3bbdcffd89b2b94d9377faab ] This propagates the xfrm_user fix made in commit bcf0dda8d2408fe1c1040cdec5a98e5fcad2ac72 ("[XFRM]: xfrm_user: fix selector family initialization") Based upon a bug report from, and tested by, Alan Swanson. Signed-off-by: Kazunori MIYAZAWA Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 53bb30ecca7c5fa33efd9bec02396a2f3d539183 Author: David S. Miller Date: Mon Jun 9 13:49:22 2008 -0700 sunhv: Fix locking in non-paged I/O case. [ upstream commit: 3651751fff44ede58f65cbb1e39242139ead251b ] This causes the lock to be taken twice, thus resulting in a deadlock. Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit fdca786572904fdf11c489143781beec0024d5c5 Author: Geoff Levand Date: Sat Jun 7 11:26:34 2008 -0700 fbdev: export symbol fb_mode_option upstream commit: 659179b28f15ab1b1db5f8767090f5e728f115a1 Frame buffer and mode setting drivers can be built as modules, so fb_mode_option needs to be exported to support these. Prevents this error: ERROR: "fb_mode_option" [drivers/ps3/ps3av_mod.ko] undefined! Signed-off-by: Geoff Levand Acked-by: Geert Uytterhoeven Cc: Krzysztof Helt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit 7e8b238e605b64476292db9959be62a35d457ebb Author: Cyrill Gorcunov Date: Sun Jun 8 11:00:36 2008 +0200 ecryptfs: fix missed mutex_unlock upstream commit: 71fd5179e8d1d4d503b517e0c5374f7c49540bfc Cc: Michael Halcrow Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit 0daa6dfc3879ecd7c455b9facc60290070273971 Author: Miklos Szeredi Date: Sun Jun 8 10:59:23 2008 +0200 ecryptfs: clean up (un)lock_parent upstream commit: 8dc4e37362a5dc910d704d52ac6542bfd49ddc2f dget(dentry->d_parent) --> dget_parent(dentry) unlock_parent() is racy and unnecessary. Replace single caller with unlock_dir(). There are several other suspect uses of ->d_parent in ecryptfs... Signed-off-by: Miklos Szeredi Cc: Michael Halcrow Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit b2c908b6b75478eb7cd88bfc69b85082444574d2 Author: Michael Halcrow Date: Sun Jun 8 10:58:02 2008 +0200 eCryptfs: protect crypt_stat->flags in ecryptfs_open() upstream commit: 2f9b12a31fcb738ea8c9eb0d4ddf906c6f1d696c Make sure crypt_stat->flags is protected with a lock in ecryptfs_open(). Signed-off-by: Michael Halcrow Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit 2583783370aa26010ca861111b21700a9655d238 Author: Miklos Szeredi Date: Sun Jun 8 10:56:53 2008 +0200 ecryptfs: add missing lock around notify_change upstream commit: 9c3580aa52195699065bc2d7242b1c7e3e6903fa Callers of notify_change() need to hold i_mutex. Signed-off-by: Miklos Szeredi Cc: Michael Halcrow Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit 01891b7ca1373846a8ef2dfedce2bfe21369b81b Author: Jaroslav Franek Date: Sun Jun 8 09:27:26 2008 +0200 sound: emu10k1 - fix system hang with Audigy2 ZS Notebook PCMCIA card upstream commit: 868e15dbd2940f9453b4399117686f408dc77299 When the Linux kernel is compiled with CONFIG_DEBUG_SHIRQ=y, the Soundblaster Audigy2 ZS Notebook PCMCIA card causes the system hang during boot (udev stage) or when the card is hot-plug. The CONFIG_DEBUG_SHIRQ flag is by default 'y' with all Fedora kernels since 2.6.23. The problem was reported as https://bugzilla.redhat.com/show_bug.cgi?id=326411 The issue was hunted down to the snd_emu10k1_create() routine: /* pseudo-code */ snd_emu10k1_create(...) { ... request_irq(... IRQF_SHARED ...) { register the irq handler #ifdef CONFIG_DEBUG_SHIRQ call the irq handler: snd_emu10k1_interrupt() { poll I/O port // <---- !! system hangs ... } #endif } ... snd_emu10k1_cardbus_init(...) { initialize I/O ports } ... } The early access to I/O port in the interrupt handler causes the freeze. Obviously it is necessary to init the I/O ports before accessing them. This patch moves the registration of the irq handler after the initialization of the I/O ports. Signed-off-by: Jaroslav Franek Acked-by: James Courtier-Dutton Signed-off-by: Takashi Iwai Signed-off-by: Chris Wright commit 605cdaa471b8304fef3f89b317d2696e5567fb8d Author: Takashi Iwai Date: Sun Jun 8 09:26:09 2008 +0200 ALSA: hda - Fix resume of auto-config mode with Realtek codecs upstream commit: 07bc76dfa19b10017b518dd9aa1b2719e8c863de The auto-config mode of Realtek ALC codecs has a bug since 2.6.25 that it cannot resume properly. The problem was the wrong assignment of init_hook that overrides the whole initialization. Relevant bug reports: http://bugzilla.kernel.org/show_bug.cgi?id=10662 https://bugzilla.novell.com/show_bug.cgi?id=385473 Signed-off-by: Takashi Iwai Signed-off-by: Chris Wright commit 37067331d5902e42786f8456ca412512b19b8ac3 Author: Al Viro Date: Tue Apr 22 19:51:27 2008 -0400 double-free of inode on alloc_file() failure exit in create_write_pipe() upstream commit: ed1524371716466e9c762808b02601d0d0276a92 Duh... Fortunately, the bug is quite recent (post-2.6.25) and, embarrassingly, mine ;-/ http://bugzilla.kernel.org/show_bug.cgi?id=10878 Signed-off-by: Al Viro Signed-off-by: Chris Wright commit c2375e697044e4a631e227d563ac210342f17f9c Author: Michael Buesch Date: Sat Jun 7 17:57:37 2008 +0200 ssb: Fix context assertion in ssb_pcicore_dev_irqvecs_enable upstream commit: a3bafeedfff2ac5fa0a316bea4570e27900b6fcc This fixes a context assertion in ssb that makes b44 print out warnings on resume. This fixes the following kernel oops: http://www.kerneloops.org/oops.php?number=12732 http://www.kerneloops.org/oops.php?number=11410 Signed-off-by: Michael Buesch Signed-off-by: John W. Linville Signed-off-by: Chris Wright commit 59602dce717b477df34fdda9cd5398a222b0660b Author: Nick Piggin Date: Wed Jun 4 17:18:42 2008 +0200 Add 'rd' alias to new brd ramdisk driver upstream commit: efedf51c866130945b5db755cb58670e60205d83 Alias brd to rd in the hope of helping legacy users. Suggested by Jan. Signed-off-by: Nick Piggin Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit ec5154bbc1a9dcf204ff08d1b4dfa34e393ba954 Author: David Sterba Date: Fri Jun 6 10:56:35 2008 +0200 ipwireless: Fix blocked sending upstream commit: eb4e545d4ac82d9018487edb4419b33b9930c857 Packet sending is driven by two flags, tx_ready and tx_queued. It was possible, that there were queued data for sending and hardware was flagged as blocked but in fact it was not. The tx_queued was indicator but should be really a counter else first fragmented packet resets tx_queued flag, but there may be pending packets which do not get sent. New semantics: tx_ready - set, if hw is ready to send packet, no packet is being transferred right now set the flag right at the place where data are copied into hw memory and not earlier without checking if it was succesful tx_queued - count of enqueued packets, including fragments Tested-by: Michal Rokos Signed-off-by: David Sterba Signed-off-by: Jiri Kosina Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit d83f57dcd1e434e85a9e21febc78a64f775e04ef Author: Michael Buesch Date: Thu May 22 16:32:16 2008 +0200 b43: Fix controller restart crash upstream commit: 3bf0a32e22fedc0b46443699db2d61ac2a883ac4 This fixes a kernel crash on rmmod, in the case where the controller was restarted before doing the rmmod. Signed-off-by: Michael Buesch Signed-off-by: John W. Linville Signed-off-by: Chris Wright