- 24 Mar, 2008 40 commits
-
-
Chris Wright authored
-
Heiko Carstens authored
a0c1e907 "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 <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Joe Korty authored
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 <joe.korty@ccur.com> Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Jens Axboe authored
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 <jens.axboe@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
Dave Young authored
Jens Axboe noticed that we were queueing &conn->work on both btaddconn and keventd_wq. Signed-off-by:
Dave Young <hidave.darkstar@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Matthew Wilcox authored
commit: 951b62c1 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 <willy@linux.intel.com> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Dan Williams authored
commit: 8d8002f6 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: <stable@kernel.org> Cc: Neil Brown <neilb@suse.de> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> [chrisw@sous-sol.org: backport to 2.6.24.3] Signed-off-by:
-
Quentin Barnes authored
commit: 6cb2a210 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 <qbarnes+linux@yahoo-inc.com> Reviewed-by:
Zach Brown <zach.brown@oracle.com> Cc: Benjamin LaHaise <bcrl@kvack.org> Cc: <stable@kernel.org> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> [ 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 <torvalds@linux-foundation.org> Signed-off-by:
-
Duane Griffin authored
commit: 439aeec6 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 <duaneg@dghda.com> Acked-by:
Jan Kara <jack@suse.cz> Cc: <linux-ext4@vger.kernel.org> Signed-off-by:
-
Duane Griffin authored
commit: d0025676 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:
-
Dave Young authored
commit: 08ca0db8 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:
Christian Perle <chris@linuxinfotag.de> Signed-off-by:
-
Eric Leblond authored
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 <eric@inl.fr> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Eric Leblond authored
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:
-
Jan Engelhardt authored
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 <jengelh@computergmbh.de> Signed-off-by:
-
Michal Schmidt authored
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 fa85ae24 "sched: rt time limit" (in 2.6.25-rc1). Signed-off-by:
Michal Schmidt <mschmidt@redhat.com> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
J. Bruce Fields authored
This bug was always here, but before my commit 6fa02839 ("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 <bfields@citi.umich.edu> Cc: Lukas Hejtmanek <xhejtman@ics.muni.cz> Signed-off-by:
-
Hiroshi Shimamoto authored
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 <h-shimamoto@ct.jp.nec.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> [chrisw@sous-sol.org: backport to 2.6.24.3] Signed-off-by:
-
Krzysztof Oledzki authored
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 <ole@ans.pl> Acked-by:
Eric Moore <Eric.Moore@lsi.com> Signed-off-by:
-
Boaz Harrosh authored
commit: ee54cc6a 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 <bharrosh@panasas.com> Tested-by:
Joerg Dorchain: <joerg@dorchain.net> Tested-by:
Stefan Priebe <s.priebe@allied-internet.ag> Tested-by:
Jon Chelton <jchelton@ffpglobal.com> Signed-off-by:
-
Boaz Harrosh authored
commit: b31ddd31 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:
-
Samuel Thibault authored
commit: 5ce2087e 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 <samuel.thibault@ens-lyon.org> Signed-off-by:
Tony Breeds <tony@bakeyournoodle.com> Signed-off-by:
-
H. Peter Anvin authored
Commit: 959b3be6 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 <hpa@zytor.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> [cebbert@redhat.com: backport take 2, with parens this time] Signed-off-by:
-
Tony Battersby authored
commit: 4d2de3a5 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 <tonyb@cybernetics.com> Acked-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
-
Misha Zhilin authored
commit: b5f7a0ec 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 14c04c0f ), 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 <misha@epiphan.com> Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Sven Andersen authored
[upstream commit: 4ae897df ] Add EM1010PC to ftdi_sio.c Signed-off-by:
Sven Andersen <s.andersen@cryonet.de> Cc: stable <stable@kernel.org> Signed-off-by:
-
Kevin Vance authored
commit: 546d7eec 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 <kvance@kvance.com> Signed-off-by:
-
Samuel Thibault authored
commit: 8182ec49 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:
-
Michael Halcrow authored
commit: e4465fda 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 <mhalcrow@us.ibm.com> Cc: Benedikt Driessen <bdriessen@escrypt.com> Signed-off-by:
-
Dan Williams authored
commit: 6497dcff 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:
Shannon Nelson <shannon.nelson@intel.com> [chrisw@sous-sol.org: backport to 2.6.24.3] Signed-off-by:
-
Atsushi Nemoto authored
commit: 179956f4 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 <anemo@mba.ocn.ne.jp> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by:
-
Hiroshi Shimamoto authored
[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:
-
Atsushi Nemoto authored
commit: f6febccd 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:
-
Michael Buesch authored
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 <mb@bu3sch.de> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: John W. Linville <linville@tuxdriver.com> Cc: Alexey Zaytsev <alexey.zaytsev@gmail.com> Signed-off-by:
-
Mike Pagano authored
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 <nick.cheng@areca.com.tw> 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 <dsd@gentoo.org> Cc: Nick Cheng <nick.cheng@areca.com.tw> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Auke Kok authored
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 <auke-jan.h.kok@intel.com> Signed-off-by:
-
Ivan Kokshaysky authored
[upsteam commit: a0ca9909] Thanks to Loic Prylli <loic@myri.com>, 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 <ink@jurassic.park.msu.ru> Signed-off-by:
-
Ivan Kokshaysky authored
[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:
-
Alan Cox authored
[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 <alan@redhat.com> Signed-off-by:
-
FUJITA Tomonori authored
commit 7d5d408c 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 <fujita.tomonori@lab.ntt.co.jp> Signed-off-by:
-
Patrick McHardy authored
Upstream commit 1b04ab45 : The function ebt_do_table doesn't take NF_DROP as a verdict from the targets. Signed-off-by:
Joonwoo Park <joonwpark81@gmail.com> Signed-off-by:
-
