- Feb 17, 2009
-
-
Greg Kroah-Hartman authored
-
Jarek Poplawski authored
[ Upstream commit 8b9d3728 ] The trick in socket splicing where we try to convert the skb->data into a page based reference using virt_to_page() does not work so well. The idea is to pass the virt_to_page() reference via the pipe buffer, and refcount the buffer using a SKB reference. But if we are splicing from a socket to a socket (via sendpage) this doesn't work. The from side processing will grab the page (and SKB) references. The sendpage() calls will grab page references only, return, and then the from side processing completes and drops the SKB ref. The page based reference to skb->data is not enough to keep the kmalloc() buffer backing it from being reused. Yet, that is all that the socket send side has at this point. This leads to data corruption if the skb->data buffer is reused by SLAB before the send side socket actually gets the TX packet out to the device. The fix employed here is to simply allocate a page and copy the skb->data bytes into that page. This will hurt performance, but there is no clear way to fix this properly without a copy at the present time, and it is important to get rid of the data corruption. With fixes from Herbert Xu. Tested-by:
Willy Tarreau <w@1wt.eu> Foreseen-by:
Changli Gao <xiaosuo@gmail.com> Diagnosed-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
Jarek Poplawski <jarkao2@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Takashi Iwai authored
commit 32cf9a16 upstream. Fix the initial value for input hwport. The old value (-1) may cause Oops when an realtime MIDI byte is received before the input port is explicitly given. Instead, now it's set to the broadcasting as default. Tested-by:
Holger Dehnhardt <dehnhardt@ahdehnhardt.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Jianjun Kong authored
commit 013cd397 upstream. net/mac80211/debugfs_sta.c The trailing zero was written to state[4], it's out of bounds. Signed-off-by:
Jianjun Kong <jianjun@zeuux.org> Signed-off-by:
-
Andreas Herrmann authored
commit ffd565a8 upstream. Impact: extend allowed configuration space access on 11h CPUs from 256 to 4K Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Sergei Shtylyov authored
commit 2999b58b upstream. When checking for the CFA feature set support, ata_id_is_cfa() tests bit 2 in word 82 of the identify data instead the word 83; it also checks the ATA/PI version support in the word 80 (which the CompactFlash specifications have as reserved), this having no slightest chance to work on the modern CF cards that don't have 0x848A in the word 0... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Tejun Heo authored
commit d89293ab upstream. The dev->pio_mode > XFER_PIO_0 test is there to avoid unnecessary speed down warning messages but it accidentally disabled SATA link spd down during configuration phase after reset where PIO mode is always zero. This patch fixes the problem by moving the test where it belongs. This makes libata probing sequence behave better when the connection is flaky at higher link speeds which isn't too uncommon for eSATA devices. [cebbert@redhat.com: trivial backport to 2.6.27] Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Jiri Kosina authored
commit 0fb21de0 upstream HID: adjust report descriptor fixup for MS 1028 receiver [Backport to 2.6.27: cebbert@redhat.com] Report descriptor fixup for MS 1028 receiver changes also values for Keyboard and Consumer, which incorrectly trims the range, causing correct events being thrown away before passing to userspace. We need to keep the GenDesk usage fixup though, as it reports totally bogus values about axis. Reported-by:
Lucas Gadani <lgadani@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Torsten Rausche authored
This patch is basically a backport of commit ee8a1a0a upstream which was made after the big HID overhaul in 2.6.28. Kernel 2.6.27 fails to handle quirks for the aluminum Apple Wireless Keyboard because it is handled as USB device and not as Bluetooth device. This patch expands 'hidp_blacklist' to make the kernel handle the keyboard in the same way as the Apple wireless Mighty Mouse (also a Bluetooth device). Signed-off-by:
Torsten Rausche <torsten@rausche.net> Cc: Jan Scholz <Scholz@fias.uni-frankfurt.de> Cc: Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Qu Haoran authored
netfilter: xt_sctp: sctp chunk mapping doesn't work Upstream commit: d4e2675a When user tries to map all chunks given in argument, kernel works on a copy of the chunkmap, but at the end it doesn't check the copy, but the orginal one. Signed-off-by:
Qu Haoran <haoran.qu@6wind.com> Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Eric Leblond authored
netfilter: fix tuple inversion for Node information request Upstream commit: a51f42f3 The patch fixes a typo in the inverse mapping of Node Information request. Following draft-ietf-ipngwg-icmp-name-lookups-09, "Querier" sends a type 139 (ICMPV6_NI_QUERY) packet to "Responder" which answer with a type 140 (ICMPV6_NI_REPLY) packet. Signed-off-by:
Eric Leblond <eric@inl.fr> Signed-off-by:
-
David S. Miller authored
[ Upstream commit e4265019 ] Signed-off-by:
-
Christian Borntraeger authored
[ Upstream commit 67605d68 ] sparc64 needs sign-extended function parameters. We have to enable the system call wrappers. Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
Dimitris Michailidis authored
[ Upstream commit 9fa5fdf2 ] tcp_splice_data_recv has two lengths to consider: the len parameter it gets from tcp_read_sock, which specifies the amount of data in the skb, and rd_desc->count, which is the amount of data the splice caller still wants. Currently it passes just the latter to skb_splice_bits, which then splices min(rd_desc->count, skb->len - offset) bytes. Most of the time this is fine, except when the skb contains urgent data. In that case len goes only up to the urgent byte and is less than skb->len - offset. By ignoring len tcp_splice_data_recv may a) splice data tcp_read_sock told it not to, b) return to tcp_read_sock a value > len. Now, tcp_read_sock doesn't handle used > len and leaves the socket in a bad state (both sk_receive_queue and copied_seq are bad at that point) resulting in duplicated data and corruption. Fix by passing min(rd_desc->count, len) to skb_splice_bits. Signed-off-by:
Dimitris Michailidis <dm@chelsio.com> Acked-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
-
Willy Tarreau authored
[ Upstream commit 33966dd0 ] As spotted by Willy Tarreau, current splice() from tcp socket to pipe is not optimal. It processes at most one segment per call. This results in low performance and very high overhead due to syscall rate when splicing from interfaces which do not support LRO. Willy provided a patch inside tcp_splice_read(), but a better fix is to let tcp_read_sock() process as many segments as possible, so that tcp_rcv_space_adjust() and tcp_cleanup_rbuf() are called less often. With this change, splice() behaves like tcp_recvmsg(), being able to consume many skbs in one system call. With typical 1460 bytes of payload per frame, that means splice(SPLICE_F_NONBLOCK) can return 16*1460 = 23360 bytes. Signed-off-by:
-
Herbert Xu authored
[ Upstream commit 905db440 ] As the mmap handler gets called under mmap_sem, and we may grab mmap_sem elsewhere under the socket lock to access user data, we should avoid grabbing the socket lock in the mmap handler. Since the only thing we care about in the mmap handler is for pg_vec* to be invariant, i.e., to exclude packet_set_ring, we can achieve this by simply using a new mutex. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Tested-by:
Martin MOKREJŠ <mmokrejs@ribosome.natur.cuni.cz> Signed-off-by:
-
Shyam Iyer authored
[ Upstream commit 71b3346d ] It oopsd for me in skb_seq_read. addr2line said it was linux-2.6/net/core/skbuff.c:2228, which is this line: while (st->frag_idx < skb_shinfo(st->cur_skb)->nr_frags) { I added some printks in there and it looks like we hit this: } else if (st->root_skb == st->cur_skb && skb_shinfo(st->root_skb)->frag_list) { st->cur_skb = skb_shinfo(st->root_skb)->frag_list; st->frag_idx = 0; goto next_skb; } Actually I did some testing and added a few printks and found that the st->cur_skb->data was 0 and hence the ptr used by iscsi_tcp was null. This caused the kernel panic. if (abs_offset < block_limit) { - *data = st->cur_skb->data + abs_offset; + *data = st->cur_skb->data + (abs_offset - st->stepped_offset); I enabled the debug_tcp and with a few printks found that the code did not go to the next_skb label and could find that the sequence being followed was this - It hit this if condition - if (st->cur_skb->next) { st->cur_skb = st->cur_skb->next; st->frag_idx = 0; goto next_skb; And so, now the st pointer is shifted to the next skb whereas actually it should have hit the second else if first since the data is in the frag_list. else if (st->root_skb == st->cur_skb && skb_shinfo(st->root_skb)->frag_list) { st->cur_skb = skb_shinfo(st->root_skb)->frag_list; goto next_skb; } Reversing the two conditions the attached patch fixes the issue for me on top of Herbert's patches. Signed-off-by:
Shyam Iyer <shyam_iyer@dell.com> Signed-off-by:
-
Herbert Xu authored
[ Upstream commit 95e3b24c ] The frag_list handling was broken in skb_seq_read: 1) We didn't add the stepped offset when looking at the head are of fragments other than the first. 2) We didn't take the stepped offset away when setting the data pointer in the head area. 3) The frag index wasn't reset. This patch fixes both issues. Signed-off-by:
-
Alex Williamson authored
[ Upstream commit e918085a ] 802.1Q expanded the maximum ethernet frame size by 4 bytes for the VLAN tag. We're not taking this into account in virtio_net, which means the buffers we provide to the backend in the virtqueue RX ring aren't big enough to hold a full MTU VLAN packet. For QEMU/KVM, this results in the backend exiting with a packet truncation error. Signed-off-by:
Alex Williamson <alex.williamson@hp.com> Acked-by:
Mark McLoughlin <markmc@redhat.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit e408b8dc ] Commit 93821778 (udp: Fix rcv socket locking) accidentally removed sk_drops increments for UDP IPV4 sockets. This field can be used to detect incorrect sizing of socket receive buffers. Signed-off-by:
-
Jesper Dangaard Brouer authored
[ Upstream commit 7b5e56f9 ] The UDP header pointer assignment must happen after calling pskb_may_pull(). As pskb_may_pull() can potentially alter the SKB buffer. This was exposted by running multicast traffic through the NIU driver, as it won't prepull the protocol headers into the linear area on receive. Signed-off-by:
Jesper Dangaard Brouer <hawk@comx.dk> Signed-off-by:
-
Alex Williamson authored
[ Upstream commit cfbf84fc ] Tap devices can make use of a small MAC filter set via the TUNSETTXFILTER ioctl. The filter has a set of exact matches plus a hash for imperfect filtering of additional multicast addresses. The current code is unbalanced, adding unicast addresses to the multicast hash, but only checking the hash against multicast addresses. This results in the filter dropping unicast addresses that overflow the exact filter. The fix is simply to disable the filter by leaving count set to zero if we find non-multicast addresses after the exact match table is filled. Signed-off-by:
-
David S. Miller authored
[ Upstream commit df1c46b2 ] Based upon a report from Michael Tokarev <mjt@tls.msk.ru>: Just saw in dmesg: ioctl32(kvm:4408): Unknown cmd fd(9) cmd(800454cf){t:'T';sz:4} arg(ffc668e4) on /dev/net/tun Signed-off-by:
-
Ilkka Virta authored
[ Upstream commit 71822faa ] From: Ilkka Virta <itvirta@iki.fi> In the lockup situation the driver seems to go off in an eternal storm of interrupts right after calling request_irq(). It doesn't actually do anything interesting in the interrupt handler. Since connecting the link afterwards works, something later in initialization must fix this. Looking at gem_do_start() and gem_open(), it seems that the only thing done while opening the device after the request_irq(), is a call to napi_enable(). I don't know what the ordering requirements are for the initialization, but I boldly tried to move the napi_enable() call inside gem_do_start() before the link state is checked and interrupts subsequently enabled, and it seems to work for me. Doesn't even break anything too obvious... Signed-off-by:
-
Alexey Dobriyan authored
[ Upstream commit a11da890 ] Printing anything over netconsole before hw is up and running is, of course, not going to work. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Acked-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
Sebastiano Di Paola authored
[ Upstream commit f9e69345 ] packet_lookup_frames() fails to get user frame if current frame header status contains extra flags. This is due to the wrong assumption on the operators precedence during frame status tests. Fixed by forcing the right operators precedence order with explicit brackets. Signed-off-by:
Paolo Abeni <paolo.abeni@gmail.com> Signed-off-by:
Sebastiano Di Paola <sebastiano.dipaola@gmail.com> Signed-off-by:
-
Clément Lecigne authored
[ Upstream commit df0bca04 ] In function sock_getsockopt() located in net/core/sock.c, optval v.val is not correctly initialized and directly returned in userland in case we have SO_BSDCOMPAT option set. This dummy code should trigger the bug: int main(void) { unsigned char buf[4] = { 0, 0, 0, 0 }; int len; int sock; sock = socket(33, 2, 2); getsockopt(sock, 1, SO_BSDCOMPAT, &buf, &len); printf("%x%x%x%x\n", buf[0], buf[1], buf[2], buf[3]); close(sock); } Here is a patch that fix this bug by initalizing v.val just after its declaration. Signed-off-by:
Clément Lecigne <clement.lecigne@netasq.com> Signed-off-by:
-
Herbert Xu authored
[ Upstream commit 0178b695 ] As the options passed to ip6_append_data may be ephemeral, we need to duplicate it for corking. This patch applies the simplest fix which is to memdup all the relevant bits. Signed-off-by:
-
David S. Miller authored
[ Upstream commit 684de409 ] Just like PKTINFO, limit the options area to 64K. Based upon report by Eric Sesterhenn and analysis by Roland Dreier. Signed-off-by:
-
Benjamin Zores authored
[ Upstream commit 9d8dba6c ] Signed-off-by:
Benjamin Zores <benjamin.zores@alcatel-lucent.fr> Signed-off-by:
-
Roel Kluin authored
[ Upstream commit c25b9abb ] Fix inverted logic Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Signed-off-by:
-
Vlad Yasevich authored
[ Upstream commit 759af00e ] Recent changes to the retransmit code exposed a long standing bug where it was possible for a chunk to be time stamped after the retransmit timer was reset. This caused a rare situation where the retrnamist timer has expired, but nothing was marked for retrnasmission because all of timesamps on data were less then 1 rto ago. As result, the timer was never restarted since nothing was retransmitted, and this resulted in a hung association that did couldn't complete the data transfer. The solution is to timestamp the chunk when it's added to the packet for transmission purposes. After the packet is trsnmitted the rtx timer is restarted. This guarantees that when the timer expires, there will be data to retransmit. Signed-off-by:
Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by:
-
Vlad Yasevich authored
[ Upstream commit 6574df9a ] Commit 62aeaff5 (sctp: Start T3-RTX timer when fast retransmitting lowest TSN) introduced a regression where it was possible to forcibly restart the sctp retransmit timer at the transmission of any new chunk. This resulted in much longer timeout times and sometimes hung sctp connections. Signed-off-by:
-
Vlad Yasevich authored
[ Upstream commit 9c5ff5f7 ] crc32c algorithm provides a byteswaped result. On little-endian arches, the result ends up in big-endian/network byte order. On big-endinan arches, the result ends up in little-endian order and needs to be byte swapped again. Thus calling cpu_to_le32 gives the right output. Tested-by:
Jukka Taimisto <jukka.taimisto@mail.suomi.net> Signed-off-by:
-
Hin-Tak Leung authored
commit efb43f4b upstream. Three people (Petr Mensik <pihhan@cipis.net> ["si" should be U+0161 U+00ED], Stephen Ho <stephenhoinhk@gmail.com> on zd1211-devs and Ismael Ojeda Perez <iojedaperez@gmail.com> on linux-wireless) reported success in getting TP-Link WN322G/WN422G working by treating MAXIM_NEW_RF(0x08) as UW2453_RF(0x09) for rf chip hardware initialization. Signed-off-by:
Hin-Tak Leung <htl10@users.sourceforge.net> Tested-by:
Petr Mensik <pihhan@cipis.net> Tested-by:
Stephen Ho <stephenhoinhk@gmail.com> Tested-by:
Ismael Ojeda Perez <iojedaperez@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Hin-Tak Leung authored
commit 14990c69 upstream. Christoph Biedl <sourceforge.bnwi@manchmal.in-ulm.de> reported success in the sourceforge zd1211 mailing list on this addition. This product ID was supported by the vendor driver ZD1211LnxDrv 2.22.0.0 (and possibly earlier) and it probably should have been added earlier. Signed-off-by:
Christoph Biedl <sourceforge.bnwi@manchmal.in-ulm.de> Signed-off-by:
-
Alok Kataria authored
commit 55a8ba4b upstream. Commit 6194ba6f ("x86: don't special-case pmd allocations as much") made changes to the way we handle pmd allocations, and while doing that it dropped a call to paravirt_release_pd on the pgd page from the pgd_dtor code path. As a result of this missing release, the hypervisor is now unaware of the pgd page being freed, and as a result it ends up tracking this page as a page table page. After this the guest may start using the same page for other purposes, and depending on what use the page is put to, it may result in various performance and/or functional issues ( hangs, reboots). Since this release is only required for VMI, I now release the pgd page from the (vmi)_pgd_free hook. Signed-off-by:
Alok N Kataria <akataria@vmware.com> Acked-by:
Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by:
-
Federico Cuello authored
commit 89e12190 upstream. Commit dcf6a79d ("write-back: fix nr_to_write counter") fixed nr_to_write counter, but didn't set the break condition properly. If nr_to_write == 0 after being decremented it will loop one more time before setting done = 1 and breaking the loop. [akpm@linux-foundation.org: coding-style fixes] Cc: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Acked-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Artem Bityutskiy authored
commit dcf6a79d upstream. Commit 05fe478d introduced some @wbc->nr_to_write breakage. It made the following changes: 1. Decrement wbc->nr_to_write instead of nr_to_write 2. Decrement wbc->nr_to_write _only_ if wbc->sync_mode == WB_SYNC_NONE 3. If synced nr_to_write pages, stop only if if wbc->sync_mode == WB_SYNC_NONE, otherwise keep going. However, according to the commit message, the intention was to only make change 3. Change 1 is a bug. Change 2 does not seem to be necessary, and it breaks UBIFS expectations, so if needed, it should be done separately later. And change 2 does not seem to be documented in the commit message. This patch does the following: 1. Undo changes 1 and 2 2. Add a comment explaining change 3 (it very useful to have comments in _code_, not only in the commit). Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Acked-by:
-
Ian Dall authored
commit 507e2fba upstream. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=12646 When the temperature exceeds 32767 milli-degrees the temperature overflows to -32768 millidegrees. These are bothe well within the -55 - +125 degree range for the sensor. Fix overflow in left-shift of a u8. Signed-off-by:
Ian Dall <ian@beware.dropbear.id.au> Signed-off-by:
Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by:
-
