summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2009-05-08[CIFS] Fix double list addition in cifs posix open codeSteve French2-20/+9
Remove adding open file entry twice to lists in the file Do not fill file info twice in case of posix opens and creates Signed-off-by: Shirish Pargaonkar <shirishp@us.ibm.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2009-05-08Input: ff-memless - fix signed to unsigned bit overflowJussi Kivilinna1-1/+1
When userspace sets effect->u.rumble.strong_magnitude to 0x8001 or larger, ml_combine_effects() would always return strong_magnitude 0xffff. Problem is that 'gain' is passed in as signed integer. Multiplying magnitude (__u16) with gain (int) causes magnitude read as signed and results negative value (with magnitude > 0x8000). This signed integer is then divided and value, still negative, converted to 32bit unsigned integer. Finally checking combine overflow min(new+old, 0xffff) gives out 0xffff. Fix is to simply change 'gain' to unsigned int. Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Acked-by: Anssi Hannula <anssi.hannula@gmail.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2009-05-08Input: joydev - blacklist digitizersTim Cole1-1/+7
BTN_TOUCH is not set by the wacom driver which causes it to be handled by the joydev driver while the resulting device is broken. This causes problems with applications that try to use a joystick device. Ubuntu BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/300143 Signed-off-by: Tim Cole <tim.cole@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Amit Kucheria <amit.kucheria@canonical.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2009-05-08ACPI: video: DMI workaround another broken Acer BIOS enabling display brightnessLen Brown1-0/+8
http://bugzilla.kernel.org/show_bug.cgi?id=13121 Signed-off-by: Len Brown <len.brown@intel.com>
2009-05-08net: remove stale reference to fastroute from Kconfig help textAshish Karkare1-6/+0
Signed-off-by: Ashish Karkare <akarkare@marvell.com> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-07ACPICA: use acpi.* modparam namespaceLen Brown1-12/+15
Add acpi/acpica/*.c to the acpi.* modparam namespace so that any modparams we stick into ACPICA do not expose ACPICA filenames to users. There are currently only two modparams in ACPICA, just recently added for http://bugzilla.kernel.org/show_bug.cgi?id=13041 With this change, they become acpi.gts=1 acpi.bfs=1 rather than hwsleep.gts=1 hwsleep.bfs=1 Signed-off-by: Len Brown <len.brown@intel.com>
2009-05-07NOMMU: Don't check vm_region::vm_start is page aligned in add_nommu_region()David Howells1-2/+0
Don't check vm_region::vm_start is page aligned in add_nommu_region() because the region may reflect some non-page-aligned mapped file, such as could be obtained from RomFS XIP. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07Merge branch 'for-linus' of git://neil.brown.name/mdLinus Torvalds3-51/+60
* 'for-linus' of git://neil.brown.name/md: md: remove rd%d links immediately after stopping an array. md: remove ability to explicit set an inactive array to 'clean'. md: constify VFTs md: tidy up status_resync to handle large arrays. md: fix some (more) errors with bitmaps on devices larger than 2TB. md/raid10: don't clear bitmap during recovery if array will still be degraded. md: fix loading of out-of-date bitmap.
2009-05-07random: make get_random_int() more randomLinus Torvalds1-7/+12
It's a really simple patch that basically just open-codes the current "secure_ip_id()" call, but when open-coding it we now use a _static_ hashing area, so that it gets updated every time. And to make sure somebody can't just start from the same original seed of all-zeroes, and then do the "half_md4_transform()" over and over until they get the same sequence as the kernel has, each iteration also mixes in the same old "current->pid + jiffies" we used - so we should now have a regular strong pseudo-number generator, but we also have one that doesn't have a single seed. Note: the "pid + jiffies" is just meant to be a tiny tiny bit of noise. It has no real meaning. It could be anything. I just picked the previous seed, it's just that now we keep the state in between calls and that will feed into the next result, and that should make all the difference. I made that hash be a per-cpu data just to avoid cache-line ping-pong: having multiple CPU's write to the same data would be fine for randomness, and add yet another layer of chaos to it, but since get_random_int() is supposed to be a fast interface I did it that way instead. I considered using "__raw_get_cpu_var()" to avoid any preemption overhead while still getting the hash be _mostly_ ping-pong free, but in the end good taste won out. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07Merge master.kernel.org:/home/rmk/linux-2.6-armLinus Torvalds19-1027/+795
* master.kernel.org:/home/rmk/linux-2.6-arm: [ARM] 5507/1: support R_ARM_MOVW_ABS_NC and MOVT_ABS relocation types [ARM] 5506/1: davinci: DMA_32BIT_MASK --> DMA_BIT_MASK(32) i.MX31: Disable CPU_32v6K in mx3_defconfig. mx3fb: Fix compilation with CONFIG_PM mx27ads: move PBC mapping out of vmalloc space MXC: remove BUG_ON in interrupt handler mx31: remove mx31moboard_defconfig ARM: ARCH_MXC should select HAVE_CLK mxc : BUG in imx_dma_request mxc : Clean up properly when imx_dma_free() used without imx_dma_disable() [ARM] mv78xx0: update defconfig [ARM] orion5x: update defconfig [ARM] Kirkwood: update defconfig [ARM] Kconfig typo fix: "PXA930" -> "CPU_PXA930". [ARM] S3C2412: Add missing cache flush in suspend code [ARM] S3C: Add UDIVSLOT support for newer UARTS [ARM] S3C64XX: Add S3C64XX_PA_IIS{0,1} to <mach/map.h>
2009-05-07[ARM] 5507/1: support R_ARM_MOVW_ABS_NC and MOVT_ABS relocation typesPaul Gortmaker2-7/+24
From: Bruce Ashfield <bruce.ashfield@windriver.com> To fully support the armv7-a instruction set/optimizations, support for the R_ARM_MOVW_ABS_NC and R_ARM_MOVT_ABS relocation types is required. The MOVW and MOVT are both load-immediate instructions, MOVW loads 16 bits into the bottom half of a register, and MOVT loads 16 bits into the top half of a register. The relocation information for these instructions has a full 32 bit value, plus an addend which is stored in the 16 immediate bits in the instruction itself. The immediate bits in the instruction are not contiguous (the register # splits it into a 4 bit and 12 bit value), so the addend has to be extracted accordingly and added to the value. The value is then split and put into the instruction; a MOVW uses the bottom 16 bits of the value, and a MOVT uses the top 16 bits. Signed-off-by: David Borman <david.borman@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-05-07[ARM] 5506/1: davinci: DMA_32BIT_MASK --> DMA_BIT_MASK(32)Kevin Hilman1-2/+2
As per commit 284901a90a9e0b812ca3f5f852cbbfb60d10249d, use DMA_BIT_MASK(n) Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-05-07md: remove rd%d links immediately after stopping an array.NeilBrown1-8/+8
md maintains link in sys/mdXX/md/ to identify which device has which role in the array. e.g. rd2 -> dev-sda indicates that the device with role '2' in the array is sda. These links are only present when the array is active. They are created immediately after ->run is called, and so should be removed immediately after ->stop is called. However they are currently removed a little bit later, and it is possible for ->run to be called again, thus adding these links, before they are removed. So move the removal earlier so they are consistently only present when the array is active. Signed-off-by: NeilBrown <neilb@suse.de>
2009-05-07md: remove ability to explicit set an inactive array to 'clean'.NeilBrown1-5/+2
Being able to write 'clean' to an 'array_state' of an inactive array to activate it in 'clean' mode is both unnecessary and inconvenient. It is unnecessary because the same can be achieved by writing 'active'. This activates and array, but it still remains 'clean' until the first write. It is inconvenient because writing 'clean' is more often used to cause an 'active' array to revert to 'clean' mode (thus blocking any writes until a 'write-pending' is promoted to 'active'). Allowing 'clean' to both activate an array and mark an active array as clean can lead to races: One program writes 'clean' to mark the active array as clean at the same time as another program writes 'inactive' to deactivate (stop) and active array. Depending on which writes first, the array could be deactivated and immediately reactivated which isn't what was desired. So just disable the use of 'clean' to activate an array. This avoids a race that can be triggered with mdadm-3.0 and external metadata, so it suitable for -stable. Reported-by: Rafal Marszewski <rafal.marszewski@intel.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Cc: <stable@kernel.org> Signed-off-by: NeilBrown <neilb@suse.de>
2009-05-07md: constify VFTsJan Engelhardt1-1/+1
Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: NeilBrown <neilb@suse.de>
2009-05-07md: tidy up status_resync to handle large arrays.NeilBrown1-17/+28
Two problems in status_resync. 1/ It still used Kilobytes as the basic block unit, while most code now uses sectors uniformly. 2/ It doesn't allow for the possibility that max_sectors exceeds the range of "unsigned long". So - change "max_blocks" to "max_sectors", and store sector numbers in there and in 'resync' - Make 'rt' a 'sector_t' so it can temporarily hold the number of remaining sectors. - use sector_div rather than normal division. - change the magic '100' used to preserve precision to '32'. + making it a power of 2 makes division easier + it doesn't need to be as large as it was chosen when we averaged speed over the entire run. Now we average speed over the last 30 seconds or so. Reported-by: "Mario 'BitKoenig' Holbe" <Mario.Holbe@TU-Ilmenau.DE> Signed-off-by: NeilBrown <neilb@suse.de>
2009-05-07md: fix some (more) errors with bitmaps on devices larger than 2TB.NeilBrown1-7/+11
If a write intent bitmap covers more than 2TB, we sometimes work with values beyond 32bit, so these need to be sector_t. This patches add the required casts to some unsigned longs that are being shifted up. This will affect any raid10 larger than 2TB, or any raid1/4/5/6 with member devices that are larger than 2TB. Signed-off-by: NeilBrown <neilb@suse.de> Reported-by: "Mario 'BitKoenig' Holbe" <Mario.Holbe@TU-Ilmenau.DE> Cc: stable@kernel.org
2009-05-07md/raid10: don't clear bitmap during recovery if array will still be degraded.NeilBrown1-6/+6
If we have a raid10 with multiple missing devices, and we recover just one of these to a spare, then we risk (depending on the bitmap and array chunk size) clearing bits of the bitmap for which recovery isn't complete (because a device is still missing). This can lead to a subsequent "re-add" being recovered without any IO happening, which would result in loss of data. This patch takes the safe approach of not clearing bitmap bits if the array will still be degraded. This patch is suitable for all active -stable kernels. Cc: stable@kernel.org Signed-off-by: NeilBrown <neilb@suse.de>
2009-05-07md: fix loading of out-of-date bitmap.NeilBrown1-7/+4
When md is loading a bitmap which it knows is out of date, it fills each page with 1s and writes it back out again. However the write_page call makes used of bitmap->file_pages and bitmap->last_page_size which haven't been set correctly yet. So this can sometimes fail. Move the setting of file_pages and last_page_size to before the call to write_page. This bug can cause the assembly on an array to fail, thus making the data inaccessible. Hence I think it is a suitable candidate for -stable. Cc: stable@kernel.org Reported-by: Vojtech Pavlik <vojtech@suse.cz> Signed-off-by: NeilBrown <neilb@suse.de>
2009-05-07net: update skb_recycle_check() for hardware timestamping changesLennert Buytenhek1-0/+2
Commit ac45f602ee3d1b6f326f68bc0c2591ceebf05ba4 ("net: infrastructure for hardware time stamping") added two skb initialization actions to __alloc_skb(), which need to be added to skb_recycle_check() as well. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-07bnx2: Fix panic in bnx2_poll_work().Michael Chan1-2/+4
Add barrier() to bnx2_get_hw_{tx|rx}_cons() to fix this issue: http://bugzilla.kernel.org/show_bug.cgi?id=12698 This issue was reported by multiple i386 users. Without barrier(), the compiled code looks like the following where %eax contains the address of the tx_cons or rx_cons in the DMA status block. The status block contents can change between the cmpb and the movzwl instruction. The driver would crash if the value was not 0xff during the cmpb instruction, but changed to 0xff during the movzwl instruction. 6828: 80 38 ff cmpb $0xff,(%eax) 682b: 0f b7 10 movzwl (%eax),%edx With the added barrier(), the compiled code now looks correct: 683d: 0f b7 10 movzwl (%eax),%edx 6840: 0f b6 c2 movzbl %dl,%eax 6843: 3d ff 00 00 00 cmp $0xff,%eax Thanks to Pascal de Bruijn <pmjdebruijn@pcode.nl> for reporting the problem and Holger Noefer <hnoefer@pironet-ndh.com> for patiently testing test patches for us. Also updated version to 2.0.1. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-07net-sched: fix bfifo default limitPatrick McHardy1-1/+1
When no limit is given, the bfifo uses a default of tx_queue_len * mtu. Packets handled by qdiscs include the link layer header, so this should be taken into account, similar to what other qdiscs do. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-07igb: resolve panic on shutdown when SR-IOV is enabledAlexander Duyck1-7/+5
The setup_rctl call was making a call into the ring structure after it had been freed. This was causing a panic on shutdown. This call wasn't necessary since it is possible to get the needed index from adapter->vfs_allocated_count. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-07Merge branch 'linux-2.6.30.y' of ↵David S. Miller2-7/+21
git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax
2009-05-07drivers/base/iommu.c: add missing includesAndrew Morton1-0/+2
Fix zillions of -mm x86_64 allmodconfig build errors - the file uses EXPORT_SYMBOL() and kmalloc but misses the needed includes. Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07initramfs: clean up messages related to initramfs unpackingEric Piel1-9/+4
With the removal of duplicate unpack_to_rootfs() (commit df52092f3c97788592ef72501a43fb7ac6a3cfe0) the messages displayed do not actually correspond to what the kernel is doing. In addition, depending if ramdisks are supported or not, the messages are not at all the same. So keep the messages more in sync with what is really doing the kernel, and only display a second message in case of failure. This also ensure that the printk message cannot be split by other printk's. Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net> Acked-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07nommu: make the initial mmap allocation excess behaviour Kconfig configurableDavid Howells2-1/+29
NOMMU mmap() has an option controlled by a sysctl variable that determines whether the allocations made by do_mmap_private() should have the excess space trimmed off and returned to the allocator. Make the initial setting of this variable a Kconfig configuration option. The reason there can be excess space is that the allocator only allocates in power-of-2 size chunks, but mmap()'s can be made in sizes that aren't a power of 2. There are two alternatives: (1) Keep the excess as dead space. The dead space then remains unused for the lifetime of the mapping. Mappings of shared objects such as libc, ld.so or busybox's text segment may retain their dead space forever. (2) Return the excess to the allocator. This means that the dead space is limited to less than a page per mapping, but it means that for a transient process, there's more chance of fragmentation as the excess space may be reused fairly quickly. During the boot process, a lot of transient processes are created, and this can cause a lot of fragmentation as the pagecache and various slabs grow greatly during this time. By turning off the trimming of excess space during boot and disabling batching of frees, Coldfire can manage to boot. A better way of doing things might be to have /sbin/init turn this option off. By that point libc, ld.so and init - which are all long-duration processes - have all been loaded and trimmed. Reported-by: Lanttor Guo <lanttor.guo@freescale.com> Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Lanttor Guo <lanttor.guo@freescale.com> Cc: Greg Ungerer <gerg@snapgear.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07nommu: clamp zone_batchsize() to 0 under NOMMU conditionsDavid Howells1-0/+18
Clamp zone_batchsize() to 0 under NOMMU conditions to stop free_hot_cold_page() from queueing and batching frees. The problem is that under NOMMU conditions it is really important to be able to allocate large contiguous chunks of memory, but when munmap() or exit_mmap() releases big stretches of memory, return of these to the buddy allocator can be deferred, and when it does finally happen, it can be in small chunks. Whilst the fragmentation this incurs isn't so much of a problem under MMU conditions as userspace VM is glued together from individual pages with the aid of the MMU, it is a real problem if there isn't an MMU. By clamping the page freeing queue size to 0, pages are returned to the allocator immediately, and the buddy detector is more likely to be able to glue them together into large chunks immediately, and fragmentation is less likely to occur. By disabling batching of frees, and by turning off the trimming of excess space during boot, Coldfire can manage to boot. Reported-by: Lanttor Guo <lanttor.guo@freescale.com> Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Lanttor Guo <lanttor.guo@freescale.com> Cc: Greg Ungerer <gerg@snapgear.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07mm: use roundown_pow_of_two() in zone_batchsize()David Howells1-1/+1
Use roundown_pow_of_two(N) in zone_batchsize() rather than (1 << (fls(N)-1)) as they are equivalent, and with the former it is easier to see what is going on. Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Lanttor Guo <lanttor.guo@freescale.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07isl29003: fix resume functionalityDaniel Mack1-2/+7
The isl29003 does not interpret the return value of i2c_smbus_write_byte_data() correctly and hence causes an error on system resume. Also introduce power_state_before_suspend and restore the chip's power state upon wakeup. Signed-off-by: Daniel Mack <daniel@caiaq.de> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07fbdev: remove makefile reference to removed driverKrzysztof Helt1-1/+0
The cyblafb driver is removed so remove its last trace in the makefile. Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07alloc_vmap_area: fix memory leakRalph Wuerthner1-0/+1
If alloc_vmap_area() fails the allocated struct vmap_area has to be freed. Signed-off-by: Ralph Wuerthner <ralphw@linux.vnet.ibm.com> Reviewed-by: Christoph Lameter <cl@linux-foundation.org> Reviewed-by: Minchan Kim <minchan.kim@gmail.com> Cc: Nick Piggin <npiggin@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07doc: small kernel-parameters updatesRandy Dunlap1-2/+8
Change last "i386" to X86-32 as is used throughout the rest of the file. Change combination of X86-32,X86-64 to just X86, as is done throughout the rest of the file. Add a note that hyphens and underscores are equivalent in parameter names, with examples. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Jan Engelhardt <jengelh@medozas.de> Cc: Christopher Sylvain <chris.sylvain@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07fbdev: fix fillrect for 24bpp modesMichal Januszewski3-39/+48
The software fillrect routines do not work properly when the number of pixels per machine word is not an integer. To see that, run the following command on a fbdev console with a 24bpp video mode, using a non-accelerated driver such as (u)vesafb: reset ; echo -e '\e[41mtest\e[K' The expected result is 'test' displayed on a line with red background. Instead of that, 'test' has a red background, but the rest of the line (rendered using fillrect()) contains a distored colorful pattern. This patch fixes the problem by correctly computing rotation shifts. It has been tested in a 24bpp mode on 32- and 64-bit little-endian machines. Signed-off-by: Michal Januszewski <spock@gentoo.org> Acked-by: Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07oom: prevent livelock when oom_kill_allocating_task is setDavid Rientjes1-23/+21
When /proc/sys/vm/oom_kill_allocating_task is set for large systems that want to avoid the lengthy tasklist scan, it's possible to livelock if current is ineligible for oom kill. This normally happens when it is set to OOM_DISABLE, but is also possible if any threads are sharing the same ->mm with a different tgid. So change __out_of_memory() to fall back to the full task-list scan if it was unable to kill `current'. Cc: Nick Piggin <npiggin@suse.de> Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07fiemap: fix problem with setting FIEMAP_EXTENT_LASTJosef Bacik1-20/+55
Fix a problem where the generic block based fiemap stuff would not properly set FIEMAP_EXTENT_LAST on the last extent. I've reworked things to keep track if we go past the EOF, and mark the last extent properly. The problem was reported by and tested by Eric Sandeen. Tested-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Josef Bacik <jbacik@redhat.com> Cc: <linux-ext4@vger.kernel.org> Cc: <xfs-masters@oss.sgi.com> Cc: <linux-btrfs@vger.kernel.org> Cc: Steven Whitehouse <swhiteho@redhat.com> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <Joel.Becker@oracle.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07Eliminate thousands of warnings with gcc 3.2 buildAndi Kleen2-6/+14
When building with gcc 3.2 I get thousands of warnings such as include/linux/gfp.h: In function `allocflags_to_migratetype': include/linux/gfp.h:105: warning: null format string due to passing a NULL format string to warn_slowpath() in #define __WARN() warn_slowpath(__FILE__, __LINE__, NULL) Split this case out into a separate call. This also shrinks the kernel slightly: text data bss dec hex filename 4802274 707668 712704 6222646 5ef336 vmlinux text data bss dec hex filename 4799027 703572 712704 6215303 5ed687 vmlinux due to removeing one argument from the commonly-called __WARN(). [akpm@linux-foundation.org: reduce scope of `empty'] Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07doc: hashdist defaults on for 64bitHugh Dickins1-1/+1
kernel boot parameter `hashdist' now defaults on for all 64bit NUMA. Signed-off-by: Hugh Dickins <hugh@veritas.com> Acked-by: Mel Gorman <mel@csn.ul.ie> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07inotify: use GFP_NOFS in kernel_event() to work around a lockdep false-positiveWu Fengguang2-3/+3
There is what we believe to be a false positive reported by lockdep. inotify_inode_queue_event() => take inotify_mutex => kernel_event() => kmalloc() => SLOB => alloc_pages_node() => page reclaim => slab reclaim => dcache reclaim => inotify_inode_is_dead => take inotify_mutex => deadlock The plan is to fix this via lockdep annotation, but that is proving to be quite involved. The patch flips the allocation over to GFP_NFS to shut the warning up, for the 2.6.30 release. Hopefully we will fix this for real in 2.6.31. I'll queue a patch in -mm to switch it back to GFP_KERNEL so we don't forget. ================================= [ INFO: inconsistent lock state ] 2.6.30-rc2-next-20090417 #203 --------------------------------- inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage. kswapd0/380 [HC0[0]:SC0[0]:HE1:SE1] takes: (&inode->inotify_mutex){+.+.?.}, at: [<ffffffff8112f1b5>] inotify_inode_is_dead+0x35/0xb0 {RECLAIM_FS-ON-W} state was registered at: [<ffffffff81079188>] mark_held_locks+0x68/0x90 [<ffffffff810792a5>] lockdep_trace_alloc+0xf5/0x100 [<ffffffff810f5261>] __kmalloc_node+0x31/0x1e0 [<ffffffff81130652>] kernel_event+0xe2/0x190 [<ffffffff81130826>] inotify_dev_queue_event+0x126/0x230 [<ffffffff8112f096>] inotify_inode_queue_event+0xc6/0x110 [<ffffffff8110444d>] vfs_create+0xcd/0x140 [<ffffffff8110825d>] do_filp_open+0x88d/0xa20 [<ffffffff810f6b68>] do_sys_open+0x98/0x140 [<ffffffff810f6c50>] sys_open+0x20/0x30 [<ffffffff8100c272>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff irq event stamp: 690455 hardirqs last enabled at (690455): [<ffffffff81564fe4>] _spin_unlock_irqrestore+0x44/0x80 hardirqs last disabled at (690454): [<ffffffff81565372>] _spin_lock_irqsave+0x32/0xa0 softirqs last enabled at (690178): [<ffffffff81052282>] __do_softirq+0x202/0x220 softirqs last disabled at (690157): [<ffffffff8100d50c>] call_softirq+0x1c/0x50 other info that might help us debug this: 2 locks held by kswapd0/380: #0: (shrinker_rwsem){++++..}, at: [<ffffffff810d0bd7>] shrink_slab+0x37/0x180 #1: (&type->s_umount_key#17){++++..}, at: [<ffffffff8110cfbf>] shrink_dcache_memory+0x11f/0x1e0 stack backtrace: Pid: 380, comm: kswapd0 Not tainted 2.6.30-rc2-next-20090417 #203 Call Trace: [<ffffffff810789ef>] print_usage_bug+0x19f/0x200 [<ffffffff81018bff>] ? save_stack_trace+0x2f/0x50 [<ffffffff81078f0b>] mark_lock+0x4bb/0x6d0 [<ffffffff810799e0>] ? check_usage_forwards+0x0/0xc0 [<ffffffff8107b142>] __lock_acquire+0xc62/0x1ae0 [<ffffffff810f478c>] ? slob_free+0x10c/0x370 [<ffffffff8107c0a1>] lock_acquire+0xe1/0x120 [<ffffffff8112f1b5>] ? inotify_inode_is_dead+0x35/0xb0 [<ffffffff81562d43>] mutex_lock_nested+0x63/0x420 [<ffffffff8112f1b5>] ? inotify_inode_is_dead+0x35/0xb0 [<ffffffff8112f1b5>] ? inotify_inode_is_dead+0x35/0xb0 [<ffffffff81012fe9>] ? sched_clock+0x9/0x10 [<ffffffff81077165>] ? lock_release_holdtime+0x35/0x1c0 [<ffffffff8112f1b5>] inotify_inode_is_dead+0x35/0xb0 [<ffffffff8110c9dc>] dentry_iput+0xbc/0xe0 [<ffffffff8110cb23>] d_kill+0x33/0x60 [<ffffffff8110ce23>] __shrink_dcache_sb+0x2d3/0x350 [<ffffffff8110cffa>] shrink_dcache_memory+0x15a/0x1e0 [<ffffffff810d0cc5>] shrink_slab+0x125/0x180 [<ffffffff810d1540>] kswapd+0x560/0x7a0 [<ffffffff810ce160>] ? isolate_pages_global+0x0/0x2c0 [<ffffffff81065a30>] ? autoremove_wake_function+0x0/0x40 [<ffffffff8107953d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff810d0fe0>] ? kswapd+0x0/0x7a0 [<ffffffff8106555b>] kthread+0x5b/0xa0 [<ffffffff8100d40a>] child_rip+0xa/0x20 [<ffffffff8100cdd0>] ? restore_args+0x0/0x30 [<ffffffff81065500>] ? kthread+0x0/0xa0 [<ffffffff8100d400>] ? child_rip+0x0/0x20 [eparis@redhat.com: fix audit too] Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Matt Mackall <mpm@selenic.com> Cc: Christoph Lameter <clameter@sgi.com> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Eric Paris <eparis@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07jsm: removing unused spinlockBreno Leitao2-3/+0
This patch removes bd_lock spinlock (inside jsm_board structure). The lock is initialized in the probe function and not used anymore. Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07vt: Add a note on the historical abuse of CLOCK_TICK_RATEAlan Cox1-0/+6
This is one area where we can't just magic away the bizarre use of CLOCK_TICK_RATE as it leaks to user space APIs. It also means the visible CLOCK_TICK_RATE is frozen for architectures which is horrible. We need to fix this somehow Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-07lockd: fix list corruption on lockd restartJ. Bruce Fields1-4/+11
If lockd is signalled soon enough after restart then locks_start_grace() will try to re-add an entry to a list and trigger a lock corruption warning. Thanks to Wang Chen for the problem report and diagnosis. WARNING: at lib/list_debug.c:26 __list_add+0x27/0x5c() ... list_add corruption. next->prev should be prev (ef8fe958), but was ef8ff128. (next=ef8ff128). ... Pid: 23062, comm: lockd Tainted: G W 2.6.30-rc2 #3 Call Trace: [<c042d5b5>] warn_slowpath+0x71/0xa0 [<c0422a96>] ? update_curr+0x11d/0x125 [<c044b12d>] ? trace_hardirqs_on_caller+0x18/0x150 [<c044b270>] ? trace_hardirqs_on+0xb/0xd [<c051c61a>] ? _raw_spin_lock+0x53/0xfa [<c051c89f>] __list_add+0x27/0x5c [<ef8f6daa>] locks_start_grace+0x22/0x30 [lockd] [<ef8f34da>] set_grace_period+0x39/0x53 [lockd] [<c06b8921>] ? lock_kernel+0x1c/0x28 [<ef8f3558>] lockd+0x64/0x164 [lockd] [<c044b12d>] ? trace_hardirqs_on_caller+0x18/0x150 [<c04227b0>] ? complete+0x34/0x3e [<ef8f34f4>] ? lockd+0x0/0x164 [lockd] [<ef8f34f4>] ? lockd+0x0/0x164 [lockd] [<c043dd42>] kthread+0x45/0x6b [<c043dcfd>] ? kthread+0x0/0x6b [<c0403c23>] kernel_thread_helper+0x7/0x10 Reported-by: Wang Chen <wangchen@cn.fujitsu.com> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Cc: stable@kernel.org
2009-05-07wimax: oops: wimax_dev_add() is the only one that can initialize the stateInaky Perez-Gonzalez1-2/+15
When a new wimax_dev is created, it's state has to be __WIMAX_ST_NULL until wimax_dev_add() is succesfully called. This allows calls into the stack that happen before said time to be rejected. Until now, the state was being set (by mistake) to UNINITIALIZED, which was allowing calls such as wimax_report_rfkill_hw() to go through even when a call to wimax_dev_add() had failed; that was causing an oops when touching uninitialized data. This situation is normal when the device starts reporting state before the whole initialization has been completed. It just has to be dealt with. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-05-07wimax: fix oops if netlink fails to add attributeInaky Perez-Gonzalez1-5/+6
When sending a message to user space using wimax_msg(), if nla_put() fails, correctly interpret the return code from wimax_msg_alloc() as an err ptr and return the error code instead of crashing (as it is assuming than non-NULL means the pointer is ok). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-05-07nfsd4: check for negative dentry before use in nfsv4 readdirJ. Bruce Fields1-1/+15
After 2f9092e1020246168b1309b35e085ecd7ff9ff72 "Fix i_mutex vs. readdir handling in nfsd" (and 14f7dd63 "Copy XFS readdir hack into nfsd code"), an entry may be removed between the first mutex_unlock and the second mutex_lock. In this case, lookup_one_len() will return a negative dentry. Check for this case to avoid a NULL dereference. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Reviewed-by: J. R. Okajima <hooanon05@yahoo.co.jp> Cc: stable@kernel.org
2009-05-06ALSA: Release v1.0.20Jaroslav Kysela1-1/+1
Signed-off-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2009-05-06x86: Fix a typo in a printk messageNikanth Karthikesan1-1/+1
[ Impact: printk message cleanup ] Signed-off-by: Nikanth Karthikesan <knikanth@suse.de> LKML-Reference: <200905040908.27299.knikanth@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-05-06x86, srat: do not register nodes beyond e820 mapDavid Rientjes1-0/+1
The mem= option will truncate the memory map at a specified address so it's not possible to register nodes with memory beyond the e820 upper bound. unparse_node() is only called when then node had memory associated with it, although with the mem= option it is no longer addressable. [ Impact: fix boot hang on certain (large) systems ] Reported-by: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com> Signed-off-by: David Rientjes <rientjes@google.com> Acked-by: Jack Steiner <steiner@sgi.com> LKML-Reference: <alpine.DEB.2.00.0905051248150.20021@chino.kir.corp.google.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-05-06Merge branches 'topic/documentation', 'topic/slub/fixes' and 'topic/urgent' ↵Pekka Enberg2-2/+9
into for-linus
2009-05-06mm: SLOB fix reclaim_stateNick Piggin1-1/+4
SLOB does not correctly account reclaim_state.reclaimed_slab, so it will break memory reclaim. Account it like SLAB does. Cc: stable@kernel.org Cc: linux-mm@kvack.org Acked-by: Matt Mackall <mpm@selenic.com> Acked-by: Christoph Lameter <cl@linux-foundation.org> Signed-off-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>