1. 28 Mar, 2008 12 commits
  2. 27 Mar, 2008 19 commits
  3. 26 Mar, 2008 9 commits
    • Herbert Xu's avatar
      [IPSEC]: Fix BEET output · 732c8bd5
      Herbert Xu authored
      The IPv6 BEET output function is incorrectly including the inner
      header in the payload to be protected.  This causes a crash as
      the packet doesn't actually have that many bytes for a second
      header.
      
      The IPv4 BEET output on the other hand is broken when it comes
      to handling an inner IPv6 header since it always assumes an
      inner IPv4 header.
      
      This patch fixes both by making sure that neither BEET output
      function touches the inner header at all.  All access is now
      done through the protocol-independent cb structure.  Two new
      attributes are added to make this work, the IP header length
      and the IPv4 option length.  They're filled in by the inner
      mode's output function.
      
      Thanks to Joakim Koskela for finding this problem.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      732c8bd5
    • David S. Miller's avatar
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86 · 08dcf29e
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86:
        x86: fix performance drop for glx
        x86: fix trim mtrr not to setup_memory two times
        x86: GEODE: add missing module.h include
        x86, cpufreq: fix Speedfreq-SMI call that clobbers ECX
        x86: fix memoryless node oops during boot
        x86: add dmi quirk for io_delay
        x86: convert mtrr/generic.c to kernel-doc
        x86: Documentation/i386/IO-APIC.txt: fix description
      08dcf29e
    • Nishanth Aravamudan's avatar
      hugetlb: fix potential livelock in return_unused_surplus_hugepages() · 11320d17
      Nishanth Aravamudan authored
      Running the counters testcase from libhugetlbfs results in on 2.6.25-rc5
      and 2.6.25-rc5-mm1:
      
          BUG: soft lockup - CPU#3 stuck for 61s! [counters:10531]
          NIP: c0000000000d1f3c LR: c0000000000d1f2c CTR: c0000000001b5088
          REGS: c000005db12cb360 TRAP: 0901   Not tainted  (2.6.25-rc5-autokern1)
          MSR: 8000000000009032 <EE,ME,IR,DR>  CR: 48008448  XER: 20000000
          TASK = c000005dbf3d6000[10531] 'counters' THREAD: c000005db12c8000 CPU: 3
          GPR00: 0000000000000004 c000005db12cb5e0 c000000000879228 0000000000000004
          GPR04: 0000000000000010 0000000000000000 0000000000200200 0000000000100100
          GPR08: c0000000008aba10 000000000000ffff 0000000000000004 0000000000000000
          GPR12: 0000000028000442 c000000000770080
          NIP [c0000000000d1f3c] .return_unused_surplus_pages+0x84/0x18c
          LR [c0000000000d1f2c] .return_unused_surplus_pages+0x74/0x18c
          Call Trace:
          [c000005db12cb5e0] [c000005db12cb670] 0xc000005db12cb670 (unreliable)
          [c000005db12cb670] [c0000000000d24c4] .hugetlb_acct_memory+0x2e0/0x354
          [c000005db12cb740] [c0000000001b5048] .truncate_hugepages+0x1d4/0x214
          [c000005db12cb890] [c0000000001b50a4] .hugetlbfs_delete_inode+0x1c/0x3c
          [c000005db12cb920] [c000000000103fd8] .generic_delete_inode+0xf8/0x1c0
          [c000005db12cb9b0] [c0000000001b5100] .hugetlbfs_drop_inode+0x3c/0x24c
          [c000005db12cba50] [c00000000010287c] .iput+0xdc/0xf8
          [c000005db12cbad0] [c0000000000fee54] .dentry_iput+0x12c/0x194
          [c000005db12cbb60] [c0000000000ff050] .d_kill+0x6c/0xa4
          [c000005db12cbbf0] [c0000000000ffb74] .dput+0x18c/0x1b0
          [c000005db12cbc70] [c0000000000e9e98] .__fput+0x1a4/0x1e8
          [c000005db12cbd10] [c0000000000e61ec] .filp_close+0xb8/0xe0
          [c000005db12cbda0] [c0000000000e62d0] .sys_close+0xbc/0x134
          [c000005db12cbe30] [c00000000000872c] syscall_exit+0x0/0x40
          Instruction dump:
          ebbe8038 38800010 e8bf0002 3bbd0008 7fa3eb78 38a50001 7ca507b4 4818df25
          60000000 38800010 38a00000 7c601b78 <7fa3eb78> 2f800010 409d0008 38000010
      
      This was tracked down to a potential livelock in
      return_unused_surplus_hugepages().  In the case where we have surplus
      pages on some node, but no free pages on the same node, we may never
      break out of the loop. To avoid this livelock, terminate the search if
      we iterate a number of times equal to the number of online nodes without
      freeing a page.
      
      Thanks to Andy Whitcroft and Adam Litke for helping with debugging and
      the patch.
      Signed-off-by: default avatarNishanth Aravamudan <nacc@us.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      11320d17
    • Nishanth Aravamudan's avatar
      hugetlb: indicate surplus huge page counts in per-node meminfo · a1de0919
      Nishanth Aravamudan authored
      Currently we show the surplus hugetlb pool state in /proc/meminfo, but
      not in the per-node meminfo files, even though we track the information
      on a per-node basis. Printing it there can help track down dynamic pool
      bugs including the one in the follow-on patch.
      Signed-off-by: default avatarNishanth Aravamudan <nacc@us.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a1de0919
    • Suresh Siddha's avatar
      x86: fix performance drop for glx · d546b67a
      Suresh Siddha authored
      fix the 3D performance drop reported at:
      
         http://bugzilla.kernel.org/show_bug.cgi?id=10328
      
      fb drivers are using ioremap()/ioremap_nocache(), followed by mtrr_add with
      WC attribute. Recent changes in page attribute code made both
      ioremap()/ioremap_nocache() mappings as UC (instead of previous UC-). This
      breaks the graphics performance, as the effective memory type is UC instead
      of expected WC.
      
      The correct way to fix this is to add ioremap_wc() (which uses UC- in the
      absence of PAT kernel support and WC with PAT) and change all the
      fb drivers to use this new ioremap_wc() API.
      
      We can take this correct and longer route for post 2.6.25. For now,
      revert back to the UC- behavior for ioremap/ioremap_nocache.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d546b67a
    • Yinghai Lu's avatar
      x86: fix trim mtrr not to setup_memory two times · 76c32418
      Yinghai Lu authored
      we could call find_max_pfn() directly instead of setup_memory() to get
      max_pfn needed for mtrr trimming.
      
      otherwise setup_memory() is called two times... that is duplicated...
      
      [ mingo@elte.hu: both Thomas and me simulated a double call to
        setup_bootmem_allocator() and can confirm that it is a real bug
        which can hang in certain configs. It's not been reported yet but
        that is probably due to the relatively scarce nature of
        MTRR-trimming systems. ]
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      76c32418
    • Andres Salomon's avatar
      x86: GEODE: add missing module.h include · 923a0cf8
      Andres Salomon authored
      On Wed, 26 Mar 2008 11:56:22 -0600
      Jordan Crouse <jordan.crouse@amd.com> wrote:
      
      > On 26/03/08 14:31 +0100, Stefan Pfetzing wrote:
      > > Hello Jordan,
      > >
      > > I just tried to build your geodwdt driver for the geode watchdog. Therefore
      > > I pulled your repository from http://git.infradead.org/geode.git (or more,
      > > the git url).
      > >
      > > I tried to build the geodewdt driver as a module - which didn't work, and
      > > it failed with the same problem as earlier mentioned on lkmk [1]. I also
      > > checked the fix [2], but that seems to be already in your (or linus) tree -
      > > and so I'm unsure what the problem is.
      > >
      > > [1] http://kerneltrap.org/mailarchive/linux-kernel/2008/2/17/884074
      > > [2] http://kerneltrap.org/mailarchive/linux-kernel/2008/2/17/884174
      > >
      > > Building directly into the kernel seems to work.
      > >
      > > Maybe you have some idea?
      >
      > Hmm - that is strange.  Exporting the symbols should work.  I recommend
      > starting over with a clean tree.
      >
      > CCing Andres - any thoughts?
      >
      > Jordan
      >
      
      Er, yeah.  The patch below should fix it.  This should probably go into
      2.6.25.
      
      Oops, EXPORT_SYMBOL_GPL wasn't being declared due to this header
      being missing.
      Signed-off-by: default avatarAndres Salomon <dilinger@debian.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      923a0cf8
    • Stephan Diestelhorst's avatar
      x86, cpufreq: fix Speedfreq-SMI call that clobbers ECX · c6e8256a
      Stephan Diestelhorst authored
      I have found that using SMI to change the cpu's frequency on my DELL
      Latitude L400 clobbers the ECX register in speedstep_set_state, causing
      unneccessary retries because the "state" variable has changed silently (GCC
      assumes it is still present in ECX).
      
      play safe and avoid gcc caching any register across IO port accesses
      that trigger SMIs.
      
      Signed-off by: <Stephan.Diestelhorst@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      c6e8256a