1. 06 2月, 2008 2 次提交
    • F
      iommu sg merging: IA64: make sba_iommu respect the segment size limits · a031bbcb
      FUJITA Tomonori 提交于
      This patch makes sba iommu respect segment size limits when merging sg
      lists.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Acked-by: NJens Axboe <jens.axboe@oracle.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a031bbcb
    • D
      timerfd: new timerfd API · 4d672e7a
      Davide Libenzi 提交于
      This is the new timerfd API as it is implemented by the following patch:
      
      int timerfd_create(int clockid, int flags);
      int timerfd_settime(int ufd, int flags,
      		    const struct itimerspec *utmr,
      		    struct itimerspec *otmr);
      int timerfd_gettime(int ufd, struct itimerspec *otmr);
      
      The timerfd_create() API creates an un-programmed timerfd fd.  The "clockid"
      parameter can be either CLOCK_MONOTONIC or CLOCK_REALTIME.
      
      The timerfd_settime() API give new settings by the timerfd fd, by optionally
      retrieving the previous expiration time (in case the "otmr" parameter is not
      NULL).
      
      The time value specified in "utmr" is absolute, if the TFD_TIMER_ABSTIME bit
      is set in the "flags" parameter.  Otherwise it's a relative time.
      
      The timerfd_gettime() API returns the next expiration time of the timer, or
      {0, 0} if the timerfd has not been set yet.
      
      Like the previous timerfd API implementation, read(2) and poll(2) are
      supported (with the same interface).  Here's a simple test program I used to
      exercise the new timerfd APIs:
      
      http://www.xmailserver.org/timerfd-test2.c
      
      [akpm@linux-foundation.org: coding-style cleanups]
      [akpm@linux-foundation.org: fix ia64 build]
      [akpm@linux-foundation.org: fix m68k build]
      [akpm@linux-foundation.org: fix mips build]
      [akpm@linux-foundation.org: fix alpha, arm, blackfin, cris, m68k, s390, sparc and sparc64 builds]
      [heiko.carstens@de.ibm.com: fix s390]
      [akpm@linux-foundation.org: fix powerpc build]
      [akpm@linux-foundation.org: fix sparc64 more]
      Signed-off-by: NDavide Libenzi <davidel@xmailserver.org>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4d672e7a
  2. 03 2月, 2008 4 次提交
    • A
      remove Documentation/smp.txt · 03502faa
      Adrian Bunk 提交于
      After seeing the filename I'd have expected something about the
      implementation of SMP in the Linux kernel - not some notes on kernel
      configuration and building trivialities noone would search at this
      place.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Acked-by: NAlan Cox <alan@redhat.com>
      03502faa
    • M
      Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig · 125e5645
      Mathieu Desnoyers 提交于
      Move the instrumentation Kconfig to
      
      arch/Kconfig for architecture dependent options
        - oprofile
        - kprobes
      
      and
      
      init/Kconfig for architecture independent options
        - profiling
        - markers
      
      Remove the "Instrumentation Support" menu. Everything moves to "General setup".
      Delete the kernel/Kconfig.instrumentation file.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      125e5645
    • M
      Add HAVE_KPROBES · 3f550096
      Mathieu Desnoyers 提交于
      Linus:
      
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config KPROBES_SUPPORT
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      - Use HAVE_KPROBES
      - Use a select
      
      - Yet another update :
      Moving to HAVE_* now.
      
      - Update ARM for kprobes support.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      3f550096
    • M
      Add HAVE_OPROFILE · 42d4b839
      Mathieu Desnoyers 提交于
      Linus:
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config ARCH_SUPPORTS_KPROBES
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      Changelog :
      
      - Moving to HAVE_*.
      - Add AVR32 oprofile.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      42d4b839
  3. 31 1月, 2008 3 次提交
  4. 30 1月, 2008 5 次提交
    • T
      percpu: make the asm-generic/percpu.h more "generic" · acdac872
      travis@sgi.com 提交于
      - add support for PER_CPU_ATTRIBUTES
      
      - fix generic smp percpu_modcopy to use per_cpu_offset() macro.
      
      Add the ability to use generic/percpu even if the arch needs to override
      several aspects of its operations. This will enable the use of generic
      percpu.h for all arches.
      
      An arch may define:
      
      __per_cpu_offset	Do not use the generic pointer array. Arch must
      			define per_cpu_offset(cpu) (used by x86_64, s390).
      
      __my_cpu_offset		Can be defined to provide an optimized way to determine
      			the offset for variables of the currently executing
      			processor. Used by ia64, x86_64, x86_32, sparc64, s/390.
      
      SHIFT_PTR(ptr, offset)	If an arch defines it then special handling
      			of pointer arithmentic may be implemented. Used
      			by s/390.
      
      (Some of these special percpu arch implementations may be later consolidated
      so that there are less cases to deal with.)
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      acdac872
    • T
      percpu: use a kconfig variable to signal arch specific percpu setup · b32ef636
      travis@sgi.com 提交于
      The use of the __GENERIC_PERCPU is a bit problematic since arches
      may want to run their own percpu setup while using the generic
      percpu definitions. Replace it through a kconfig variable.
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b32ef636
    • N
      spinlock: lockbreak cleanup · 95c354fe
      Nick Piggin 提交于
      The break_lock data structure and code for spinlocks is quite nasty.
      Not only does it double the size of a spinlock but it changes locking to
      a potentially less optimal trylock.
      
      Put all of that under CONFIG_GENERIC_LOCKBREAK, and introduce a
      __raw_spin_is_contended that uses the lock data itself to determine whether
      there are waiters on the lock, to be used if CONFIG_GENERIC_LOCKBREAK is
      not set.
      
      Rename need_lockbreak to spin_needbreak, make it use spin_is_contended to
      decouple it from the spinlock implementation, and make it typesafe (rwlocks
      do not have any need_lockbreak sites -- why do they even get bloated up
      with that break_lock then?).
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      95c354fe
    • A
      x86: PIE executable randomization, checkpatch fixes · bb1ad820
      Andrew Morton 提交于
      #39: FILE: arch/ia64/ia32/binfmt_elf32.c:229:
      +elf32_map (struct file *filep, unsigned long addr, struct elf_phdr *eppnt, int prot, int type, unsigned long unused)
      
      WARNING: no space between function name and open parenthesis '('
      #39: FILE: arch/ia64/ia32/binfmt_elf32.c:229:
      +elf32_map (struct file *filep, unsigned long addr, struct elf_phdr *eppnt, int prot, int type, unsigned long unused)
      
      WARNING: line over 80 characters
      #67: FILE: arch/x86/kernel/sys_x86_64.c:80:
      +			new_begin = randomize_range(*begin, *begin + 0x02000000, 0);
      
      ERROR: use tabs not spaces
      #110: FILE: arch/x86/kernel/sys_x86_64.c:185:
      + ^I        mm->cached_hole_size = 0;$
      
      ERROR: use tabs not spaces
      #111: FILE: arch/x86/kernel/sys_x86_64.c:186:
      + ^I^Imm->free_area_cache = mm->mmap_base;$
      
      ERROR: use tabs not spaces
      #112: FILE: arch/x86/kernel/sys_x86_64.c:187:
      + ^I}$
      
      ERROR: use tabs not spaces
      #141: FILE: arch/x86/kernel/sys_x86_64.c:216:
      + ^I^I/* remember the largest hole we saw so far */$
      
      ERROR: use tabs not spaces
      #142: FILE: arch/x86/kernel/sys_x86_64.c:217:
      + ^I^Iif (addr + mm->cached_hole_size < vma->vm_start)$
      
      ERROR: use tabs not spaces
      #143: FILE: arch/x86/kernel/sys_x86_64.c:218:
      + ^I^I        mm->cached_hole_size = vma->vm_start - addr;$
      
      ERROR: use tabs not spaces
      #157: FILE: arch/x86/kernel/sys_x86_64.c:232:
      +  ^Imm->free_area_cache = TASK_UNMAPPED_BASE;$
      
      ERROR: need a space before the open parenthesis '('
      #291: FILE: arch/x86/mm/mmap_64.c:101:
      +	} else if(mmap_is_legacy()) {
      
      WARNING: braces {} are not necessary for single statement blocks
      #302: FILE: arch/x86/mm/mmap_64.c:112:
      +	if (current->flags & PF_RANDOMIZE) {
      +		mm->mmap_base += ((long)rnd) << PAGE_SHIFT;
      +	}
      
      WARNING: line over 80 characters
      #314: FILE: fs/binfmt_elf.c:48:
      +static unsigned long elf_map (struct file *, unsigned long, struct elf_phdr *, int, int, unsigned long);
      
      WARNING: no space between function name and open parenthesis '('
      #314: FILE: fs/binfmt_elf.c:48:
      +static unsigned long elf_map (struct file *, unsigned long, struct elf_phdr *, int, int, unsigned long);
      
      WARNING: line over 80 characters
      #429: FILE: fs/binfmt_elf.c:438:
      +					   eppnt, elf_prot, elf_type, total_size);
      
      ERROR: need space after that ',' (ctx:VxV)
      #480: FILE: fs/binfmt_elf.c:939:
      +				elf_prot, elf_flags,0);
       				                   ^
      
      total: 9 errors, 7 warnings, 461 lines checked
      Your patch has style problems, please review.  If any of these errors
      are false positives report them to the maintainer, see
      CHECKPATCH in MAINTAINERS.
      
      Please run checkpatch prior to sending patches
      
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      bb1ad820
    • J
      x86: PIE executable randomization · cc503c1b
      Jiri Kosina 提交于
      main executable of (specially compiled/linked -pie/-fpie) ET_DYN binaries
      onto a random address (in cases in which mmap() is allowed to perform a
      randomization).
      
      The code has been extraced from Ingo's exec-shield patch
      http://people.redhat.com/mingo/exec-shield/
      
      [akpm@linux-foundation.org: fix used-uninitialsied warning]
      [kamezawa.hiroyu@jp.fujitsu.com: fixed ia32 ELF on x86_64 handling]
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      cc503c1b
  5. 29 1月, 2008 2 次提交
  6. 26 1月, 2008 2 次提交
  7. 25 1月, 2008 2 次提交
  8. 16 1月, 2008 1 次提交
    • L
      [IA64] Fix unaligned handler for floating point instructions with base update · 1a499150
      Luck, Tony 提交于
      The compiler team did the hard work for this distilling a problem in
      large fortran application which showed up when applied to a 290MB input
      data set down to this instruction:
      
      	ldfd f34=[r17],-8
      
      Which they noticed incremented r17 by 0x10 rather than decrementing it
      by 8 when the value in r17 caused an unaligned data fault.  I tracked
      it down to some bad instruction decoding in unaligned.c. The code
      assumes that the 'x' bit can determine whether the instruction is
      an "ldf" or "ldfp" ... which it is for opcode=6 (see table 4-29 on
      page 3:302 of the SDM).  But for opcode=7 the 'x' bit is irrelevent,
      all variants are "ldf" instructions (see table 4-36 on page 3:306).
      
      Note also that interpreting the instruction as "ldfp" means that the
      "paired" floating point register (f35 in the example here) will also
      be corrupted.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      1a499150
  9. 04 1月, 2008 1 次提交
  10. 20 12月, 2007 7 次提交
  11. 19 12月, 2007 5 次提交
  12. 08 12月, 2007 6 次提交