1. 16 4月, 2008 3 次提交
  2. 15 4月, 2008 1 次提交
  3. 14 4月, 2008 1 次提交
  4. 13 4月, 2008 1 次提交
  5. 12 4月, 2008 1 次提交
  6. 11 4月, 2008 4 次提交
    • H
      Fix "$(AS) -traditional" compile breakage caused by asmlinkage_protect · b0fac023
      Heiko Carstens 提交于
      git commit 54a01510 ("asmlinkage_protect
      replaces prevent_tail_call") causes this build failure on s390:
      
          AS      arch/s390/kernel/entry64.o
        In file included from arch/s390/kernel/entry64.S:14:
        include/linux/linkage.h:34: error: syntax error in macro parameter list
        make[1]: *** [arch/s390/kernel/entry64.o] Error 1
        make: *** [arch/s390/kernel] Error 2
      
      and some other architectures.  The reason is that some architectures add
      the "-traditional" flag to the invocation of $(AS), which disables
      variadic macro argument support.
      
      So just surround the new define with an #ifndef __ASSEMBLY__ to prevent
      any side effects on asm code.
      
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b0fac023
    • B
      pnp: increase number of devices supported per protocol · 544451a1
      Bjorn Helgaas 提交于
      Increase the PNP "number of devices" limit.  We currently use an unsigned
      char, which limits us to 256 devices per protocol.  This patch changes that to
      an unsigned int.
      
      Not all backends can take advantage of this: we limit ISAPNP to 10 devices in
      isapnp_cfg_begin(), and PNPBIOS is limited to 256 devices because the BIOS
      interfaces use a one-byte device node number.
      
      But there is no limit on the number of PNPACPI devices we may have.  Large HP
      Integrity machines have more than 256, which causes the current "unsigned char
      number" to wrap around.  This causes errors like this:
      
          pnp: PnP ACPI init
          kobject_add failed for 00:00 with -EEXIST, don't try to register things with the same name in the same directory.
      
          Call Trace:
           [<a000000100010720>] show_stack+0x40/0xa0
           [<a0000001000107b0>] dump_stack+0x30/0x60
           [<a0000001001dbdf0>] kobject_add+0x290/0x2c0
           [<a0000001002bfd40>] device_add+0x160/0x860
           [<a0000001002c0470>] device_register+0x30/0x60
           [<a00000010026ba70>] __pnp_add_device+0x130/0x180
           [<a00000010026bb70>] pnp_add_device+0xb0/0xe0
           [<a0000001007f2730>] pnpacpi_add_device+0x510/0x5a0
           [<a0000001007f2810>] pnpacpi_add_device_handler+0x50/0x80
      
      This patch increases the limit to fix this PNPACPI problem.  It should not
      have any adverse effect on ISAPNP or PNPBIOS because their limits are still
      enforced in the backends.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      544451a1
    • L
      Add commentary about the new "asmlinkage_protect()" macro · d10d89ec
      Linus Torvalds 提交于
      It's really a pretty ugly thing to need, and some day it will hopefully
      be obviated by teaching gcc about the magic calling conventions for the
      low-level system call code, but in the meantime we can at least add big
      honking comments about why we need these insane and strange macros.
      
      I took my comments from my version of the macro, but I ended up deciding
      to just pick Roland's version of the actual code instead (with his
      prettier syntax that uses vararg macros).  Thus the previous two commits
      that actually implement it.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d10d89ec
    • R
      asmlinkage_protect replaces prevent_tail_call · 54a01510
      Roland McGrath 提交于
      The prevent_tail_call() macro works around the problem of the compiler
      clobbering argument words on the stack, which for asmlinkage functions
      is the caller's (user's) struct pt_regs.  The tail/sibling-call
      optimization is not the only way that the compiler can decide to use
      stack argument words as scratch space, which we have to prevent.
      Other optimizations can do it too.
      
      Until we have new compiler support to make "asmlinkage" binding on the
      compiler's own use of the stack argument frame, we have work around all
      the manifestations of this issue that crop up.
      
      More cases seem to be prevented by also keeping the incoming argument
      variables live at the end of the function.  This makes their original
      stack slots attractive places to leave those variables, so the compiler
      tends not clobber them for something else.  It's still no guarantee, but
      it handles some observed cases that prevent_tail_call() did not.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      54a01510
  7. 08 4月, 2008 1 次提交
    • R
      virtio: remove overzealous BUG_ON. · 2557a933
      Rusty Russell 提交于
      The 'disable_cb' callback is designed as an optimization to tell the host
      we don't need callbacks now.  As it is not reliable, the debug check is
      overzealous: it can happen on two CPUs at the same time.  Document this.
      
      Even if it were reliable, the virtio_net driver doesn't disable
      callbacks on transmit so the START_USE/END_USE debugging reentrance
      protection can be easily tripped even on UP.
      
      Thanks to Balaji Rao for the bug report and testing.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      CC: Balaji Rao <balajirrao@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2557a933
  8. 05 4月, 2008 2 次提交
    • P
      cgroups: add cgroup support for enabling controllers at boot time · 8bab8dde
      Paul Menage 提交于
      The effects of cgroup_disable=foo are:
      
      - foo isn't auto-mounted if you mount all cgroups in a single hierarchy
      - foo isn't visible as an individually mountable subsystem
      
      As a result there will only ever be one call to foo->create(), at init time;
      all processes will stay in this group, and the group will never be mounted on
      a visible hierarchy.  Any additional effects (e.g.  not allocating metadata)
      are up to the foo subsystem.
      
      This doesn't handle early_init subsystems (their "disabled" bit isn't set be,
      but it could easily be extended to do so if any of the early_init systems
      wanted it - I think it would just involve some nastier parameter processing
      since it would occur before the command-line argument parser had been run.
      
      Hugh said:
      
        Ballpark figures, I'm trying to get this question out rather than
        processing the exact numbers: CONFIG_CGROUP_MEM_RES_CTLR adds 15% overhead
        to the affected paths, booting with cgroup_disable=memory cuts that back to
        1% overhead (due to slightly bigger struct page).
      
        I'm no expert on distros, they may have no interest whatever in
        CONFIG_CGROUP_MEM_RES_CTLR=y; and the rest of us can easily build with or
        without it, or apply the cgroup_disable=memory patches.
      
      Unix bench's execl test result on x86_64 was
      
      == just after boot without mounting any cgroup fs.==
      mem_cgorup=off : Execl Throughput       43.0     3150.1      732.6
      mem_cgroup=on  : Execl Throughput       43.0     2932.6      682.0
      ==
      
      [lizf@cn.fujitsu.com: fix boot option parsing]
      Signed-off-by: NBalbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Paul Menage <menage@google.com>
      Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Pavel Emelyanov <xemul@openvz.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Sudhir Kumar <skumar@linux.vnet.ibm.com>
      Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8bab8dde
    • T
      x86: revert assign IRQs to hpet timer · 5761d64b
      Thomas Gleixner 提交于
      The commits:
      
      commit 37a47db8
      Author: Balaji Rao <balajirrao@gmail.com>
      Date:   Wed Jan 30 13:30:03 2008 +0100
      
          x86: assign IRQs to HPET timers, fix
      
      and
      
      commit e3f37a54
      Author: Balaji Rao <balajirrao@gmail.com>
      Date:   Wed Jan 30 13:30:03 2008 +0100
      
          x86: assign IRQs to HPET timers
      
      have been identified to cause a regression on some platforms due to
      the assignement of legacy IRQs which makes the legacy devices
      connected to those IRQs disfunctional.
      
      Revert them.
      
      This fixes http://bugzilla.kernel.org/show_bug.cgi?id=10382Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5761d64b
  9. 04 4月, 2008 2 次提交
  10. 03 4月, 2008 1 次提交
    • C
      kvm: provide kvm.h for all architecture: fixes headers_install · dd135ebb
      Christian Borntraeger 提交于
      Currently include/linux/kvm.h is not considered by make headers_install,
      because Kbuild cannot handle " unifdef-$(CONFIG_FOO) += foo.h.  This problem
      was introduced by
      
      commit fb56dbb3
      Author: Avi Kivity <avi@qumranet.com>
      Date:   Sun Dec 2 10:50:06 2007 +0200
      
          KVM: Export include/linux/kvm.h only if $ARCH actually supports KVM
      
          Currently, make headers_check barfs due to <asm/kvm.h>, which <linux/kvm.h>
          includes, not existing.  Rather than add a zillion <asm/kvm.h>s, export kvm.
          only if the arch actually supports it.
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      
      which makes this an 2.6.25 regression.
      
      One way of solving the issue is to enhance Kbuild, but Avi and David conviced
      me, that changing headers_install is not the way to go.  This patch changes
      the definition for linux/kvm.h to unifdef-y.
      
      If  unifdef-y is used for linux/kvm.h "make headers_check" will fail on all
      architectures without asm/kvm.h.  Therefore, this patch also provides
      asm/kvm.h on all architectures.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Acked-by: NAvi Kivity <avi@qumranet.com>
      Cc: Sam Ravnborg <sam@ravnborg.org
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dd135ebb
  11. 02 4月, 2008 1 次提交
  12. 01 4月, 2008 1 次提交
  13. 31 3月, 2008 2 次提交
  14. 30 3月, 2008 2 次提交
  15. 29 3月, 2008 4 次提交
  16. 28 3月, 2008 4 次提交
  17. 26 3月, 2008 2 次提交
  18. 25 3月, 2008 4 次提交
  19. 23 3月, 2008 1 次提交
  20. 21 3月, 2008 2 次提交