1. 30 11月, 2006 7 次提交
  2. 29 11月, 2006 3 次提交
  3. 28 11月, 2006 1 次提交
  4. 27 11月, 2006 3 次提交
    • L
      Fix 'ALIGN()' macro, take 2 · 2ea58144
      Linus Torvalds 提交于
      You wouldn't think that doing an ALIGN() macro that aligns something up
      to a power-of-two boundary would be likely to have bugs, would you?
      
      But hey, in the wonderful world of mixing integer types, you have to be
      careful.  This just makes sure that the alignment is interpreted in the
      same type as the thing to be aligned.
      
      Thanks to Roland Dreier, who noticed that the amso1100 driver got broken
      by the previous fix (that just extended the mask to "unsigned long", but
      was still broken in "unsigned long long" - it just happened to be the
      same on 64-bit architectures).
      
      See commit 4c8bd7ee for the history of
      bugs here...
      Acked-by: NRoland Dreier <rdreier@cisco.com>
      Cc: Andrew Morton <akpm@osdl.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2ea58144
    • K
      [PATCH] Fix incorrent type of flags in <asm/semaphore.h> · c9c3b86f
      Kyle McMartin 提交于
      I still think using BUILD_BUG_ON() is unacceptable, especially given how
      vague the error message was.
      Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
      [ And I already removed gthe BUILD_BUG_ON() in the previous commit ]
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c9c3b86f
    • L
      Revert "[PATCH] Enforce "unsigned long flags;" when spinlocking" · b8e6ec86
      Linus Torvalds 提交于
      This reverts commit ee3ce191, since it
      broke on at least ARM, MIPS and PA-RISC due to complicated header file
      dependencies.
      
      Conflicts in include/linux/spinlock.h (due to the "nested" variety
      fixes) fixed up by hand.
      
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Kyle McMartin <kyle@parisc-linux.org>
      Cc: Russell King <rmk+lkml@arm.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b8e6ec86
  5. 26 11月, 2006 4 次提交
    • P
      [NET]: Re-fix of doc-comment in sock.h · dc9b3346
      Paul Bonser 提交于
      Restoring old, correct comment for sk_filter_release, moving it to
      where it should actually be, and changing new comment into proper
      comment for sk_filter_rcu_free, where it actually makes sense.
      
      The original fix submitted for this on Oct 23 mistakenly documented
      the wrong function.
      Signed-off-by: NPaul Bonser <misterpib@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dc9b3346
    • A
      [PATCH] lockdep: spin_lock_irqsave_nested() · cfd3ef23
      Arjan van de Ven 提交于
      Introduce spin_lock_irqsave_nested(); implementation from:
       http://lkml.org/lkml/2006/6/1/122
      Patch from:
       http://lkml.org/lkml/2006/9/13/258
      
      [akpm@osdl.org: two compile fixes]
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NJiri Kosina <jikos@jikos.cz>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cfd3ef23
    • A
      [PATCH] Enforce "unsigned long flags;" when spinlocking · ee3ce191
      Alexey Dobriyan 提交于
      Make it break or warn if you pass to spin_lock_irqsave() and friends
      something different from "unsigned long flags;".  Suprisingly large amount
      of these was caught by recent commit
      c53421b1 and others.
      
      Idea is largely from FRV typechecking. Suggestions from Andrew Morton.
      All stupid typos in first version fixed.
      
      Passes allmodconfig on i386, x86_64, alpha, arm as well as my usual config.
      
      Note #1: checking with sparse is still needed, because a driver can save
      	 and pass around flags or something. So far patch is very intrusive.
      Note #2: techically, we should break only if
      		sizeof(flags) < sizeof(unsigned long),
      	 however, the more pain for getting suspicious code into kernel,
      	 the better.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ee3ce191
    • V
      [PATCH] mounstats NULL pointer dereference · 701e054e
      Vasily Tarasov 提交于
      OpenVZ developers team has encountered the following problem in 2.6.19-rc6
      kernel. After some seconds of running script
      
      while [[ 1 ]]
      do
      	find  /proc -name mountstats | xargs cat
      done
      
      this Oops appears:
      
      BUG: unable to handle kernel NULL pointer dereference at virtual address
      00000010
       printing eip:
      c01a6b70
      *pde = 00000000
      Oops: 0000 [#1]
      SMP
      Modules linked in: xt_length ipt_ttl xt_tcpmss ipt_TCPMSS iptable_mangle
      iptable_filter xt_multiport xt_limit ipt_tos ipt_REJECT ip_tables x_tables
      parport_pc lp parport sunrpc af_packet thermal processor fan button battery
      asus_acpi ac ohci_hcd ehci_hcd usbcore i2c_nforce2 i2c_core tg3 floppy
      pata_amd
      ide_cd cdrom sata_nv libata
      CPU:    1
      EIP:    0060:[<c01a6b70>]    Not tainted VLI
      EFLAGS: 00010246   (2.6.19-rc6 #2)
      EIP is at mountstats_open+0x70/0xf0
      eax: 00000000   ebx: e6247030   ecx: e62470f8   edx: 00000000
      esi: 00000000   edi: c01a6b00   ebp: c33b83c0   esp: f4105eb4
      ds: 007b   es: 007b   ss: 0068
      Process cat (pid: 6044, ti=f4105000 task=f4104a70 task.ti=f4105000)
      Stack: c33b83c0 c04ee940 f46a4a80 c33b83c0 e4df31b4 c01a6b00 f4105000 c0169231
             e4df31b4 c33b83c0 c33b83c0 f4105f20 00000003 f4105000 c0169445 f2503cf0
             f7f8c4c0 00008000 c33b83c0 00000000 00008000 c0169350 f4105f20 00008000
      Call Trace:
       [<c01a6b00>] mountstats_open+0x0/0xf0
       [<c0169231>] __dentry_open+0x181/0x250
       [<c0169445>] nameidata_to_filp+0x35/0x50
       [<c0169350>] do_filp_open+0x50/0x60
       [<c01873d6>] seq_read+0xc6/0x300
       [<c0169511>] get_unused_fd+0x31/0xc0
       [<c01696d3>] do_sys_open+0x63/0x110
       [<c01697a7>] sys_open+0x27/0x30
       [<c01030bd>] sysenter_past_esp+0x56/0x79
       =======================
      Code: 45 74 8b 54 24 20 89 44 24 08 8b 42 f0 31 d2 e8 47 cb f8 ff 85 c0 89 c3
      74 51 8d 80 a0 04 00 00 e8 46 06 2c 00 8b 83 48 04 00 00 <8b> 78 10 85 ff 74
      03
      f0 ff 07 b0 01 86 83 a0 04 00 00 f0 ff 4b
      EIP: [<c01a6b70>] mountstats_open+0x70/0xf0 SS:ESP 0068:f4105eb4
      
      The problem is that task->nsproxy can be equal NULL for some time during
      task exit. This patch fixes the BUG.
      Signed-off-by: NVasily Tarasov <vtaras@openvz.org>
      Cc: Herbert Poetzl <herbert@13thfloor.at>
      Cc: "Serge E. Hallyn" <serue@us.ibm.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      701e054e
  6. 23 11月, 2006 2 次提交
  7. 22 11月, 2006 2 次提交
  8. 21 11月, 2006 2 次提交
    • L
      Add "pure_initcall" for static variable initialization · b3438f82
      Linus Torvalds 提交于
      This is a quick hack to overcome the fact that SRCU currently does not
      allow static initializers, and we need to sometimes initialize those
      things before any other initializers (even "core" ones) can do so.
      
      Currently we don't allow this at all for modules, and the only user that
      needs is right now is cpufreq. As reported by Thomas Gleixner:
      
         "Commit b4dfdbb3 ("[PATCH] cpufreq:
          make the transition_notifier chain use SRCU breaks cpu frequency
          notification users, which register the callback > on core_init
          level."
      
      Cc: Thomas Gleixner <tglx@timesys.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Andrew Morton <akpm@osdl.org>,
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b3438f82
    • G
      [PATCH] m68knommu: fix up for the irq_handler_t changes · ace5f1d4
      Greg Ungerer 提交于
      Switch to using irq_handler_t for interrupt function handler pointers.
      
      Change name of m68knommu's irq_hanlder_t data structure so it doesn't
      clash with the common type (include/linux/interrupt.h).
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ace5f1d4
  9. 20 11月, 2006 2 次提交
  10. 17 11月, 2006 1 次提交
  11. 16 11月, 2006 4 次提交
  12. 15 11月, 2006 1 次提交
    • H
      [PATCH] hugetlb: prepare_hugepage_range check offset too · 68589bc3
      Hugh Dickins 提交于
      (David:)
      
      If hugetlbfs_file_mmap() returns a failure to do_mmap_pgoff() - for example,
      because the given file offset is not hugepage aligned - then do_mmap_pgoff
      will go to the unmap_and_free_vma backout path.
      
      But at this stage the vma hasn't been marked as hugepage, and the backout path
      will call unmap_region() on it.  That will eventually call down to the
      non-hugepage version of unmap_page_range().  On ppc64, at least, that will
      cause serious problems if there are any existing hugepage pagetable entries in
      the vicinity - for example if there are any other hugepage mappings under the
      same PUD.  unmap_page_range() will trigger a bad_pud() on the hugepage pud
      entries.  I suspect this will also cause bad problems on ia64, though I don't
      have a machine to test it on.
      
      (Hugh:)
      
      prepare_hugepage_range() should check file offset alignment when it checks
      virtual address and length, to stop MAP_FIXED with a bad huge offset from
      unmapping before it fails further down.  PowerPC should apply the same
      prepare_hugepage_range alignment checks as ia64 and all the others do.
      
      Then none of the alignment checks in hugetlbfs_file_mmap are required (nor
      is the check for too small a mapping); but even so, move up setting of
      VM_HUGETLB and add a comment to warn of what David Gibson discovered - if
      hugetlbfs_file_mmap fails before setting it, do_mmap_pgoff's unmap_region
      when unwinding from error will go the non-huge way, which may cause bad
      behaviour on architectures (powerpc and ia64) which segregate their huge
      mappings into a separate region of the address space.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Acked-by: NAdam Litke <agl@us.ibm.com>
      Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      68589bc3
  13. 14 11月, 2006 3 次提交
    • A
      [PATCH] x86-64: Fix race in exit_idle · 9446868b
      Andi Kleen 提交于
      When another interrupt happens in exit_idle the exit idle notifier
      could be called an incorrect number of times.
      
      Add a test_and_clear_bit_pda and use it handle the bit
      atomically against interrupts to avoid this.
      
      Pointed out by Stephane Eranian
      Signed-off-by: NAndi Kleen <ak@suse.de>
      9446868b
    • A
      [PATCH] x86-64: Fix vgetcpu when CONFIG_HOTPLUG_CPU is disabled · 8c131af1
      Andi Kleen 提交于
      The vgetcpu per CPU initialization previously relied on CPU hotplug
      events for all CPUs to initialize the per CPU state. That only
      worked only on kernels with CONFIG_HOTPLUG_CPU enabled.  On the
      others some CPUs didn't get their state initialized properly
      and vgetcpu wouldn't work.
      
      Change the initialization sequence to instead run in a normal
      initcall (which runs after the normal CPU bootup) and initialize
      all running CPUs there. Later hotplug CPUs are still handled
      with an hotplug notifier.
      
      This actually simplifies the code somewhat.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      8c131af1
    • A
      [PATCH] x86: Add acpi_user_timer_override option for Asus boards · fa18f477
      Andi Kleen 提交于
      Timer overrides are normally disabled on Nvidia board because
      they are commonly wrong, except on new ones with HPET support.
      Unfortunately there are quite some Asus boards around that
      don't have HPET, but need a timer override.
      
      We don't know yet how to handle this transparently,
      but at least add a command line option to force the timer override
      and let them boot.
      
      Cc: len.brown@intel.com
      Signed-off-by: NAndi Kleen <ak@suse.de>
      fa18f477
  14. 13 11月, 2006 3 次提交
  15. 10 11月, 2006 1 次提交
  16. 09 11月, 2006 1 次提交