Linux Kernel是Linux系统的核心部件,支持Intel、Alpha、PPC、 Sparc、IA-64、ARM、MIPS、Amiga、Atari和IBMs/390等,还支持32位大文件系统.而在Intel平台上,物理内存最大支持可以达到64GB.加强对IDE和SCSI硬件系统的支持,并增强了对USB设备和3D加速卡的支持.
下载:Linux Kernel 2.6.25.7查看:commit 82745b047c35da2d0b582f0e098bea573f250490Author: Greg Kroah-Hartman <gregkh@SUSE.de>Date: Mon Jun 16 13:24:36 2008 -0700Linux 2.6.25.7commit 6a8096e5c154cecbb2b2a25f4c0c9013b3372b03Author: Dan Williams <dcbw@RedHat.com>Date: Tue Jun 3 23:39:55 2008 -0400mac80211: send association event on IBSS createpatch 507b06d0622480f8026d49a94f86068bb0fd6ed6 upstreamOtherwise userspace has no idea the IBSS creation succeeded.Signed-off-by: Dan Williams <dcbw@redhat.com>Signed-off-by: John W. Linville <linville@tuxdriver.com>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>commit dbeda1b14c51a1490d43975e506252cbe4964e21Author: Roman Zippel <zippel@linux-m68k.org>Date: Fri Feb 29 05:09:02 2008 +0100x86: fix recursive dependenciescommit 823c248e7cc75b4f22da914b01f8e5433cff197e in mainlineThe proper dependency check uncovered a few dependency problems,the subarchitecture used a mixture of selects and depends on SMPand PCI dependency was messed up.Signed-off-by: Roman Zippel <zippel@linux-m68k.org>Signed-off-by: Ingo Molnar <mingo@elte.hu>Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>commit 69f24455cf25d776f8b19d06c7a43a8185fc633dAuthor: Arjan van de Ven <arjan@linux.intel.com>Date: Tue May 20 09:53:52 2008 -0700bttv: Fix a deadlock in the bttv drivercommit 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 doesmutex_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 <mchehab@infradead.org>Reported-by: Koos Vriezen <koos.vriezen@gmail.com>Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>commit c7559a1531958785bdc25363f8cde154011c0f9dAuthor: Sam Ravnborg <sam@ravnborg.org>Date: Sun May 25 23:03:18 2008 +0200Kconfig: introduce ARCH_DEFCONFIG to DEFCONFIG_LISTcommit 73531905ed53576d9e8707659a761e7046a60497 in mainline.init/Kconfig contains a list of configs that are searchedfor if "make *config" are used with no .config present.Extend this list to look at the config identified byARCH_DEFCONFIG.With this change we now try the defconfig targets last.This fixes a regression reportedby: Linus Torvalds <torvalds@linux-foundation.org>Signed-off-by: Sam Ravnborg <sam@ravnborg.org>Cc: Linus Torvalds <torvalds@linux-foundation.org>Cc: Thomas Gleixner <tglx@linutronix.de>Cc: Ingo Molnar <mingo@redhat.com>Cc: "H. Peter Anvin" <hpa@zytor.com>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>commit 3f8c9c7e37568163e4a9d923286b8ca30a42bed6Author: Arjan van de Ven <arjan@linux.intel.com>Date: Fri May 23 13:04:49 2008 -0700serial: fix enable_irq_wake/disable_irq_wake imbalance in serial_core.ccommit 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 andresume functions...This is causing a regular WARN_ON（） as found athttp://www.kerneloops.org/search.php？search=set_irq_wakeThis patch makes the conditions for triggering the _wake enable/disablesequence identical.Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>commit 0349d90da8f3cccf7800501dfd70819323fa8302Author: Chris Wright <chrisw@sous-sol.org>Date: Fri Jun 6 21:26:02 2008 -0700CPUFREQ: Fix format string bug.commit 326f6a5c9c9e1a62aec37bdc0c3f8d53adabe77b upstreamFormat string bug.Not exploitable, as this is only writable by root,but worth fixing all the same.From: Chris Wright <chrisw@sous-sol.org>Spotted-by: Ilja van Sprundel <ilja@netric.org>Signed-off-by: Dave Jones <davej@redhat.com>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>commit 9b69cb3f98440c69faa39580f30afa77f94b7b08Author: Marcin Slusarz <marcin.slusarz@gmail.com>Date: Tue Jun 10 21:37:02 2008 +0000cifs: fix oops on mount when CONFIG_CIFS_DFS_UPCALL is enabledsimple "mount -t cifs //xxx /mnt" oopsed on strlen of optionshttp://kerneloops.org/guilty.php？guilty=cifs_get_sb&version=2.6.25-release&start=16711 68&end=1703935&class=oopsSigned-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>Acked-by: Jeff Layton <jlayton@redhat.com>Signed-off-by: Steve French <sfrench@us.ibm.com>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>commit c547cbac3ae2fe6689e764ba45f99b5733e506a9Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>Date: Sun Jun 8 22:30:48 2008 +0200m68k: Add ext2_find_{first,next}_bit（） for ext4commit 69c5ddf58a03da3686691ad2f293bc79fd977c10 upstreamAdd 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=10393Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>commit bc5f3280dfe06b606f49a0eee13fede2cc7f5635Author: Roland Dreier <rolandd@cisco.com>Date: Tue Jun 10 02:35:12 2008 +0000IB/umem: Avoid sign problems when demoting npages to integercommit 8079ffa0e18baaf2940e52e0c118eef420a473a4 upstreamOn a 64-bit architecture, if ib_umem_get（） is called with a size valuethat is so big that npages is negative when cast to int, then thelength of the page list passed to get_user_pages（）, namelymin_t（int, npages, PAGE_SIZE / sizeof （struct page *））will be negative, and get_user_pages（） will immediately return 0 （atleast since 900cf086, "Be more robust about bad arguments inget_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 ofnpages is never truncated.The impact of this bug isn"t too severe, since the value of npages ischecked against RLIMIT_MEMLOCK, so a process would need to have anastronomical limit or have CAP_IPC_LOCK to be able to trigger this,and such a process could already cause lots of mischief.But it doeslet buggy userspace code cause a kernel lock-up; for example I hitthis with code that passes a negative value into a memory registartionfunction where it is promoted to a huge u64 value.Signed-off-by: Roland Dreier <rolandd@cisco.com>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>commit 7a0c866aacab51afa7a6cbf6eccf5e1aa5fd64b9Author: Ilpo J?rvinen <ilpo.jarvinen@helsinki.fi>Date: Tue Jun 10 15:37:34 2008 -0700tcp: 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 aninvalid state where ca_state was left to CA_Open while somesegments already came into sacked_out. If next valid ACK doesn"tcontain new SACK information TCP fails to enter intotcp_fastretrans_alert（）. Thus at least high_seq is setincorrectly to a too high seqno because some new data segmentscould be sent in between （and also, limited transmit is notbeing correctly invoked there）. Reordering in both directionscan easily cause this situation to occur.I guess we would want to use tcp_moderate_cwnd（tp） there as wellas it may be possible to use this to trigger oversized burst tonetwork by sending an old ACK with huge amount of SACK info, butI"m a bit unsure about its effects （mainly to FlightSize）, so tobe on the safe side I just currently fixed it minimally to keepTCP"s state consistent （obviously, such nasty ACKs have beenpossible this far）. Though it seems that FlightSize is alreadyunderestimated by some amount, so probably on the long term wemight want to trigger recovery there too, if appropriate, to makeFlightSize calculation to resemble reality at the time when thelosses where discovered （but such change scares me too much nowand requires some more thinking anyway how to do that as itlikely involves some code shuffling）.This bug was found by Brian Vowell while running my TCP debugpatch to find cause of another TCP issue （fackets_outmiscount）.Signed-off-by: Ilpo J?rvinen <ilpo.jarvinen@helsinki.fi>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>commit 8af4f53dd282f803621c9c5d928e17eed65e0d76Author: Ayaz Abdulla <aabdulla@nvidia.com>Date: Thu Jun 12 00:20:18 2008 +0000forcedeth: msi interruptscommit 4db0ee176e256444695ee2d7b004552e82fec987 upstreamAdd a workaround for lost MSI interrupts.There is a race condition inthe HW in which future interrupts could be missed.The workaround is totoggle the MSI irq mask.Added cleanup based on comments from Andrew Morton.Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>Cc: Manfred Spraul <manfred@colorfullife.com>Cc: Jeff Garzik <jeff@garzik.org>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>Signed-off-by: Jeff Garzik <jgarzik@redhat.com>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>commit eea341fa413396a3857386051f4a1f6e3a1d81bcAuthor: Krzysztof Helt <krzysztof.h1@wp.pl>Date: Fri Jun 13 02:40:28 2008 +0000hgafb: resource management fixcommit 630c270183133ac25bef8c8d726ac448df9b169a upstreamDate: Thu, 12 Jun 2008 15:21:29 -0700Subject: hgafb: resource management fixRelease ports which are requested during detection which are not freed ifthere is no hga card.Otherwise there is a crash during cat /proc/ioportscommand.Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>commit 5f500e6d8fdce3de036859ee45c92ce8dd5b5b04Author: Mike Miller <mike.miller@hp.com>Date: Fri Jun 13 02:40:19 2008 +0000cciss: add new hardware supportcommit 24aac480e76c6f5d1391ac05c5e9c0eb9b0cd302 upstreamDate: Thu, 12 Jun 2008 15:21:34 -0700Subject: cciss: add new hardware supportAdd support for the next generation of HP Smart Array SAS/SATAcontrollers.Shipping date is late Fall 2008.Bump the driver version to 3.6.20 to reflect the new hardware support frompatch 1 of this set.Signed-off-by: Mike Miller <mike.miller@hp.com>Cc: Jens Axboe <jens.axboe@Oracle.com>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>commit 7c691016a6a9185f98700b91e041b0b4ceecba2bAuthor: Chuck Ebbert <cebbert@redhat.com>Date: Fri Jun 13 02:40:16 2008 +0000mmc: wbsd: initialize tasklets before requesting interruptcommit cef33400d0349fb24b6f8b7dea79b66e3144fd8b upstreamWith CONFIG_DEBUG_SHIRQ set we will get an interrupt as soon as weallocate one.Tasklets may be scheduled in the interrupt handler but theywill be initialized after the handler returns, causing a BUG（） inkernel/softirq.c when they run.Should fix this Fedora bug report:https://bugzilla.redhat.com/show_bug.cgi？id=449817Signed-off-by: Chuck Ebbert <cebbert@redhat.com>Acked-by: Pierre Ossman <drzeus@drzeus.cx>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>commit 99d737e98d81762332242cc82e5604520842911aAuthor: Ilpo J?rvinen <ilpo.jarvinen@helsinki.fi>Date: Tue May 13 02:54:19 2008 -0700tcp FRTO: work-around inorder receivers[ upstream commit: 79d44516b4b178ffb6e2159c75584cfcfc097914 ]If receiver consumes segments successfully only in-order, FRTOfallback to conventional recovery produces RTO loop becauseFRTO"s forward transmissions will always get dropped and need tobe resent, yet by default they"re not marked as lost （which arethe only segments we will retransmit in CA_Loss）.Price to pay about this is occassionally unnecessarilyretransmitting the forward transmission（s）. SACK blocks helpa bit to avoid this, so it"s mainly a concern for NewReno casethough SACK is not fully immune either.This change has a side-effect of fixing SACKFRTO problem whereit didn"t have snd_nxt of the RTO time available anymore whenfallback become necessary （this problem would have only occuredwhen RTO would occur for two or more segments and ECE arrivesin step 3; no need to figure out how to fix that unless theTODO item of selective behavior is considered in future）.Signed-off-by: Ilpo J?rvinen <ilpo.jarvinen@helsinki.fi>Reported-by: Damon L. Chesser <damon@damtek.com>Tested-by: Damon L. Chesser <damon@damtek.com>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 59a16700219922a1b095abd76caa25fd4417470cAuthor: Ilpo J?rvinen <ilpo.jarvinen@helsinki.fi>Date: Thu May 8 01:09:11 2008 -0700tcp FRTO: SACK variant is errorneously used with NewReno[ upstream commit: 62ab22278308a40bcb7f4079e9719ab8b7fe11b5 ]Note: there"s actually another bug in FRTO"s SACK variant, whichis the causing failure in NewReno case because of the errorthat"s fixed here. I"ll fix the SACK case separately （it"sa separate bug really, though related, but in order to fix thatI need to audit tp->snd_nxt usage a bit）.There were two places where SACK variant of FRTO is gettingincorrectly used even if SACK wasn"t negotiated by the TCP flow.This leads to incorrect setting of frto_highmark with NewRenoif a previous recovery was interrupted by another RTO.An eventual fallback to conventional recovery then incorrectlyconsiders one or couple of segments as forward transmissionsthough they weren"t, which then are not LOST marked duringfallback making them "non-retransmittable" until the next RTO.In a bad case, those segments are really lost and are the onlyone left in the window. Thus TCP needs another RTO to continue.The next FRTO, however, could again repeat the same eventsmaking the progress of the TCP flow extremely slow.In order for these events to occur at all, FRTO must occuragain in FRTOs step 3 while the key segments must be lost aswell, which is not too likely in practice. It seems to mostfrequently with some small devices such as network printersthat *seem* to accept TCP segments only in-order. In caseswere key segments weren"t lost, things get automaticallyresolved because those wrongly marked segments don"t need to beretransmitted in order to continue.I found a reproducer after digging up relevant reports （fewreports in total, none at netdev or lkml I know of）, somecases seemed to indicate middlebox issues which seems nowto be a false assumption some people had made. Bugzilla#10063 _might_ be related. Damon L. Chesser <damon@damtek.com>had a reproducable case and was kind enough to tcpdump itfor me. With the tcpdump log it was quite trivial to figureout.Signed-off-by: Ilpo J?rvinen <ilpo.jarvinen@helsinki.fi>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 76ab0a7c88886400dd16870db65106215f3e4aa3Author: Ilpo J?rvinen <ilpo.jarvinen@helsinki.fi>Date: Tue May 13 02:53:26 2008 -0700tcp FRTO: Fix fallback to conventional recovery[ upstream commit: a1c1f281b84a751fdb5ff919da3b09df7297619f ]It seems that commit 009a2e3e4ec （"[TCP] FRTO: Improveinteroperability with other undo_marker users"） run intoanother land-mine which caused fallback to conventionalrecovery to break:1. Cumulative ACK arrives after FRTO retransmission2. tcp_try_to_open sees zero retrans_out, clears retrans_stamp which should be kept like in CA_Loss state it would be3. 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 recoveredone loss per RTT, which is not that efficient. It was quiteunobvious that the undo_marker change broken something likethis, I had a quite long session to track it down because ofthe non-intuitiviness of the bug （luckily I had a trivialreproducer at hand and I was also able to learn to use kprobesin the process as well :-））.This together with the NewReno+FRTO fix and FRTO in-orderworkaround this fixes Damon"s problems, this and the firstmentioned are enough to fix Bugzilla #10063.Signed-off-by: Ilpo J?rvinen <ilpo.jarvinen@helsinki.fi>Reported-by: Damon L. Chesser <damon@damtek.com>Tested-by: Damon L. Chesser <damon@damtek.com>Tested-by: Sebastian Hyrwall <zibbe@cisko.org>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 47478b42b8e74c2311674eda6700a0ced1509383Author: Ilpo J?rvinen <ilpo.jarvinen@helsinki.fi>Date: Wed Jun 4 12:07:44 2008 -0700tcp: 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 againthat particular segment thus updating fack_count twice fora single skb and finally that value is assigned to fackets_outby tcp_sacktag_one.It is safe to call tcp_sacktag_one just once for a segment （atDSACK）, no need to call again for plain SACK.Potential problem of the miscount are limited to premature entryto recovery and to inflated reordering metric （which could evencancel each other out in the most the luckiest scenarios :-））.Both are quite insignificant in worst case too and there existsalso code to reset them （fackets_out once sacked_out becomes zeroand reordering metric on RTO）.This has been reported by a number of people, because it occurredquite rarely, it has been very evasive. Andy Furniss was able toget it to occur couple of times so that a bit more info wascollected about the problem using a debug patch, though it stillrequired lot of checking around. Thanks also to others who havetried to help here.This is listed as Bugzilla #10346. The bug was introduced byme in commit 68f8353b48 （[TCP]: Rewrite SACK block processing &sack_recv_cache use）, I probably thought back then that there"sneed to scan that entry twice or didn"t dare to make it gothrough it just once there. Going through twice would haverequired 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 <ilpo.jarvinen@helsinki.fi>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 11f814feeb526e7be8253452382ce299634540c3Author: James Chapman <jchapman@katalix.com>Date: Mon Jun 9 13:35:41 2008 -0700l2tp: 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 oopsin the pppol2tp driver if L2TP tunnels fail while passing data.The pppol2tp driver uses private data that is referenced via thesk->sk_user_data of its UDP and PPPoL2TP sockets. This patch makessure that the driver uses sock_hold（） when it holds a reference to thesk 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 withno oops since running this patch. Without the patch, an oops wouldoccur every 1-2 days.Signed-off-by: James Chapman <jchapman@katalix.com>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 42cd7667f27ebcf7c9aa3f814d8f0dd1aa1b39c1Author: James Chapman <jchapman@katalix.com>Date: Mon Jun 9 13:34:39 2008 -0700l2tp: 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 inthe tunnel"s reorder queue, a kernel warning is logged because thesocket is closed while skbs are still referencing it. The fix is topurge 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 [<c0423c58>] warn_on_slowpath+0x41/0x51 [<c05d33a7>] udp_lib_unhash+0x41/0x68 [<c059424d>] sk_common_release+0x23/0x90 [<c05d16be>] udp_lib_close+0x8/0xa [<c05d8684>] inet_release+0x42/0x48 [<c0592599>] sock_release+0x14/0x60 [<c059299f>] sock_close+0x29/0x30 [<c046ef52>] __fput+0xad/0x15b [<c046f1d9>] fput+0x17/0x19 [<c046c8c4>] filp_close+0x50/0x5a [<c046da06>] sys_close+0x69/0x9f [<c04048ce>] syscall_call+0x7/0xbSigned-off-by: James Chapman <jchapman@katalix.com>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 413b0a22cad909f8cf86299ecf37d34df5d1eb38Author: John Heffner <johnwheffner@gmail.com>Date: Tue Apr 29 03:13:52 2008 -0700tcp: Limit cwnd growth when deferring for GSO[ upstream commit: 246eb2af060fc32650f07203c02bdc0456ad76c7 ]This fixes inappropriately large cwnd growth on sender-limited flowswhen 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 <johnwheffner@gmail.com>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 73c00341a340bda4aea6a5d765686e37d9f23441Author: John Heffner <johnwheffner@gmail.com>Date: Tue Apr 29 03:13:02 2008 -0700tcp: 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 growup to tcp_max_burst（） even when sk_can_gso（） is false, or whensysctl_tcp_tso_win_divisor ！= 0.Signed-off-by: John Heffner <johnwheffner@gmail.com>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 41308bd54a42725ec38924c09cc00e8a56022fefAuthor: Sridhar Samudrala <sri@us.ibm.com>Date: Wed May 21 16:42:20 2008 -0700tcp: 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 neededmessage that is received after net.ipv4.tcp_retries1 retransmits.The default value of retries1 is 3. So if the path mtu changesand ICMP frag needed is lost for the first 3 retransmits or ifit gets delayed until 3 retransmits are done, TCP doesn"t updateMSS correctly and continues to retransmit the orginal messageuntil 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 exceedstcp_retries1 value, the dst cache entry of the socket is reset.At this time, if we receive an ICMP frag needed message, thedst entry gets updated with the new MTU, but the TCP socketsdst_cache entry remains NULL.So the next time when we try to retransmit after the ICMP fragneeded is received, tcp_retransmit_skb（） gets called. Here thecur_mss value is calculated at the start of the routine witha NULL sk_dst_cache. Instead we should call tcp_current_mss afterthe rebuild_header that caches the dst entry with the updated mtu.Also the rebuild_header should be called before tcp_fragmentso that skb is fragmented if the mss goes down.Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit ac1f91cebd455f1651b46fd933805536233a1a98Author: Patrick McHardy <kaber@trash.net>Date: Mon Jun 9 11:42:44 2008 -0700vlan: 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 VLANdevices, effectively disabling state propagation to underlying VLANdevices. This is needed for layered VLANs though, so restore theoriginal behaviour.Signed-off-by: Patrick McHardy <kaber@trash.net>Acked-by: Pavel Emelyanov <xemul@openvz.org>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 85339198d7abe9edf5204381e0d756c773a739e8Author: James Chapman <jchapman@katalix.com>Date: Mon May 19 14:10:01 2008 -0700l2tp: avoid skb truesize bug if headroom is increased[ upstream commit: 090c48d3dd5ea90b37350334aaed9a93b0c1e0a1 ]A user reported seeing occasional bugs such as the following whenusing the L2TP driver.SKB BUG: Invalid truesize （272） len=72, sizeof（sk_buff）=208When L2TP adds its header in the transmit path, it might need toincrease the headroom of the skb. In some cases, the increasedheadroom trips a kernel bug when the skb is freed because the skb hasgrown beyond its truesize value. The fix is to increase the truesizeby the amount of headroom added, after orphaning the skb.While here, fix a misleading comment.Thanks to Iouri Kharon <bc-info@styx.cabel.net> for the initialreport and testing the fix.Signed-off-by: James Chapman <jchapman@katalix.com>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit f118d52421c0f803b89fb42dc6448cacbafbd8eeAuthor: Thomas Graf <tgraf@suug.ch>Date: Thu May 22 10:48:59 2008 -0700netlink: Fix nla_parse_nested_compat（） to call nla_parse（） directly[ upstream commit: b9a2f2e450b0f770bb4347ae8d48eb2dea701e24 ]The purpose of nla_parse_nested_compat（） is to parse attributes whichcontain a struct followed by a stream of nested attributes.So far,it called nla_parse_nested（） to parse the stream of nested attributeswhich was wrong, as nla_parse_nested（） expects a container attributeas data which holds the attribute stream.It needs to callnla_parse（） directly while pointing at the next possible alignmentpoint after the struct in the beginning of the attribute.With this patch, I can no longer reproduce the reported leftoverwarnings.Signed-off-by: Thomas Graf <tgraf@suug.ch>Acked-by: Patrick McHardy <kaber@trash.net>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 28cdf87938f6d470098c85d4f1694276dc85958dAuthor: Herbert Xu <herbert@gondor.apana.org.au>Date: Tue May 20 14:32:14 2008 -0700ipsec: Use the correct ip_local_out function[ upstream commit: 1ac06e0306d0192a7a4d9ea1c9e06d355ce7e7d3 ]Because the IPsec output function xfrm_output_resume does itsown dst_output call it should always call __ip_local_outputinstead of ip_local_output as the latter may invoke dst_outputdirectly.Otherwise the return values from nf_hook and dst_outputmay clash as they both use the value 1 but for different purposes.When that clash occurs this can cause a packet to be used afterit has been freed which usually leads to a crash.Because theoffending value is only returned from dst_output with qdiscssuch as HTB, this bug is normally not visible.Thanks to Marco Berizzi for his perseverance in tracking thisdown.Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 58c1bcf7e5454a95ef8997f7c769361d687bfd82Author: Patrick McHardy <kaber@trash.net>Date: Tue May 20 14:34:46 2008 -0700net_sched: cls_api: fix return value for non-existant classifiers[ upstream commit: f2df824948d559ea818e03486a8583e42ea6ab37 ]cls_api should return ENOENT when the requested classifier doesn"texist.Signed-off-by: Patrick McHardy <kaber@trash.net>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 6600b220d4e12ec47b4ffc710840c98940c1bb8eAuthor: David Woodhouse <dwmw2@infradead.org>Date: Tue May 20 14:36:14 2008 -0700net: 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 todev->change_rx_flags（dev, IFF_MULTICAST） in dev_change_flags（） neverhappen？We"ve just set dev->flags = flags & IFF_MULTICAST, effectively. So thecondition "（dev->flags ^ flags） & IFF_MULTICAST" is _never_ going to betrue.Signed-off-by: David Woodhouse <dwmw2@infradead.org>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 5c1c9ddc6d50656beef56b03cf87510f1a01e5efAuthor: David S. Miller <davem@davemloft.net>Date: Wed May 21 17:05:34 2008 -0700cassini: Only use chip checksum for ipv4 packets.[ upstream commit: b1443e2f6501f06930a162ff1ff08382a98bf23e ]According to David Monro, at least with Natsemi Saturn chips thecassini driver has some trouble with ipv6 checksums.Until we have more information about what"s going on here, onlyuse the chip checksums for ipv4.This workaround was suggested and tested by David.Update version and release date.Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 93218a8f95d09c71e18d6baed5f50a98974602e3Author: Sam Ravnborg <sam@ravnborg.org>Date: Mon Jun 9 11:22:01 2008 -0700can: Fix copy_from_user（） results interpretation[ Upstream commit: 3f91bd420a955803421f2db17b2e04aacfbb2bb8 ]Both copy_to_ and _from_user return the number of bytes, that failed toreach their destination, not the 0/-EXXX values.Based on patch from Pavel Emelyanov <xemul@openvz.org>Signed-off-by: Sam Ravnborg <sam@ravnborg.org>Acked-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 0f624e67aa7cf66cf8477bb8b0d61750f4f94f4dAuthor: Dave Young <hidave.darkstar@gmail.com>Date: Sun Jun 1 23:50:52 2008 -0700bluetooth: rfcomm_dev_state_change deadlock fixcommit 537d59af73d894750cff14f90fe2b6d77fbab15b in mainlineThere"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 totake the dlc lock, then we will deadlock.Here fixed it by unlock dlc before rfcomm_dev_get inrfcomm_dev_state_change.why not unlock just before rfcomm_dev_put？ it"s because there"sanother problem.rfcomm_dev_get/rfcomm_dev_del will takerfcomm_dev_lock, but in rfcomm_dev_add the lock order is :rfcomm_dev_lock --> dlc lockso I unlock dlc before the taken of rfcomm_dev_lock.Actually it"s a regression caused by commit1905f6c736cb618e07eca0c96e60e3c024023428 （"bluetooth :__rfcomm_dlc_close lock fix"）, the dlc state_change could be twocallbacks : rfcomm_sk_state_change and rfcomm_dev_state_change. Imissed the rfcomm_sk_state_change that time.Thanks Arjan van de Ven <arjan@linux.intel.com> for the effort incommit 4c8411f8c115def968820a4df6658ccfd55d7f1a （"bluetooth: fixlocking bug in the rfcomm socket cleanup handling"） but he missed therfcomm_dev_state_change lock issue.Signed-off-by: Dave Young <hidave.darkstar@gmail.com>Acked-by: Marcel Holtmann <marcel@holtmann.org>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>commit 8b1a1d515c3499d3bff3ccb58b76d351c8a466bdAuthor: Arjan van de Ven <arjan@linux.intel.com>Date: Thu May 29 01:32:47 2008 -0700bluetooth: fix locking bug in the rfcomm socket cleanup handling[ Upstream commit: 7dccf1f4e1696c79bff064c3770867cc53cbc71c ]in net/bluetooth/rfcomm/sock.c, rfcomm_sk_state_change（） does thefollowing 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 callrfcomm_sock_destruct（） which takes the rfcomm_dlc_lock（）... so far so good.HOWEVER, this assumes that the rfcomm_sk_state_change（） function always getscalled with the rfcomm_dlc_lock（） taken. This is the case for all but onecase, and in that case where we don"t have the lock, we do a double unlockfollowed by an attempt to take the lock, which due to underflow isn"tgoing anywhere fast.This patch fixes this by moving the stragling case inside the lock, likethe other usages of the same call are doing in this code.This was found with the help of the www.kerneloops.org project, where thisdeadlock was observed 51 times at this point in time:http://www.kerneloops.org/search.php？search=rfcomm_sock_destructSigned-off-by: Arjan van de Ven <arjan@linux.intel.com>Acked-by: Marcel Holtmann <marcel@holtmann.org>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 0121f65abe268ba1cc3a3b9ece0a7467c20512d6Author: Jarek Poplawski <jarkao2@gmail.com>Date: Tue Jun 3 14:53:46 2008 -0700ax25: Fix NULL pointer dereference and lockup.[ Upstream commit: 7dccf1f4e1696c79bff064c3770867cc53cbc71c ]There is only one function in AX25 calling skb_append（）, and it reallylooks suspicious: appends skb after previously enqueued one, but inthe meantime this previous skb could be removed from the queue.This patch Fixes it the simple way, so this is not fully compatible withthe current method, but testing hasn"t shown any problems.Signed-off-by: Ralf Baechle <ralf@linux-mips.org>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 7e9402be41bbaa44c56f995b2ebecb123ff5a251Author: Kazunori MIYAZAWA <kazunori@miyazawa.org>Date: Wed May 21 13:26:11 2008 -0700af_key: Fix selector family initialization.[ upstream commit: 4da5105687e0993a3bbdcffd89b2b94d9377faab ]This propagates the xfrm_user fix made in commitbcf0dda8d2408fe1c1040cdec5a98e5fcad2ac72 （"[XFRM]: xfrm_user: fixselector family initialization"）Based upon a bug report from, and tested by, Alan Swanson.Signed-off-by: Kazunori MIYAZAWA <kazunori@miyazawa.org>Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 53bb30ecca7c5fa33efd9bec02396a2f3d539183Author: David S. Miller <davem@davemloft.net>Date: Mon Jun 9 13:49:22 2008 -0700sunhv: Fix locking in non-paged I/O case.[ upstream commit: 3651751fff44ede58f65cbb1e39242139ead251b ]This causes the lock to be taken twice, thus resulting ina deadlock.Signed-off-by: David S. Miller <davem@davemloft.net>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit fdca786572904fdf11c489143781beec0024d5c5Author: Geoff Levand <geoffrey.levand@am.sony.com>Date: Sat Jun 7 11:26:34 2008 -0700fbdev: export symbol fb_mode_optionupstream commit: 659179b28f15ab1b1db5f8767090f5e728f115a1Frame 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 <geoffrey.levand@am.sony.com>Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 7e8b238e605b64476292db9959be62a35d457ebbAuthor: Cyrill Gorcunov <gorcunov@gmail.com>Date: Sun Jun 8 11:00:36 2008 +0200ecryptfs: fix missed mutex_unlockupstream commit: 71fd5179e8d1d4d503b517e0c5374f7c49540bfcCc: Michael Halcrow <mhalcrow@us.ibm.com>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 0daa6dfc3879ecd7c455b9facc60290070273971Author: Miklos Szeredi <mszeredi@suse.cz>Date: Sun Jun 8 10:59:23 2008 +0200ecryptfs: clean up （un）lock_parentupstream commit: 8dc4e37362a5dc910d704d52ac6542bfd49ddc2fdget（dentry->d_parent） --> dget_parent（dentry）unlock_parent（） is racy and unnecessary.Replace single caller withunlock_dir（）.There are several other suspect uses of ->d_parent in ecryptfs...Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>Cc: Michael Halcrow <mhalcrow@us.ibm.com>Cc: Christoph Hellwig <hch@infradead.org>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit b2c908b6b75478eb7cd88bfc69b85082444574d2Author: Michael Halcrow <mhalcrow@us.ibm.com>Date: Sun Jun 8 10:58:02 2008 +0200eCryptfs: protect crypt_stat->flags in ecryptfs_open（）upstream commit: 2f9b12a31fcb738ea8c9eb0d4ddf906c6f1d696cMake sure crypt_stat->flags is protected with a lock in ecryptfs_open（）.Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>Cc: Al Viro <viro@ZenIV.linux.org.uk>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 2583783370aa26010ca861111b21700a9655d238Author: Miklos Szeredi <mszeredi@suse.cz>Date: Sun Jun 8 10:56:53 2008 +0200ecryptfs: add missing lock around notify_changeupstream commit: 9c3580aa52195699065bc2d7242b1c7e3e6903faCallers of notify_change（） need to hold i_mutex.Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>Cc: Michael Halcrow <mhalcrow@us.ibm.com>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 01891b7ca1373846a8ef2dfedce2bfe21369b81bAuthor: Jaroslav Franek <jarin.franek@post.cz>Date: Sun Jun 8 09:27:26 2008 +0200sound: emu10k1 - fix system hang with Audigy2 ZS Notebook PCMCIA cardupstream commit: 868e15dbd2940f9453b4399117686f408dc77299When the Linux kernel is compiled with CONFIG_DEBUG_SHIRQ=y,the Soundblaster Audigy2 ZS Notebook PCMCIA card causes thesystem hang during boot （udev stage） or when the card is hot-plug.The CONFIG_DEBUG_SHIRQ flag is by default "y" with all Fedorakernels since 2.6.23. The problem was reported ashttps://bugzilla.redhat.com/show_bug.cgi？id=326411The 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_SHIRQcall 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 causesthe freeze. Obviously it is necessary to init the I/O portsbefore accessing them. This patch moves the registration ofthe irq handler after the initialization of the I/O ports.Signed-off-by: Jaroslav Franek <jarin.franek@post.cz>Acked-by: James Courtier-Dutton <James@superbug.co.uk>Signed-off-by: Takashi Iwai <tiwai@suse.de>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 605cdaa471b8304fef3f89b317d2696e5567fb8dAuthor: Takashi Iwai <tiwai@suse.de>Date: Sun Jun 8 09:26:09 2008 +0200ALSA: hda - Fix resume of auto-config mode with Realtek codecsupstream commit: 07bc76dfa19b10017b518dd9aa1b2719e8c863deThe auto-config mode of Realtek ALC codecs has a bug since 2.6.25that it cannot resume properly.The problem was the wrong assignmentof init_hook that overrides the whole initialization.Relevant bug reports:http://bugzilla.kernel.org/show_bug.cgi？id=10662https://bugzilla.novell.com/show_bug.cgi？id=385473Signed-off-by: Takashi Iwai <tiwai@suse.de>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 37067331d5902e42786f8456ca412512b19b8ac3Author: Al Viro <viro@zeniv.linux.org.uk>Date: Tue Apr 22 19:51:27 2008 -0400double-free of inode on alloc_file（） failure exit in create_write_pipe（）upstream commit: ed1524371716466e9c762808b02601d0d0276a92Duh...Fortunately, the bug is quite recent （post-2.6.25） and, embarrassingly,mine ;-/http://bugzilla.kernel.org/show_bug.cgi？id=10878Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit c2375e697044e4a631e227d563ac210342f17f9cAuthor: Michael Buesch <mb@bu3sch.de>Date: Sat Jun 7 17:57:37 2008 +0200ssb: Fix context assertion in ssb_pcicore_dev_irqvecs_enableupstream commit: a3bafeedfff2ac5fa0a316bea4570e27900b6fccThis fixes a context assertion in ssb that makes b44 printout warnings on resume.This fixes the following kernel oops:http://www.kerneloops.org/oops.php？number=12732http://www.kerneloops.org/oops.php？number=11410Signed-off-by: Michael Buesch <mb@bu3sch.de>Signed-off-by: John W. Linville <linville@tuxdriver.com>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit 59602dce717b477df34fdda9cd5398a222b0660bAuthor: Nick Piggin <npiggin@suse.de>Date: Wed Jun 4 17:18:42 2008 +0200Add "rd" alias to new brd ramdisk driverupstream commit: efedf51c866130945b5db755cb58670e60205d83Alias brd to rd in the hope of helping legacy users. Suggested by Jan.Signed-off-by: Nick Piggin <npiggin@suse.de>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit ec5154bbc1a9dcf204ff08d1b4dfa34e393ba954Author: David Sterba <dsterba@suse.cz>Date: Fri Jun 6 10:56:35 2008 +0200ipwireless: Fix blocked sendingupstream commit: eb4e545d4ac82d9018487edb4419b33b9930c857Packet sending is driven by two flags, tx_ready and tx_queued.It was possible, that there were queued data for sending andhardware was flagged as blocked but in fact it was not.The tx_queued was indicator but should be really a counter elsefirst fragmented packet resets tx_queued flag, but there may bepending 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 succesfultx_queued - count of enqueued packets, including fragmentsTested-by: Michal Rokos <michal.rokos@gmail.com>Signed-off-by: David Sterba <dsterba@suse.cz>Signed-off-by: Jiri Kosina <jkosina@suse.cz>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>Signed-off-by: Chris Wright <chrisw@sous-sol.org>commit d83f57dcd1e434e85a9e21febc78a64f775e04efAuthor: Michael Buesch <mb@bu3sch.de>Date: Thu May 22 16:32:16 2008 +0200b43: Fix controller restart crashupstream commit: 3bf0a32e22fedc0b46443699db2d61ac2a883ac4This fixes a kernel crash on rmmod, in the case where the controllerwas restarted before doing the rmmod.Signed-off-by: Michael Buesch <mb@bu3sch.de>Signed-off-by: John W. Linville <linville@tuxdriver.com>Signed-off-by: Chris Wright <chrisw@sous-sol.org>
易网时代-编程资源站