[消息]内核发行版：Linux Kernel 2.6.25.7下载
[消息]内核发行版：Linux Kernel 2.6.25.7下载
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 82745b047c35da2d0b582f0e098bea573f250490
Author: Greg Kroah-Hartman <gregkh@SUSE.de>
Date: Mon Jun 16 13:24:36 2008 -0700
Linux 2.6.25.7
commit 6a8096e5c154cecbb2b2a25f4c0c9013b3372b03
Author: Dan Williams <dcbw@RedHat.com>
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 <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit dbeda1b14c51a1490d43975e506252cbe4964e21
Author: Roman Zippel <zippel@linux-m68k.org>
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 <zippel@linux-m68k.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
commit 69f24455cf25d776f8b19d06c7a43a8185fc633d
Author: Arjan van de Ven <arjan@linux.intel.com>
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 <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 c7559a1531958785bdc25363f8cde154011c0f9d
Author: Sam Ravnborg <sam@ravnborg.org>
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 <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 3f8c9c7e37568163e4a9d923286b8ca30a42bed6
Author: Arjan van de Ven <arjan@linux.intel.com>
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 <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 0349d90da8f3cccf7800501dfd70819323fa8302
Author: Chris Wright <chrisw@sous-sol.org>
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 <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 9b69cb3f98440c69faa39580f30afa77f94b7b08
Author: Marcin Slusarz <marcin.slusarz@gmail.com>
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 <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 c547cbac3ae2fe6689e764ba45f99b5733e506a9
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
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 <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 bc5f3280dfe06b606f49a0eee13fede2cc7f5635
Author: Roland Dreier <rolandd@cisco.com>
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 <rolandd@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 7a0c866aacab51afa7a6cbf6eccf5e1aa5fd64b9
Author: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
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 <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 8af4f53dd282f803621c9c5d928e17eed65e0d76
Author: Ayaz Abdulla <aabdulla@nvidia.com>
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 <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 eea341fa413396a3857386051f4a1f6e3a1d81bc
Author: Krzysztof Helt <krzysztof.h1@wp.pl>
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 <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 5f500e6d8fdce3de036859ee45c92ce8dd5b5b04
Author: Mike Miller <mike.miller@hp.com>
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 <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 7c691016a6a9185f98700b91e041b0b4ceecba2b
Author: Chuck Ebbert <cebbert@redhat.com>
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 <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 99d737e98d81762332242cc82e5604520842911a
Author: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
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 <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 59a16700219922a1b095abd76caa25fd4417470c
Author: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
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 <damon@damtek.com>
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 <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit 76ab0a7c88886400dd16870db65106215f3e4aa3
Author: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
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 <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 47478b42b8e74c2311674eda6700a0ced1509383
Author: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
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 <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit 11f814feeb526e7be8253452382ce299634540c3
Author: James Chapman <jchapman@katalix.com>
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 <jchapman@katalix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit 42cd7667f27ebcf7c9aa3f814d8f0dd1aa1b39c1
Author: James Chapman <jchapman@katalix.com>
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
[<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/0xb
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 413b0a22cad909f8cf86299ecf37d34df5d1eb38
Author: John Heffner <johnwheffner@gmail.com>
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 <johnwheffner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit 73c00341a340bda4aea6a5d765686e37d9f23441
Author: John Heffner <johnwheffner@gmail.com>
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 <johnwheffner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit 41308bd54a42725ec38924c09cc00e8a56022fef
Author: Sridhar Samudrala <sri@us.ibm.com>
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 <sri@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit ac1f91cebd455f1651b46fd933805536233a1a98
Author: Patrick McHardy <kaber@trash.net>
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 <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 85339198d7abe9edf5204381e0d756c773a739e8
Author: James Chapman <jchapman@katalix.com>
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 <bc-info@styx.cabel.net> for the initial
report 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 f118d52421c0f803b89fb42dc6448cacbafbd8ee
Author: Thomas Graf <tgraf@suug.ch>
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 <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 28cdf87938f6d470098c85d4f1694276dc85958d
Author: Herbert Xu <herbert@gondor.apana.org.au>
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 <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit 58c1bcf7e5454a95ef8997f7c769361d687bfd82
Author: Patrick McHardy <kaber@trash.net>
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 <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit 6600b220d4e12ec47b4ffc710840c98940c1bb8e
Author: David Woodhouse <dwmw2@infradead.org>
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 <dwmw2@infradead.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit 5c1c9ddc6d50656beef56b03cf87510f1a01e5ef
Author: David S. Miller <davem@davemloft.net>
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 <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit 93218a8f95d09c71e18d6baed5f50a98974602e3
Author: Sam Ravnborg <sam@ravnborg.org>
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 <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 0f624e67aa7cf66cf8477bb8b0d61750f4f94f4d
Author: Dave Young <hidave.darkstar@gmail.com>
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 <arjan@linux.intel.com> 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 <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 8b1a1d515c3499d3bff3ccb58b76d351c8a466bd
Author: Arjan van de Ven <arjan@linux.intel.com>
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 <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 0121f65abe268ba1cc3a3b9ece0a7467c20512d6
Author: Jarek Poplawski <jarkao2@gmail.com>
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 <ralf@linux-mips.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit 7e9402be41bbaa44c56f995b2ebecb123ff5a251
Author: Kazunori MIYAZAWA <kazunori@miyazawa.org>
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 <kazunori@miyazawa.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit 53bb30ecca7c5fa33efd9bec02396a2f3d539183
Author: David S. Miller <davem@davemloft.net>
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 <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit fdca786572904fdf11c489143781beec0024d5c5
Author: Geoff Levand <geoffrey.levand@am.sony.com>
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 <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 7e8b238e605b64476292db9959be62a35d457ebb
Author: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Sun Jun 8 11:00:36 2008 +0200
ecryptfs: fix missed mutex_unlock
upstream commit: 71fd5179e8d1d4d503b517e0c5374f7c49540bfc
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 0daa6dfc3879ecd7c455b9facc60290070273971
Author: Miklos Szeredi <mszeredi@suse.cz>
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 <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 b2c908b6b75478eb7cd88bfc69b85082444574d2
Author: Michael Halcrow <mhalcrow@us.ibm.com>
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 <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 2583783370aa26010ca861111b21700a9655d238
Author: Miklos Szeredi <mszeredi@suse.cz>
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 <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 01891b7ca1373846a8ef2dfedce2bfe21369b81b
Author: Jaroslav Franek <jarin.franek@post.cz>
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 <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 605cdaa471b8304fef3f89b317d2696e5567fb8d
Author: Takashi Iwai <tiwai@suse.de>
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 <tiwai@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit 37067331d5902e42786f8456ca412512b19b8ac3
Author: Al Viro <viro@zeniv.linux.org.uk>
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 <viro@zeniv.linux.org.uk>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit c2375e697044e4a631e227d563ac210342f17f9c
Author: Michael Buesch <mb@bu3sch.de>
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 <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit 59602dce717b477df34fdda9cd5398a222b0660b
Author: Nick Piggin <npiggin@suse.de>
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 <npiggin@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
commit ec5154bbc1a9dcf204ff08d1b4dfa34e393ba954
Author: David Sterba <dsterba@suse.cz>
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 <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 d83f57dcd1e434e85a9e21febc78a64f775e04ef
Author: Michael Buesch <mb@bu3sch.de>
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 <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
评论暂时关闭