commit 16c64cac7d9c6a503f49887219c4fe675e7d43d9 Author: Chris Wright Date: Mon Mar 24 11:49:18 2008 -0700 Linux 2.6.24.4 commit 78d05881017eef1e9ea49571c52275dc2935e719 Author: Heiko Carstens Date: Thu Mar 20 17:33:38 2008 +0100 S390 futex: let futex_atomic_cmpxchg_pt survive early functional tests. a0c1e9073ef7428a14309cba010633a6cd6719ea "futex: runtime enable pi and robust functionality" introduces a test wether futex in atomic stuff works or not. It does that by writing to address 0 of the kernel address space. This will crash on older machines where addressing mode switching is enabled but where the mvcos instruction is not available. Page table walking is done by hand and therefore the code tries to access current->mm which is NULL. Therefore add an extra check, so we survive the early test. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Cc: Thomas Gleixner Signed-off-by: Chris Wright commit 0837aca7b42f1bc9cd8dc1cd4d10aa2aaddaf84d Author: Joe Korty Date: Wed Mar 5 15:04:59 2008 -0800 slab: NUMA slab allocator migration bugfix NUMA slab allocator cpu migration bugfix The NUMA slab allocator (specifically, cache_alloc_refill) is not refreshing its local copies of what cpu and what numa node it is on, when it drops and reacquires the irq block that it inherited from its caller. As a result those values become invalid if an attempt to migrate the process to another numa node occured while the irq block had been dropped. The solution is to make cache_alloc_refill reload these variables whenever it drops and reacquires the irq block. The error is very difficult to hit. When it does occur, one gets the following oops + stack traceback bits in check_spinlock_acquired: kernel BUG at mm/slab.c:2417 cache_alloc_refill+0xe6 kmem_cache_alloc+0xd0 ... This patch was developed against 2.6.23, ported to and compiled-tested only against 2.6.25-rc4. Signed-off-by: Joe Korty Signed-off-by: Christoph Lameter Signed-off-by: Chris Wright commit c0715b44c9330454e7f8a1b271f5f6e1ed849614 Author: Jens Axboe Date: Mon Mar 17 09:04:59 2008 +0100 relay: fix subbuf_splice_actor() adding too many pages If subbuf_pages was larger than the max number of pages the pipe buffer will hold, subbuf_splice_actor() would happily go beyond the array size. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 981a64f60d0cb62846ae5a7d5cd27851dddfbed9 Author: Dave Young Date: Thu Jan 31 18:33:10 2008 -0800 BLUETOOTH: Fix bugs in previous conn add/del workqueue changes. Jens Axboe noticed that we were queueing &conn->work on both btaddconn and keventd_wq. Signed-off-by: Dave Young Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 868145d87bd058f271921c69519d4e2311171d28 Author: Matthew Wilcox Date: Fri Mar 21 15:15:03 2008 +0000 SCSI advansys: Fix bug in AdvLoadMicrocode commit: 951b62c11e86acf8c55d9828aa8c921575023c29 buf[i] can be up to 0xfd, so doubling it and assigning the result to an unsigned char truncates the value. Just use an unsigned int instead; it's only a temporary. Signed-off-by: Matthew Wilcox Signed-off-by: James Bottomley Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 5d51c29a9ccf12c169c13d155a22b5e683280604 Author: Dan Williams Date: Wed Mar 19 04:40:04 2008 +0000 async_tx: avoid the async xor_zero_sum path when src_cnt > device->max_xor commit: 8d8002f642886ae256a3c5d70fe8aff4faf3631a If the channel cannot perform the operation in one call to ->device_prep_dma_zero_sum, then fallback to the xor+page_is_zero path. This only affects users with arrays larger than 16 devices on iop13xx or 32 devices on iop3xx. Cc: Cc: Neil Brown Signed-off-by: Dan Williams [chrisw@sous-sol.org: backport to 2.6.24.3] Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 0db49fc729eee503836ea12745b55f7f802d2abb Author: Quentin Barnes Date: Thu Mar 20 02:45:07 2008 +0000 aio: bad AIO race in aio_complete() leads to process hang commit: 6cb2a21049b8990df4576c5fce4d48d0206c22d5 My group ran into a AIO process hang on a 2.6.24 kernel with the process sleeping indefinitely in io_getevents(2) waiting for the last wakeup to come and it never would. We ran the tests on x86_64 SMP. The hang only occurred on a Xeon box ("Clovertown") but not a Core2Duo ("Conroe"). On the Xeon, the L2 cache isn't shared between all eight processors, but is L2 is shared between between all two processors on the Core2Duo we use. My analysis of the hang is if you go down to the second while-loop in read_events(), what happens on processor #1: 1) add_wait_queue_exclusive() adds thread to ctx->wait 2) aio_read_evt() to check tail 3) if aio_read_evt() returned 0, call [io_]schedule() and sleep In aio_complete() with processor #2: A) info->tail = tail; B) waitqueue_active(&ctx->wait) C) if waitqueue_active() returned non-0, call wake_up() The way the code is written, step 1 must be seen by all other processors before processor 1 checks for pending events in step 2 (that were recorded by step A) and step A by processor 2 must be seen by all other processors (checked in step 2) before step B is done. The race I believed I was seeing is that steps 1 and 2 were effectively swapped due to the __list_add() being delayed by the L2 cache not shared by some of the other processors. Imagine: proc 2: just before step A proc 1, step 1: adds to ctx->wait, but is not visible by other processors yet proc 1, step 2: checks tail and sees no pending events proc 2, step A: updates tail proc 1, step 3: calls [io_]schedule() and sleeps proc 2, step B: checks ctx->wait, but sees no one waiting, skips wakeup so proc 1 sleeps indefinitely My patch adds a memory barrier between steps A and B. It ensures that the update in step 1 gets seen on processor 2 before continuing. If processor 1 was just before step 1, the memory barrier makes sure that step A (update tail) gets seen by the time processor 1 makes it to step 2 (check tail). Before the patch our AIO process would hang virtually 100% of the time. After the patch, we have yet to see the process ever hang. Signed-off-by: Quentin Barnes Reviewed-by: Zach Brown Cc: Benjamin LaHaise Cc: Cc: Nick Piggin Signed-off-by: Andrew Morton [ We should probably disallow that "if (waitqueue_active()) wake_up()" coding pattern, because it's so often buggy wrt memory ordering ] Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit d447e76ecaa4d4bb005eef4de5655a8418a4d60d Author: Duane Griffin Date: Thu Mar 20 02:45:06 2008 +0000 jbd: correctly unescape journal data blocks commit: 439aeec639d7c57f3561054a6d315c40fd24bb74 Fix a long-standing typo (predating git) that will cause data corruption if a journal data block needs unescaping. At the moment the wrong buffer head's data is being unescaped. To test this case mount a filesystem with data=journal, start creating and deleting a bunch of files containing only JFS_MAGIC_NUMBER (0xc03b3998), then pull the plug on the device. Without this patch the files will contain zeros instead of the correct data after recovery. Signed-off-by: Duane Griffin Acked-by: Jan Kara Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 9ecfdfeaf6210f17b93f4130845a9349ab893196 Author: Duane Griffin Date: Thu Mar 20 02:45:05 2008 +0000 jbd2: correctly unescape journal data blocks commit: d00256766a0b4f1441931a7f569a13edf6c68200 Fix a long-standing typo (predating git) that will cause data corruption if a journal data block needs unescaping. At the moment the wrong buffer head's data is being unescaped. To test this case mount a filesystem with data=journal, start creating and deleting a bunch of files containing only JBD2_MAGIC_NUMBER (0xc03b3998), then pull the plug on the device. Without this patch the files will contain zeros instead of the correct data after recovery. Signed-off-by: Duane Griffin Acked-by: Jan Kara Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 6eb36c282b77ba9f392e7bc332f7fda80c310db6 Author: Dave Young Date: Thu Mar 20 02:45:04 2008 +0000 zisofs: fix readpage() outside i_size commit: 08ca0db8aa2db4ddcf487d46d85dc8ffb22162cc A read request outside i_size will be handled in do_generic_file_read(). So we just return 0 to avoid getting -EIO as normal reading, let do_generic_file_read do the rest. At the same time we need unlock the page to avoid system stuck. Fixes http://bugzilla.kernel.org/show_bug.cgi?id=10227 Signed-off-by: Dave Young Acked-by: Jan Kara Report-by: Christian Perle Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 58392e3a38e2a7a3d4a8e70889be017346c94e90 Author: Eric Leblond Date: Mon Mar 17 15:41:47 2008 +0100 NETFILTER: nfnetlink_log: fix computation of netlink skb size Upstream commit 7000d38d: This patch is similar to nfnetlink_queue fixes. It fixes the computation of skb size by using NLMSG_SPACE instead of NLMSG_ALIGN. Signed-off-by: Eric Leblond Signed-off-by: Patrick McHardy Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit c5251ae9027b9d2dcc413335bf834e896f769c30 Author: Eric Leblond Date: Mon Mar 17 15:41:46 2008 +0100 NETFILTER: nfnetlink_queue: fix computation of allocated size for netlink skb Upstream commit cabaa9bf: Size of the netlink skb was wrongly computed because the formula was using NLMSG_ALIGN instead of NLMSG_SPACE. NLMSG_ALIGN does not add the room for netlink header as NLMSG_SPACE does. This was causing a failure of message building in some cases. On my test system, all messages for packets in range [8*k+41, 8*k+48] where k is an integer were invalid and the corresponding packets were dropped. Signed-off-by: Eric Leblond Signed-off-by: Patrick McHardy Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 32b4faa2b264717b37114bdbf0f799ab9d8a850b Author: Jan Engelhardt Date: Mon Mar 17 15:41:44 2008 +0100 NETFILTER: xt_time: fix failure to match on Sundays Upstream commit 4f4c9430: xt_time_match() in net/netfilter/xt_time.c in kernel 2.6.24 never matches on Sundays. On my host I have a rule like iptables -A OUTPUT -m time --weekdays Sun -j REJECT and it never matches. The problem is in localtime_2(), which uses r->weekday = (4 + r->dse) % 7; to map the epoch day onto a weekday in {0,...,6}. In particular this gives 0 for Sundays. But 0 has to be wrong; a weekday of 0 can never match. xt_time_match() has if (!(info->weekdays_match & (1 << current_time.weekday))) return false; and when current_time.weekday = 0, the result of the & is always zero, even when info->weekdays_match = XT_TIME_ALL_WEEKDAYS = 0xFE. Signed-off-by: Jan Engelhardt Signed-off-by: Patrick McHardy Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 38f469963d11172bf68ebcb8c056bf4145c40241 Author: Michal Schmidt Date: Tue Mar 18 00:13:16 2008 +0100 sched_nr_migrate wrong mode bits sched_nr_migrate has strange permission bits: $ ls -l /proc/sys/kernel/sched_nr_migrate --w----r-T 1 root root 0 2008-03-17 23:31 /proc/sys/kernel/sched_nr_migrate The bug is an obvious decimal/octal confusion. Fixed (collaterally) in Linus's tree by Peter Zijlstra with commit fa85ae241 "sched: rt time limit" (in 2.6.25-rc1). Signed-off-by: Michal Schmidt Acked-by: Peter Zijlstra Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 7a2f56f3783496d860de6dfbce95154cc5adcabd Author: J. Bruce Fields Date: Fri Mar 14 19:37:11 2008 -0400 nfsd: fix oops on access from high-numbered ports This bug was always here, but before my commit 6fa02839bf9412e18e77 ("recheck for secure ports in fh_verify"), it could only be triggered by failure of a kmalloc(). After that commit it could be triggered by a client making a request from a non-reserved port for access to an export marked "secure". (Exports are "secure" by default.) The result is a struct svc_export with a reference count one too low, resulting in likely oopses next time the export is accessed. The reference counting here is not straightforward; a later patch will clean up fh_verify(). Thanks to Lukas Hejtmanek for the bug report and followup. Signed-off-by: J. Bruce Fields Cc: Lukas Hejtmanek Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit ccab3340fa6f495c1932fad84163e3fab40094e1 Author: Hiroshi Shimamoto Date: Mon Mar 10 11:01:20 2008 -0700 sched: fix race in schedule() Fix a hard to trigger crash seen in the -rt kernel that also affects the vanilla scheduler. There is a race condition between schedule() and some dequeue/enqueue functions; rt_mutex_setprio(), __setscheduler() and sched_move_task(). When scheduling to idle, idle_balance() is called to pull tasks from other busy processor. It might drop the rq lock. It means that those 3 functions encounter on_rq=0 and running=1. The current task should be put when running. Here is a possible scenario: CPU0 CPU1 | schedule() | ->deactivate_task() | ->idle_balance() | -->load_balance_newidle() rt_mutex_setprio() | | --->double_lock_balance() *get lock *rel lock * on_rq=0, ruuning=1 | * sched_class is changed | *rel lock *get lock : | : ->put_prev_task_rt() ->pick_next_task_fair() => panic The current process of CPU1(P1) is scheduling. Deactivated P1, and the scheduler looks for another process on other CPU's runqueue because CPU1 will be idle. idle_balance(), load_balance_newidle() and double_lock_balance() are called and double_lock_balance() could drop the rq lock. On the other hand, CPU0 is trying to boost the priority of P1. The result of boosting only P1's prio and sched_class are changed to RT. The sched entities of P1 and P1's group are never put. It makes cfs_rq invalid, because the cfs_rq has curr and no leaf, but pick_next_task_fair() is called, then the kernel panics. Signed-off-by: Hiroshi Shimamoto Signed-off-by: Peter Zijlstra Signed-off-by: Ingo Molnar [chrisw@sous-sol.org: backport to 2.6.24.3] Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 282dac698e338351d3b9fb9db2739fe07e1c2ef9 Author: Krzysztof Oledzki Date: Tue Mar 4 14:56:23 2008 -0800 SCSI: mpt fusion: don't oops if NumPhys==0 Don't oops if NumPhys==0, instead return -ENODEV. This patch fixes http://bugzilla.kernel.org/show_bug.cgi?id=9909 Signed-off-by: Krzysztof Piotr Oledzki Acked-by: Eric Moore Signed-off-by: Andrew Morton Signed-off-by: James Bottomley Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 94429518999e4e6b8f84807afa4bf089a63da0b4 Author: Boaz Harrosh Date: Thu Mar 6 02:10:13 2008 +0000 SCSI: gdth: fix to internal commands execution commit: ee54cc6af95a7fa09da298493b853a9e64fa8abd The recent patch named: [SCSI] gdth: !use_sg cleanup and use of scsi accessors has done a bad job in handling internal commands issued by gdth_execute(). Internal commands are issued with device gdth_cmd_str ready made directly to the card, without any mapping or translations of scsi commands. So here I added a gdth_cmd_str pointer to the gdth_cmndinfo private structure which is then copied directly to host. following this patch is a cleanup that removes the home cooked accessors and reverts them to regular scsi_cmnd accessors. Since they are not used anymore. After review maybe the 2 patches should be squashed together. FIXME: There is still a problem with gdth_get_info(). as reported there is a WARN_ON trigerd in dma_free_coherent() when doing: $ cat /proc/sys/gdth/0 Signed-off-by: Boaz Harrosh Tested-by: Joerg Dorchain: Tested-by: Stefan Priebe Tested-by: Jon Chelton Signed-off-by: James Bottomley Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 14bbd0f8e4209f565c83b9e3df2fefbd77e0e961 Author: Boaz Harrosh Date: Thu Mar 6 02:10:15 2008 +0000 SCSI: gdth: bugfix for the at-exit problems commit: b31ddd31c266c2ad1b708cad0d3d8e0aa7fa2737 gdth_exit would first remove all cards then stop the timer and would not sync with the timer function. This caused a crash in gdth_timer() when module was unloaded. So del_timer_sync the timer before we delete the cards. also the reboot notifier function would crash. So clean that up and fix the crashes. Signed-off-by: Boaz Harrosh Tested-by: Joerg Dorchain: Tested-by: Stefan Priebe Tested-by: Jon Chelton Signed-off-by: James Bottomley Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit c0b53aa6d8f2298d6fbe3763ef164f0d8a13c71b Author: Samuel Thibault Date: Mon Mar 3 01:23:49 2008 +0000 Fix default compose table initialization commit: 5ce2087ed0eb424e0889bdc9102727f65d2ecdde Oddly enough, unsigned int c = '\300'; puts a "negative" value in c, not 0300... This fixes the default unicode compose table by using integers instead of character constants. Signed-off-by: Samuel Thibault Signed-off-by: Linus Torvalds Fold in upstream commit 10a7f3135ac4937a3dc8ed11614a2b70cbd44728 (Build fix for drivers/s390/char/defkeymap.c) from Tony Breeds. Commit 5ce2087ed0eb424e0889bdc9102727f65d2ecdde (Fix default compose table initialization) left a trailing quote. CC drivers/s390/char/defkeymap.o drivers/s390/char/defkeymap.c:155: error: missing terminating ' character drivers/s390/char/defkeymap.c:156: error: syntax error before ';' token make[3]: *** [drivers/s390/char/defkeymap.o] Error 1 Fix that. Signed-off-by: Tony Breeds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit a71fad255d2ab627ad9f16caf3681aaba84c2510 Author: H. Peter Anvin Date: Tue Mar 18 19:23:07 2008 -0400 x86: don't use P6_NOPs if compiling with CONFIG_X86_GENERIC Commit: 959b3be64cab9160cd74532a49b89cdd918d38e9 x86: don't use P6_NOPs if compiling with CONFIG_X86_GENERIC P6_NOPs are definitely not supported on some VIA CPUs, and possibly (unverified) on AMD K7s. It is also the only thing that prevents a 686 kernel from running on Transmeta TM3x00/5x00 (Crusoe) series. The performance benefit over generic NOPs is very small, so when building for generic consumption, avoid using them. Signed-off-by: H. Peter Anvin Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner [cebbert@redhat.com: backport take 2, with parens this time] Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit b9c98c2a4580b94021266bbf3f4a70b6ca030558 Author: Tony Battersby Date: Wed Mar 5 10:23:26 2008 -0600 SCSI: fix BUG when sum(scatterlist) > bufflen commit: 4d2de3a50ce19af2008a90636436a1bf5b3b697b When sending a SCSI command to a tape drive via the SCSI Generic (sg) driver, if the command has a data transfer length more than scatter_elem_sz (32 KB default) and not a multiple of 512, then I either hit BUG_ON(!valid_dma_direction(direction)) in dma_unmap_sg() or else the command never completes (depending on the LLDD). When constructing scatterlists, the sg driver rounds up the scatterlist element sizes to be a multiple of 512. This can result in sum(scatterlist lengths) > bufflen. In this case, scsi_req_map_sg() incorrectly sets bio->bi_size to sum(scatterlist lengths) rather than to bufflen. When the command completes, req_bio_endio() detects that bio->bi_size != 0, and so it doesn't call bio_endio(). This causes the command to be resubmitted, resulting in BUG_ON or the command never completing. This patch makes scsi_req_map_sg() set bio->bi_size to bufflen rather than to sum(scatterlist lengths), which fixes the problem. Signed-off-by: Tony Battersby Acked-by: Mike Christie Signed-off-by: James Bottomley Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 5475187c2752adcc6d789592b5f68c81c39e5a81 Author: Misha Zhilin Date: Wed Mar 5 00:50:27 2008 +0000 USB: ehci: handle large bulk URBs correctly (again) commit: b5f7a0ec11694e60c99d682549dfaf8a03d7ad97 USB: ehci: Fixes completion for multi-qtd URB the short read case When use of urb->status in the EHCI driver was reworked last August (commit 14c04c0f88f228fee1f412be91d6edcb935c78aa), a bug was inserted in the handling of early completion for bulk transactions that need more than one qTD (e.g. more than 20KB in one URB). This patch resolves that problem by ensuring that the early completion status is preserved until the URB is handed back to its submitter, instead of resetting it after each qTD. Signed-off-by: Misha Zhilin Signed-off-by: David Brownell Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 1b52961e49f8b7293b52826c7e12a689d516fe18 Author: Sven Andersen Date: Tue Mar 4 22:09:11 2008 +0100 USB: ftdi_sio - really enable EM1010PC [upstream commit: 4ae897df] Add EM1010PC to ftdi_sio.c Signed-off-by: Sven Andersen Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 1ea057839fc9b6bc267e1da5d080c5c6ae6e75dd Author: Kevin Vance Date: Wed Mar 5 00:50:26 2008 +0000 USB: ftdi_sio: Workaround for broken Matrix Orbital serial port commit: 546d7eec389a3df3173b3131d92829c14e614601 Workaround for the FT232RL-based, Matrix Orbital VK204-25-USB serial port added to the ftdi_sio driver. The device has an invalid endpoint descriptor, which must be modified before it can be used. Signed-off-by: Kevin Vance Signed-off-by: Greg Kroah-Hartman [chrisw@sous-sol.org: backport to 2.6.24.3 w/out ftdi_jtag_probe] Signed-off-by: Chris Wright commit e39ebfc41dcef0ec42a51342e8603045b1a626da Author: Samuel Thibault Date: Wed Mar 5 00:50:23 2008 +0000 VT notifier fix for VT switch commit: 8182ec49a73729334f5a6c65a607ba7009ebd6d6 VT notifier callbacks need to be aware of console switches. This is already partially done from console_callback(), but at that time fg_console, cursor positions, etc. are not yet updated and hence screen readers fetch the old values. This adds an update notify after all of the values are updated in redraw_screen(vc, 1). Signed-off-by: Samuel Thibault Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit d458a7c853ced17ff79a2a213f0c4e59e5715c1b Author: Michael Halcrow Date: Wed Mar 5 00:50:13 2008 +0000 eCryptfs: make ecryptfs_prepare_write decrypt the page commit: e4465fdaeb3f7b5ef47f389d3eac76db79ff20d8 When the page is not up to date, ecryptfs_prepare_write() should be acting much like ecryptfs_readpage(). This includes the painfully obvious step of actually decrypting the page contents read from the lower encrypted file. Note that this patch resolves a bug in eCryptfs in 2.6.24 that one can produce with these steps: # mount -t ecryptfs /secret /secret # echo "abc" > /secret/file.txt # umount /secret # mount -t ecryptfs /secret /secret # echo "def" >> /secret/file.txt # cat /secret/file.txt Without this patch, the resulting data returned from cat is likely to be something other than "abc\ndef\n". (Thanks to Benedikt Driessen for reporting this.) Signed-off-by: Michael Halcrow Cc: Benedikt Driessen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [chrisw@sous-sol.org: backport to 2.6.24.3] Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit f2336eeb199d3ed113e6d01c8020ea8919dd85c9 Author: Dan Williams Date: Tue Mar 4 19:40:09 2008 +0000 ioat: fix 'ack' handling, driver must ensure that 'ack' is zero commit: 6497dcffe07b7c3d863f9899280c4f6eae999161 Initialize 'ack' to zero in case the descriptor has been recycled. Prevents "kernel BUG at crypto/async_tx/async_xor.c:185!" Signed-off-by: Dan Williams Acked-by: Shannon Nelson [chrisw@sous-sol.org: backport to 2.6.24.3] Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 40f3601686b66ffa7c2cab2bbdff5ec0fc52aa43 Author: Atsushi Nemoto Date: Mon Mar 3 16:51:48 2008 +0100 macb: Fix speed setting commit: 179956f498bd8cc55fb803c4ee0cf18be59c8b01 Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by conversion to generic PHY layer in kernel 2.6.23. Signed-off-by: Atsushi Nemoto Signed-off-by: Jeff Garzik Signed-off-by: Haavard Skinnemoen Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit a542b46db3536a4009b618609058a44edad9d22d Author: Hiroshi Shimamoto Date: Wed Jan 30 13:33:00 2008 +0100 x86: move out tick_nohz_stop_sched_tick() call from the loop [upstream commit: 3d97775a] Move out tick_nohz_stop_sched_tick() call from the loop in cpu_idle same as 32-bit version. Signed-off-by: Hiroshi Shimamoto Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Cc: Ed Tomlinson Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 495b375c8798fd9bd7d084bacad100d249a0ddf2 Author: Atsushi Nemoto Date: Fri Feb 29 15:16:16 2008 +0100 atmel_spi: fix clock polarity commit: f6febccd7f86fbe94858a4a32d9384cc014c9f40 The atmel_spi driver does not initialize clock polarity correctly (except for at91rm9200 CS0 channel) in some case. The atmel_spi driver uses gpio-controlled chipselect. OTOH spi clock signal is controlled by CSRn.CPOL bit, but this register controls clock signal correctly only in 'real transfer' duration. At the time of cs_activate() call, CSRn.CPOL will be initialized correctly, but the controller do not know which channel is to be used next, so clock signal will stay at the inactive state of last transfer. If clock polarity of new transfer and last transfer was differ, new transfer will start with wrong clock signal state. For example, if you started SPI MODE 2 or 3 transfer after SPI MODE 0 or 1 transfer, the clock signal state at the assertion of chipselect will be low. Of course this will violates SPI transfer. This patch is short term solution for this problem. It makes all CSRn.CPOL match for the transfer before activating chipselect. For longer term, the best fix might be to let NPCS0 stay selected permanently in MR and overwrite CSR0 with to the new slave's settings before asserting CS. Signed-off-by: Atsushi Nemoto Acked-by: Haavard Skinnemoen Cc: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 061e98a971b62ce4ee25c6cbd88b46d9870d5d9f Author: Michael Buesch Date: Fri Feb 29 12:55:41 2008 +0100 b43: Backport bcm4311 fix This is a backport of upstream commit 013978b6 ("b43: Changes to enable BCM4311 rev 02 with wireless core revision 13") and the changes include the following: (1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43. (2) Add PHY revision 9 to the supported list. (3) Change the 2-bit routing code for address extensions to 0b10 rather than the 0b01 used for the 32-bit case. (4) Remove some magic numbers in the DMA setup. The DMA implementation for this chip supports full 64-bit addressing with one exception. Whenever the Descriptor Ring Buffer is in high memory, a fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due to code to "Bias the placement of kernel pages at lower PFNs". When commit 44048d70 reverted that code, the DMA error appeared. As a "fix", use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present, this problem is thought to arise from a hardware error. Signed-off-by: Michael Buesch Cc: Larry Finger Cc: John W. Linville Cc: Alexey Zaytsev Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit d5940b2fc01d028b1cffb271294667f81e6a819a Author: Mike Pagano Date: Wed Feb 27 19:35:01 2008 -0500 arcmsr: fix IRQs disabled warning spew As of 2.6.24, running the archttp passthrough daemon with the arcmsr driver produces an endless spew of dma_free_coherent warnings: WARNING: at arch/x86/kernel/pci-dma_64.c:169 dma_free_coherent() It turns out that coherent memory is not needed, so commit 76d78300 by Nick Cheng switched it to kmalloc (as well as making a lot of other changes which have not been included here). James Bottomley pointed out that the new kmalloc usage was also wrong, I corrected this in commit 69e562c2. This patch combines both of the above for the purpose of fixing 2.6.24. details in http://bugs.gentoo.org/208493. Signed-off-by: Daniel Drake Cc: Nick Cheng Cc: James Bottomley Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 535d75274d992be482951967af0ec4d99c99fadc Author: Auke Kok Date: Tue Feb 12 15:20:24 2008 -0800 e1000e: Fix CRC stripping in hardware context bug CRC stripping was only correctly enabled for packet split recieves which is used when receiving jumbo frames. Correctly enable SECRC also for normal buffer packet receives. Tested by Andy Gospodarek and Johan Andersson, see bugzilla #9940. Signed-off-by: Auke Kok Signed-off-by: Jeff Garzik Cc: Mike Pagano Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit b39bf4a535df7afb304cc3884b669210036cb960 Author: Ivan Kokshaysky Date: Mon Jan 14 17:31:09 2008 -0500 PCI x86: always use conf1 to access config space below 256 bytes [upsteam commit: a0ca9909] Thanks to Loic Prylli , who originally proposed this idea. Always using legacy configuration mechanism for the legacy config space and extended mechanism (mmconf) for the extended config space is a simple and very logical approach. It's supposed to resolve all known mmconf problems. It still allows per-device quirks (tweaking dev->cfg_size). It also allows to get rid of mmconf fallback code. This patch fixes a boot hang on Intel Q35 chipset as detailed at: http://bugs.gentoo.org/198810 Signed-off-by: Ivan Kokshaysky Signed-off-by: Matthew Wilcox Signed-off-by: Linus Torvalds Cc: Mike Pagano Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit d25532f4d8283edb7f844ae5a7770cbd51d05dc8 Author: Ivan Kokshaysky Date: Wed Feb 13 15:03:26 2008 -0800 moduleparam: fix alpha, ia64 and ppc64 compile failures [upstream commit: 91d35dd9] On alpha, ia64 and ppc64 only relocations to local data can go into read-only sections. The vast majority of module parameters use the global generic param_set_*/param_get_* functions, so the 'const' attribute for struct kernel_param is not only useless, but it also causes compile failures due to 'section type conflict' in those rare cases where param_set/get are local functions. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8964 Signed-off-by: Ivan Kokshaysky Cc: Richard Henderson Cc: Tony Luck Cc: Anton Blanchard Cc: Paul Mackerras Cc: Adrian Bunk Cc: Kamalesh Babulal Cc: Rusty Russell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Mike Pagano [chrisw@sous-sol.org: backport to 2.6.24.3] Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 9256d0b8cb13a854c0a29861ce37a252f7712568 Author: Alan Cox Date: Tue Feb 26 13:35:54 2008 -0800 pata_hpt*, pata_serverworks: fix UDMA masking [upstream commit: 6ddd6861] When masking, mask out the modes that are unsupported not the ones that are supported. This makes life happier. Signed-off-by: Alan Cox Signed-off-by: Andrew Morton Signed-off-by: Jeff Garzik Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit db29706ff57deba8866fb4681a1a8b99bf59c805 Author: FUJITA Tomonori Date: Wed Feb 27 02:06:18 2008 +0900 SCSI advansys: fix overrun_buf aligned bug commit 7d5d408c77cee95d1380511de46b7a4c8dc2211d struct asc_dvc_var needs overrun buffer to be placed on an 8 byte boundary. advansys defines struct asc_dvc_var: struct asc_dvc_var { ... uchar overrun_buf[ASC_OVERRUN_BSIZE] __aligned(8); The problem is that struct asc_dvc_var is placed on shost->hostdata. So if the hostdata is not on an 8 byte boundary, the advansys crashes. The hostdata is placed on a sizeof(unsigned long) boundary so the 8 byte boundary is not garanteed with x86_32. With 2.6.23 and 2.6.24, the hostdata is on an 8 byte boundary by chance, but with the current git, it's not. This patch removes overrun_buf static array and use kzalloc. Signed-off-by: FUJITA Tomonori Signed-off-by: James Bottomley FUJITA Tomonori notes: We thought that 2.6.24 doesn't have this bug, however it does. Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 3752f4024d617852b6d4758b9a7ac89a530cf98e Author: Patrick McHardy Date: Mon Feb 25 15:01:04 2008 +0100 NETFILTER: fix ebtable targets return Upstream commit 1b04ab459: The function ebt_do_table doesn't take NF_DROP as a verdict from the targets. Signed-off-by: Joonwoo Park Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit bc7869bf6e038edaccc9ad9e8ba9e300f96dddee Author: Patrick McHardy Date: Mon Feb 25 15:01:02 2008 +0100 NETFILTER: Fix incorrect use of skb_make_writable Upstream commit eb1197bc0: http://bugzilla.kernel.org/show_bug.cgi?id=9920 The function skb_make_writable returns true or false. Signed-off-by: Joonwoo Park Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit ca02fcbe2193c3947466f5659fc7ac7b851ea20b Author: Patrick McHardy Date: Mon Feb 25 15:01:01 2008 +0100 NETFILTER: nfnetlink_queue: fix SKB_LINEAR_ASSERT when mangling packet data Upstream commit e2b58a67: As reported by Tomas Simonaitis , inserting new data in skbs queued over {ip,ip6,nfnetlink}_queue triggers a SKB_LINEAR_ASSERT in skb_put(). Going back through the git history, it seems this bug is present since at least 2.6.12-rc2, probably even since the removal of skb_linearize() for netfilter. Linearize non-linear skbs through skb_copy_expand() when enlarging them. Tested by Thomas, fixes bugzilla #9933. Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit d8d644bcd0e46dc2a354ffce219a788630a0cdcc Author: Ned Forrester Date: Sun Feb 24 02:10:06 2008 +0000 spi: pxa2xx_spi clock polarity fix commit: b97c74bddce4e2c6fef6b3b58910b4fd9eb7f3b8 Fixes a sequencing bug in spi driver pxa2xx_spi.c in which the chip select for a transfer may be asserted before the clock polarity is set on the interface. As a result of this bug, the clock signal may have the wrong polarity at transfer start, so it may need to make an extra half transition before the intended clock/data signals begin. (This probably means all transfers are one bit out of sequence.) This only occurs on the first transfer following a change in clock polarity in systems using more than one more than one such polarity. The fix assures that the clock mode is properly set before asserting chip select. This bug was introduced in a patch merged on 2006/12/10, kernel 2.6.20. The patch defines an additional bit in: include/asm-arm/arch-pxa/regs-ssp.h for 2.6.25 and newer kernels but this addition must be made in: include/asm-arm/arch-pxa/pxa-regs.h for kernels between 2.6.20 and 2.6.24, inclusive Signed-off-by: Ned Forrester Signed-off-by: David Brownell Cc: Russell King Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [chrisw@sous-sol.org: backport to 2.6.24.3] Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 55004de819a04430d92aaa5f6c39464862b57028 Author: Roel Kluin <12o3l@tiscali.nl> Date: Sun Feb 24 02:10:08 2008 +0000 ufs: fix parenthesisation in ufs_set_fs_state() commit: f81e8a43871f44f98dd14e83a83bf9ca0b3b46c5 This bug snuck in with commit 252e211e90ce56bf005cb533ad5a297c18c19407 Author: Mark Fortescue Date: Tue Oct 16 23:26:31 2007 -0700 Add in SunOS 4.1.x compatible mode for UFS Signed-off-by: Roel Kluin <12o3l@tiscali.nl> Acked-by: Evgeniy Dushistov Cc: Mark Fortescue Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 83e8acc059f9b3075de6b4386488f09abc9a4868 Author: Andy Whitcroft Date: Sun Feb 24 02:10:08 2008 +0000 hugetlb: ensure we do not reference a surplus page after handing it to buddy commit: e5df70ab194543522397fa3da8c8f80564a0f7d3 When we free a page via free_huge_page and we detect that we are in surplus the page will be returned to the buddy. After this we no longer own the page. However at the end free_huge_page we clear out our mapping pointer from page private. Even where the page is not a surplus we free the page to the hugepage pool, drop the pool locks and then clear page private. In either case the page may have been reallocated. BAD. Make sure we clear out page private before we free the page. Signed-off-by: Andy Whitcroft Acked-by: Adam Litke Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 2628814b59f33d6a1aae535adc7ef44359aafe98 Author: Serge E. Hallyn Date: Sun Feb 24 02:10:07 2008 +0000 file capabilities: simplify signal check commit: 094972840f2e7c1c6fc9e1a97d817cc17085378e Simplify the uid equivalence check in cap_task_kill(). Anyone can kill a process owned by the same uid. Without this patch wireshark is reported to fail. Signed-off-by: Serge E. Hallyn Signed-off-by: Andrew G. Morgan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit f9e77acd4060fefbb60a351cdb8d30fca27fe194 Author: Thomas Gleixner Date: Sun Feb 24 02:10:05 2008 +0000 futex: runtime enable pi and robust functionality commit: a0c1e9073ef7428a14309cba010633a6cd6719ea Not all architectures implement futex_atomic_cmpxchg_inatomic(). The default implementation returns -ENOSYS, which is currently not handled inside of the futex guts. Futex PI calls and robust list exits with a held futex result in an endless loop in the futex code on architectures which have no support. Fixing up every place where futex_atomic_cmpxchg_inatomic() is called would add a fair amount of extra if/else constructs to the already complex code. It is also not possible to disable the robust feature before user space tries to register robust lists. Compile time disabling is not a good idea either, as there are already architectures with runtime detection of futex_atomic_cmpxchg_inatomic support. Detect the functionality at runtime instead by calling cmpxchg_futex_value_locked() with a NULL pointer from the futex initialization code. This is guaranteed to fail, but the call of futex_atomic_cmpxchg_inatomic() happens with pagefaults disabled. On architectures, which use the asm-generic implementation or have a runtime CPU feature detection, a -ENOSYS return value disables the PI/robust features. On architectures with a working implementation the call returns -EFAULT and the PI/robust features are enabled. The relevant syscalls return -ENOSYS and the robust list exit code is blocked, when the detection fails. Fixes http://lkml.org/lkml/2008/2/11/149 Originally reported by: Lennart Buytenhek Signed-off-by: Thomas Gleixner Acked-by: Ingo Molnar Cc: Lennert Buytenhek Cc: Riku Voipio Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit c51d3bbd2c2256e2567984068bc0950b4ac73e49 Author: Thomas Gleixner Date: Sun Feb 24 02:10:06 2008 +0000 futex: fix init order commit: 3e4ab747efa8e78562ec6782b08bbf21a00aba1b When the futex init code fails to initialize the futex pseudo file system it returns early without initializing the hash queues. Should the boot succeed then a futex syscall which tries to enqueue a waiter on the hashqueue will crash due to the unitilialized plist heads. Initialize the hash queues before the filesystem. Signed-off-by: Thomas Gleixner Acked-by: Ingo Molnar Cc: Lennert Buytenhek Cc: Riku Voipio Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit e08b12e87e90a96df9380e8b17424e939c9f3448 Author: Russell King Date: Sun Feb 24 15:55:37 2008 +0100 ARM pxa: fix clock lookup to find specific device clocks commit: a0dd005d1d9f4c3beab52086f3844ef9342d1e67 Ensure that the clock lookup always finds an entry for a specific device and ID before it falls back to finding just by ID. This fixes a problem reported by Holger Schurig where the BTUART was assigned the wrong clock. Tested-by: Holger Schurig Signed-off-by: Russell King Uli Luckas notes: The patch fixes the otherwise unusable bluetooth uart on pxa25x. The patch is written by Russell King [1] who also gave his OK for stable inclusion [2]. The patch is also available as commit a0dd005d1d9f4c3beab52086f3844ef9342d1e67 to Linus' tree. [1] http://marc.info/?l=linux-arm-kernel&m=120298366510315 [2] http://marc.info/?l=linux-arm-kernel&m=120384388411097 Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 512ec490759a432367546adff16877e9dd9e5409 Author: Thomas Gleixner Date: Sat Feb 23 11:56:56 2008 -0500 x86: replace LOCK_PREFIX in futex.h Commit: 9d55b9923a1b7ea8193b8875c57ec940dc2ff027 The exception fixup for the futex macros __futex_atomic_op1/2 and futex_atomic_cmpxchg_inatomic() is missing an entry when the lock prefix is replaced by a NOP via SMP alternatives. Chuck Ebert tracked this down from the information provided in: https://bugzilla.redhat.com/show_bug.cgi?id=429412 A possible solution would be to add another fixup after the LOCK_PREFIX, so both the LOCK and NOP case have their own entry in the exception table, but it's not really worth the trouble. Simply replace LOCK_PREFIX with lock and keep those untouched by SMP alternatives. Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar [cebbert@redhat.com: backport to 2.6.24] Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 2d367bd043bee47750b26b2a5fbdf998cfa78fe5 Author: James Bottomley Date: Sat Feb 23 20:55:15 2008 +0000 SCSI aic94xx: fix REQ_TASK_ABORT and REQ_DEVICE_RESET commit: cb84e2d2ff3b50c0da5a7604a6d8634294a00a01 This driver has been failing under heavy load with aic94xx: escb_tasklet_complete: REQ_TASK_ABORT, reason=0x6 aic94xx: escb_tasklet_complete: Can't find task (tc=4) to abort! The second message is because the driver fails to identify the task it's being asked to abort. On closer inpection, there's a thinko in the for each task loop over pending tasks in both the REQ_TASK_ABORT and REQ_DEVICE_RESET cases where it doesn't look at the task on the pending list but at the one on the ESCB (which is always NULL). Fix by looking at the right task. Also add a print for the case where the pending SCB doesn't have a task attached. Not sure if this will fix all the problems, but it's a definite first step. Signed-off-by: James Bottomley Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 461bab342d2601c5e032f85b27e66beafef66ff8 Author: James Bottomley Date: Sat Feb 23 20:55:14 2008 +0000 SCSI gdth: don't call pci_free_consistent under spinlock commit: ff83efacf2b77a1fe8942db6613825a4b80ee5e2 The spinlock is held over too large a region: pscratch is a permanent address (it's allocated at boot time and never changes). All you need the smp lock for is mediating the scratch in use flag, so fix this by moving the spinlock into the case where we set the pscratch_busy flag to false. Signed-off-by: James Bottomley Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit f59549d67e4d2f236a87f7d9d2e48dfe84d70f6b Author: FUJITA Tomonori Date: Sat Feb 23 20:55:12 2008 +0000 SCSI ips: fix data buffer accessors conversion bug commit: 2b28a4721e068ac89bd5435472723a1bc44442fe This fixes a bug that can't handle a passthru command with more than two sg entries. Big thanks to Tim Pepper for debugging the problem. Signed-off-by: FUJITA Tomonori Acked-by: Mark Salyzyn Signed-off-by: James Bottomley Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 90fbe8b1fa081a99616ccd7760f5877fcafa35ef Author: Alan Stern Date: Fri Feb 22 17:03:25 2008 -0500 usb-storage: don't access beyond the end of the sg buffer This patch (as1038) fixes a bug in usb_stor_access_xfer_buf() and usb_stor_set_xfer_buf() (the bug was originally found by Boaz Harrosh): The routine must not attempt to write beyond the end of a scatter-gather list or beyond the number of bytes requested. This is the minimal 2.6.24 equivalent to as1035 + as1037 (7084191d53b224b953c8e1db525ea6c31aca5fc7 "USB: usb-storage: don't access beyond the end of the sg buffer" + 6d512a80c26d87f8599057c86dc920fbfe0aa3aa "usb-storage: update earlier scatter-gather bug fix"). Mark Glines has confirmed that it fixes his problem. Signed-off-by: Alan Stern Cc: Mark Glines Cc: Boaz Harrosh Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 759be208409db44bdc81bd28156c38e4f9501ecd Author: Miklos Szeredi Date: Sat Feb 23 15:23:27 2008 -0800 fuse: fix permission checking [upstream commit 1a823ac9ff09cbdf39201df37b7ede1f9395de83] I added a nasty local variable shadowing bug to fuse in 2.6.24, with the result, that the 'default_permissions' mount option is basically ignored. How did this happen? - old err declaration in inner scope - new err getting declared in outer scope - 'return err' from inner scope getting removed - old declaration not being noticed -Wshadow would have saved us, but it doesn't seem practical for the kernel :( More testing would have also saved us :(( Signed-off-by: Miklos Szeredi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 7c0f76561fdc0a24ebfae4ee4112d62473eb3bdc Author: Sebastian Siewior Date: Wed Mar 12 12:18:36 2008 +0800 CRYPTO xts: Use proper alignment [ Upstream commit: 6212f2c7f70c591efb0d9f3d50ad29112392fee2 ] The XTS blockmode uses a copy of the IV which is saved on the stack and may or may not be properly aligned. If it is not, it will break hardware cipher like the geode or padlock. This patch encrypts the IV in place so we don't have to worry about alignment. Signed-off-by: Sebastian Siewior Tested-by: Stefan Hellermann Signed-off-by: Herbert Xu Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 0c7ac6f8e603b7e33c7ee268c30f2de59111951c Author: Joy Latten Date: Wed Mar 12 12:17:45 2008 +0800 CRYPTO xcbc: Fix crash with IPsec [ Upstream commit: 2f40a178e70030c4712fe63807c883f34c3645eb ] When using aes-xcbc-mac for authentication in IPsec, the kernel crashes. It seems this algorithm doesn't account for the space IPsec may make in scatterlist for authtag. Thus when crypto_xcbc_digest_update2() gets called, nbytes may be less than sg[i].length. Since nbytes is an unsigned number, it wraps at the end of the loop allowing us to go back into loop and causing crash in memcpy. I used update function in digest.c to model this fix. Please let me know if it looks ok. Signed-off-by: Joy Latten Signed-off-by: Herbert Xu Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 0ad5232c1ccba61437676cdb88d030b1c369dec7 Author: Jeff Garzik Date: Wed Mar 12 10:25:42 2008 +0900 SCSI ips: handle scsi_add_host() failure, and other err cleanups commit 2551a13e61d3c3df6c2da6de5a3ece78e6d67111 Signed-off-by: Jeff Garzik Acked-by: Mark Salyzyn Signed-off-by: Andrew Morton Signed-off-by: James Bottomley FUJITA Tomonori notes: It didn't intend to fix a critical bug, however, it turned out that it does. Without this patch, the ips driver in 2.6.23 and 2.6.24 doesn't work at all. You can find the more details at the following thread: http://marc.info/?t=120293911900023&r=1&w=2 Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 41abba651b51394ae1119ac26bd1dd2e31bc2dc0 Author: Jan Beulich Date: Tue Mar 11 11:30:25 2008 +0100 x86: adjust enable_NMI_through_LVT0() commit e94271017f0933b29362a3c9dea5a6b9d04d98e1 Its previous use in a call to on_each_cpu() was pointless, as at the time that code gets executed only one CPU is online. Further, the function can be __cpuinit, and for this to work without CONFIG_HOTPLUG_CPU setup_nmi() must also get an attribute (this one can even be __init; on 64-bits check_timer() also was lacking that attribute). Signed-off-by: Jan Beulich Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner [ tglx@linutronix.de: backport to 2.6.24.3] Cc: Justin Piszcz Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit c9ef5a43530e7dbec05c1dad59356f85516d2c0b Author: James Bottomley Date: Tue Mar 11 01:50:07 2008 +0000 drivers: fix dma_get_required_mask commit: e88a0c2ca81207a75afe5bbb8020541dabf606ac Date: Sun, 9 Mar 2008 11:57:56 -0500 Subject: drivers: fix dma_get_required_mask There's a bug in the current implementation of dma_get_required_mask() where it ands the returned mask with the current device mask. This rather defeats the purpose if you're using the call to determine what your mask should be (since you will at that time have the default DMA_32BIT_MASK). This bug results in any driver that uses this function *always* getting a 32 bit mask, which is wrong. Fix by removing the and with dev->dma_mask. Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit b6845726368e5b7b086e6d6438c9380bf5b7bc1c Author: Nick Piggin Date: Tue Mar 11 01:50:06 2008 +0000 iov_iter_advance() fix commit: f7009264c519603b8ec67c881bd368a56703cfc9 iov_iter_advance() skips over zero-length iovecs, however it does not properly terminate at the end of the iovec array. Fix this by checking against i->count before we skip a zero-length iov. The bug was reproduced with a test program that continually randomly creates iovs to writev. The fix was also verified with the same program and also it could verify that the correct data was contained in the file after each writev. Signed-off-by: Nick Piggin Tested-by: "Kevin Coffman" Cc: "Alexey Dobriyan" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit cc7571b226c93b032164ebb3ff3b365651c4652f Author: Aurelien Jarno Date: Sat Mar 8 11:43:52 2008 +0100 x86: Clear DF before calling signal handler x86: Clear DF before calling signal handler The Linux kernel currently does not clear the direction flag before calling a signal handler, whereas the x86/x86-64 ABI requires that. This become a real problem with gcc version 4.3, which assumes that the direction flag is correctly cleared at the entry of a function. This patches changes the setup_frame() functions to clear the direction before entering the signal handler. This is a backport of patch e40cd10ccff3d9fbffd57b93780bee4b7b9bff51 ("x86: clear DF before calling signal handler") that has been applied in 2.6.25-rc. Signed-off-by: Aurelien Jarno Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit b83b97b0e5185e2c9c80824e2dd880419c200c09 Author: Pete Zaitcev Date: Fri Mar 7 17:36:54 2008 +0100 ub: fix up the conversion to sg_init_table() Signed-off-by: Pete Zaitcev Cc: "Oliver Pinter" Cc: FUJITA Tomonori Cc: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit a1843b4dedab81c769ccdce4ec9ed2fce6f6ad90 Author: Ralf Baechle Date: Fri Feb 8 04:22:02 2008 -0800 MIPS: Mark all but i8259 interrupts as no-probe. Use set_irq_noprobe() to mark all MIPS interrupts as non-probe. Override that default for i8259 interrupts. Signed-off-by: Ralf Baechle Acked-and-tested-by: Rob Landley Cc: Alan Cox Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 6224c2148e2d6df8d537f081e31381a18eee918e Author: Ralf Baechle Date: Fri Feb 8 04:22:01 2008 -0800 IRQ_NOPROBE helper functions Probing non-ISA interrupts using the handle_percpu_irq as their handle_irq method may crash the system because handle_percpu_irq does not check IRQ_WAITING. This for example hits the MIPS Qemu configuration. This patch provides two helper functions set_irq_noprobe and set_irq_probe to set rsp. clear the IRQ_NOPROBE flag. The only current caller is MIPS code but this really belongs into generic code. As an aside, interrupt probing these days has become a mostly obsolete if not dangerous art. I think Linux interrupts should be changed to default to non-probing but that's subject of this patch. Signed-off-by: Ralf Baechle Acked-and-tested-by: Rob Landley Cc: Alan Cox Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 11b47c8828d4cd1df21636719603784ec5e26067 Author: Herbert Xu Date: Wed Mar 5 20:07:37 2008 -0800 IPCOMP: Disable BH on output when using shared tfm Upstream commit: 21e43188f272c7fd9efc84b8244c0b1dfccaa105 Because we use shared tfm objects in order to conserve memory, (each tfm requires 128K of vmalloc memory), BH needs to be turned off on output as that can occur in process context. Previously this was done implicitly by the xfrm output code. That was lost when it became lockless. So we need to add the BH disabling to IPComp directly. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 5eb4efe242d2fbd36551f6016707ee280bb30f31 Author: Stephen Hemminger Date: Wed Mar 5 14:44:01 2008 -0800 IPCONFIG: The kernel gets no IP from some DHCP servers Upstream commit: dea75bdfa57f75a7a7ec2961ec28db506c18e5db From: Stephen Hemminger Based upon a patch by Marcel Wappler: This patch fixes a DHCP issue of the kernel: some DHCP servers (i.e. in the Linksys WRT54Gv5) are very strict about the contents of the DHCPDISCOVER packet they receive from clients. Table 5 in RFC2131 page 36 requests the fields 'ciaddr' and 'siaddr' MUST be set to '0'. These DHCP servers ignore Linux kernel's DHCP discovery packets with these two fields set to '255.255.255.255' (in contrast to popular DHCP clients, such as 'dhclient' or 'udhcpc'). This leads to a not booting system. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 44e77f1afc44a41375c4dc16d26459a3bbfddf61 Author: David S. Miller Date: Wed Mar 5 14:44:30 2008 -0800 IPV4: Remove IP_TOS setting privilege checks. Upstream commit: e4f8b5d4edc1edb0709531bd1a342655d5e8b98e Various RFCs have all sorts of things to say about the CS field of the DSCP value. In particular they try to make the distinction between values that should be used by "user applications" and things like routing daemons. This seems to have influenced the CAP_NET_ADMIN check which exists for IP_TOS socket option settings, but in fact it has an off-by-one error so it wasn't allowing CS5 which is meant for "user applications" as well. Further adding to the inconsistency and brokenness here, IPV6 does not validate the DSCP values specified for the IPV6_TCLASS socket option. The real actual uses of these TOS values are system specific in the final analysis, and these RFC recommendations are just that, "a recommendation". In fact the standards very purposefully use "SHOULD" and "SHOULD NOT" when describing how these values can be used. In the final analysis the only clean way to provide consistency here is to remove the CAP_NET_ADMIN check. The alternatives just don't work out: 1) If we add the CAP_NET_ADMIN check to ipv6, this can break existing setups. 2) If we just fix the off-by-one error in the class comparison in IPV4, certain DSCP values can be used in IPV6 but not IPV4 by default. So people will just ask for a sysctl asking to override that. I checked several other freely available kernel trees and they do not make any privilege checks in this area like we do. For the BSD stacks, this goes back all the way to Stevens Volume 2 and beyond. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit bb59adefa5eccfde1e7e174a8fb48fe45bc089f9 Author: Denis V. Lunev Date: Wed Mar 5 14:43:05 2008 -0800 IPV6: dst_entry leak in ip4ip6_err. Upstream commit: 9937ded8e44de8865cba1509d24eea9d350cebf0 The result of the ip_route_output is not assigned to skb. This means that - it is leaked - possible OOPS below dereferrencing skb->dst - no ICMP message for this case Signed-off-by: Denis V. Lunev Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit ba8fd2d277fcc06905a45380a2203c4bd9d8d025 Author: Herbert Xu Date: Wed Mar 5 14:46:35 2008 -0800 IPV6: Fix IPsec datagram fragmentation Upstream commits: 28a89453b1e8de8d777ad96fa1eef27b5d1ce074 b5c15fc004ac83b7ad280acbe0fd4bbed7e2c8d4 This is a long-standing bug in the IPsec IPv6 code that breaks when we emit a IPsec tunnel-mode datagram packet. The problem is that the code the emits the packet assumes the IPv6 stack will fragment it later, but the IPv6 stack assumes that whoever is emitting the packet is going to pre-fragment the packet. In the long term we need to fix both sides, e.g., to get the datagram code to pre-fragment as well as to get the IPv6 stack to fragment locally generated tunnel-mode packet. For now this patch does the second part which should make it work for the IPsec host case. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 430ff1d0b6e50d7665baf3d8dc1ef83d3295c9ad Author: Matti Linnanvuori Date: Wed Mar 5 14:42:41 2008 -0800 NET: Fix race in dev_close(). (Bug 9750) Upstream commit: d8b2a4d21e0b37b9669b202867bfef19f68f786a There is a race in Linux kernel file net/core/dev.c, function dev_close. The function calls function dev_deactivate, which calls function dev_watchdog_down that deletes the watchdog timer. However, after that, a driver can call netif_carrier_ok, which calls function __netdev_watchdog_up that can add the watchdog timer again. Function unregister_netdevice calls function dev_shutdown that traps the bug !timer_pending(&dev->watchdog_timer). Moving dev_deactivate after netif_running() has been cleared prevents function netif_carrier_on from calling __netdev_watchdog_up and adding the watchdog timer again. Signed-off-by: Matti Linnanvuori Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 53a8bf30f67d9a10e1b8e0adfed889d3a5694813 Author: Jorge Boncompte [DTI2] Date: Wed Mar 5 14:47:01 2008 -0800 NET: Messed multicast lists after dev_mc_sync/unsync Upstream commit: 12aa343add3eced38a44bdb612b35fdf634d918c Commit a0a400d79e3dd7843e7e81baa3ef2957bdc292d0 ("[NET]: dev_mcast: add multicast list synchronization helpers") from you introduced a new field "da_synced" to struct dev_addr_list that is not properly initialized to 0. So when any of the current users (8021q, macvlan, mac80211) calls dev_mc_sync/unsync they mess the address list for both devices. The attached patch fixed it for me and avoid future problems. Signed-off-by: Jorge Boncompte [DTI2] Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 887b7b08e75ee7dae5da7924291cd90d4bcb5b40 Author: David S. Miller Date: Wed Mar 5 14:49:01 2008 -0800 NIU: Bump driver version and release date. Upstream commit: a442585952f137bd4cdb1f2f3166e4157d383b82 Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 6a9d3b1f4ec21b365f027d241bbfc871c4c91152 Author: Matheos Worku Date: Wed Mar 5 14:47:36 2008 -0800 NIU: Fix BMAC alternate MAC address indexing. Upstream commit: 3b5bcedeeb755b6e813537fcf4c32f010b490aef BMAC port alternate MAC address index needs to start at 1. Index 0 is used for the main MAC address. Signed-off-by: Matheos Worku Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 958346d4b18fa1474a706a535396e94a6eaf5fb4 Author: Matheos Worku Date: Wed Mar 5 14:48:37 2008 -0800 NIU: More BMAC alt MAC address fixes. Upstream commit: fa907895b7b776208a1406efe5ba7ffe0f49f507 From: Matheos Worku 1) niu_enable_alt_mac() needs to be adjusted so that the mask is computed properly for the BMAC case. 2) BMAC has 6 alt MAC addresses available, not 7. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit beeb75e6ebc60fb4323f9ce5cfeffaea5ccffc36 Author: David S. Miller Date: Wed Mar 5 14:49:24 2008 -0800 TCP: Improve ipv4 established hash function. Upstream commit: 7adc3830f90df04a13366914d80a3ed407db5381 If all of the entropy is in the local and foreign addresses, but xor'ing together would cancel out that entropy, the current hash performs poorly. Suggested by Cosmin Ratiu: Basically, the situation is as follows: There is a client machine and a server machine. Both create 15000 virtual interfaces, open up a socket for each pair of interfaces and do SIP traffic. By profiling I noticed that there is a lot of time spent walking the established hash chains with this particular setup. The addresses were distributed like this: client interfaces were 198.18.0.1/16 with increments of 1 and server interfaces were 198.18.128.1/16 with increments of 1. As I said, there were 15000 interfaces. Source and destination ports were 5060 for each connection. So in this case, ports don't matter for hashing purposes, and the bits from the address pairs used cancel each other, meaning there are no differences in the whole lot of pairs, so they all end up in the same hash chain. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 7564c2eb8926cc19fe06f8b0c6f9f08628c544da Author: David S. Miller Date: Thu Mar 6 14:47:51 2008 -0800 SPARC: Fix link errors with gcc-4.3 Upstream commit: f0e98c387e61de00646be31fab4c2fa0224e1efb Reported by Adrian Bunk. Just like in changeset a3f9985843b674cbcb58f39fab8416675e7ab842 ("[SPARC64]: Move kernel unaligned trap handlers into assembler file.") we have to move the assembler bits into a seperate asm file because as far as the compiler is concerned these inline bits we're doing in unaligned.c are unreachable. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 68b498d251d97de9adda518fda42cfe1451063b7 Author: David S. Miller Date: Thu Mar 6 14:47:20 2008 -0800 SPARC64: Loosen checks in exception table handling. Upstream commits: 622eaec613130e6ea78f2a5d5070e3278b21cd8f be71716e464f4ea38f08034dc666f2feb55535d9 Some parts of the kernel now do things like do *_user() accesses while set_fs(KERNEL_DS) that fault on purpose. See, for example, the code added by changeset a0c1e9073ef7428a14309cba010633a6cd6719ea ("futex: runtime enable pi and robust functionality"). That trips up the ASI sanity checking we make in do_kernel_fault(). Just remove it for now. Maybe we can add it back later with an added conditional which looks at the current get_fs() value. Also, because of the new futex validation init handler, we have to accept faults in init section text as well as the normal kernel text. Thanks to Tom Callaway for the bug report. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 5c2699a0d511a78ae8692ab08f4a332a634b0d67 Author: Greg Kroah-Hartman Date: Thu Mar 6 16:00:36 2008 -0800 Revert "NET: Add if_addrlabel.h to sanitized headers." This reverts commit 5fb7ba76544d95bfa05199f7394a442de5660be7. It was incorrectly added to the .24.y stable tree and causes build breakages. Cc: Stephen Hemminger Cc: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright