1. 07 10月, 2009 1 次提交
  2. 01 10月, 2009 1 次提交
  3. 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
  4. 15 9月, 2009 1 次提交
  5. 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
  6. 19 6月, 2009 2 次提交
  7. 16 6月, 2009 1 次提交
  8. 23 4月, 2009 8 次提交
  9. 22 4月, 2009 5 次提交
  10. 27 2月, 2009 1 次提交
  11. 06 1月, 2009 3 次提交
  12. 25 12月, 2008 1 次提交
  13. 14 7月, 2008 1 次提交
  14. 10 6月, 2008 1 次提交
  15. 10 4月, 2008 1 次提交
  16. 08 2月, 2008 2 次提交
  17. 29 1月, 2008 1 次提交
  18. 01 11月, 2007 1 次提交
  19. 11 10月, 2007 3 次提交
    • U
      [AF_IUCV]: postpone receival of iucv-packets · f0703c80
      Ursula Braun 提交于
      AF_IUCV socket programs may waste Linux storage, because af_iucv
      allocates an skb whenever posted by the receive callback routine and
      receives the message immediately.
      Message receival is now postponed if data from previous callbacks has
      not yet been transferred to the receiving socket program. Instead a
      message handle is saved in a message queue as a reminder. Once
      messages could be given to the receiving socket program, there is
      an additional checking for entries in the message queue, followed
      by skb allocation and message receival if applicable.
      Signed-off-by: NUrsula Braun <braunu@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f0703c80
    • H
    • E
      [NET]: Make socket creation namespace safe. · 1b8d7ae4
      Eric W. Biederman 提交于
      This patch passes in the namespace a new socket should be created in
      and has the socket code do the appropriate reference counting.  By
      virtue of this all socket create methods are touched.  In addition
      the socket create methods are modified so that they will fail if
      you attempt to create a socket in a non-default network namespace.
      
      Failing if we attempt to create a socket outside of the default
      network namespace ensures that as we incrementally make the network stack
      network namespace aware we will not export functionality that someone
      has not audited and made certain is network namespace safe.
      Allowing us to partially enable network namespaces before all of the
      exotic protocols are supported.
      
      Any protocol layers I have missed will fail to compile because I now
      pass an extra parameter into the socket creation code.
      
      [ Integrated AF_IUCV build fixes from Andrew Morton... -DaveM ]
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b8d7ae4
  20. 15 7月, 2007 1 次提交