commit 3ef22854c2ddd56393d99c9c39dc80c7afe1b468 Author: Greg Kroah-Hartman Date: Fri Aug 1 12:03:00 2008 -0700 Linux 2.6.25.14 commit 18b8506ad15f608f7c0e0745c55dd2cd5ff7c091 Author: Linus Torvalds Date: Wed Jul 30 22:20:18 2008 +0000 Fix off-by-one error in iov_iter_advance() commit 94ad374a0751f40d25e22e036c37f7263569d24c upstream The iov_iter_advance() function would look at the iov->iov_len entry even though it might have iterated over the whole array, and iov was pointing past the end. This would cause DEBUG_PAGEALLOC to trigger a kernel page fault if the allocation was at the end of a page, and the next page was unallocated. The quick fix is to just change the order of the tests: check that there is any iovec data left before we check the iov entry itself. Thanks to Alexey Dobriyan for finding this case, and testing the fix. Reported-and-tested-by: Alexey Dobriyan Cc: Nick Piggin Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 09bd119f360128b1944837c2249237686a4ddefc Author: Patrick McHardy Date: Thu Jul 17 14:07:47 2008 +0200 netfilter -stable: nf_conntrack_tcp: fix endless loop netfilter: nf_conntrack_tcp: fix endless loop Upstream commit 6b69fe0: When a conntrack entry is destroyed in process context and destruction is interrupted by packet processing and the packet is an attempt to reopen a closed connection, TCP conntrack tries to kill the old entry itself and returns NF_REPEAT to pass the packet through the hook again. This may lead to an endless loop: TCP conntrack repeatedly finds the old entry, but can not kill it itself since destruction is already in progress, but destruction in process context can not complete since TCP conntrack is keeping the CPU busy. Drop the packet in TCP conntrack if we can't kill the connection ourselves to avoid this. Reported by: hemao77@gmail.com [ Kernel bugzilla #11058 ] Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 482780d80ba2ab6e6bcbb4ec2bf868d2f9bd4628 Author: David Gibson Date: Fri Jul 18 15:55:49 2008 +1000 Correct hash flushing from huge_ptep_set_wrprotect() Correct hash flushing from huge_ptep_set_wrprotect() [stable tree version] A fix for incorrect flushing of the hash page table at fork() for hugepages was recently committed as 86df86424939d316b1f6cfac1b6204f0c7dee317. Without this fix, a process can make a MAP_PRIVATE hugepage mapping, then fork() and have writes to the mapping after the fork() pollute the child's version. Unfortunately this bug also exists in the stable branch. In fact in that case copy_hugetlb_page_range() from mm/hugetlb.c calls ptep_set_wrprotect() directly, the hugepage variant hook huge_ptep_set_wrprotect() doesn't even exist. The patch below is a port of the fix to the stable25/master branch. It introduces a huge_ptep_set_wrprotect() call, but this is #defined to be equal to ptep_set_wrprotect() unless the arch defines its own version and sets __HAVE_ARCH_HUGE_PTEP_SET_WRPROTECT. This arch preprocessor flag is kind of nasty, but it seems the sanest way to introduce this fix with minimum risk of breaking other archs for whom prep_set_wprotect() is suitable for hugepages. Signed-off-by: Andy Whitcroft Signed-off-by: David Gibson Signed-off-by: Greg Kroah-Hartman commit 620f2f722008f4cb95d7e2282aafc89253119627 Author: Pavel Roskin Date: Wed Jul 30 18:20:14 2008 +0000 ath5k: don't enable MSI, we cannot handle it yet commit 256b152b005e319f985f50f2a910a75ba0def74f upstream MSI is a nice thing, but we cannot enable it without changing the interrupt handler. If we do it, we break MSI capable hardware, specifically AR5006 chipset. Signed-off-by: Pavel Roskin Acked-by: Nick Kossifidis Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 0d9351dbb8ee534d2b87111b44cf513d955d6218 Author: Julia Lawall Date: Wed Jul 30 18:20:12 2008 +0000 b43legacy: Release mutex in error handling code commit 4104863fb4a724723d1d5f3cba9d3c5084087e45 upstream The mutex is released on a successful return, so it would seem that it should be released on an error return as well. The semantic patch finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // @@ expression l; @@ mutex_lock(l); .. when != mutex_unlock(l) when any when strict ( if (...) { ... when != mutex_unlock(l) + mutex_unlock(l); return ...; } | mutex_unlock(l); ) // Signed-off-by: Julia Lawall Signed-off-by: Michael Buesch Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 72ca61bf9daad9ad1ac867e6e041dc21a00fe8c6 Author: Thomas Renninger Date: Wed Jul 30 18:20:10 2008 +0000 cpufreq acpi: only call _PPC after cpufreq ACPI init funcs got called already commit a1531acd43310a7e4571d52e8846640667f4c74b upstream Ingo Molnar provided a fix to not call _PPC at processor driver initialization time in "[PATCH] ACPI: fix cpufreq regression" (git commit e4233dec749a3519069d9390561b5636a75c7579) But it can still happen that _PPC is called at processor driver initialization time. This patch should make sure that this is not possible anymore. Signed-off-by: Thomas Renninger Cc: Andi Kleen Cc: Len Brown Cc: Dave Jones Cc: Ingo Molnar Cc: Venkatesh Pallipadi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8bcc8c0511d5e73fd3ea614bc8768382923673e1 Author: Eric Sandeen Date: Tue Jul 29 02:50:12 2008 +0000 eCryptfs: use page_alloc not kmalloc to get a page of memory commit 7fcba054373d5dfc43d26e243a5c9b92069972ee upstream Date: Mon, 28 Jul 2008 15:46:39 -0700 Subject: eCryptfs: use page_alloc not kmalloc to get a page of memory With SLUB debugging turned on in 2.6.26, I was getting memory corruption when testing eCryptfs. The root cause turned out to be that eCryptfs was doing kmalloc(PAGE_CACHE_SIZE); virt_to_page() and treating that as a nice page-aligned chunk of memory. But at least with SLUB debugging on, this is not always true, and the page we get from virt_to_page does not necessarily match the PAGE_CACHE_SIZE worth of memory we got from kmalloc. My simple testcase was 2 loops doing "rm -f fileX; cp /tmp/fileX ." for 2 different multi-megabyte files. With this change I no longer see the corruption. Signed-off-by: Eric Sandeen Acked-by: Michael Halcrow Acked-by: Rik van Riel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 933bba608975914e6a2733c3780672835a779707 Author: Jesse Brandeburg Date: Fri Jul 11 17:34:58 2008 -0700 ixgbe: remove device ID for unsupported device commit bb5d10ac8cc315d53306963001fe650d88a1cbb2 upstream The ixgbe driver was untested with device ID 8086:10c8 but still advertises support. Currently if this device is present in the system when the driver is loaded, the system will panic. Remove this device ID until full support can be tested with available hardware. This patch is necessary for 2.6.24, 2.6.25 and 2.6.26 Signed-off-by: Jesse Brandeburg Signed-off-by: Jeff Kirsher Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 7e625dc756c7561c6805dc068c564fbad7b95f09 Author: Mathieu Desnoyers Date: Wed Jul 30 18:20:05 2008 +0000 markers: fix markers read barrier for multiple probes commit 5def9a3a22e09c99717f41ab7f07ec9e1a1f3ec8 upstream Paul pointed out two incorrect read barriers in the marker handler code in the path where multiple probes are connected. Those are ordering reads of "ptype" (single or multi probe marker), "multi" array pointer, and "multi" array data access. It should be ordered like this : read ptype smp_rmb() read multi array pointer smp_read_barrier_depends() access data referenced by multi array pointer The code with a single probe connected (optimized case, does not have to allocate an array) has correct memory ordering. It applies to kernel 2.6.26.x, 2.6.25.x and linux-next. Signed-off-by: Mathieu Desnoyers Cc: Paul E. McKenney Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 01d7669a29b5f6ee59e9adbca508544581fefd5d Author: Luotao Fu Date: Tue Jul 29 02:50:14 2008 +0000 mpc52xx_psc_spi: fix block transfer commit 9a7867e1b34c3575e7e76a05c0c54c6edbdae2a4 upstream The block transfer routine in the mpc52xx psc spi driver misinterpret the datasheet. According to the processor datasheet the chipselect is held as long as the EOF is not written. Theoretically blocks of any sizes can be transferred in this way. The old routine however writes an EOF after every word, which has the size of size_of_word. This makes the transfer slow. Also fixed some duplicate code. Signed-off-by: Luotao Fu Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 007de77dcf9604bef3858183856d72ffa46fe0bf Author: Hugh Dickins Date: Tue Jul 29 02:50:18 2008 +0000 tmpfs: fix kernel BUG in shmem_delete_inode commit 14fcc23fdc78e9d32372553ccf21758a9bd56fa1 upstream SuSE's insserve initscript ordering program hits kernel BUG at mm/shmem.c:814 on 2.6.26. It's using posix_fadvise on directories, and the shmem_readpage method added in 2.6.23 is letting POSIX_FADV_WILLNEED allocate useless pages to a tmpfs directory, incrementing i_blocks count but never decrementing it. Fix this by assigning shmem_aops (pointing to readpage and writepage and set_page_dirty) only when it's needed, on a regular file or a long symlink. Many thanks to Kel for outstanding bugreport and steps to reproduce it. Reported-by: Kel Modderman Tested-by: Kel Modderman Signed-off-by: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 555fad4e25c58f61298917832d78e867acffc2c7 Author: Alex Nixon Date: Wed Jul 30 18:20:08 2008 +0000 VFS: increase pseudo-filesystem block size to PAGE_SIZE commit 3971e1a917548977cff71418a7c3575ffbc9571f upstream This commit: commit ba52de123d454b57369f291348266d86f4b35070 Author: Theodore Ts'o Date: Wed Sep 27 01:50:49 2006 -0700 [PATCH] inode-diet: Eliminate i_blksize from the inode structure caused the block size used by pseudo-filesystems to decrease from PAGE_SIZE to 1024 leading to a doubling of the number of context switches during a kernbench run. Signed-off-by: Alex Nixon Cc: Andi Kleen Cc: Jeremy Fitzhardinge Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Ian Campbell Cc: "Theodore Ts'o" Cc: Alexander Viro Cc: Hugh Dickins Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0d4f40b70ed6b905e21a8de006a80415ba76997f Author: Ingo Molnar Date: Sun Jul 20 17:24:03 2008 +0200 x86: fix kernel_physical_mapping_init() for large x86 systems based on e22146e610bb7aed63282148740ab1d1b91e1d90 upstream Fix bug in kernel_physical_mapping_init() that causes kernel page table to be built incorrectly for systems with greater than 512GB of memory. Signed-off-by: Jack Steiner Cc: linux-mm@kvack.org Signed-off-by: Ingo Molnar Cc: Oliver Pinter Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit c2a0d55885173608ecdd5b653969e5228b5b70c0 Author: Tejun Heo Date: Fri Jul 18 19:14:40 2008 -0400 ahci: retry enabling AHCI a few times before spitting out WARN_ON() commit 15fe982e429e0e6b7466719acb6cfd9dbfe47f0c upstream ahci: retry enabling AHCI a few times before spitting out WARN_ON() Some chips need AHCI_EN set more than once to actually set it. Try a few times before giving up and spitting out WARN_ON(). Signed-off-by: Tejun Heo Cc: Peer Chen Cc: Volker Armin Hemmann Signed-off-by: Jeff Garzik Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit 97ed97fb560c5e40eb6dbed8b2ba01a1a4bc22ca Author: Pierre Ossman Date: Fri Jul 18 19:04:27 2008 -0400 ALSA: trident - pause s/pdif output Commit 981bcead3f2279a1ec6fb5f2c57aff79ed61a700 upstream. Stop the S/PDIF DMA engine and output when the device is told to pause. It will keep on looping the current buffer contents if this isn't done. Signed-off-by: Pierre Ossman Tested-by: Rene Herman Signed-off-by: Takashi Iwai Signed-off-by: Jaroslav Kysela Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit d74797166a181f7aa1f0fdfbabe9944e87823074 Author: Akio Idehara Date: Sat Jul 26 16:40:14 2008 +0900 ALSA: hda - Fix "alc262_sony_unsol[]" hda_verb array [ALSA] hda - Fix "alc262_sony_unsol[]" hda_verb array commit 7b1e8795ebfe1705153d1001f2a899119f4d9012 upstream I think that hda_verb array must have "terminator (empty array)". But alc262_sony_unsol[] does not have it. And it causes gcc-4.3's buggy behavior with snd_hda_sequence_write(). Signed-off-by: Akio Idehara Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit aed2e3edbf681321a057b515e8438b655f28bf0b Author: Andrew Morton Date: Sun Jul 27 23:55:02 2008 +0000 ARM: fix fls() for 64-bit arguments commit 0c65f459ce6c8bd873a61b3ae1e57858ab1debf3 upstream arm's fls() is implemented as a macro, causing it to misbehave when passed 64-bit arguments. Fix. Cc: Nickolay Vinogradov Tested-by: Krzysztof Halasa Signed-off-by: Andrew Morton Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 0f52801ee0e775a521c484df98c9bf0e3c7ab2b0 Author: Atsushi Nemoto Date: Tue Jul 22 20:05:17 2008 +0000 Fix build on COMPAT platforms when CONFIG_EPOLL is disabled commit 5f17156fc55abac476d180e480bedb0f07f01b14 upstream Add missing cond_syscall() entry for compat_sys_epoll_pwait. Signed-off-by: Atsushi Nemoto Cc: Davide Libenzi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit df8b6217e65519f9cdc8aea5bd5003fc54e58ce6 Author: Jens Axboe Date: Thu Jul 24 22:05:15 2008 +0000 ide-cd: fix oops when using growisofs commit e8e7b9eb11c34ee18bde8b7011af41938d1ad667 upstream cdrom_read_capacity() will blindly return the capacity from the device without sanity-checking it. This later causes code in fs/buffer.c to oops. Fix this by checking that the device is telling us sensible things. From: Jens Axboe Cc: Michael Buesch Cc: Jan Kara Cc: Arnd Bergmann Cc: Borislav Petkov Signed-off-by: Andrew Morton [bart: print device name instead of driver name] Signed-off-by: Bartlomiej Zolnierkiewicz [harvey: blocklen is a big-endian value] Signed-off-by: Harvey Harrison Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit 9b7bca7cc5bc852fb7c1a4137912c5f549b8bf7b Author: Mathieu Desnoyers Date: Tue Jul 22 20:05:14 2008 +0000 markers: fix duplicate modpost entry commit: d35cb360c29956510b2fe1a953bd4968536f7216 When a kernel was rebuilt, the previous Module.markers was not cleared. It caused markers with different format strings to appear as duplicates when a markers was changed. This problem is present since scripts/mod/modpost.c started to generate Module.markers, commit b2e3e658b344c6bcfb8fb694100ab2f2b5b2edb0 It therefore applies to 2.6.25, 2.6.26 and linux-next. I merely merged the patches from Roland, Wenji and Takashi here. Credits to Roland McGrath Wenji Huang and Takashi Nishiie for providing the individual fixes. - Changelog : - Integrated Takashi's Makefile modification to clear Module.markers upon make clean. Signed-off-by: Mathieu Desnoyers Cc: Roland McGrath Cc: Wenji Huang Cc: Takashi Nishiie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit feaf6a2f9bb63a5b40ccb3d6ec6a4a109eaf3edc Author: Alan Cox Date: Fri Jul 18 19:13:02 2008 -0400 pata_atiixp: Don't disable Commit 05177f178efe1459d2d0ac05430027ba201889a4 upstream pata_atiixp: Don't disable A couple of distributions (Fedora, Ubuntu) were having weird problems with the ATI IXP series PATA controllers being reported as simplex. At the heart of the problem is that both distros ignored the recommendations to load pata_acpi and ata_generic *AFTER* specific host drivers. The underlying cause however is that if you D3 and then D0 an ATI IXP it helpfully throws away some configuration and won't let you rewrite it. Add checks to ata_generic and pata_acpi to pin ATIIXP devices. Possibly the real answer here is to quirk them and pin them, but right now we can't do that before they've been pcim_enable()'d by a driver. I'm indebted to David Gero for this. His bug report not only reported the problem but identified the cause correctly and he had tested the right values to prove what was going on [If you backport this for 2.6.24 you will need to pull in the 2.6.25 removal of the bogus WARN_ON() in pcim_enagle] Signed-off-by: Alan Cox Tested-by: David Gero Signed-off-by: Andrew Morton Signed-off-by: Jeff Garzik commit 3d050b676de95e25d0f58dd8f5aec17d9a24fe72 Author: David S. Miller Date: Mon Jul 21 13:17:38 2008 -0700 sparc64: Do not define BIO_VMERGE_BOUNDARY. [ Upstream commit 74988bd85d1cb97987534fd7ffbc570e81145418 ] The IOMMU code and the block layer can split things up using different rules, so this can't work reliably. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fc4fc6aa87f0c3be05f7deacea807cd4a574bc05 Author: David S. Miller Date: Wed Jul 23 16:21:07 2008 -0700 sparc64: Fix cpufreq notifier registry. [ Upstream commit 7ae93f51d7fa8b9130d47e0b7d17979a165c5bc3 ] Based upon a report by Daniel Smolik. We do it too early, which triggers a BUG in cpufreq_register_notifier(). Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 77baae697bbcedfcd803b9687984d136ac2f1e7f Author: David S. Miller Date: Tue Jul 22 22:34:29 2008 -0700 sparc64: Fix lockdep issues in LDC protocol layer. [ Upstream commit b7c2a75725dee9b5643a0aae3a4cb47f52e00a49 ] We're calling request_irq() with a IRQs disabled. No straightforward fix exists because we want to enable these IRQs and setup state atomically before getting into the IRQ handler the first time. What happens now is that we mark the VIRQ to not be automatically enabled by request_irq(). Then we make explicit enable_irq() calls when we grab the LDC channel. This way we don't need to call request_irq() illegally under the LDC channel lock any more. Bump LDC version and release date. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8017765e8d0f0ee534187956d4979c6bd29699c8 Author: David S. Miller Date: Fri Jul 25 16:53:38 2008 -0700 tcp: Clear probes_out more aggressively in tcp_ack(). [ Upstream commit 4b53fb67e385b856a991d402096379dab462170a ] This is based upon an excellent bug report from Eric Dumazet. tcp_ack() should clear ->icsk_probes_out even if there are packets outstanding. Otherwise if we get a sequence of ACKs while we do have packets outstanding over and over again, we'll never clear the probes_out value and eventually think the connection is too sick and we'll reset it. This appears to be some "optimization" added to tcp_ack() in the 2.4.x timeframe. In 2.2.x, probes_out is pretty much always cleared by tcp_ack(). Here is Eric's original report: ---------------------------------------- Apparently, we can in some situations reset TCP connections in a couple of seconds when some frames are lost. In order to reproduce the problem, please try the following program on linux-2.6.25.* Setup some iptables rules to allow two frames per second sent on loopback interface to tcp destination port 12000 iptables -N SLOWLO iptables -A SLOWLO -m hashlimit --hashlimit 2 --hashlimit-burst 1 --hashlimit-mode dstip --hashlimit-name slow2 -j ACCEPT iptables -A SLOWLO -j DROP iptables -A OUTPUT -o lo -p tcp --dport 12000 -j SLOWLO Then run the attached program and see the output : # ./loop State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,200ms,1) State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,200ms,3) State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,200ms,5) State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,200ms,7) State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,200ms,9) State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,200ms,11) State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,201ms,13) State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 40 127.0.0.1:54455 127.0.0.1:12000 timer:(persist,188ms,15) write(): Connection timed out wrote 890 bytes but was interrupted after 9 seconds ESTAB 0 0 127.0.0.1:12000 127.0.0.1:54455 Exiting read() because no data available (4000 ms timeout). read 860 bytes While this tcp session makes progress (sending frames with 50 bytes of payload, every 500ms), linux tcp stack decides to reset it, when tcp_retries 2 is reached (default value : 15) tcpdump : 15:30:28.856695 IP 127.0.0.1.56554 > 127.0.0.1.12000: S 33788768:33788768(0) win 32792 15:30:28.856711 IP 127.0.0.1.12000 > 127.0.0.1.56554: S 33899253:33899253(0) ack 33788769 win 32792 15:30:29.356947 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 1:61(60) ack 1 win 257 15:30:29.356966 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 61 win 257 15:30:29.866415 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 61:111(50) ack 1 win 257 15:30:29.866427 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 111 win 257 15:30:30.366516 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 111:161(50) ack 1 win 257 15:30:30.366527 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 161 win 257 15:30:30.876196 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 161:211(50) ack 1 win 257 15:30:30.876207 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 211 win 257 15:30:31.376282 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 211:261(50) ack 1 win 257 15:30:31.376290 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 261 win 257 15:30:31.885619 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 261:311(50) ack 1 win 257 15:30:31.885631 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 311 win 257 15:30:32.385705 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 311:361(50) ack 1 win 257 15:30:32.385715 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 361 win 257 15:30:32.895249 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 361:411(50) ack 1 win 257 15:30:32.895266 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 411 win 257 15:30:33.395341 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 411:461(50) ack 1 win 257 15:30:33.395351 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 461 win 257 15:30:33.918085 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 461:511(50) ack 1 win 257 15:30:33.918096 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 511 win 257 15:30:34.418163 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 511:561(50) ack 1 win 257 15:30:34.418172 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 561 win 257 15:30:34.927685 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 561:611(50) ack 1 win 257 15:30:34.927698 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 611 win 257 15:30:35.427757 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 611:661(50) ack 1 win 257 15:30:35.427766 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 661 win 257 15:30:35.937359 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 661:711(50) ack 1 win 257 15:30:35.937376 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 711 win 257 15:30:36.437451 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 711:761(50) ack 1 win 257 15:30:36.437464 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 761 win 257 15:30:36.947022 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 761:811(50) ack 1 win 257 15:30:36.947039 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 811 win 257 15:30:37.447135 IP 127.0.0.1.56554 > 127.0.0.1.12000: P 811:861(50) ack 1 win 257 15:30:37.447203 IP 127.0.0.1.12000 > 127.0.0.1.56554: . ack 861 win 257 15:30:41.448171 IP 127.0.0.1.12000 > 127.0.0.1.56554: F 1:1(0) ack 861 win 257 15:30:41.448189 IP 127.0.0.1.56554 > 127.0.0.1.12000: R 33789629:33789629(0) win 0 Source of program : /* * small producer/consumer program. * setup a listener on 127.0.0.1:12000 * Forks a child * child connect to 127.0.0.1, and sends 10 bytes on this tcp socket every 100 ms * Father accepts connection, and read all data */ #include #include #include #include #include #include #include int port = 12000; char buffer[4096]; int main(int argc, char *argv[]) { int lfd = socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in socket_address; time_t t0, t1; int on = 1, sfd, res; unsigned long total = 0; socklen_t alen = sizeof(socket_address); pid_t pid; time(&t0); socket_address.sin_family = AF_INET; socket_address.sin_port = htons(port); socket_address.sin_addr.s_addr = htonl(INADDR_LOOPBACK); if (lfd == -1) { perror("socket()"); return 1; } setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(int)); if (bind(lfd, (struct sockaddr *)&socket_address, sizeof(socket_address)) == -1) { perror("bind"); close(lfd); return 1; } if (listen(lfd, 1) == -1) { perror("listen()"); close(lfd); return 1; } pid = fork(); if (pid == 0) { int i, cfd = socket(AF_INET, SOCK_STREAM, 0); close(lfd); if (connect(cfd, (struct sockaddr *)&socket_address, sizeof(socket_address)) == -1) { perror("connect()"); return 1; } for (i = 0 ; ;) { res = write(cfd, "blablabla\n", 10); if (res > 0) total += res; else if (res == -1) { perror("write()"); break; } else break; usleep(100000); if (++i == 10) { system("ss -on dst 127.0.0.1:12000"); i = 0; } } time(&t1); fprintf(stderr, "wrote %lu bytes but was interrupted after %g seconds\n", total, difftime(t1, t0)); system("ss -on | grep 127.0.0.1:12000"); close(cfd); return 0; } sfd = accept(lfd, (struct sockaddr *)&socket_address, &alen); if (sfd == -1) { perror("accept"); return 1; } close(lfd); while (1) { struct pollfd pfd[1]; pfd[0].fd = sfd; pfd[0].events = POLLIN; if (poll(pfd, 1, 4000) == 0) { fprintf(stderr, "Exiting read() because no data available (4000 ms timeout).\n"); break; } res = read(sfd, buffer, sizeof(buffer)); if (res > 0) total += res; else if (res == 0) break; else perror("read()"); } fprintf(stderr, "read %lu bytes\n", total); close(sfd); return 0; } ---------------------------------------- Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2b12fe50eff8e574b153919955c9991bfb2d0114 Author: Jan Beulich Date: Sun Jul 27 17:30:04 2008 +0000 vmlinux.lds: move __attribute__((__cold__)) functions back into final .text section commit fb5e2b379732e1a6ea32392980bb42e0212db842 upstream Due to the addition of __attribute__((__cold__)) to a few symbols without adjusting the linker scripts, those symbols currently may end up outside the [_stext,_etext) range, as they get placed in .text.unlikely by (at least) gcc 4.3.0. This may confuse code not only outside of the kernel, symbol_put_addr()'s BUG() could also trigger. Hence we need to add .text.unlikely (and for future uses of __attribute__((__hot__)) also .text.hot) to the TEXT_TEXT() macro. Issue observed by Lukas Lipavsky. Signed-off-by: Jan Beulich Tested-by: Lukas Lipavsky Signed-off-by: Sam Ravnborg Signed-off-by: Greg Kroah-Hartman commit e1ff4ff140fb5e92bd0e1ea2af4c6159ee4d3186 Author: Jan Kratochvil Date: Tue Jul 22 20:55:04 2008 +0000 x86: fix crash due to missing debugctlmsr on AMD K6-3 commit d536b1f86591fb081c7a56eab04e711eb4dab951 upstream currently if you use PTRACE_SINGLEBLOCK on AMD K6-3 (i586) it will crash. Kernel now wrongly assumes existing DEBUGCTLMSR MSR register there. Removed the assumption also for some other non-K6 CPUs but I am not sure there (but it can only bring small inefficiency there if my assumption is wrong). Based on info from Roland McGrath, Chuck Ebbert and Mikulas Patocka. More info at: https://bugzilla.redhat.com/show_bug.cgi?id=456175 Signed-off-by: Jan Kratochvil Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f1fe461e24dd19144f39051ce8ef79d7a18c3f5a Author: Adam Greenblatt Date: Fri Jul 25 18:15:11 2008 +0000 isofs: fix minor filesystem corruption commit c0a1633b6201ef79e31b7da464d44fdf5953054d upstream Some iso9660 images contain files with rockridge data that is either incorrect or incompletely parsed. Prior to commit f2966632a134e865db3c819346a1dc7d96e05309 ("[PATCH] rock: handle directory overflows") (included with kernel 2.6.13) the kernel ignored the rockridge data for these files, while still allowing the files to be accessed under their non-rockridge names. That commit inadvertently changed things so that files with invalid rockridge data could not be accessed at all. (I ran across the problem when comparing some old CDs with hard disk copies I had made long ago under kernel 2.4: a few of the files on the hard disk copies were no longer visible on the CDs.) This change reverts to the pre-2.6.13 behavior. Signed-off-by: Adam Greenblatt Reviewed-by: Pekka Enberg Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 68e70b83ec48682bda0d6772c1a64550796606a0 Author: Jan Kara Date: Fri Jul 25 18:15:07 2008 +0000 quota: fix possible infinite loop in quota code commit b48d380541f634663b71766005838edbb7261685 upstream When quota structure is going to be dropped and it is dirty, quota code tries to write it. If the write fails for some reason (e. g. transaction cannot be started because the journal is aborted), we try writing again and again and again... Fix the problem by clearing the dirty bit even if the write failed. (akpm: for 2.6.27, 2.6.26.x and 2.6.25.x) Signed-off-by: Jan Kara Reviewed-by: dingdinghua Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman