1. 13 Jun, 2008 31 commits
  2. 12 Jun, 2008 9 commits
    • David S. Miller's avatar
      tcp: Revert 'process defer accept as established' changes. · ec0a1966
      David S. Miller authored
      This reverts two changesets, ec3c0982
      ("[TCP]: TCP_DEFER_ACCEPT updates - process as established") and
      the follow-on bug fix 9ae27e0a
      ("tcp: Fix slab corruption with ipv6 and tcp6fuzz").
      
      This change causes several problems, first reported by Ingo Molnar
      as a distcc-over-loopback regression where connections were getting
      stuck.
      
      Ilpo Järvinen first spotted the locking problems.  The new function
      added by this code, tcp_defer_accept_check(), only has the
      child socket locked, yet it is modifying state of the parent
      listening socket.
      
      Fixing that is non-trivial at best, because we can't simply just grab
      the parent listening socket lock at this point, because it would
      create an ABBA deadlock.  The normal ordering is parent listening
      socket --> child socket, but this code path would require the
      reverse lock ordering.
      
      Next is a problem noticed by Vitaliy Gusev, he noted:
      
      ----------------------------------------
      >--- a/net/ipv4/tcp_timer.c
      >+++ b/net/ipv4/tcp_timer.c
      >@@ -481,6 +481,11 @@ static void tcp_keepalive_timer (unsigned long data)
      > 		goto death;
      > 	}
      >
      >+	if (tp->defer_tcp_accept.request && sk->sk_state == TCP_ESTABLISHED) {
      >+		tcp_send_active_reset(sk, GFP_ATOMIC);
      >+		goto death;
      
      Here socket sk is not attached to listening socket's request queue. tcp_done()
      will not call inet_csk_destroy_sock() (and tcp_v4_destroy_sock() which should
      release this sk) as socket is not DEAD. Therefore socket sk will be lost for
      freeing.
      ----------------------------------------
      
      Finally, Alexey Kuznetsov argues that there might not even be any
      real value or advantage to these new semantics even if we fix all
      of the bugs:
      
      ----------------------------------------
      Hiding from accept() sockets with only out-of-order data only
      is the only thing which is impossible with old approach. Is this really
      so valuable? My opinion: no, this is nothing but a new loophole
      to consume memory without control.
      ----------------------------------------
      
      So revert this thing for now.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ec0a1966
    • David S. Miller's avatar
      ipv6: Fix duplicate initialization of rawv6_prot.destroy · f23d60de
      David S. Miller authored
      In changeset 22dd4850
      ("raw: Raw socket leak.") code was added so that we
      flush pending frames on raw sockets to avoid leaks.
      
      The ipv4 part was fine, but the ipv6 part was not
      done correctly.  Unlike the ipv4 side, the ipv6 code
      already has a .destroy method for rawv6_prot.
      
      So now there were two assignments to this member, and
      what the compiler does is use the last one, effectively
      making the ipv6 parts of that changeset a NOP.
      
      Fix this by removing the:
      
      	.destroy	   = inet6_destroy_sock,
      
      line, and adding an inet6_destroy_sock() call to the
      end of raw6_destroy().
      
      Noticed by Al Viro.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      f23d60de
    • Eilon Greenstein's avatar
      bnx2x: Updating the Maintainer · 24e3fcef
      Eilon Greenstein authored
      I would like to thank Eliezer Tamir for writing and maintaining the
      driver for the past two years. I will take over maintaining the bnx2x
      driver from now on.
      Signed-off-by: default avatarEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: default avatarEliezer Tamir <eliezert@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      24e3fcef
    • Linus Torvalds's avatar
      Linux 2.6.26-rc6 · 5dd34572
      Linus Torvalds authored
      .. and a new name, courtesy of Alan.
      5dd34572
    • Linus Torvalds's avatar
      Merge branch 'x86-fixes-for-linus' of... · cbfa66b8
      Linus Torvalds authored
      Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        x86: fix pointer type warning in arch/x86/mm/init_64.c:early_memtest
        x86, lockdep: fix "WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x128()"
        x86: fix an incompatible pointer type warning on 64-bit compilations
        x86: fix lockdep warning during suspend-to-ram
        x86: fix unused variable 'loops' warning in arch/x86/boot/a20.c
        Revert "x86: fix ioapic bug again"
        x86: fix asm warning in head_32.S
        x86: fix endless page faults in mount_block_root for Linux 2.6
        geode: fix modular build
      cbfa66b8
    • Linus Torvalds's avatar
      Merge branch 'sched-fixes-for-linus' of... · 1b3cba8e
      Linus Torvalds authored
      Merge branch 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        sched: 64-bit: fix arithmetics overflow
        sched: fair group: fix overflow(was: fix divide by zero)
        sched: fix TASK_WAKEKILL vs SIGKILL race
      1b3cba8e
    • Stefan Schmidt's avatar
      [ARM] 5091/1: Add missing bitfield include to regs-lcd.h · 3692fd0a
      Stefan Schmidt authored
      Macros like Fld() or FShft used in regs-lcd.h are defined in bitfield.h, but
      the latter is not included.
      Also fix one whitespace issue while being there.
      Signed-off-by: default avatarAntonio Ospite <ao2@openezx.org>
      Signed-off-by: default avatarStefan Schmidt <stefan@datenfreihafen.org>
      Acked-by: default avatarEric Miao <eric.miao@marvell.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      3692fd0a
    • Kevin Winchester's avatar
      x86: fix pointer type warning in arch/x86/mm/init_64.c:early_memtest · f8a45704
      Kevin Winchester authored
      Changed the call to find_e820_area_size to pass u64 instead of unsigned long.
      Signed-off-by: default avatarKevin Winchester <kjwinchester@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      f8a45704
    • Vegard Nossum's avatar
      x86, lockdep: fix "WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x128()" · 4461145e
      Vegard Nossum authored
      Alessandro Suardi reported:
      > Recently upgraded my FC6 desktop to Fedora 9; with the
      >  latest nautilus RPM updates my VNC session went nuts
      >  with nautilus pegging the CPU for everything that breathed.
      >
      > I now reverted to an earlier nautilus package, but during
      >  the peak CPU period my kernel spat this:
      >
      > [314185.623294] ------------[ cut here ]------------
      > [314185.623414] WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x128()
      > [314185.623514] Modules linked in: iptable_filter ip_tables x_tables
      > sunrpc ipv6 fuse snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart
      > snd_rawmidi via686a hwmon parport_pc sg parport uhci_hcd ehci_hcd
      > [314185.623924] Pid: 12314, comm: nautilus Not tainted 2.6.26-rc5-git2 #4
      > [314185.624021]  [<c0115b95>] warn_on_slowpath+0x41/0x7b
      > [314185.624021]  [<c010de70>] ? do_page_fault+0x2c1/0x5fd
      > [314185.624021]  [<c0128396>] ? up_read+0x16/0x28
      > [314185.624021]  [<c010de70>] ? do_page_fault+0x2c1/0x5fd
      > [314185.624021]  [<c012fa33>] ? __lock_acquire+0xbb4/0xbc3
      > [314185.624021]  [<c012d0a0>] check_flags+0x4c/0x128
      > [314185.624021]  [<c012fa73>] lock_acquire+0x31/0x7d
      > [314185.624021]  [<c0128cf6>] __atomic_notifier_call_chain+0x30/0x80
      > [314185.624021]  [<c0128cc6>] ? __atomic_notifier_call_chain+0x0/0x80
      > [314185.624021]  [<c0128d52>] atomic_notifier_call_chain+0xc/0xe
      > [314185.624021]  [<c0128d81>] notify_die+0x2d/0x2f
      > [314185.624021]  [<c01043b0>] do_int3+0x1f/0x4d
      > [314185.624021]  [<c02f2d3b>] int3+0x27/0x2c
      > [314185.624021]  =======================
      > [314185.624021] ---[ end trace 1923f65a2d7bb246 ]---
      > [314185.624021] possible reason: unannotated irqs-off.
      > [314185.624021] irq event stamp: 488879
      > [314185.624021] hardirqs last  enabled at (488879): [<c0102d67>]
      > restore_nocheck+0x12/0x15
      > [314185.624021] hardirqs last disabled at (488878): [<c0102dca>]
      > work_resched+0x19/0x30
      > [314185.624021] softirqs last  enabled at (488876): [<c011a1ba>]
      > __do_softirq+0xa6/0xac
      > [314185.624021] softirqs last disabled at (488865): [<c010476e>]
      > do_softirq+0x57/0xa6
      >
      > I didn't seem to find it with some googling, so here it is.
      >
      > I was incidentally ltracing that process to try and find out
      >  what was gulping down that much CPU (sorry, no idea
      >  whether ltrace and the WARNING happened at the same
      >  time or which came first) and:
      
      Yeah, this is extremely likely to be the source of the warning.
      
      The warning should be harmless, however.
      
      > Box is my trusty noname K7-800, 512MB RAM; if there's
      >  anything else useful I might be able to provide, just ask.
      
      It would be interesting to see where the int3 comes from.  Too bad,
      lockdep doesn't provide the register dump. The stacktrace also doesn't
      go further than the int3(), I wonder if this int3 came from userspace?
      The ltrace readme says "software breakpoints, like gdb", so I guess
      this is the case. Yep, seems like it.
      
      This looks relevant:
      
      | commit fb1dac90
      | Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
      | Date:   Wed Jan 16 09:51:59 2008 +0100
      |
      |     lockdep: more hardirq annotations for notify_die()
      
      I'm attaching a similarly-looking patch for this case (DO_VM86_ERROR),
      though I suspect it might be missing for the other cases
      (DO_ERROR/DO_ERROR_INFO) as well.
      Reported-by: default avatarAlessandro Suardi <alessandro.suardi@gmail.com>
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4461145e