aboutsummaryrefslogtreecommitdiffstats
path: root/sound (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2006-10-21[PATCH] ATA must depend on BLOCKAdrian Bunk1-0/+1
Fix the following compile error with CONFIG_ATA=y, CONFIG_BLOCK=n: ... CC drivers/ata/libata-scsi.o /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ata/libata-scsi.c: In function ‘ata_scsi_dev_config’: /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ata/libata-scsi.c:791: warning: implicit declaration of function ‘blk_queue_max_sectors’ /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ata/libata-scsi.c:799: error: ‘request_queue_t’ undeclared (first use in this function) /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ata/libata-scsi.c:799: error: (Each undeclared identifier is reported only once /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ata/libata-scsi.c:799: error: for each function it appears in.) /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ata/libata-scsi.c:799: error: ‘q’ undeclared (first use in this function) /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ata/libata-scsi.c:800: warning: implicit declaration of function ‘blk_queue_max_hw_segments’ /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ata/libata-scsi.c: In function ‘ata_scsi_slave_config’: /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ata/libata-scsi.c:831: warning: implicit declaration of function ‘blk_queue_max_phys_segments’ make[3]: *** [drivers/ata/libata-scsi.o] Error 1 Bug report by Jesper Juhl. Signed-off-by: Adrian Bunk <bunk@stusta.de> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-10-21[PATCH] libata: use correct map_db values for ICH8Kristen Carlson Accardi1-2/+2
Use valid values for ICH8 map_db. With the old values, when the controller was in Native mode, and SCC was 1 (drives configured for IDE), any drive plugged into a slave port was not recognized. For Combined Mode (and SCC is still 1), 2 is a value value for MAP.map_value, and needs to be recognized. Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-10-21[PATCH] ibmveth: Fix index increment calculationDavid Gibson1-4/+6
On Thu, Oct 12, 2006 at 06:22:14PM +1000, David Gibson wrote: > Your recent ibmveth commit, 751ae21c6cd1493e3d0a4935b08fb298b9d89773 > ("fix int rollover panic"), causes a rapid oops on my test machine > (POWER5 LPAR). > > I've bisected it down to that commit, but am still investigating the > cause of the crash itself. Found the problem, I believe: an object lesson in the need for great caution using ++. [...] @@ -213,6 +213,7 @@ static void ibmveth_replenish_buffer_poo } free_index = pool->consumer_index++ % pool->size; + pool->consumer_index = free_index; index = pool->free_map[free_index]; ibmveth_assert(index != IBM_VETH_INVALID_MAP); Since the ++ is used as post-increment, the increment is not included in free_index, and so the added line effectively reverts the increment. The produced_index side has an analagous bug. The following change corrects this: The recent commit 751ae21c6cd1493e3d0a4935b08fb298b9d89773 introduced a bug in the producer/consumer index calculation in the ibmveth driver - incautious use of the post-increment ++ operator resulted in an increment being immediately reverted. This patch corrects the logic. Without this patch, the driver oopses almost immediately after activation on at least some machines. Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-10-21[PATCH] Fix timer raceRalf Baechle1-2/+2
When closing the driver or reinitializing the hardware there is the usual del_timer() race condition that exists when timers re-add themselves. Fix by conversion to del_timer_sync(). Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-10-21[PATCH] Remove useless comment from sb1250Dave Jones1-1/+1
Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-10-21[PATCH] ucc_geth: changes to ucc_geth driver as a result of qe_lib changes and bugfixesLi Yang5-436/+475
changes due to qe_lib changes include: o removed inclusion of platform header file o removed platform_device code, replaced with of_device o removed typedefs o uint -> u32 conversions o removed following defines: QE_SIZEOF_BD, BD_BUFFER_ARG, BD_BUFFER_CLEAR, BD_BUFFER, BD_STATUS_AND_LENGTH_SET, BD_STATUS_AND_LENGTH, and BD_BUFFER_SET because they hid sizeof/in_be32/out_be32 operations from the reader. o removed irrelevant comments, added others to resemble removed BD_ defines o const'd and uncasted all get_property() assignments bugfixes, courtesy of Scott Wood, include: - Read phy_address as a u32, not u8. - Match on type == "network" as well as compatible == "ucc_geth", as device_is_compatible() will only compare up to the length of the test string, allowing "ucc_geth_phy" to match as well. - fixes the MAC setting code in ucc_geth.c. The old code was overwriting and dereferencing random stack contents. Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-10-21[PATCH] sky2: 88E803X transmit lockupStephen Hemminger1-21/+12
The reason sky2 driver was locking up on transmit on the Yukon-FE chipset is that it was misconfiguring the internal RAM buffer so the transmitter and receiver were sharing the same space. The code assumed there was 16K of RAM on Yukon-FE (taken from vendor driver sk98lin which is even more f*cked up on this). Then it assigned based on that. The giveaway was that the registers would only hold 9bits so both RX/TX had 0..1ff for space. It is a wonder it worked at all! This patch addresses this, and fixes an easily reproducible hang on Transmit. Only the Yukon-FE chip is Marvell 88E803X (10/100 only) are affected. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-10-21[PATCH] e1000: Reset all functions after a PCI errorLinas Vepstas1-4/+0
During the handling of the PCI error recovery sequence, the current e1000 driver erroneously blocks a device reset for any but the first PCI function. It shouldn't -- this is a cut-n-paste error from a different driver (which tolerated only one hardware reset per hardware card). Signed-off-by: Linas Vepstas <linas@austin.ibm.com> Cc: Jesse Brandeburg <jesse.brandeburg@intel.com> Acked-by: Auke Kok <auke-jan.h.kok@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-10-21[PATCH] WAN/pc300: handle, propagate minor errorsJeff Garzik1-5/+19
- move definition of 'tmc' and 'br' locals closer to usage - handle clock_rate_calc() error - propagate errors back to upper level open routine Signed-off-by: Jeff Garzik <jeff@garzik.org> Cc: Krzysztof Halasa <khc@pm.waw.pl> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-10-21[PATCH] Update smc91x driver with ARM Versatile board infoDeepak Saxena1-0/+18
We need to specify a Versatile-specific SMC_IRQ_FLAGS value or the new generic IRQ layer will complain thusly: No IRQF_TRIGGER set_type function for IRQ 25 (<NULL>) Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Cc: Jeff Garzik <jeff@garzik.org> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Nicolas Pitre <nico@cam.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-10-21[PATCH] x86-64: Revert timer routing behaviour back to 2.6.16 stateAndi Kleen3-5/+8
By default route the 8254 over the 8259 and only disable it on ATI boards where this causes double timer interrupts. This should unbreak some Nvidia boards where the timer doesn't seem to tick of it isn't enabled in the 8259. At least one VIA board also seemed to have a little trouble with the disabled 8259. For 2.6.20 we'll try both dynamically without black listing, but I think for .19 this is the safer approach because it has been already well tested in earlier kernels. This also makes the x86-64 behaviour the same as i386. Command line options can change all this of course. Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-21[PATCH] x86-64: Overlapping program headers in physical addr space fixVivek Goyal1-1/+2
o A recent change to vmlinux.ld.S file broke kexec as now resulting vmlinux program headers are overlapping in physical address space. o Now all the vsyscall related sections are placed after data and after that mostly init data sections are placed. To avoid physical overlap among phdrs, there are three possible solutions. - Place vsyscall sections also in data phdrs instead of user - move vsyscal sections after init data in bss. - create another phdrs say data.init and move all the sections after vsyscall into this new phdr. o This patch implements the third solution. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Magnus Damm <magnus@valinux.co.jp> Cc: Andi Kleen <ak@suse.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org>
2006-10-21[PATCH] x86-64: Put more than one cpu in TARGET_CPUSEric W. Biederman1-1/+1
TARGET_CPUS is the default irq routing poicy. It specifies which cpus the kernel should aim an irq at. In physflat delivery mode we can route an irq to a single cpu. But that doesn't mean our default policy should only be a single cpu is allowed. By allowing the irq routing code to select from multiple cpus this enables systems with more irqs then we can service on a single processor to actually work. I just audited and tested the code and irqbalance doesn't care, and the io_apic.c doesn't care if we have extra cpus in the mask. Everything will use or assume we are using the lowest numbered cpu in the mask if we can't use them all. So this should result in no behavior changes except on systems that need it. Thanks for YH Lu for spotting this problem in his testing. Cc: Yinghai Lu <yinghai.lu@amd.com> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-21[PATCH] x86: Revert new unwind kernel stack terminationAndi Kleen2-10/+1
Jan convinced me that it was unnecessary because the assembly stubs do this already on the stack. Cc: jbeulich@novell.com Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-21[PATCH] x86-64: Use irq_domain in ioapic_retrigger_irqEric W. Biederman1-2/+5
Thanks to YH Lu for spotting this. It appears I missed this function when I refactored allocate_irq_vector and introduced irq_domain, with the result that all retriggered irqs would go to cpu 0 even if we were not prepared to receive them there. While reviewing YH's patch I also noticed that this function was missing locking, and since I am now reading two values from two diffrent arrays that looks like a race we might be able to hit in the real world. Cc: Yinghai Lu <yinghai.lu@amd.com> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-21[PATCH] i386: Disable nmi watchdog on all ThinkPadsAndi Kleen3-5/+27
Even newer Thinkpads have bugs in SMM code that causes hangs with NMI watchdog. Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-21[PATCH] x86-64: Revert interrupt backlink changesAndi Kleen1-3/+0
They break more than they fix Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-21[PATCH] x86-64: Fix ENOSYS in system call tracingJan Beulich1-0/+2
This patch: - out of range system calls failing to return -ENOSYS under system call tracing [AK: split out from another patch by Jan as separate bugfix] Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-21[PATCH] i386: Fix fake return addressJeremy Fitzhardinge1-1/+1
The fake return address was being set to __KERNEL_PDA, rather than 0. Push it earlier while %eax still equals 0. Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andi Kleen <ak@muc.de> Cc: Andrew Morton <akpm@osdl.org>
2006-10-21[PATCH] x86-64: x86_64 add NX mask for PTE entrybibo,mao1-0/+1
If function change_page_attr_addr calls revert_page to revert to original pte value, mk_pte_phys does not mask NX bit. If NX bit is set on no NX hardware supported x86_64 machine, there is will be RSVD type page fault and system will crash. This patch adds NX mask bit for PTE entry. Signed-off-by: bibo,mao <bibo.mao@intel.com> Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-21[PATCH] x86-64: Speed up dwarf2 unwinderJan Beulich5-39/+299
This changes the dwarf2 unwinder to do a binary search for CIEs instead of a linear work. The linker is unfortunately not able to build a proper lookup table at link time, instead it creates one at runtime as soon as the bootmem allocator is usable (so you'll continue using the linear lookup for the first [hopefully] few calls). The code should be ready to utilize a build-time created table once a fixed linker becomes available. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-21[PATCH] x86: Use -maccumulate-outgoing-argsAndi Kleen2-0/+8
This avoids some problems with gcc 4.x and earlier generating invalid unwind information. In 4.1 the option is default when unwind information is enabled. And it seems to generate smaller code too, so it's probably a good thing on its own. With gcc 4.0: i386: 4683198 902112 480868 6066178 5c9002 vmlinux (before) 4449895 902112 480868 5832875 5900ab vmlinux (after) x86-64: 4939761 1449584 648216 7037561 6b6279 vmlinux (before) 4854193 1449584 648216 6951993 6a1439 vmlinux (after) On 4.1 it shouldn't make much difference because it is default when unwind is enabled anyways. Suggested by Michael Matz and Jan Beulich Cc: jbeulich@novell.com Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-21[PATCH] x86-64: fix page align in e820 allocatorVivek Goyal1-7/+7
Currently some code pieces assume that address returned by find_e820_area() are page aligned. But looks like find_e820_area() had no such intention and hence one might end up stomping over some of the data. One such case is bootmem allocator initialization code stomped over bss. This patch modified find_e820_area() to return page aligned address. This might be little wasteful of memory but at the same time probably it is easier to handle page aligned memory. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
2006-10-21[PATCH] x86-64: Fix for arch/x86_64/pci/Makefile CFLAGSCorey Minyard1-1/+1
The arch/x86_64/pci directory was giving problems in a wierd cross-compile environment. The exact cause is unknown, but the Makefile used CFLAGS instead of EXTRA_CFLAGS. From what I can tell from Documentation/kbuild/makefiles.txt, CFLAGS should not be used for this, it should be EXTRA_CFLAGS. And it solves the cross-compile problem. Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andi Kleen <ak@muc.de> Cc: Vojtech Pavlik <vojtech@suse.cz> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org>
2006-10-21[PATCH] i386: fix .cfi_signal_frame copy-n-paste errorAndrew Morton1-2/+2
This was copied, pasted but not edited. Cc: Andi Kleen <ak@muc.de> Cc: Jan Beulich <jbeulich@novell.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-21[PATCH] x86-64: typo in __assign_irq_vector when updating pos for vector and offsetYinghai Lu1-3/+3
typo with cpu instead of new_cpu Signed-off-by: Yinghai Lu <yinghai.lu@amd.com> Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-21[PATCH] x86-64: x86_64 hot-add memory srat.c fixkeith mannthey1-2/+2
This patch corrects the logic used in srat.c to figure out what parsing what action to take when registering hot-add areas. Hot-add areas should only be added to the node information for the MEMORY_HOTPLUG_RESERVE case. When booting MEMORY_HOTPLUG_SPARSE hot-add areas on everything but the last node are getting include in the node data and during kernel boot the pages are setup then the kernel dies when the pages are used. This patch fixes this issue. Signed-off-by: Keith Mannthey <kmannth@us.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-21[PATCH] i386: Update defconfigAndi Kleen1-15/+15
Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-21[PATCH] x86-64: Update defconfigAndi Kleen1-15/+15
Signed-off-by: Andi Kleen <ak@suse.de>
2006-10-20[PATCH] fix PXA2xx UDC compilation errorNicolas Pitre1-1/+1
This was apparently missed by the move to the generic IRQ code. Signed-off-by: Nicolas Pitre <nico@cam.org> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20[PATCH] Fix up rpaphp driver for pci hotplug header moveOlaf Hering1-1/+1
Use grep instead of make during interface changes. Signed-off-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20configfs: handle kzalloc() failure in check_perm()Chandra Seetharaman1-6/+8
check_perm() does not drop the reference to the module when kzalloc() failure occurs. Signed-Off-By: Chandra Seetharaman <sekharan@us.ibm.com> Signed-off-by: Joel Becker <joel.becker@oracle.com> Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
2006-10-20ocfs2: cond_resched() in ocfs2_zero_extend()Mark Fasheh1-0/+7
The loop within ocfs2_zero_extend() can execute for a long time, causing spurious soft lockup warnings. Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
2006-10-20ocfs2: fix page zeroing during simple extendsMark Fasheh1-20/+24
The page zeroing code was missing the region between old i_size and new i_size for those extends that didn't actually require a change in space allocation. Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
2006-10-20ocfs2: remove spurious d_count check in ocfs2_rename()Sunil Mushran1-8/+0
This was causing some folks to incorrectly get -EBUSY during rename. Signed-off-by: Sunil Mushran <sunil.mushran@oracle.com> Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
2006-10-20ocfs2: delete redundant memcmp()Akinobu Mita1-4/+6
This patch deletes redundant memcmp() while looking up in rb tree. Signed-off-by: Akinbou Mita <akinobu.mita@gmail.com> Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
2006-10-20Revert "[mv643xx] Add pci device table for auto module loading."Linus Torvalds1-6/+0
This reverts commit 4596c75c23dde2623cbeec69357d5eb13d28387e as requested by Olaf Hering. It causes compile errors, and says Olaf: "This change is also wrong, the autoloading works perfect with 2.6.18, no need to add random PCI ids. See commit a0245f7ad5214cb00131d7cd176446e067c913dc, platform devices have now a modalias entry in sysfs. The network card is not a PCI device." Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20[PATCH] one more ARM IRQ fixAdrian Bunk1-1/+1
Fix one more compile breakage caused by the post -rc1 IRQ changes. Signed-off-by: Adrian Bunk <bunk@stusta.de> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20[PATCH] knfsd: fix race that can disable NFS serverNeilBrown1-1/+1
This patch is suitable for just about any 2.6 kernel. It should go in 2.6.19 and 2.6.18.2 and possible even the .17 and .16 stable series. This is a long standing bug that seems to have only recently become apparent, presumably due to increasing use of NFS over TCP - many distros seem to be making it the default. The SK_CONN bit gets set when a listening socket may be ready for an accept, just as SK_DATA is set when data may be available. It is entirely possible for svc_tcp_accept to be called with neither of these set. It doesn't happen often but there is a small race in svc_sock_enqueue as SK_CONN and SK_DATA are tested outside the spin_lock. They could be cleared immediately after the test and before the lock is gained. This normally shouldn't be a problem. The sockets are non-blocking so trying to read() or accept() when ther is nothing to do is not a problem. However: svc_tcp_recvfrom makes the decision "Should I accept() or should I read()" based on whether SK_CONN is set or not. This usually works but is not safe. The decision should be based on whether it is a TCP_LISTEN socket or a TCP_CONNECTED socket. Signed-off-by: Neil Brown <neilb@suse.de> Cc: Adrian Bunk <bunk@stusta.de> Cc: <stable@kernel.org> Cc: Trond Myklebust <trond.myklebust@fys.uio.no> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20[PATCH] kernel/nsproxy.c: use kmemdup()Alexey Dobriyan1-4/+2
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20[PATCH] ext3/4: fix J_ASSERT(transaction->t_updates > 0) in journal_stop()OGAWA Hirofumi2-4/+6
A disk generated some I/O error, after it, I hitted J_ASSERT(transaction->t_updates > 0) in journal_stop(). It seems to happened on ext3_truncate() path from stack trace. Then, maybe the following case may trigger J_ASSERT(transaction->t_updates > 0). ext3_truncate() -> ext3_free_branches() -> ext3_journal_test_restart() -> ext3_journal_restart() -> journal_restart() transaction->t_updates--; /* another process aborted journal */ -> start_this_handle() returns -EROFS without transaction->t_updates++; -> ext3_journal_stop() -> journal_stop() J_ASSERT(transaction->t_updates > 0) If journal was aborted in middle of journal_restart(), ext3_truncate() may trigger J_ASSERT(). Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: <linux-ext4@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20[PATCH] mm: more commenting on lock orderingNick Piggin2-23/+17
Clarify lockorder comments now that sys_msync dropps mmap_sem before calling do_fsync. Signed-off-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20[PATCH] firmware/dcdbas: add size check in smi_data_writeDoug Warzecha1-2/+5
Add a size check in smi_data_write to prevent possible wrapping problems with large pos values when calling smi_data_buf_realloc on 32-bit. Signed-off-by: Doug Warzecha <Douglas_Warzecha@dell.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20[PATCH] ipmi: fix return codes in failure caseDave Jones1-2/+2
These returns should be negative, like the others in this function. Signed-off-by: Dave Jones <davej@redhat.com> Acked-by: Corey Minyard <minyard@acm.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20[PATCH] mm: D-cache aliasing issue in cow_user_pageDmitriy Monakhov1-0/+1
--=-=-= from mm/memory.c: 1434 static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va) 1435 { 1436 /* 1437 * If the source page was a PFN mapping, we don't have 1438 * a "struct page" for it. We do a best-effort copy by 1439 * just copying from the original user address. If that 1440 * fails, we just zero-fill it. Live with it. 1441 */ 1442 if (unlikely(!src)) { 1443 void *kaddr = kmap_atomic(dst, KM_USER0); 1444 void __user *uaddr = (void __user *)(va & PAGE_MASK); 1445 1446 /* 1447 * This really shouldn't fail, because the page is there 1448 * in the page tables. But it might just be unreadable, 1449 * in which case we just give up and fill the result with 1450 * zeroes. 1451 */ 1452 if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) 1453 memset(kaddr, 0, PAGE_SIZE); 1454 kunmap_atomic(kaddr, KM_USER0); #### D-cache have to be flushed here. #### It seems it is just forgotten. 1455 return; 1456 1457 } 1458 copy_user_highpage(dst, src, va); #### Ok here. flush_dcache_page() called from this func if arch need it 1459 } Following is the patch fix this issue: Signed-off-by: Dmitriy Monakhov <dmonakhov@openvz.org> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20[PATCH] doc: fixing cpu-hotplug documentationSatoru Takeuchi1-74/+74
Fixing cpu-hotplug documentation as follows: - moving confusing asterisk on additional_cpus descrition - fixing some typos - unifying indentation for source code and command line example Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> Cc: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20[PATCH] drivers/isdn: ioremap balanced with iounmapAmol Lad2-3/+25
ioremap must be balanced by an iounmap and failing to do so can result in a memory leak. Signed-off-by: Amol Lad <amol@verismonetworks.com> Acked-by: Karsten Keil <kkeil@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20[PATCH] highest_possible_node_id() linkage fixAndrew Morton2-16/+16
Qooting Adrian: - net/sunrpc/svc.c uses highest_possible_node_id() - include/linux/nodemask.h says highest_possible_node_id() is out-of-line #if MAX_NUMNODES > 1 - the out-of-line highest_possible_node_id() is in lib/cpumask.c - lib/Makefile: lib-$(CONFIG_SMP) += cpumask.o CONFIG_ARCH_DISCONTIGMEM_ENABLE=y, CONFIG_SMP=n, CONFIG_SUNRPC=y -> highest_possible_node_id() is used in net/sunrpc/svc.c CONFIG_NODES_SHIFT defined and > 0 -> include/linux/numa.h: MAX_NUMNODES > 1 -> compile error The bug is not present on architectures where ARCH_DISCONTIGMEM_ENABLE depends on NUMA (but m32r isn't the only affected architecture). So move the function into page_alloc.c Cc: Adrian Bunk <bunk@stusta.de> Cc: Paul Jackson <pj@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20[PATCH] Fix potential interrupts during alternative patchingZachary Amsden1-0/+4
Interrupts must be disabled during alternative instruction patching. On systems with high timer IRQ rates, or when running in an emulator, timing differences can result in random kernel panics because of running partially patched instructions. This doesn't yet fix NMIs, which requires extricating the patch code from the late bug checking and is logically separate (and also less likely to cause problems). Signed-off-by: Zachary Amsden <zach@vmware.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20[PATCH] nfsd: nfs_replay_meAl Viro3-5/+6
We are using NFS_REPLAY_ME as a special error value that is never leaked to clients. That works fine; the only problem is mixing host- and network- endian values in the same objects. Network-endian equivalent would work just as fine; switch to it. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Trond Myklebust <trond.myklebust@fys.uio.no> Acked-by: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>