- 30 Jul, 2009 39 commits
-
-
Joe Perches authored
Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Thomas Woller's email address bounces Nils Faerber isn't active Added Thomas Woller to CREDITS, Nils already has an entry Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Jonathan Layes is hard to find. Signed-off-by:
-
Joe Perches authored
from sections that should not have them. Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Jiri Slaby authored
To avoid userspace build failures such as: .../linux/uio.h:37: error: expected `=', `,', `;', `asm' or `__attribute__' before `iov_length' .../linux/uio.h:47: error: expected declaration specifiers or `...' before `size_t' move uio functions inside a __KERNEL__ block. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@infradead.org> Signed-off-by:
-
Albin Tonnerre authored
drivers/serial/atmel_serial.c: fix compile when CONFIG_SERIAL_ATMEL=Y and CONFIG_SERIAL_ATMEL_CONSOLE=N When SERIAL_ATMEL_CONSOLE is disabled, ATMEL_CONSOLE_DEVICE is set to NULL, and trying to access ATMEL_CONSOLE_DEVICE->flags in atmel_serial_probe makes the compile fail. This fixes the issue by only accessing it if CONFIG_SERIAL_ATMEL_CONSOLE is defined Signed-off-by:
Albin Tonnerre <albin.tonnerre@free-electrons.com> Signed-off-by:
Haavard Skinnemoen <haavard.skinnemoen@atmel.com> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Dave Hansen authored
Once a structure goes over PAGE_SIZE*2, we see occasional allocation failures. Some people have chosen to switch over to things like vmalloc() that will let them keep array-like access to such a large structures. But, vmalloc() has plenty of downsides. Here's an alternative. I think it's what Andrew was suggesting here: http://lkml.org/lkml/2009/7/2/518 I call it a flexible array. It does all of its work in PAGE_SIZE bits, so never does an order>0 allocation. The base level has PAGE_SIZE-2*sizeof(int) bytes of storage for pointers to the second level. So, with a 32-bit arch, you get about 4MB (4183112 bytes) of total storage when the objects pack nicely into a page. It is half that on 64-bit because the pointers are twice the size. There's a table detailing this in the code. There are kerneldocs for the functions, but here's an overview: flex_array_alloc() - dynamically allocate a base structure flex_array_free() - free the array and all of the second-level pages flex_array_free_parts() - free the second-level pages, but not the base (for static bases) flex_array_put() - copy into the array at the given index flex_array_get() - copy out of the array at the given index flex_array_prealloc() - preallocate the second-level pages between the given indexes to guarantee no allocs will occur at put() time. We could also potentially just pass the "element_size" into each of the API functions instead of storing it internally. That would get us one more base pointer on 32-bit. I've been testing this by running it in userspace. The header and patch that I've been using are here, as well as the little script I'm using to generate the size table which goes in the kerneldocs. http://sr71.net/~dave/linux/flexarray/ [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
Dave Hansen <dave@linux.vnet.ibm.com> Reviewed-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
-
Anton Vorontsov authored
Since commit 8dfd0374 ("MMC core: limit minimum initialization frequency to 400kHz") MMC core checks for minimum frequency, and that causes following messages flood when using eSDHC controllers: ... mmc0: Minimum clock frequency too high for identification mode mmc0: Minimum clock frequency too high for identification mode ... The warnings are legitimate, since if we'd use 133 MHz clocks for standard SDHCI controllers, we'd not able to scale frequency down to 400 kHz. But eSDHC controllers have a non-standard SD clock management, so we can divide clock by 256 * 16, not just 256. This patch introduces get_min_clock() callback for sdhci core and implements it for sdhci-of driver, and thus fixes the issue. Signed-off-by:
Anton Vorontsov <avorontsov@ru.mvista.com> Cc: Matt Fleming <matt@console-pimps.org> Cc: Ian Molton <ian@mnementh.co.uk> Cc: "Roberto A. Foglietta" <roberto.foglietta@gmail.com> Cc: Pierre Ossman <drzeus@drzeus.cx> Signed-off-by:
-
Hidetoshi Seto authored
commit d6580a9f ("kexec: sysrq: simplify sysrq-c handler") changed the behavior of sysrq-c to unconditional dereference of NULL pointer. So in cases with CONFIG_KEXEC, where crash_kexec() was directly called from sysrq-c before, now it can be said that a step of "real oops" was inserted before starting kdump. However, in contrast to oops via SysRq-c from keyboard which results in panic due to in_interrupt(), oops via "echo c > /proc/sysrq-trigger" will not become panic unless panic_on_oops=1. It means that even if dump is properly configured to be taken on panic, the sysrq-c from proc interface might not start crashdump while the sysrq-c from keyboard can start crashdump. This confuses traditional users of kdump, i.e. people who expect sysrq-c to do common behavior in both of the keyboard and proc interface. This patch brings the keyboard and proc interface behavior of sysrq-c in line, by forcing panic_on_oops=1 before oops in sysrq-c handler. And some updates in documentation are included, to clarify that there is no longer dependency with CONFIG_KEXEC, and that now the system can just crash by sysrq-c if no dump mechanism is configured. Signed-off-by:
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Acked-by:
Vivek Goyal <vgoyal@redhat.com> Cc: Brayan Arraes <brayan@yack.com.br> Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Dave Jones authored
Found with make headers_check /usr/include/linux/pps.h:52: found __[us]{8,16,32,64} type without #include <linux/types.h> Signed-off-by:Dave Jones <davej@redhat.com> Cc: Rodolfo Giometti <giometti@linux.it> Signed-off-by:
-
Catalin Marinas authored
This file makes use of various macros defined in files like asm/current.h or asm-generic/resource.h. All these files can be included via sched.h. The building of the !MMU ARM kernel (with additional patches) fails without this change. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Acked-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Mel Gorman authored
The DCCP protocol tries to allocate some large hash tables during initialisation using the largest size possible. This can be larger than what the page allocator can provide so it prints a warning. However, the caller is able to handle the situation so this patch suppresses the warning. Signed-off-by:
Mel Gorman <mel@csn.ul.ie> Acked-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by:
-
Mel Gorman authored
When profile= is used, a large buffer is allocated early at boot. This can be larger than what the page allocator can provide so it prints a warning. However, the caller is able to handle the situation so this patch suppresses the warning. Signed-off-by:
-
Mel Gorman authored
The page allocator warns once when an order >= MAX_ORDER is specified. This is to catch callers of the allocator that are always falling back to their worst-case when it was not expected. However, there are cases where the caller is behaving correctly but cannot suppress the warning. This patch allows the warning to be suppressed by the callers by specifying __GFP_NOWARN. Signed-off-by:
David Rientjes <rientjes@google.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
After commit ec64f515 ("cgroup: fix frequent -EBUSY at rmdir"), cgroup's rmdir (especially against memcg) doesn't return -EBUSY by temporary ref counts. That commit expects all refs after pre_destroy() is temporary but...it wasn't. Then, rmdir can wait permanently. This patch tries to fix that and change followings. - set CGRP_WAIT_ON_RMDIR flag before pre_destroy(). - clear CGRP_WAIT_ON_RMDIR flag when the subsys finds racy case. if there are sleeping ones, wakes them up. - rmdir() sleeps only when CGRP_WAIT_ON_RMDIR flag is set. Tested-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Reported-by:
Paul Menage <menage@google.com> Acked-by:
Balbir Sigh <balbir@linux.vnet.ibm.com> Signed-off-by:
-
Sebastian Heutling authored
Under certain circumstances msleep(1) within the loop, which waits for the EEPROM to be finished, might take longer than the timeout. On the next loop the status register might now return to be ready and therefore the loop finishes. The following check now tests if a timeout occurred and if so returns an error although the device reported it was ready. This fix replaces testing the occurrence of the timeout by testing the "not ready" bit in the status register. Signed-off-by:
Sebastian Heutling <heutling@who-ing.de> Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Li Zefan authored
The bug was introduced by commit cc31edce ("cgroups: convert tasks file to use a seq_file with shared pid array"). We cache a pid array for all threads that are opening the same "tasks" file, but the pids in the array are always from the namespace of the last process that opened the file, so all other threads will read pids from that namespace instead of their own namespaces. To fix it, we maintain a list of pid arrays, which is keyed by pid_ns. The list will be of length 1 at most time. Reported-by:
Li Zefan <lizf@cn.fujitsu.com> Reviewed-by:
Serge Hallyn <serue@us.ibm.com> Cc: Balbir Singh <balbir@in.ibm.com> Signed-off-by:
-
Kristoffer Ericson authored
Signed-off-by:
Kristoffer Ericson <kristoffer.ericson@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Roland Dreier authored
The generic atomic64_t implementation in lib/ did not export the functions it defined, which means that modules that use atomic64_t would not link on platforms (such as 32-bit powerpc). For example, trying to build a kernel with CONFIG_NET_RDS on such a platform would fail with: ERROR: "atomic64_read" [net/rds/rds.ko] undefined! ERROR: "atomic64_set" [net/rds/rds.ko] undefined! Fix this by exporting the atomic64_t functions to modules. (I export the entire API even if it's not all currently used by in-tree modules to avoid having to continue fixing this in dribs and drabs) Signed-off-by:Roland Dreier <rolandd@cisco.com> Acked-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Eric Sandeen authored
As reported in Red Hat bz #509671, i_blocks for files on hugetlbfs get accounting wrong when doing something like: $ > foo $ date > foo date: write error: Invalid argument $ /usr/bin/stat foo File: `foo' Size: 0 Blocks: 18446744073709547520 IO Block: 2097152 regular ... This is because hugetlb_unreserve_pages() is unconditionally removing blocks_per_huge_page(h) on each call rather than using the freed amount. If there were 0 blocks, it goes negative, resulting in the above. This is a regression from commit a5516438 ("hugetlb: modular state for hugetlb page size") which did: - inode->i_blocks -= BLOCKS_PER_HUGEPAGE * freed; + inode->i_blocks -= blocks_per_huge_page(h); so just put back the freed multiplier, and it's all happy again. Signed-off-by:Eric Sandeen <sandeen@redhat.com> Acked-by:
Andi Kleen <andi@firstfloor.org> Cc: William Lee Irwin III <wli@holomorphy.com> Cc: <stable@kernel.org> Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
rtc-cmos has two drivers, one PNP and one platform. When PNP has not succeeded probing, platform is registered. However, it tries to unregister both drivers unconditionally, instead of only unregistering those that were successfully registered. This causes runtime warnings to be emitted from the driver core code. Fix this with a boolean variable for each driver indicating whether registering was successful. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Cc: David Brownell <david-b@pacbell.net> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Alessandro Zummo <alessandro.zummo@towertech.it> Cc: Ingo Molnar <mingo@elte.hu> Cc: David Brownell <david-b@pacbell.net> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Greg KH <greg@kroah.com> Cc: Ozan Caglayan <ozan@pardus.org.tr> Signed-off-by:
-
Eero Nurkkala authored
When data is read through DMA, the last element must be read separately through the RX register. It cannot be transferred by the DMA. For further details see e.g. OMAP35x TRM (table 19-16). Without the fix the driver causes extra clocks to be clocked to the bus after DMA RX operations. This can cause interesting behaviour with some devices. Signed-off-by:
Juuso Oikarinen <juuso.oikarinen@nokia.com> Signed-off-by:
Eero Nurkkala <ext-eero.nurkkala@nokia.com> [aaro.koskinen@nokia.com: Simplified the patch while keeping the idea.] Signed-off-by:
Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by:
-
Jouni Hogander authored
Currently mcspi wake-ups are not enabled. This might cause cases where OMAP is not waking up on mcspi events. Signed-off-by:
Jouni Hogander <jouni.hogander@nokia.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Pawel Osciak authored
Fixed off-by-one bug in loop indexes - some elements beyond windows' array were accessed, which might result in memory access violations when removing/suspending the device. Signed-off-by:
Pawel Osciak <p.osciak@samsung.com> Reviewed-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by:
-
Lu Zhihe authored
Intel X38 MCHBAR is a 64bits register, base from 0x48, so its higher base is 0x4C. Signed-off-by:
Lu Zhihe <tombowfly@gmail.com> Signed-off-by:
Doug Thompson <dougthompson@xmission.com> Cc: <stable@kernel.org> [2.6.30.x] Signed-off-by:
-
Hidetoshi Seto authored
Setting "crashkernel=512M-2G:64M,2G-:128M" does not work but it turns to work if it has a trailing-whitespace, like "crashkernel=512M-2G:64M,2G-:128M ". It was because of a bug in the parser, running over the cmdline. This patch adds a check of the termination. Reported-by:
Jin Dongming <jin.dongming@np.css.fujitsu.com> Signed-off-by:
-
Rik van Riel authored
Fix a post-2.6.31 regression which was introduced by 2ff05b2b ("oom: move oom_adj value from task_struct to mm_struct"). After moving the oom_adj value from the task struct to the mm_struct, the oom_adj value was no longer properly inherited by child processes. Copying over the oom_adj value at fork time fixes that bug. [kosaki.motohiro@jp.fujitsu.com: test for current->mm before dereferencing it] Signed-off-by:
Rik van Riel <riel@redhat.com> Reported-by:
Paul Menage <manage@google.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Acked-by:
-
David Rientjes authored
If a task is oom killed and still cannot find memory when trying with no watermarks, it's better to fail the allocation attempt than to loop endlessly. Direct reclaim has already failed and the oom killer will be a no-op since current has yet to die, so there is no other alternative for allocations that are not __GFP_NOFAIL. Acked-by:
Hugh Dickins <hugh.dickins@tiscali.co.uk> Signed-off-by:
-
Mel Gorman authored
Fix a post-2.6.24 performace regression caused by 3dfa5721 ("page-allocator: preserve PFN ordering when __GFP_COLD is set"). Narayanan reports "The regression is around 15%. There is no disk controller as our setup is based on Samsung OneNAND used as a memory mapped device on a OMAP2430 based board." The page allocator tries to preserve contiguous PFN ordering when returning pages such that repeated callers to the allocator have a strong chance of getting physically contiguous pages, particularly when external fragmentation is low. However, of the bulk of the allocations have __GFP_COLD set as they are due to aio_read() for example, then the PFNs are in reverse PFN order. This can cause performance degration when used with IO controllers that could have merged the requests. This patch attempts to preserve the contiguous ordering of PFNs for users of __GFP_COLD. Signed-off-by:
Narayananu Gopalakrishnan <narayanan.g@samsung.com> Tested-by:
-
Matthew Wilcox authored
A 32-bit perl can't handle 64-bit addresses without using the BigInt package. Signed-off-by:
Matthew Wilcox <willy@linux.intel.com> Acked-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
-
- 29 Jul, 2009 1 commit
-
-
Catalin Marinas authored
Objects passed to kmemleak_seq_next() have an incremented reference count (hence not freed) but they may point via object_list.next to other freed objects. To avoid this, the whole start/next/stop sequence must be protected by rcu_read_lock(). Signed-off-by:
-
