- 15 Apr, 2011 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/vapier/blackfinLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/vapier/blackfin: Blackfin: SMP: fix cache flush loop Blackfin: time-ts: ack gptimer sooner to avoid missing short ints Blackfin: gptimers: fix thinko when disabling timers Blackfin: SMP: make all barriers handle cache issues
-
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-clientLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client: libceph: fix linger request requeueing
-
- 14 Apr, 2011 28 commits
-
-
Ben Hutchings authored
The conventional format for boolean attributes in sysfs is numeric ("0" or "1" followed by new-line). Any boolean attribute can then be read and written using a generic function. Using the strings "yes [no]", "[yes] no" (read), "yes" and "no" (write) will frustrate this. [akpm@linux-foundation.org: use kstrtoul()] [akpm@linux-foundation.org: test_bit() doesn't return 1/0, per Neil] Signed-off-by:Ben Hutchings <ben@decadent.org.uk> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Johannes Weiner <jweiner@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Hugh Dickins <hughd@google.com> Tested-by:
David Rientjes <rientjes@google.com> Cc: NeilBrown <neilb@suse.de> Cc: <stable@kernel.org> [2.6.38.x] Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Bob Liu authored
On no-mmu arch, there is a memleak during shmem test. The cause of this memleak is ramfs_nommu_expand_for_mapping() added page refcount to 2 which makes iput() can't free that pages. The simple test file is like this: int main(void) { int i; key_t k = ftok("/etc", 42); for ( i=0; i<100; ++i) { int id = shmget(k, 10000, 0644|IPC_CREAT); if (id == -1) { printf("shmget error\n"); } if(shmctl(id, IPC_RMID, NULL ) == -1) { printf("shm rm error\n"); return -1; } } printf("run ok...\n"); return 0; } And the result: root:/> free total used free shared buffers Mem: 60320 17912 42408 0 0 -/+ buffers: 17912 42408 root:/> shmem run ok... root:/> free total used free shared buffers Mem: 60320 19096 41224 0 0 -/+ buffers: 19096 41224 root:/> shmem run ok... root:/> free total used free shared buffers Mem: 60320 20296 40024 0 0 -/+ buffers: 20296 40024 ... After this patch the test result is:(no memleak anymore) root:/> free total used free shared buffers Mem: 60320 16668 43652 0 0 -/+ buffers: 16668 43652 root:/> shmem run ok... root:/> free total used free shared buffers Mem: 60320 16668 43652 0 0 -/+ buffers: 16668 43652 Signed-off-by:Bob Liu <lliubbo@gmail.com> Acked-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
David Howells <dhowells@redhat.com> Cc: <stable@kernel.org> Signed-off-by:
-
Richard Weinberger authored
Commit 8a5ec0ba "Lockless (and preemptless) fastpaths for slub" makes use of this_cpu_cmpxchg_double() which needs this_cpu_cmpxchg16b_emu() on x86_64. Implementing cmpxchg16b emulation for UML would introduce too much complexity. So just disable it. Signed-off-by:
Richard Weinberger <richard@nod.at> Reported-by:
Sergei Trofimovich <slyich@gmail.com> Acked-by:
Pekka Enberg <penberg@kernel.org> Signed-off-by:
-
Richard Weinberger authored
Commit 1de1502c ("x86, um: now we can get rid of trivial uml headers") removed accidentally bug.h which broke UML's call tracer and bug handler. Without asm-generic/bug.h UML uses BUG() from arch/x86/ which makes use of ud2. UML cannot use ud2, it raises SIGILL in user mode. As UML has a different stack for handling signals the call trace will be cut off. Signed-off-by:
-
Jeff Mahoney authored
force_o_largefile() on ia64 is defined in <asm/fcntl.h> and requires <linux/personality.h>. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
-
Hans J. Koch authored
My old mail address doesn't exist anymore. This patch changes all occurences in MAINTAINERS to my new address. Signed-off-by:
Hans J. Koch <hjk@hansjkoch.de> Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
Alexandre Bounine authored
Fix a possible problem with mport registration left non-cleared after fsl_rio_setup() exits on link error. Abort mport initialization if registration failed. This patch is applicable to 2.6.39-rc1 only. The problem does not exist for earlier versions. Signed-off-by:
Alexandre Bounine <alexandre.bounine@idt.com> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Li Yang <leoli@freescale.com> Cc: Thomas Moll <thomas.moll@sysgo.com> Signed-off-by:
-
Alexandre Bounine authored
Signed-off-by:
-
KOSAKI Motohiro authored
This is an almost-revert of commit 93b43fa5 ("oom: give the dying task a higher priority"). That commit dramatically improved oom killer logic when a fork-bomb occurs. But I've found that it has nasty corner case. Now cpu cgroup has strange default RT runtime. It's 0! That said, if a process under cpu cgroup promote RT scheduling class, the process never run at all. If an admin inserts a !RT process into a cpu cgroup by setting rtruntime=0, usually it runs perfectly because a !RT task isn't affected by the rtruntime knob. But if it promotes an RT task via an explicit setscheduler() syscall or an OOM, the task can't run at all. In short, the oom killer doesn't work at all if admins are using cpu cgroup and don't touch the rtruntime knob. Eventually, kernel may hang up when oom kill occur. I and the original author Luis agreed to disable this logic. Signed-off-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Acked-by:
Luis Claudio R. Goncalves <lclaudio@uudg.org> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Reviewed-by:
Minchan Kim <minchan.kim@gmail.com> Acked-by:
-
KOSAKI Motohiro authored
all_unreclaimable check in direct reclaim has been introduced at 2.6.19 by following commit. 2006 Sep 25; commit 408d8544; oom: use unreclaimable info And it went through strange history. firstly, following commit broke the logic unintentionally. 2008 Apr 29; commit a41f24ea; page allocator: smarter retry of costly-order allocations Two years later, I've found obvious meaningless code fragment and restored original intention by following commit. 2010 Jun 04; commit bb21c7ce; vmscan: fix do_try_to_free_pages() return value when priority==0 But, the logic didn't works when 32bit highmem system goes hibernation and Minchan slightly changed the algorithm and fixed it . 2010 Sep 22: commit d1908362: vmscan: check all_unreclaimable in direct reclaim path But, recently, Andrey Vagin found the new corner case. Look, struct zone { .. int all_unreclaimable; .. unsigned long pages_scanned; .. } zone->all_unreclaimable and zone->pages_scanned are neigher atomic variables nor protected by lock. Therefore zones can become a state of zone->page_scanned=0 and zone->all_unreclaimable=1. In this case, current all_unreclaimable() return false even though zone->all_unreclaimabe=1. This resulted in the kernel hanging up when executing a loop of the form 1. fork 2. mmap 3. touch memory 4. read memory 5. munmmap as described in http://www.gossamer-threads.com/lists/linux/kernel/1348725#1348725 Is this ignorable minor issue? No. Unfortunately, x86 has very small dma zone and it become zone->all_unreclamble=1 easily. and if it become all_unreclaimable=1, it never restore all_unreclaimable=0. Why? if all_unreclaimable=1, vmscan only try DEF_PRIORITY reclaim and a-few-lru-pages>>DEF_PRIORITY always makes 0. that mean no page scan at all! Eventually, oom-killer never works on such systems. That said, we can't use zone->pages_scanned for this purpose. This patch restore all_unreclaimable() use zone->all_unreclaimable as old. and in addition, to add oom_killer_disabled check to avoid reintroduce the issue of commit d1908362 ("vmscan: check all_unreclaimable in direct reclaim path"). Reported-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
-
Michael Ellerman authored
In __access_remote_vm() we need to check that we have found the right vma, not the following vma before we try to access it. Otherwise we might call the vma's access routine with an address which does not fall inside the vma. It was discovered on a current kernel but with an unreleased driver, from memory it was strace leading to a kernel bad access, but it obviously depends on what the access implementation does. Looking at other access implementations I only see: $ git grep -A 5 vm_operations|grep access arch/powerpc/platforms/cell/spufs/file.c- .access = spufs_mem_mmap_access, arch/x86/pci/i386.c- .access = generic_access_phys, drivers/char/mem.c- .access = generic_access_phys fs/sysfs/bin.c- .access = bin_access, The spufs one looks like it might behave badly given the wrong vma, it assumes vma->vm_file->private_data is a spu_context, and looks like it would probably blow up pretty quickly if it wasn't. generic_access_phys() only uses the vma to check vm_flags and get the mm, and then walks page tables using the address. So it should bail on the vm_flags check, or at worst let you access some other VM_IO mapping. And bin_access() just proxies to another access implementation. Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Reviewed-by:
-
Jiri Kosina authored
5520e894 ("brk: fix min_brk lower bound computation for COMPAT_BRK") tried to get the whole logic of brk randomization for legacy (libc5-based) applications finally right. It turns out that the way to detect whether brk has actually been randomized in the end or not introduced by that patch still doesn't work for those binaries, as reported by Geert: : /sbin/init from my old m68k ramdisk exists prematurely. : : Before the patch: : : | brk(0x80005c8e) = 0x80006000 : : After the patch: : : | brk(0x80005c8e) = 0x80005c8e : : Old libc5 considers brk() to have failed if the return value is not : identical to the requested value. I don't like it, but currently see no better option than a bit flag in task_struct to catch the CONFIG_COMPAT_BRK && randomize_va_space == 2 case. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Tested-by:
Geert Uytterhoeven <geert@linux-m68k.org> Reported-by:
-
Wanlong Gao authored
Fix the wrong members and the wrong function's definition, since the irq_chip had changed. Signed-off-by:
Wanlong Gao <wanlong.gao@gmail.com> Cc: Jack Steiner <steiner@sgi.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Hugh Dickins authored
If you fill up a tmpfs, df was showing tmpfs 460800 - - - /tmp because of an off-by-one in the max_blocks checks. Fix it so df shows tmpfs 460800 460800 0 100% /tmp Signed-off-by:
-
Randy Dunlap authored
Drop Chris Wright from STABLE maintainers. He hasn't done STABLE release work for quite some time. Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Acked-by:
Chris Wright <chrisw@sous-sol.org> Cc: Greg KH <gregkh@suse.de> Signed-off-by:
-
Andi Kleen authored
I found it difficult to make sense of transparent huge pages without having any counters for its actions. Add some counters to vmstat for allocation of transparent hugepages and fallback to smaller pages. Optional patch, but useful for development and understanding the system. Contains improvements from Andrea Arcangeli and Johannes Weiner [akpm@linux-foundation.org: coding-style fixes] [hannes@cmpxchg.org: fix vmstat_text[] entries] Signed-off-by:
Andi Kleen <ak@linux.intel.com> Acked-by:
Andrea Arcangeli <aarcange@redhat.com> Reviewed-by:
Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
-
Joe Perches authored
Commits 4a6514e6 ("tty: move obsolete and broken tty drivers to drivers/staging/tty/") and a6afd9f3 ("tty: move a number of tty drivers from drivers/char/ to drivers/tty/") moved files around. Update patterns and orphan some files that were moved to staging. Signed-off-by:
Joe Perches <joe@perches.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
Joe Perches authored
Commit 66d857b0 ("m68k: merge m68k and m68knommu arch directories") moved the files around. Signed-off-by:
Greg Ungerer <gerg@uclinux.org> Signed-off-by:
-
Alexander Clouter authored
Signed-off-by:
Alexander Clouter <alex@digriz.org.uk> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Alexey Dobriyan authored
Fix the following warnings: CC [M] lib/test-kstrtox.o lib/test-kstrtox.c: In function 'test_kstrtou64_ok': lib/test-kstrtox.c:318: warning: this decimal constant is unsigned only in ISO C90 ... Signed-off-by: -
Antonio Ospite authored
Make the driver aware of the initial status of the regulator. The leds-regulator driver was ignoring the initial status of the regulator; this resulted in rdev->use_count being incremented to 2 after calling regulator_led_set_value() in the .probe method when a regulator was already enabled at insmod time, which made it impossible to ever disable the regulator. Signed-off-by:
Antonio Ospite <ospite@studenti.unina.it> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Antonio Ospite <ospite@studenti.unina.it> Acked-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Daniel Ribeiro <drwyrm@gmail.com> Signed-off-by:
-
Christoph Lameter authored
Signed-off-by:
Christoph Lameter <cl@linux.com> Signed-off-by:
-
Paul Mundt authored
The memory hotplug case involves calling to build_all_zonelists() which in turns calls in to setup_zone_pageset(). The latter is marked __meminit while build_all_zonelists() itself has no particular annotation. build_all_zonelists() is only handed a non-NULL pointer in the case of memory hotplug through an existing __meminit path, so the setup_zone_pageset() reference is always safe. The options as such are either to flag build_all_zonelists() as __ref (as per __build_all_zonelists()), or to simply discard the __meminit annotation from setup_zone_pageset(). Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Acked-by:
Mel Gorman <mel@csn.ul.ie> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Acked-by:
-
Timo Warns authored
The kernel automatically evaluates partition tables of storage devices. The code for evaluating LDM partitions (in fs/partitions/ldm.c) contains a bug that causes a kernel oops on certain corrupted LDM partitions. A kernel subsystem seems to crash, because, after the oops, the kernel no longer recognizes newly connected storage devices. The patch validates the value of vblk_size. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
Timo Warns <warns@pre-sense.de> Cc: Eugene Teo <eugeneteo@kernel.sg> Cc: Harvey Harrison <harvey.harrison@gmail.com> Cc: Richard Russon <rich@flatcap.org> Signed-off-by:
-
Axel Lin authored
The platform_device_id table is supposed to be zero-terminated. Signed-off-by:
Axel Lin <axel.lin@gmail.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Daniel Kiper authored
If CONFIG_FLATMEM is enabled pfn is calculated in online_page() more than once. It is possible to optimize that and use value established at beginning of that function. Signed-off-by:
Daniel Kiper <dkiper@net-space.pl> Acked-by:
Dave Hansen <dave@linux.vnet.ibm.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Wu Fengguang <fengguang.wu@intel.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Christoph Lameter <cl@linux.com> Acked-by:
Jesper Juhl <jj@chaosbits.net> Signed-off-by:
-
Eric Dumazet authored
commit 3f58a829 ("move memcg reclaimable page into tail of inactive list") added inline keyword twice in its prototype. CC arch/x86/kernel/asm-offsets.s In file included from include/linux/swap.h:8, from include/linux/suspend.h:4, from arch/x86/kernel/asm-offsets.c:12: include/linux/memcontrol.h:220: error: duplicate `inline' Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Reviewed-by:
-
- 13 Apr, 2011 10 commits
-
-
Sonic Zhang authored
The recent commit (10774912647781) wasn't entirely correct. While it fixed some issues, it introduced others. So pull in the fixes from the public cache flush functions, and document why we need to call things directly ourselves. Signed-off-by:
Sonic Zhang <sonic.zhang@analog.com> Signed-off-by:
Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
If the period of a gptimer is fairly low, we might miss an interrupt by acking it too late (we end up acking the new int as well). Reported-by:
Isabelle Leonardi <i.leonardi@detracom.fr> Signed-off-by:
-
Mike Frysinger authored
We only want to clear the run bit for this one timer, not all status bits. So don't read the whole reg and then write all the bits back out. Reported-by:
-
Graf Yang authored
When suspending/resuming, the common task freezing code will run in parallel and freeze processes on each core. This is because the code uses the non-smp version of memory barriers (as well it should). The Blackfin smp barrier logic at the moment contains the cache sync logic, but the non-smp barriers do not. This is incorrect as Rafel summarized: > ... > The existing memory barriers are SMP barriers too, but they are more > than _just_ SMP barriers. At least that's how it is _supposed_ to be > (eg. rmb() is supposed to be stronger than smp_rmb()). > ... > However, looking at the blackfin's definitions of SMP barriers I see > that it uses extra stuff that should _also_ be used in the definitions > of the mandatory barriers. > ... URL: http://lkml.org/lkml/2011/4/13/11 LKML-Reference: <BANLkTi=F-C-vwX4PGGfbkdTBw3OWL-twfg@mail.gmail.com> Signed-off-by:
Graf Yang <graf.yang@analog.com> Signed-off-by:
-
Linus Torvalds authored
Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86 * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86: x86 platform drivers: Build fix for intel_pmic_gpio
-
git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/avr32-2.6Linus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/avr32-2.6: avr32: add ATAG_BOARDINFO don't check platform_get_irq's return value against zero avr32: init cannot ignore signals sent by force_sig_info() avr32: fix deadlock when reading clock list in debugfs avr32: Fix .size directive for cpu_enter_idle avr32: At32ap: pio fix typo "))" on gpio_irq_unmask prototype fix the wrong argument of the functions definition
-
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6Linus Torvalds authored
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (22 commits) Revert "i915: restore only the mode of this driver on lastclose" Revert "ttm: Utilize the DMA API for pages that have TTM_PAGE_FLAG_DMA32 set." i915: select VIDEO_OUTPUT_CONTROL for ACPI_VIDEO drm/radeon/kms: properly program vddci on evergreen+ drm/radeon/kms: add voltage type to atom set voltage function drm/radeon/kms: fix pcie_p callbacks on btc and cayman drm/radeon/kms: fix suspend on rv530 asics drm/radeon/kms: clean up gart dummy page handling drm/radeon/kms: make radeon i2c put/get bytes less noisy drm/radeon/kms: pll tweaks for rv6xx drm/radeon: Fix KMS legacy backlight support if CONFIG_BACKLIGHT_CLASS_DEVICE=m. radeon: Fix KMS CP writeback on big endian machines. i915: restore only the mode of this driver on lastclose drm/nvc0: improve vm flush function drm/nv50-nvc0: remove some code that doesn't belong here drm/nv50: use "nv86" tlb flush method on everything except 0x50/0xac drm/nouveau: quirk for XFX GT-240X-YA drm/nv50-nvc0: work around an evo channel hang that some people see drm/nouveau: implement init table opcode 0x5c drm/nouveau: fix oops on unload with disabled LVDS panel ...
-
Matthew Garrett authored
Fix an incorrect function name so the driver builds. Signed-off-by:Matthew Garrett <mjg@redhat.com>
-
Linus Torvalds authored
We really only want to unplug the pending IO when the process actually goes to sleep. So move the test for flushing the plug up to the place where we actually deactivate the task - where we have properly checked for preemption and for the process really sleeping. Acked-by:
Jens Axboe <jaxboe@fusionio.com> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Linus Torvalds authored
Commit 982134ba ("mm: avoid wrapping vm_pgoff in mremap()") fixed the case of a expanding mapping causing vm_pgoff wrapping when you used mremap. But there was another case where we expand mappings hiding in plain sight: the automatic stack expansion. This fixes that case too. This one also found by Robert Święcki, using his nasty system call fuzzer tool. Good job. Reported-and-tested-by:
Robert Święcki <robert@swiecki.net> Cc: stable@kernel.org Signed-off-by:
-
