- 05 Oct, 2012 40 commits
-
-
Tejun Heo authored
SG mapping iterator w/ SG_MITER_ATOMIC set required IRQ disabled because it originally used KM_BIO_SRC_IRQ to allow use from IRQ handlers. kmap_atomic() has long been updated to handle stacking atomic mapping requests on per-cpu basis and only requires not sleeping while mapped. Update sg_mapping_iter such that atomic iterators only require disabling preemption instead of disabling IRQ. While at it, convert wte weird @ARG@ notations to @ARG in the comment of sg_miter_start(). Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Alex Dubov <oakad@yahoo.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Borislav Petkov authored
They show up in dmesg [ 4.041094] start plist test [ 4.045804] end plist test without a lot of meaning so hide them behind debug loglevel. Signed-off-by:
Borislav Petkov <borislav.petkov@amd.com> Cc: Lai Jiangshan <laijs@cn.fujitsu.com> Acked-by:
Steven Rostedt <rostedt@goodmis.org> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Jan Beulich authored
Xen's pciback points out a couple of deficiencies with vsscanf()'s standard conformance: - Trailing character matching cannot be checked by the caller: With a format string of "(%x:%x.%x) %n" absence of the closing parenthesis cannot be checked, as input of "(00:00.0)" doesn't cause the %n to be evaluated (because of the code not skipping white space before the trailing %n). - The parameter corresponding to a trailing %n could get filled even if there was a matching error: With a format string of "(%x:%x.%x)%n", input of "(00:00.0]" would still fill the respective variable pointed to (and hence again make the mismatch non-detectable by the caller). This patch aims at fixing those, but leaves other non-conforming aspects of it untouched, among them these possibly relevant ones: - improper handling of the assignment suppression character '*' (blindly discarding all succeeding non-white space from the format and input strings), - not honoring conversion specifiers for %n, - not recognizing the C99 conversion specifier 't' (recognized by vsprintf()). Signed-off-by:
Jan Beulich <jbeulich@suse.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Vikram Mulukutla authored
The logic in do_raw_spin_lock() attempts to acquire a spinlock by invoking arch_spin_trylock() in a loop with a delay between each attempt. Now consider the following situation in a 2 CPU system: 1. CPU-0 continually acquires and releases a spinlock in a tight loop; it stays in this loop until some condition X is satisfied. X can only be satisfied by another CPU. 2. CPU-1 tries to acquire the same spinlock, in an attempt to satisfy the aforementioned condition X. However, it never sees the unlocked value of the lock because the debug spinlock code uses trylock instead of just lock; it checks at all the wrong moments - whenever CPU-0 has locked the lock. Now in the absence of debug spinlocks, the architecture specific spinlock code can correctly allow CPU-1 to wait in a "queue" (e.g., ticket spinlocks), ensuring that it acquires the lock at some point. However, with the debug spinlock code, livelock can easily occur due to the use of try_lock, which obviously cannot put the CPU in that "queue". This queueing mechanism is implemented in both x86 and ARM spinlock code. Note that the situation mentioned above is not hypothetical. A real problem was encountered where CPU-0 was running hrtimer_cancel with interrupts disabled, and CPU-1 was attempting to run the hrtimer that CPU-0 was trying to cancel. Address this by actually attempting arch_spin_lock once it is suspected that there is a spinlock lockup. If we're in a situation that is described above, the arch_spin_lock should succeed; otherwise other timeout mechanisms (e.g., watchdog) should alert the system of a lockup. Therefore, if there is a genuine system problem and the spinlock can't be acquired, the end result (irrespective of this change being present) is the same. If there is a livelock caused by the debug code, this change will allow the lock to be acquired, depending on the implementation of the lower level arch specific spinlock code. [akpm@linux-foundation.org: tweak comment] Signed-off-by:
Vikram Mulukutla <markivx@codeaurora.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Benjamin Gaignard authored
Premit use of another algorithm than the default first-fit one. For example a custom algorithm could be used to manage alignment requirements. As I can't predict all the possible requirements/needs for all allocation uses cases, I add a "free" field 'void *data' to pass any needed information to the allocation function. For example 'data' could be used to handle a structure where you store the alignment, the expected memory bank, the requester device, or any information that could influence the allocation algorithm. An usage example may look like this: struct my_pool_constraints { int align; int bank; ... }; unsigned long my_custom_algo(unsigned long *map, unsigned long size, unsigned long start, unsigned int nr, void *data) { struct my_pool_constraints *constraints = data; ... deal with allocation contraints ... return the index in bitmap where perform the allocation } void create_my_pool() { struct my_pool_constraints c; struct gen_pool *pool = gen_pool_create(...); gen_pool_add(pool, ...); gen_pool_set_algo(pool, my_custom_algo, &c); } Add of best-fit algorithm function: most of the time best-fit is slower then first-fit but memory fragmentation is lower. The random buffer allocation/free tests don't show any arithmetic relation between the allocation time and fragmentation but the best-fit algorithm is sometime able to perform the allocation when the first-fit can't. This new algorithm help to remove static allocations on ESRAM, a small but fast on-chip RAM of few KB, used for high-performance uses cases like DMA linked lists, graphic accelerators, encoders/decoders. On the Ux500 (in the ARM tree) we have define 5 ESRAM banks of 128 KB each and use of static allocations becomes unmaintainable: cd arch/arm/mach-ux500 && grep -r ESRAM . ./include/mach/db8500-regs.h:/* Base address and bank offsets for ESRAM */ ./include/mach/db8500-regs.h:#define U8500_ESRAM_BASE 0x40000000 ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK_SIZE 0x00020000 ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK0 U8500_ESRAM_BASE ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK1 (U8500_ESRAM_BASE + U8500_ESRAM_BANK_SIZE) ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK2 (U8500_ESRAM_BANK1 + U8500_ESRAM_BANK_SIZE) ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK3 (U8500_ESRAM_BANK2 + U8500_ESRAM_BANK_SIZE) ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK4 (U8500_ESRAM_BANK3 + U8500_ESRAM_BANK_SIZE) ./include/mach/db8500-regs.h:#define U8500_ESRAM_DMA_LCPA_OFFSET 0x10000 ./include/mach/db8500-regs.h:#define U8500_DMA_LCPA_BASE (U8500_ESRAM_BANK0 + U8500_ESRAM_DMA_LCPA_OFFSET) ./include/mach/db8500-regs.h:#define U8500_DMA_LCLA_BASE U8500_ESRAM_BANK4 I want to use genalloc to do dynamic allocations but I need to be able to fine tune the allocation algorithm. I my case best-fit algorithm give better results than first-fit, but it will not be true for every use case. Signed-off-by:Benjamin Gaignard <benjamin.gaignard@stericsson.com> Cc: Huang Ying <ying.huang@intel.com> Signed-off-by:
-
Davidlohr Bueso authored
Account for all properties when a and/or b are 0: gcd(0, 0) = 0 gcd(a, 0) = a gcd(0, b) = b Fixes no known problems in current kernels. Signed-off-by:
Davidlohr Bueso <dave@gnu.org> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jan Beulich authored
The main option should not appear in the resulting .config when the dependencies aren't met (i.e. use "depends on" rather than directly setting the default from the combined dependency values). The sub-options should depend on the main option rather than a more generic higher level one. Signed-off-by:
Don Zickus <dzickus@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Alex Elder authored
The result of converting an integer value to another signed integer type that's unable to represent the original value is implementation defined. (See notes in section 6.3.1.3 of the C standard.) In match_number(), the result of simple_strtol() (which returns type long) is assigned to a value of type int. Instead, handle the result of simple_strtol() in a well-defined way, and return -ERANGE if the result won't fit in the int variable used to hold the parsed result. No current callers pay attention to the particular error value returned, so this additional return code shouldn't do any harm. [akpm@linux-foundation.org: coding-style tweaks] Signed-off-by:
Alex Elder <elder@inktank.com> Cc: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Fengguang Wu authored
To avoid name conflicts: drivers/video/riva/fbdev.c:281:9: sparse: preprocessor token MAX_LEVEL redefined While at it, also make the other names more consistent and add parentheses. [akpm@linux-foundation.org: repair fallout] [sfr@canb.auug.org.au: IB/mlx4: fix for MAX_ID_MASK to MAX_IDR_MASK name change] Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Cc: Bernd Petrovitsch <bernd@petrovitsch.priv.at> Cc: walter harms <wharms@bfs.de> Cc: Glauber Costa <glommer@parallels.com> Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Cc: Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Takuya Yoshikawa authored
Now that we have defined generic set_bit_le() we do not need to use test_and_set_bit_le() for atomically setting a bit. Signed-off-by:
Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp> Cc: Avi Kivity <avi@redhat.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Takuya Yoshikawa authored
Needed to replace test_and_set_bit_le() in virt/kvm/kvm_main.c which is being used for this missing function. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Avi Kivity <avi@redhat.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Takuya Yoshikawa authored
Needed to replace test_and_set_bit_le() in virt/kvm/kvm_main.c which is being used for this missing function. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Marcelo Tosatti <mtosatti@redhat.com> Cc: Avi Kivity <avi@redhat.com> Signed-off-by:
-
Takuya Yoshikawa authored
To introduce generic set_bit_le() later, we remove our own definition and use a proper non-atomic bitops function: __set_bit_le(). Signed-off-by:
Grant Grundler <grundler@parisc-linux.org> Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
Ben Hutchings authored
There are now standard functions for dealing with little-endian bit arrays, so use them instead of our own implementations. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
-
Jingoo Han authored
This patch adds the of_match_table to platform-lcd driver to be probed when platform-lcd device node is found in the device tree. [akpm@linux-foundation.org: include of.h] Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Julia Lawall authored
devm_kfree should not have to be explicitly used. The semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x,d; @@ x = devm_kzalloc(...) ... ?-devm_kfree(d,x); // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Acked-by:
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by:
-
Marcin Juszkiewicz authored
This driver was for the ProGear webpad device which was produced in 2000/2001 and is not available on a market. I no longer have this hardware so can not even check how Linux works on it. Signed-off-by:
Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> Signed-off-by:
-
G.Shark Jeong authored
This driver is a general version for LM3639 backlgiht + flash driver chip of TI. LM3639: The LM3639 is a single chip LCD Display Backlight driver + white LED Camera driver. Programming is done over an I2C compatible interface. www.ti.com [akpm@linux-foundation.org: code layout tweaks] Signed-off-by:
G.Shark Jeong <gshark.jeong@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Daniel Jeong <daniel.jeong@ti.com> Cc: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
G.Shark Jeong authored
This driver is a general version for LM3630 backlgiht driver chip of TI. LM3630 : The LM3630 is a current mode boost converter which supplies the power and controls the current in two strings of up to 10 LEDs per string. Programming is done over an I2C compatible interface. www.ti.com [akpm@linux-foundation.org: make bled_name[] static, a few coding style tuneups, create new set_intensity(), partly to avoid awkward layout gymnastics] Signed-off-by:
-
Kim, Milo authored
LP8556 backlight driver supports fast refresh mode when exiting the low power mode. This bit can be configurable in the platform side. Signed-off-by:
Milo(Woogyom) Kim <milo.kim@ti.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Bryan Wu <bryan.wu@canonical.com> Signed-off-by:
-
Jingoo Han authored
Since msleep() might not sleep for the desired amount when less than 20ms, use usleep_range(). Signed-off-by:
-
Jingoo Han authored
Since msleep() might not sleep for the desired amount when less than 20ms, use usleep_range(). Signed-off-by:
-
Jingoo Han authored
Since msleep() might not sleep for the desired amount when less than 20ms, use usleep_range(). Signed-off-by:
-
Khalid Aziz authored
Signed-off-by:
Khalid Aziz <khalid.aziz@hp.com> Cc: Khalid Aziz <khalid@gonehiking.org> Signed-off-by:
-
Andy Shevchenko authored
Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Joe Perches authored
Commit ec21e2ec ("freescale: Move the Freescale drivers") moved the files, update the pattern. Signed-off-by:
Joe Perches <joe@perches.com> Acked-by:
Richard Cochran <richardcochran@gmail.com> Acked-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Uwe Kleine-König authored
Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Yang Bai authored
Signed-off-by:
Yang Bai <hamo.by@gmail.com> Signed-off-by:
-
Andy Shevchenko authored
Acked-by:
Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by:
-
George Spelvin authored
Numbering the 8 potential digits 2 though 9 never did make a lot of sense. Signed-off-by:
George Spelvin <linux@horizon.com> Cc: Denys Vlasenko <vda.linux@googlemail.com> Cc: Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
-
George Spelvin authored
If you're going to have a conditional branch after each 32x32->64-bit multiply, might as well shrink the code and make it a loop. This also avoids using the long multiply for small integers. (This leaves the comments in a confusing state, but that's a separate patch to make review easier.) Signed-off-by:
-
George Spelvin authored
The same multiply-by-inverse technique can be used to convert division by 10000 to a 32x32->64-bit multiply. Signed-off-by:
-
George Spelvin authored
Shrink the reciprocal approximations used in put_dec_full4() based on the comments in put_dec_full9(). Signed-off-by:
-
hongfeng authored
orderly_poweroff is trying to poweroff platform in two steps: step 1: Call user space application to poweroff step 2: If user space poweroff fail, then do a force power off if force param is set. The bug here is, step 1 is always successful with param UMH_NO_WAIT, which obey the design goal of orderly_poweroff. We have two choices here: UMH_WAIT_EXEC which means wait for the exec, but not the process; UMH_WAIT_PROC which means wait for the process to complete. we need to trade off the two choices: If using UMH_WAIT_EXEC, there is potential issue comments by Serge E. Hallyn: The exec will have started, but may for whatever (very unlikely) reason fail. If using UMH_WAIT_PROC, there is potential issue comments by Eric W. Biederman: If the caller is not running in a kernel thread then we can easily get into a case where the user space caller will block waiting for us when we are waiting for the user space caller. Thanks for their excellent ideas, based on the above discussion, we finally choose UMH_WAIT_EXEC, which is much more safe, if the user application really fails, we just complain the application itself, it seems a better choice here. Signed-off-by:Feng Hong <hongfeng@marvell.com> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Serge Hallyn <serge.hallyn@canonical.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Acked-by:
"Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by:
-
Shawn Guo authored
As kernel_power_off() calls disable_nonboot_cpus(), we may also want to have kernel_restart() call disable_nonboot_cpus(). Doing so can help machines that require boot cpu be the last alive cpu during reboot to survive with kernel restart. This fixes one reboot issue seen on imx6q (Cortex-A9 Quad). The machine requires that the restart routine be run on the primary cpu rather than secondary ones. Otherwise, the secondary core running the restart routine will fail to come to online after reboot. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jiri Kosina authored
Historically, the top three bytes of personality have been used for things such as ADDR_NO_RANDOMIZE, which made sense only for specific architectures. We now however have a flag there that is general no matter the architecture (UNAME26); generally we have to be careful to preserve the personality flags across exec(). This patch fixes tile architecture not to forcefully overwrite personality flags during exec(). In addition to that, we fix two other things along the way: - exec_domain switching is fixed -- set_personality() should always be used instead of directly assigning to current->personality. - as pointed out by Arnd Bergmann, PER_LINUX_32BIT is not used anywhere by tile, so let's just drop that in favor of PER_LINUX Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Acked-by:
Chris Metcalf <cmetcalf@tilera.com> Signed-off-by:
-
Jiri Kosina authored
Historically, the top three bytes of personality have been used for things such as ADDR_NO_RANDOMIZE, which made sense only for specific architectures. We now however have a flag there that is general no matter the architecture (UNAME26); generally we have to be careful to preserve the personality flags across exec(). This patch tries to fix all architectures that forcefully overwrite personality flags during exec() (ppc32 and s390 have been fixed recently by commits f9783ec8 ("[S390] Do not clobber personality flags on exec") and 59e4c3a2 ("powerpc/32: Don't clobber personality flags on exec") in a similar way already). Signed-off-by:
-
Fengguang Wu authored
It's required for the core fs/namespace.c and many other basic features. Signed-off-by:
Lennox Wu <lennox.wu@gmail.com> Signed-off-by:
-
Geert Uytterhoeven authored
Commit 6afe1a1f ("PM: Remove legacy PM") removed the initialization of retval, causing: arch/frv/kernel/pm.c: In function 'sysctl_pm_do_suspend': arch/frv/kernel/pm.c:165:5: warning: 'retval' may be used uninitialized in this function [-Wuninitialized] Remove the variable completely to fix this, and convert to a proper switch (...) { ... } construct to improve readability. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
-
Joe Mario authored
Fix the const sections for the code generated by crc32 table. There's no ro version of the cacheline aligned section, so we cannot put in const data without a conflict Just don't make the crc tables const for now. [ak@linux.intel.com: some fixes and new description] [akpm@linux-foundation.org: checkpatch fixes] Signed-off-by:
Joe Mario <jmario@redhat.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
