1. 18 10月, 2009 2 次提交
  2. 07 10月, 2009 1 次提交
  3. 01 10月, 2009 1 次提交
  4. 17 9月, 2009 4 次提交
    • H
      af_iucv: fix race when queueing skbs on the backlog queue · bf95d20f
      Hendrik Brueckner 提交于
      iucv_sock_recvmsg() and iucv_process_message()/iucv_fragment_skb race
      for dequeuing an skb from the backlog queue.
      
      If iucv_sock_recvmsg() dequeues first, iucv_process_message() calls
      sock_queue_rcv_skb() with an skb that is NULL.
      
      This results in the following kernel panic:
      
      <1>Unable to handle kernel pointer dereference at virtual kernel address (null)
      <4>Oops: 0004 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      <4>Modules linked in: af_iucv sunrpc qeth_l3 dm_multipath dm_mod vmur qeth ccwgroup
      <4>CPU: 0 Not tainted 2.6.30 #4
      <4>Process client-iucv (pid: 4787, task: 0000000034e75940, ksp: 00000000353e3710)
      <4>Krnl PSW : 0704000180000000 000000000043ebca (sock_queue_rcv_skb+0x7a/0x138)
      <4>           R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:0 PM:0 EA:3
      <4>Krnl GPRS: 0052900000000000 000003e0016e0fe8 0000000000000000 0000000000000000
      <4>           000000000043eba8 0000000000000002 0000000000000001 00000000341aa7f0
      <4>           0000000000000000 0000000000007800 0000000000000000 0000000000000000
      <4>           00000000341aa7f0 0000000000594650 000000000043eba8 000000003fc2fb28
      <4>Krnl Code: 000000000043ebbe: a7840006            brc     8,43ebca
      <4>           000000000043ebc2: 5930c23c            c       %r3,572(%r12)
      <4>           000000000043ebc6: a724004c            brc     2,43ec5e
      <4>          >000000000043ebca: e3c0b0100024        stg     %r12,16(%r11)
      <4>           000000000043ebd0: a7190000            lghi    %r1,0
      <4>           000000000043ebd4: e310b0200024        stg     %r1,32(%r11)
      <4>           000000000043ebda: c010ffffdce9        larl    %r1,43a5ac
      <4>           000000000043ebe0: e310b0800024        stg     %r1,128(%r11)
      <4>Call Trace:
      <4>([<000000000043eba8>] sock_queue_rcv_skb+0x58/0x138)
      <4> [<000003e0016bcf2a>] iucv_process_message+0x112/0x3cc [af_iucv]
      <4> [<000003e0016bd3d4>] iucv_callback_rx+0x1f0/0x274 [af_iucv]
      <4> [<000000000053a21a>] iucv_message_pending+0xa2/0x120
      <4> [<000000000053b5a6>] iucv_tasklet_fn+0x176/0x1b8
      <4> [<000000000014fa82>] tasklet_action+0xfe/0x1f4
      <4> [<0000000000150a56>] __do_softirq+0x116/0x284
      <4> [<0000000000111058>] do_softirq+0xe4/0xe8
      <4> [<00000000001504ba>] irq_exit+0xba/0xd8
      <4> [<000000000010e0b2>] do_extint+0x146/0x190
      <4> [<00000000001184b6>] ext_no_vtime+0x1e/0x22
      <4> [<00000000001fbf4e>] kfree+0x202/0x28c
      <4>([<00000000001fbf44>] kfree+0x1f8/0x28c)
      <4> [<000000000044205a>] __kfree_skb+0x32/0x124
      <4> [<000003e0016bd8b2>] iucv_sock_recvmsg+0x236/0x41c [af_iucv]
      <4> [<0000000000437042>] sock_aio_read+0x136/0x160
      <4> [<0000000000205e50>] do_sync_read+0xe4/0x13c
      <4> [<0000000000206dce>] vfs_read+0x152/0x15c
      <4> [<0000000000206ed0>] SyS_read+0x54/0xac
      <4> [<0000000000117c8e>] sysc_noemu+0x10/0x16
      <4> [<00000042ff8def3c>] 0x42ff8def3c
      Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bf95d20f
    • H
      af_iucv: do not call iucv_sock_kill() twice · 7514bab0
      Hendrik Brueckner 提交于
      For non-accepted sockets on the accept queue, iucv_sock_kill()
      is called twice (in iucv_sock_close() and iucv_sock_cleanup_listen()).
      This typically results in a kernel oops as shown below.
      
      Remove the duplicate call to iucv_sock_kill() and set the SOCK_ZAPPED
      flag in iucv_sock_close() only.
      
      The iucv_sock_kill() function frees a socket only if the socket is zapped
      and orphaned (sk->sk_socket == NULL):
        - Non-accepted sockets are always orphaned and, thus, iucv_sock_kill()
          frees the socket twice.
        - For accepted sockets or sockets created with iucv_sock_create(),
          sk->sk_socket is initialized. This caused the first call to
          iucv_sock_kill() to return immediately. To free these sockets,
          iucv_sock_release() uses sock_orphan() before calling iucv_sock_kill().
      
      <1>Unable to handle kernel pointer dereference at virtual kernel address 000000003edd3000
      <4>Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      <4>Modules linked in: af_iucv sunrpc qeth_l3 dm_multipath dm_mod qeth vmur ccwgroup
      <4>CPU: 0 Not tainted 2.6.30 #4
      <4>Process iucv_sock_close (pid: 2486, task: 000000003aea4340, ksp: 000000003b75bc68)
      <4>Krnl PSW : 0704200180000000 000003e00168e23a (iucv_sock_kill+0x2e/0xcc [af_iucv])
      <4>           R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3
      <4>Krnl GPRS: 0000000000000000 000000003b75c000 000000003edd37f0 0000000000000001
      <4>           000003e00168ec62 000000003988d960 0000000000000000 000003e0016b0608
      <4>           000000003fe81b20 000000003839bb58 00000000399977f0 000000003edd37f0
      <4>           000003e00168b000 000003e00168f138 000000003b75bcd0 000000003b75bc98
      <4>Krnl Code: 000003e00168e22a: c0c0ffffe6eb	larl	%r12,3e00168b000
      <4>           000003e00168e230: b90400b2		lgr	%r11,%r2
      <4>           000003e00168e234: e3e0f0980024	stg	%r14,152(%r15)
      <4>          >000003e00168e23a: e310225e0090	llgc	%r1,606(%r2)
      <4>           000003e00168e240: a7110001		tmll	%r1,1
      <4>           000003e00168e244: a7840007		brc	8,3e00168e252
      <4>           000003e00168e248: d507d00023c8	clc	0(8,%r13),968(%r2)
      <4>           000003e00168e24e: a7840009		brc	8,3e00168e260
      <4>Call Trace:
      <4>([<000003e0016b0608>] afiucv_dbf+0x0/0xfffffffffffdea20 [af_iucv])
      <4> [<000003e00168ec6c>] iucv_sock_close+0x130/0x368 [af_iucv]
      <4> [<000003e00168ef02>] iucv_sock_release+0x5e/0xe4 [af_iucv]
      <4> [<0000000000438e6c>] sock_release+0x44/0x104
      <4> [<0000000000438f5e>] sock_close+0x32/0x50
      <4> [<0000000000207898>] __fput+0xf4/0x250
      <4> [<00000000002038aa>] filp_close+0x7a/0xa8
      <4> [<00000000002039ba>] SyS_close+0xe2/0x148
      <4> [<0000000000117c8e>] sysc_noemu+0x10/0x16
      <4> [<00000042ff8deeac>] 0x42ff8deeac
      Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7514bab0
    • H
      af_iucv: handle non-accepted sockets after resuming from suspend · 56a73de3
      Hendrik Brueckner 提交于
      After resuming from suspend, all af_iucv sockets are disconnected.
      Ensure that iucv_accept_dequeue() can handle disconnected sockets
      which are not yet accepted.
      Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      56a73de3
    • H
      af_iucv: fix race in __iucv_sock_wait() · d9973179
      Hendrik Brueckner 提交于
      Moving prepare_to_wait before the condition to avoid a race between
      schedule_timeout and wake up.
      The race can appear during iucv_sock_connect() and iucv_callback_connack().
      Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d9973179
  5. 15 9月, 2009 1 次提交
  6. 10 7月, 2009 1 次提交
    • J
      net: adding memory barrier to the poll and receive callbacks · a57de0b4
      Jiri Olsa 提交于
      Adding memory barrier after the poll_wait function, paired with
      receive callbacks. Adding fuctions sock_poll_wait and sk_has_sleeper
      to wrap the memory barrier.
      
      Without the memory barrier, following race can happen.
      The race fires, when following code paths meet, and the tp->rcv_nxt
      and __add_wait_queue updates stay in CPU caches.
      
      CPU1                         CPU2
      
      sys_select                   receive packet
        ...                        ...
        __add_wait_queue           update tp->rcv_nxt
        ...                        ...
        tp->rcv_nxt check          sock_def_readable
        ...                        {
        schedule                      ...
                                      if (sk->sk_sleep && waitqueue_active(sk->sk_sleep))
                                              wake_up_interruptible(sk->sk_sleep)
                                      ...
                                   }
      
      If there was no cache the code would work ok, since the wait_queue and
      rcv_nxt are opposit to each other.
      
      Meaning that once tp->rcv_nxt is updated by CPU2, the CPU1 either already
      passed the tp->rcv_nxt check and sleeps, or will get the new value for
      tp->rcv_nxt and will return with new data mask.
      In both cases the process (CPU1) is being added to the wait queue, so the
      waitqueue_active (CPU2) call cannot miss and will wake up CPU1.
      
      The bad case is when the __add_wait_queue changes done by CPU1 stay in its
      cache, and so does the tp->rcv_nxt update on CPU2 side.  The CPU1 will then
      endup calling schedule and sleep forever if there are no more data on the
      socket.
      
      Calls to poll_wait in following modules were ommited:
      	net/bluetooth/af_bluetooth.c
      	net/irda/af_irda.c
      	net/irda/irnet/irnet_ppp.c
      	net/mac80211/rc80211_pid_debugfs.c
      	net/phonet/socket.c
      	net/rds/af_rds.c
      	net/rfkill/core.c
      	net/sunrpc/cache.c
      	net/sunrpc/rpc_pipe.c
      	net/tipc/socket.c
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a57de0b4
  7. 19 6月, 2009 2 次提交
  8. 16 6月, 2009 1 次提交
  9. 23 4月, 2009 8 次提交
  10. 22 4月, 2009 5 次提交
  11. 27 2月, 2009 1 次提交
  12. 06 1月, 2009 3 次提交
  13. 25 12月, 2008 1 次提交
  14. 14 7月, 2008 1 次提交
  15. 10 6月, 2008 1 次提交
  16. 10 4月, 2008 1 次提交
  17. 08 2月, 2008 2 次提交
  18. 29 1月, 2008 1 次提交
  19. 01 11月, 2007 1 次提交
  20. 11 10月, 2007 2 次提交