- 07 May, 2007 40 commits
-
-
Oleg Nesterov authored
refrigerator() can miss a wakeup, "wait event" loop needs a proper memory ordering. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Acked-by:
"Rafael J. Wysocki" <rjw@sisk.pl> Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Robert P. J. Day authored
Remove the apparently useless config option GENERIC_BUST_SPINLOCK, since nothing in the source tree refers to it. Signed-off-by:
Robert P. J. Day <rpjday@mindspring.com> Acked-by:
Ian Molton <spyro@f2s.com> Signed-off-by:
-
Andrew Morton authored
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=8341 Cc: <matthias.kaehlcke@gmail.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by:
-
Ivan Kokshaysky authored
Files: include/asm-alpha/thread_info.h Provide "prctl" macros for ALPHA. Signed-off-by:
Jay Estabrook <jay.estabrook@hp.com> Signed-off-by:
Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Richard Henderson <rth@twiddle.net> Signed-off-by:
-
Ivan Kokshaysky authored
Files: arch/alpha/boot/bootpz.c Create a dummy "__kmalloc()" to satisfy the loader; never called. arch/alpha/boot/tools/objstrip.c Remove an include that is now (2.6.x) unnecessary. Signed-off-by:
-
Milind Arun Choudhary authored
ROUND_UP macro cleanup use ALIGN Signed-off-by:
Milind Arun Choudhary <milindchoudhary@gmail.com> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Richard Henderson <rth@twiddle.net> Signed-off-by:
-
Yoshinori Sato authored
h8300 zImage target support. Signed-off-by:
Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by:
-
Yoshinori Sato authored
h8300 using generic irq handler patch. Signed-off-by:
-
john stultz authored
Currently h8/300 does not implement sub-jiffy timekeeping, so there is no benefit to having arch specific timekeeping code. This patch simply removes those functions and enables the generic timekeeping code. Signed-off-by:
John Stultz <johnstul@us.ibm.com> Acked-by:
-
Wu, Bryan authored
This patch implements the driver necessary use the Analog Devices Blackfin processor's SPI Port. Signed-off-by:
Bryan Wu <bryan.wu@analog.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by:
-
Wu, Bryan authored
This patch implements the driver necessary use the Analog Devices Blackfin processor's on-chip RTC controller. Signed-off-by:
-
Wu, Bryan authored
As SMC91X ethernet controller are used in blackfin STAMP 533 development board, this patch add blackfin support to the smc91x linux driver. Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Bryan Wu authored
This patch implements the driver necessary use the Analog Devices Blackfin processor's Serial Port. Signed-off-by:
-
Bryan Wu authored
This adds support for the Analog Devices Blackfin processor architecture, and currently supports the BF533, BF532, BF531, BF537, BF536, BF534, and BF561 (Dual Core) devices, with a variety of development platforms including those avaliable from Analog Devices (BF533-EZKit, BF533-STAMP, BF537-STAMP, BF561-EZKIT), and Bluetechnix! Tinyboards. The Blackfin architecture was jointly developed by Intel and Analog Devices Inc. (ADI) as the Micro Signal Architecture (MSA) core and introduced it in December of 2000. Since then ADI has put this core into its Blackfin processor family of devices. The Blackfin core has the advantages of a clean, orthogonal,RISC-like microprocessor instruction set. It combines a dual-MAC (Multiply/Accumulate), state-of-the-art signal processing engine and single-instruction, multiple-data (SIMD) multimedia capabilities into a single instruction-set architecture. The Blackfin architecture, including the instruction set, is described by the ADSP-BF53x/BF56x Blackfin Processor Programming Reference http://blackfin.uclinux.org/gf/download/frsrelease/29/2549/Blackfin_PRM.pdf The Blackfin processor is already supported by major releases of gcc, and there are binary and source rpms/tarballs for many architectures at: http://blackfin.uclinux.org/gf/project/toolchain/frs There is complete documentation, including "getting started" guides available at: http://docs.blackfin.uclinux.org/ which provides links to the sources and patches you will need in order to set up a cross-compiling environment for bfin-linux-uclibc This patch, as well as the other patches (toolchain, distribution, uClibc) are actively supported by Analog Devices Inc, at: http://blackfin.uclinux.org/ We have tested this on LTP, and our test plan (including pass/fails) can be found at: http://docs.blackfin.uclinux.org/doku.php?id=testing_the_linux_kernel [m.kozlowski@tuxland.pl: balance parenthesis in blackfin header files] Signed-off-by:
Mariusz Kozlowski <m.kozlowski@tuxland.pl> Signed-off-by:
Aubrey Li <aubrey.li@analog.com> Signed-off-by:
Jie Zhang <jie.zhang@analog.com> Signed-off-by:
-
Roland McGrath authored
wait* syscalls return -ECHILD even when an individual PID of a live child was requested explicitly, when security_task_wait denies the operation. This means that something like a broken SELinux policy can produce an unexpected failure that looks just like a bug with wait or ptrace or something. This patch makes do_wait return -EACCES (or other appropriate error returned from security_task_wait() instead of -ECHILD if some children were ruled out solely because security_task_wait failed. [jmorris@namei.org: switch error code to EACCES] Signed-off-by:
Roland McGrath <roland@redhat.com> Acked-by:
Stephen Smalley <sds@tycho.nsa.gov> Cc: Chris Wright <chrisw@sous-sol.org> Cc: James Morris <jmorris@namei.org> Signed-off-by:
-
Christoph Lameter authored
Address spaces contain an allocation flag that specifies restriction on the zone for pages placed in the mapping. I.e. some device may require pages to be allocated from a DMA zone. Block devices may not be able to use pages from HIGHMEM. Memory policies and the common use of page migration works only on the highest zone. If the address space does not allow allocation from the highest zone then the pages in the address space are not migratable simply because we can only allocate memory for a specified node if we allow allocation for the highest zone on each node. Acked-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Akinobu Mita authored
SLOB doesn't calculate correct page order when page size is not 4KB. This patch fixes it with using get_order() instead of find_order() which is SLOB version of get_order(). Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Acked-by:
Matt Mackall <mpm@selenic.com> Cc: <stable@kernel.org> Signed-off-by:
-
Akinobu Mita authored
If hugetlbfs module_init() fails, hugetlbfs_vfsmount is not initialized and shmget() with SHM_HUGETLB flag will cause NULL pointer dereference. Signed-off-by:
William Irwin <wli@holomorphy.com> Signed-off-by:
-
Christoph Lameter authored
There is no user remaining and I have never seen any use of that flag. Signed-off-by:
-
Christoph Lameter authored
SLAB_CTOR atomic is never used which is no surprise since I cannot imagine that one would want to do something serious in a constructor or destructor. In particular given that the slab allocators run with interrupts disabled. Actions in constructors and destructors are by their nature very limited and usually do not go beyond initializing variables and list operations. (The i386 pgd ctor and dtors do take a spinlock in constructor and destructor..... I think that is the furthest we go at this point.) There is no flag passed to the destructor so removing SLAB_CTOR_ATOMIC also establishes a certain symmetry. Signed-off-by:
-
Christoph Lameter authored
I have never seen a use of SLAB_DEBUG_INITIAL. It is only supported by SLAB. I think its purpose was to have a callback after an object has been freed to verify that the state is the constructor state again? The callback is performed before each freeing of an object. I would think that it is much easier to check the object state manually before the free. That also places the check near the code object manipulation of the object. Also the SLAB_DEBUG_INITIAL callback is only performed if the kernel was compiled with SLAB debugging on. If there would be code in a constructor handling SLAB_DEBUG_INITIAL then it would have to be conditional on SLAB_DEBUG otherwise it would just be dead code. But there is no such code in the kernel. I think SLUB_DEBUG_INITIAL is too problematic to make real use of, difficult to understand and there are easier ways to accomplish the same effect (i.e. add debug code before kfree). There is a related flag SLAB_CTOR_VERIFY that is frequently checked to be clear in fs inode caches. Remove the pointless checks (they would even be pointless without removeal of SLAB_DEBUG_INITIAL) from the fs constructors. This is the last slab flag that SLUB did not support. Remove the check for unimplemented flags from SLUB. Signed-off-by:
-
Benjamin Herrenschmidt authored
Remove the hugetlbfs specific hacks in toplevel get_unmapped_area() now that all archs and hugetlbfs itself do the right thing for both cases. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by:
William Irwin <bill.irwin@oracle.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: David Howells <dhowells@redhat.com> Cc: Andi Kleen <ak@suse.de> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Grant Grundler <grundler@parisc-linux.org> Cc: Matthew Wilcox <willy@debian.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Adam Litke <agl@us.ibm.com> Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
-
Benjamin Herrenschmidt authored
generic arch_get_unmapped_area() now handles MAP_FIXED. Now that all implementations have been fixed, change the toplevel get_unmapped_area() to call into arch or drivers for the MAP_FIXED case. Signed-off-by:
-
Benjamin Herrenschmidt authored
Generic hugetlb_get_unmapped_area() now handles MAP_FIXED by just calling prepare_hugepage_range() Signed-off-by:
-
Benjamin Herrenschmidt authored
Handle MAP_FIXED in x86_64 arch_get_unmapped_area(), simple case, just return the address as passed in Signed-off-by:
-
Benjamin Herrenschmidt authored
Handle MAP_FIXED in hugetlb_get_unmapped_area on sparc64 by just using prepare_hugepage_range() Signed-off-by:
-
Benjamin Herrenschmidt authored
Handle MAP_FIXED in parisc arch_get_unmapped_area(), just return the address. We might want to also check for possible cache aliasing issues now that we get called in that case (like ARM or MIPS), leave a comment for the maintainers to pick up. Signed-off-by:
-
Benjamin Herrenschmidt authored
Handle MAP_FIXED in ia64 arch_get_unmapped_area and hugetlb_get_unmapped_area(), just call prepare_hugepage_range in the later and is_hugepage_only_range() in the former. Signed-off-by:
-
Benjamin Herrenschmidt authored
Handle MAP_FIXED in i386 hugetlb_get_unmapped_area(), just call prepare_hugepage_range. Signed-off-by:
-
Benjamin Herrenschmidt authored
Handle MAP_FIXED in arch_get_unmapped_area on frv. Trivial case, just return the address. Signed-off-by:
-
Benjamin Herrenschmidt authored
ARM already had a case for MAP_FIXED in arch_get_unmapped_area() though it was not called before. Fix the comment to reflect that it will now be called. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Benjamin Herrenschmidt authored
Handle MAP_FIXED in alpha's arch_get_unmapped_area(), simple case, just return the address as passed in Signed-off-by:
-
Benjamin Herrenschmidt authored
The current get_unmapped_area code calls the f_ops->get_unmapped_area or the arch one (via the mm) only when MAP_FIXED is not passed. That makes it impossible for archs to impose proper constraints on regions of the virtual address space. To work around that, get_unmapped_area() then calls some hugetlbfs specific hacks. This cause several problems, among others: - It makes it impossible for a driver or filesystem to do the same thing that hugetlbfs does (for example, to allow a driver to use larger page sizes to map external hardware) if that requires applying a constraint on the addresses (constraining that mapping in certain regions and other mappings out of those regions). - Some archs like arm, mips, sparc, sparc64, sh and sh64 already want MAP_FIXED to be passed down in order to deal with aliasing issues. The code is there to handle it... but is never called. This series of patches moves the logic to handle MAP_FIXED down to the various arch/driver get_unmapped_area() implementations, and then changes the generic code to always call them. The hugetlbfs hacks then disappear from the generic code. Since I need to do some special 64K pages mappings for SPEs on cell, I need to work around the first problem at least. I have further patches thus implementing a "slices" layer that handles multiple page sizes through slices of the address space for use by hugetlbfs, the SPE code, and possibly others, but it requires that serie of patches first/ There is still a potential (but not practical) issue due to the fact that filesystems/drivers implemeting g_u_a will effectively bypass all arch checks. This is not an issue in practice as the only filesystems/drivers using that hook are doing so for arch specific purposes in the first place. There is also a problem with mremap that will completely bypass all arch checks. I'll try to address that separately, I'm not 100% certain yet how, possibly by making it not work when the vma has a file whose f_ops has a get_unmapped_area callback, and by making it use is_hugepage_only_range() before expanding into a new area. Also, I want to turn is_hugepage_only_range() into a more generic is_normal_page_range() as that's really what it will end up meaning when used in stack grow, brk grow and mremap. None of the above "issues" however are introduced by this patch, they are already there, so I think the patch can go ini for 2.6.22. This patch: Handle MAP_FIXED in powerpc's arch_get_unmapped_area() in all 3 implementations of it. Signed-off-by:
-
David Rientjes authored
Fixes a deadlock in the OOM killer for allocations that are not __GFP_HARDWALL. Before the OOM killer checks for the allocation constraint, it takes callback_mutex. constrained_alloc() iterates through each zone in the allocation zonelist and calls cpuset_zone_allowed_softwall() to determine whether an allocation for gfp_mask is possible. If a zone's node is not in the OOM-triggering task's mems_allowed, it is not exiting, and we did not fail on a __GFP_HARDWALL allocation, cpuset_zone_allowed_softwall() attempts to take callback_mutex to check the nearest exclusive ancestor of current's cpuset. This results in deadlock. We now take callback_mutex after iterating through the zonelist since we don't need it yet. Cc: Andi Kleen <ak@suse.de> Cc: Nick Piggin <npiggin@suse.de> Cc: Christoph Lameter <clameter@engr.sgi.com> Cc: Martin J. Bligh <mbligh@mbligh.org> Signed-off-by:
David Rientjes <rientjes@google.com> Cc: <stable@kernel.org> Signed-off-by:
-
Yasunori Goto authored
The current panic_on_oom may not work if there is a process using cpusets/mempolicy, because other nodes' memory may remain. But some people want failover by panic ASAP even if they are used. This patch makes new setting for its request. This is tested on my ia64 box which has 3 nodes. Signed-off-by:
Yasunori Goto <y-goto@jp.fujitsu.com> Signed-off-by:
Benjamin LaHaise <bcrl@kvack.org> Cc: Christoph Lameter <clameter@sgi.com> Cc: Paul Jackson <pj@sgi.com> Cc: Ethan Solomita <solo@google.com> Cc: David Rientjes <rientjes@google.com> Signed-off-by:
-
Akinobu Mita authored
Currently failslab injects failures into ____cache_alloc(). But with enabling CONFIG_NUMA it's not enough to let actual slab allocator functions (kmalloc, kmem_cache_alloc, ...) return NULL. This patch moves fault injection hook inside of __cache_alloc() and __cache_alloc_node(). These are lower call path than ____cache_alloc() and enable to inject faulures to slab allocators with CONFIG_NUMA. Acked-by:
Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by:
-
Christoph Lameter authored
It is not necessary to tell the slab allocators to align to a cacheline if an explicit alignment was already specified. It is rather confusing to specify multiple alignments. Make sure that the call sites only use one form of alignment. Signed-off-by:
-
Christoph Lameter authored
This patch provides a new macro KMEM_CACHE(<struct>, <flags>) to simplify slab creation. KMEM_CACHE creates a slab with the name of the struct, with the size of the struct and with the alignment of the struct. Additional slab flags may be specified if necessary. Example struct test_slab { int a,b,c; struct list_head; } __cacheline_aligned_in_smp; test_slab_cache = KMEM_CACHE(test_slab, SLAB_PANIC) will create a new slab named "test_slab" of the size sizeof(struct test_slab) and aligned to the alignment of test slab. If it fails then we panic. Signed-off-by: -
Christoph Lameter authored
This patch was recently posted to lkml and acked by Pekka. The flag SLAB_MUST_HWCACHE_ALIGN is 1. Never checked by SLAB at all. 2. A duplicate of SLAB_HWCACHE_ALIGN for SLUB 3. Fulfills the role of SLAB_HWCACHE_ALIGN for SLOB. The only remaining use is in sparc64 and ppc64 and their use there reflects some earlier role that the slab flag once may have had. If its specified then SLAB_HWCACHE_ALIGN is also specified. The flag is confusing, inconsistent and has no purpose. Remove it. Acked-by:
-
Peter Zijlstra authored
invalidate_bdev() is superfluous when truncate_inode_pages() is also called. do call invalidate_bh_lrus() though, to avoid stale pointers. Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
