1. 14 Aug, 2006 17 commits
    • john stultz's avatar
      [PATCH] futex_handle_fault always fails · e579dcbf
      john stultz authored
      We found this issue last week w/ the -RT kernel, but it seems the same
      issue is in mainline as well.
      
      Basically it is possible for futex_unlock_pi to return without actually
      freeing the lock.  This is due to buggy logic in the use of
      futex_handle_fault() and its attempt argument in a failure case.
      
      Looking at futex.c the logic is as follows:
      
      1) In futex_unlock_pi() we start w/ ret=0 and we go down to the first
         futex_atomic_cmpxchg_inatomic(), where we find uval==-EFAULT.  We then
         jump to the pi_faulted label.
      
      2) From pi_faulted: We increment attempt, unlock the sem and hit the
         retry label.
      
      3) From the retry label, with ret still zero, we again hit EFAULT on the
         first futex_atomic_cmpxchg_inatomic(), and again goto the pi_faulted
         label.
      
      4) Again from pi_faulted: we increment attempt and enter the
         conditional, where we call futex_handle_fault.
      
      5) futex_handle_fault fails, and we goto the out_unlock_release_sem
         label.
      
      6) From out_unlock_release_sem we return, and since ret is still zero,
         we return without error, while never actually unlocking the lock.
      
      Issue #1: at the first futex_atomic_cmpxchg_inatomic() we should probably
      be setting ret=-EFAULT before jumping to pi_faulted: However in our case
      this doesn't really affect anything, as the glibc we're using ignores the
      error value from futex_unlock_pi().
      
      Issue #2: Look at futex_handle_fault(), its first conditional will return
      -EFAULT if attempt is >= 2.  However, from the "if(attempt++)
      futex_handle_fault(attempt)" logic above, we'll *never* call
      futex_handle_fault when attempt is less then two.  So we never get a chance
      to even try to fault the page in.
      
      The following patch addresses these two issues by 1) Always setting ret to
      -EFAULT if futex_handle_fault fails, and 2) Removing the = in
      futex_handle_fault's (attempt >= 2) check.
      
      I'm really not sure this is the right fix, but wanted to bring it up so
      folks knew the issue is alive and well in the current -git tree.  From
      looking at the git logs the logic was first introduced (then later copied
      to other places) in the following commit almost a year ago:
      
      http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4732efbeb997189d9f9b04708dc26bf8613ed721;hp=5b039e681b8c5f30aac9cc04385cc94be45d0823
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Ingo Molnar <mingo@elte.hu>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e579dcbf
    • Kirill Korotaev's avatar
      [PATCH] sys_getppid oopses on debug kernel · 6997a6fa
      Kirill Korotaev authored
      sys_getppid() optimization can access a freed memory.  On kernels with
      DEBUG_SLAB turned ON, this results in Oops.  As Dave Hansen noted, this
      optimization is also unsafe for memory hotplug.
      
      So this patch always takes the lock to be safe.
      
      [oleg@tv-sign.ru: simplifications]
      Signed-off-by: default avatarKirill Korotaev <dev@openvz.org>
      Cc: <stable@kernel.org>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Signed-off-by: default avatarOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      6997a6fa
    • Horms's avatar
      [PATCH] Change panic_on_oops message to "Fatal exception" · 012c437d
      Horms authored
      Previously the message was "Fatal exception: panic_on_oops", as introduced
      in a recent patch whith removed a somewhat dangerous call to ssleep() in
      the panic_on_oops path.  However, Paul Mackerras suggested that this was
      somewhat confusing, leadind people to believe that it was panic_on_oops
      that was the root cause of the fatal exception.  On his suggestion, this
      patch changes the message to simply "Fatal exception".  A suitable oops
      message should already have been displayed.
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      012c437d
    • Michal Miroslaw's avatar
      [PATCH] dm: BUG/OOPS fix · 485311a2
      Michal Miroslaw authored
      Fix BUG I tripped on while testing failover and multipathing.
      
      BUG shows up on error path in multipath_ctr() when parse_priority_group()
      fails after returning at least once without error.  The fix is to
      initialize m->ti early - just after alloc()ing it.
      
      BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
       printing eip:
      c027c3d2
      *pde = 00000000
      Oops: 0000 [#3]
      Modules linked in: qla2xxx ext3 jbd mbcache sg ide_cd cdrom floppy
      CPU:    0
      EIP:    0060:[<c027c3d2>]    Not tainted VLI
      EFLAGS: 00010202   (2.6.17.3 #1)
      EIP is at dm_put_device+0xf/0x3b
      eax: 00000001   ebx: ee4fcac0   ecx: 00000000   edx: ee4fcac0
      esi: ee4fc4e0   edi: ee4fc4e0   ebp: 00000000   esp: c5db3e78
      ds: 007b   es: 007b   ss: 0068
      Process multipathd (pid: 15912, threadinfo=c5db2000 task=ef485a90)
      Stack: ec4eda40 c02816bd ee4fc4c0 00000000 f7e89498 f883e0bc c02816f6 f7e89480
             f7e8948c c0281801 ffffffea f7e89480 f883e080 c0281ffe 00000001 00000000
             00000004 dfe9cab8 f7a693c0 f883e080 f883e0c0 ca4b99c0 c027c6ee 01400000
      Call Trace:
       <c02816bd> free_pgpaths+0x31/0x45  <c02816f6> free_priority_group+0x25/0x2e
       <c0281801> free_multipath+0x35/0x67  <c0281ffe> multipath_ctr+0x123/0x12d
       <c027c6ee> dm_table_add_target+0x11e/0x18b  <c027e5b4> populate_table+0x8a/0xaf
       <c027e62b> table_load+0x52/0xf9  <c027ec23> ctl_ioctl+0xca/0xfc
       <c027e5d9> table_load+0x0/0xf9  <c0152146> do_ioctl+0x3e/0x43
       <c0152360> vfs_ioctl+0x16c/0x178  <c01523b4> sys_ioctl+0x48/0x60
       <c01029b3> syscall_call+0x7/0xb
      Code: 97 f0 00 00 00 89 c1 83 c9 01 80 e2 01 0f 44 c1 88 43 14 8b 04 24 59 5b 5e 5f 5d c3 53 89 c1 89 d3 ff 4a 08 0f 94 c0 84 c0 74 2a <8b> 01 8b 10 89 d8 e8 f6 fb ff ff 8b 03 8b 53 04 89 50 04 89 02
      EIP: [<c027c3d2>] dm_put_device+0xf/0x3b SS:ESP 0068:c5db3e78
      Signed-off-by: default avatarMichal Miroslaw <mirq-linux@rere.qmqm.pl>
      Acked-by: default avatarAlasdair G Kergon <agk@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      485311a2
    • Andrew Morton's avatar
      [PATCH] panic.c build fix · 657b3010
      Andrew Morton authored
      kernel/panic.c: In function 'add_taint':
      kernel/panic.c:176: warning: implicit declaration of function 'debug_locks_off'
      
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      657b3010
    • Jan Blunck's avatar
      [PATCH] fix hrtimer percpu usage typo · 3773dc92
      Jan Blunck authored
      The percpu variable is used incorrectly in switch_hrtimer_base().
      Signed-off-by: default avatarJan Blunck <jblunck@suse.de>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      3773dc92
    • Dan Bastone's avatar
      [PATCH] initialize parts of udf inode earlier in create · 95f8797f
      Dan Bastone authored
      Eric says:
      
      > I saw an oops down this path when trying to create a new file on a UDF
      > filesystem which was internally marked as readonly, but mounted rw:
      >
      > udf_create
      >         udf_new_inode
      >                 new_inode
      >                         alloc_inode
      >                         	udf_alloc_inode
      >                 udf_new_block
      >                         returns EIO due to readonlyness
      >                 iput (on error)
      
      I ran into the same issue today, but when listing a directory with
      invalid/corrupt entries:
      
      udf_lookup
              udf_iget
                      get_new_inode_fast
                              alloc_inode
                                      udf_alloc_inode
                      __udf_read_inode
                              fails for any reason
                      iput (on error)
                              ...
      
      The following patch to udf_alloc_inode() should take care of both (and
      other similar) cases, but I've only tested it with udf_lookup().
      Signed-off-by: default avatarDan Bastone <dan@pwienterprises.com>
      Cc: Eric Sandeen <sandeen@sandeen.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      95f8797f
    • Andrew Morton's avatar
      [PATCH] adfs error message fix · 1725cd0a
      Andrew Morton authored
      Don't use NULL as a printf control string.  Fixes bug #6889.
      
      Cc: Ralph Corderoy <ralph@inputplus.co.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1725cd0a
    • Edgar Hucek's avatar
      [PATCH] add imacfb documentation and detection · b64ef8af
      Edgar Hucek authored
      Add basic Machine detection to imacfb and some Ducumentation bits for
      imacfb.
      Signed-off-by: default avatarEdgar Hucek <hostmaster@ed-soft.at>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      b64ef8af
    • Herbert Xu's avatar
      [INET]: Use pskb_trim_unique when trimming paged unique skbs · e9fa4f7b
      Herbert Xu authored
      The IPv4/IPv6 datagram output path was using skb_trim to trim paged
      packets because they know that the packet has not been cloned yet
      (since the packet hasn't been given to anything else in the system).
      
      This broke because skb_trim no longer allows paged packets to be
      trimmed.  Paged packets must be given to one of the pskb_trim functions
      instead.
      
      This patch adds a new pskb_trim_unique function to cover the IPv4/IPv6
      datagram output path scenario and replaces the corresponding skb_trim
      calls with it.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e9fa4f7b
    • Mark Huang's avatar
      [NETFILTER]: ulog: fix panic on SMP kernels · dcb7cd97
      Mark Huang authored
      Fix kernel panic on various SMP machines. The culprit is a null
      ub->skb in ulog_send(). If ulog_timer() has already been scheduled on
      one CPU and is spinning on the lock, and ipt_ulog_packet() flushes the
      queue on another CPU by calling ulog_send() right before it exits,
      there will be no skbuff when ulog_timer() acquires the lock and calls
      ulog_send(). Cancelling the timer in ulog_send() doesn't help because
      it has already been scheduled and is running on the first CPU.
      
      Similar problem exists in ebt_ulog.c and nfnetlink_log.c.
      Signed-off-by: default avatarMark Huang <mlhuang@cs.princeton.edu>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dcb7cd97
    • Patrick McHardy's avatar
      [NETFILTER]: {arp,ip,ip6}_tables: proper error recovery in init path · 0eff66e6
      Patrick McHardy authored
      Neither of {arp,ip,ip6}_tables cleans up behind itself when something goes
      wrong during initialization.
      
      Noticed by Rennie deGraaf <degraaf@cpsc.ucalgary.ca>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0eff66e6
    • Stephen Hemminger's avatar
      [LLC]: multicast receive device match · 7ee66fcb
      Stephen Hemminger authored
      Fix from Aji_Srinivas@emc.com, STP packets are incorrectly received on
      all LLC datagram sockets, whichever interface they are bound to.  The
      llc_sap datagram receive logic sends packets with a unicast
      destination MAC to one socket bound to that SAP and MAC, and multicast
      packets to all sockets bound to that SAP. STP packets are multicast,
      and we do need to know on which interface they were received.
      Signed-off-by: default avatarStephen Hemminger <shemminger@osdl.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7ee66fcb
    • David S. Miller's avatar
      [IPSEC]: Validate properly in xfrm_dst_check() · d49c73c7
      David S. Miller authored
      If dst->obsolete is -1, this is a signal from the
      bundle creator that we want the XFRM dst and the
      dsts that it references to be validated on every
      use.
      
      I misunderstood this intention when I changed
      xfrm_dst_check() to always return NULL.
      
      Now, when we purge a dst entry, by running dst_free()
      on it.  This will set the dst->obsolete to a positive
      integer, and we want to return NULL in that case so
      that the socket does a relookup for the route.
      
      Thus, if dst->obsolete<0, let stale_bundle() validate
      the state, else always return NULL.
      
      In general, we need to do things more intelligently
      here because we flush too much state during rule
      changes.  Herbert Xu has some ideas wherein the key
      manager gives us some help in this area.  We can also
      use smarter state management algorithms inside of
      the kernel as well.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d49c73c7
    • Patrick McHardy's avatar
      [NETFILTER]: xt_hashlimit: fix limit off-by-one · 1c7628bd
      Patrick McHardy authored
      Hashlimit doesn't account for the first packet, which is inconsistent
      with the limit match.
      
      Reported by ryan.castellucci@gmail.com, netfilter bugzilla #500.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c7628bd
    • Phil Oester's avatar
      [NETFILTER]: xt_string: fix negation · 97c802a1
      Phil Oester authored
      The xt_string match is broken with ! negation.
      This resolves a portion of netfilter bugzilla #497.
      Signed-off-by: default avatarPhil Oester <kernel@linuxace.com>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      97c802a1
    • David S. Miller's avatar
      [TCP]: Fix botched memory leak fix to tcpprobe_read(). · 18b6fe64
      David S. Miller authored
      Somehow I clobbered James's original fix and only my
      subsequent compiler warning change went in for that
      changeset.
      
      Get the real fix in there.
      
      Noticed by Jesper Juhl.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      18b6fe64
  2. 11 Aug, 2006 11 commits
  3. 10 Aug, 2006 5 commits
  4. 09 Aug, 2006 7 commits