- 30 Jul, 2009 40 commits
-
-
Rusty Russell authored
I don't really notice it (except to begrudge the extra vertical space), but Ingo does. And he pointed out that one excuse of lguest is as a teaching tool, it should set a good example. Signed-off-by:Rusty Russell <rusty@rustcorp.com.au> Cc: Ingo Molnar <mingo@redhat.com>
-
Michael S. Tsirkin authored
This refactors find_vqs, making it more readable and robust, and fixing two regressions from 2.6.30: - double free_irq causing BUG_ON on device removal - probe failure when vq can't be assigned to msi-x vector (reported on old host kernels) Tested-by:
Amit Shah <amit.shah@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Michael S. Tsirkin authored
This makes delete vq the reverse of find vq. This is required to make it possible to retry find_vqs after a failure, otherwise the list gets corrupted. Signed-off-by:
-
Michael S. Tsirkin authored
Make vp_free_vectors do the reverse of vq_request_vectors. Signed-off-by:
-
Rusty Russell authored
1d589bb1 "Add serial number support for virtio_blk, V4a" extended 'struct virtio_blk_config' to 536 bytes. Lguest and S/390 both use an 8 bit value for the feature length, and this change broke them (if the code is naive). Signed-off-by:
-
Dan Carpenter authored
"new" was freed and then dereferenced. Also the return value wasn't being used so I modified the caller as well. Compile tested only. Found by smatch (http://repo.or.cz/w/smatch.git). regards, dan carpenter Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
git://aeryn.fluff.org.uk/bjdooks/linuxLinus Torvalds authored
* 'i2c-fixes-rc4' of git://aeryn.fluff.org.uk/bjdooks/linux: i2c-omap: OMAP3430 Silicon Errata 1.153 i2c-omap: In case of a NACK|ARDY|AL return from the ISR i2c-omap: Bug in reading the RXSTAT/TXSTAT values from the I2C_BUFFSTAT register i2c-sh_mobile: change module_init() to subsys_initcall() i2c: strncpy does not null terminate string i2c-s3c2410: s3c24xx_i2c_init: don't clobber IICLC value
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6Linus Torvalds authored
* 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6: PM / Hibernate: Replace bdget call with simple atomic_inc of i_count PM / ACPI: HP G7000 Notebook needs a SCI_EN resume quirk
-
Kristoffer Ericson authored
Add the relevant git repositories and affected files to the maintainership of HP Jornada 700-series and Epson s1d13xxxfb support. Signed-off-by:
Kristoffer Ericson <kristoffer.ericson@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Joe Perches authored
Add some touchups to the sample record. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Joe Perches authored
Switch the MAINTAINERS email address format from P: Linus Torvalds M: torvalds@linux-foundation.org to M: Linus Torvalds <torvalds@linux-foundation.org> Mainly to ease the copy-n-pasting of maitnainer addresses into email clients. The script to perform this operation: #! /bin/sh # # Change MAINTAINERS from # P: name # M: address # to: # M: name <address> # # Integrate P: and M: lines # perl -i -e 'local $/; while(<>) { s@P: ([^\n]+)\nM: ([^\n]+)\n@M: \1 <\2>\n@g; print; }' MAINTAINERS # # Quote names with periods, commas and parentheses # sed -r -i -e "s/^M: (.+)([\.,'\(])(.*) </M: \"\1\2\3\" </g" MAINTAINERS Signed-off-by:Pavel Machek <pavel@ucw.cz> Acked-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Joe Perches authored
Allow an option to control the minimum percentage of sign-offs required before being considered a maintainer. git-min-percent has a default value of 5 Signed-off-by:
-
Joe Perches authored
Allow an option to control the minimum percentage of sign-offs required before being considered a maintainer. git-min-percent has a default value of 5 Signed-off-by:
-
Joe Perches authored
Don't require a specific file in a directory to be tested. Also Arnd Bergmann pointed out that the MAINTAINERS pattern requirement that directory patterns have a trailing slash was unnecessary and was likely to be error prone. Removed that requirement. Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
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:
-
