1. 29 10月, 2009 2 次提交
  2. 28 10月, 2009 8 次提交
  3. 27 10月, 2009 1 次提交
    • E
      vlan: allow null VLAN ID to be used · 05423b24
      Eric Dumazet 提交于
      We currently use a 16 bit field (vlan_tci) to store VLAN ID/PRIO on a skb.
      
      Null value is used as a special value, meaning vlan tagging not enabled.
      This forbids use of null vlan ID.
      
      As pointed by David, some drivers use the 3 high order bits (PRIO)
      
      As VLAN ID is 12 bits, we can use the remaining bit (CFI) as a flag, and
      allow null VLAN ID.
      
      In case future code really wants to use VLAN_CFI_MASK, we'll have to use
      a bit outside of vlan_tci.
      
      #define VLAN_PRIO_MASK         0xe000 /* Priority Code Point */
      #define VLAN_PRIO_SHIFT        13
      #define VLAN_CFI_MASK          0x1000 /* Canonical Format Indicator */
      #define VLAN_TAG_PRESENT       VLAN_CFI_MASK
      #define VLAN_VID_MASK          0x0fff /* VLAN Identifier */
      Reported-by: NGertjan Hofman <gertjan_hofman@yahoo.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05423b24
  4. 24 10月, 2009 8 次提交
  5. 23 10月, 2009 2 次提交
  6. 22 10月, 2009 1 次提交
  7. 21 10月, 2009 4 次提交
  8. 20 10月, 2009 13 次提交
    • E
      filter: Add SKF_AD_QUEUE instruction · d19742fb
      Eric Dumazet 提交于
      It can help being able to filter packets on their queue_mapping.
      
      If filter performance is not good, we could add a "numqueue" field
      in struct packet_type, so that netif_nit_deliver() and other functions
      can directly ignore packets with not expected queue number.
      
      Lets experiment this simple filter extension first.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d19742fb
    • E
      af_packet: mc_drop/flush_mclist changes · ad959e76
      Eric Dumazet 提交于
      We hold RTNL, we can use __dev_get_by_index() instead of dev_get_by_index()
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad959e76
    • E
      af_packet: Avoid cache line dirtying · 94b05952
      Eric Dumazet 提交于
      While doing multiple captures, I found af_packet was dirtying cache line
      containing its prot_hook.
      
      This slow down machines where several cpus are necessary to handle capture
      traffic, as each prot_hook is traversed for each packet coming in or out
      the host.
      
      This patches moves "struct packet_type prot_hook" to the end of
      packet_sock, and uses a ____cacheline_aligned_in_smp to make sure
      this remains shared by all cpus.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      94b05952
    • H
      tcp: Try to catch MSG_PEEK bug · b6b39e8f
      Herbert Xu 提交于
      This patch tries to print out more information when we hit the
      MSG_PEEK bug in tcp_recvmsg.  It's been around since at least
      2005 and it's about time that we finally fix it.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b6b39e8f
    • J
      IP: Cleanups · 0eae750e
      John Dykstra 提交于
      Use symbols instead of magic constants while checking PMTU discovery
      setsockopt.
      
      Remove redundant test in ip_rt_frag_needed() (done by caller).
      Signed-off-by: NJohn Dykstra <john.dykstra1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0eae750e
    • J
      pkt_sched: ingress socket filter by mark · 7e75f93e
      jamal 提交于
      Allow bpf to set a filter to drop packets that dont
      match a specific mark
      Signed-off-by: NJamal Hadi Salim <hadi@cyberus.ca>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e75f93e
    • E
      net: Fix IP_MULTICAST_IF · 55b80503
      Eric Dumazet 提交于
      ipv4/ipv6 setsockopt(IP_MULTICAST_IF) have dubious __dev_get_by_index() calls.
      
      This function should be called only with RTNL or dev_base_lock held, or reader
      could see a corrupt hash chain and eventually enter an endless loop.
      
      Fix is to call dev_get_by_index()/dev_put().
      
      If this happens to be performance critical, we could define a new dev_exist_by_index()
      function to avoid touching dev refcount.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      55b80503
    • D
      bluetooth: static lock key fix · 45054dc1
      Dave Young 提交于
      When shutdown ppp connection, lockdep waring about non-static key
      will happen, it is caused by the lock is not initialized properly
      at that time.
      
      Fix with tuning the lock/skb_queue_head init order
      
      [   94.339261] INFO: trying to register non-static key.
      [   94.342509] the code is fine but needs lockdep annotation.
      [   94.342509] turning off the locking correctness validator.
      [   94.342509] Pid: 0, comm: swapper Not tainted 2.6.31-mm1 #2
      [   94.342509] Call Trace:
      [   94.342509]  [<c0248fbe>] register_lock_class+0x58/0x241
      [   94.342509]  [<c024b5df>] ? __lock_acquire+0xb57/0xb73
      [   94.342509]  [<c024ab34>] __lock_acquire+0xac/0xb73
      [   94.342509]  [<c024b7fa>] ? lock_release_non_nested+0x17b/0x1de
      [   94.342509]  [<c024b662>] lock_acquire+0x67/0x84
      [   94.342509]  [<c04cd1eb>] ? skb_dequeue+0x15/0x41
      [   94.342509]  [<c054a857>] _spin_lock_irqsave+0x2f/0x3f
      [   94.342509]  [<c04cd1eb>] ? skb_dequeue+0x15/0x41
      [   94.342509]  [<c04cd1eb>] skb_dequeue+0x15/0x41
      [   94.342509]  [<c054a648>] ? _read_unlock+0x1d/0x20
      [   94.342509]  [<c04cd641>] skb_queue_purge+0x14/0x1b
      [   94.342509]  [<fab94fdc>] l2cap_recv_frame+0xea1/0x115a [l2cap]
      [   94.342509]  [<c024b5df>] ? __lock_acquire+0xb57/0xb73
      [   94.342509]  [<c0249c04>] ? mark_lock+0x1e/0x1c7
      [   94.342509]  [<f8364963>] ? hci_rx_task+0xd2/0x1bc [bluetooth]
      [   94.342509]  [<fab95346>] l2cap_recv_acldata+0xb1/0x1c6 [l2cap]
      [   94.342509]  [<f8364997>] hci_rx_task+0x106/0x1bc [bluetooth]
      [   94.342509]  [<fab95295>] ? l2cap_recv_acldata+0x0/0x1c6 [l2cap]
      [   94.342509]  [<c02302c4>] tasklet_action+0x69/0xc1
      [   94.342509]  [<c022fbef>] __do_softirq+0x94/0x11e
      [   94.342509]  [<c022fcaf>] do_softirq+0x36/0x5a
      [   94.342509]  [<c022fe14>] irq_exit+0x35/0x68
      [   94.342509]  [<c0204ced>] do_IRQ+0x72/0x89
      [   94.342509]  [<c02038ee>] common_interrupt+0x2e/0x34
      [   94.342509]  [<c024007b>] ? pm_qos_add_requirement+0x63/0x9d
      [   94.342509]  [<c038e8a5>] ? acpi_idle_enter_bm+0x209/0x238
      [   94.342509]  [<c049d238>] cpuidle_idle_call+0x5c/0x94
      [   94.342509]  [<c02023f8>] cpu_idle+0x4e/0x6f
      [   94.342509]  [<c0534153>] rest_init+0x53/0x55
      [   94.342509]  [<c0781894>] start_kernel+0x2f0/0x2f5
      [   94.342509]  [<c0781091>] i386_start_kernel+0x91/0x96
      Reported-by: NOliver Hartkopp <oliver@hartkopp.net>
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Tested-by: NOliver Hartkopp <oliver@hartkopp.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      45054dc1
    • D
      bluetooth: scheduling while atomic bug fix · f74c77cb
      Dave Young 提交于
      Due to driver core changes dev_set_drvdata will call kzalloc which should be
      in might_sleep context, but hci_conn_add will be called in atomic context
      
      Like dev_set_name move dev_set_drvdata to work queue function.
      
      oops as following:
      
      Oct  2 17:41:59 darkstar kernel: [  438.001341] BUG: sleeping function called from invalid context at mm/slqb.c:1546
      Oct  2 17:41:59 darkstar kernel: [  438.001345] in_atomic(): 1, irqs_disabled(): 0, pid: 2133, name: sdptool
      Oct  2 17:41:59 darkstar kernel: [  438.001348] 2 locks held by sdptool/2133:
      Oct  2 17:41:59 darkstar kernel: [  438.001350]  #0:  (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.+.}, at: [<faa1d2f5>] lock_sock+0xa/0xc [l2cap]
      Oct  2 17:41:59 darkstar kernel: [  438.001360]  #1:  (&hdev->lock){+.-.+.}, at: [<faa20e16>] l2cap_sock_connect+0x103/0x26b [l2cap]
      Oct  2 17:41:59 darkstar kernel: [  438.001371] Pid: 2133, comm: sdptool Not tainted 2.6.31-mm1 #2
      Oct  2 17:41:59 darkstar kernel: [  438.001373] Call Trace:
      Oct  2 17:41:59 darkstar kernel: [  438.001381]  [<c022433f>] __might_sleep+0xde/0xe5
      Oct  2 17:41:59 darkstar kernel: [  438.001386]  [<c0298843>] __kmalloc+0x4a/0x15a
      Oct  2 17:41:59 darkstar kernel: [  438.001392]  [<c03f0065>] ? kzalloc+0xb/0xd
      Oct  2 17:41:59 darkstar kernel: [  438.001396]  [<c03f0065>] kzalloc+0xb/0xd
      Oct  2 17:41:59 darkstar kernel: [  438.001400]  [<c03f04ff>] device_private_init+0x15/0x3d
      Oct  2 17:41:59 darkstar kernel: [  438.001405]  [<c03f24c5>] dev_set_drvdata+0x18/0x26
      Oct  2 17:41:59 darkstar kernel: [  438.001414]  [<fa51fff7>] hci_conn_init_sysfs+0x40/0xd9 [bluetooth]
      Oct  2 17:41:59 darkstar kernel: [  438.001422]  [<fa51cdc0>] ? hci_conn_add+0x128/0x186 [bluetooth]
      Oct  2 17:41:59 darkstar kernel: [  438.001429]  [<fa51ce0f>] hci_conn_add+0x177/0x186 [bluetooth]
      Oct  2 17:41:59 darkstar kernel: [  438.001437]  [<fa51cf8a>] hci_connect+0x3c/0xfb [bluetooth]
      Oct  2 17:41:59 darkstar kernel: [  438.001442]  [<faa20e87>] l2cap_sock_connect+0x174/0x26b [l2cap]
      Oct  2 17:41:59 darkstar kernel: [  438.001448]  [<c04c8df5>] sys_connect+0x60/0x7a
      Oct  2 17:41:59 darkstar kernel: [  438.001453]  [<c024b703>] ? lock_release_non_nested+0x84/0x1de
      Oct  2 17:41:59 darkstar kernel: [  438.001458]  [<c028804b>] ? might_fault+0x47/0x81
      Oct  2 17:41:59 darkstar kernel: [  438.001462]  [<c028804b>] ? might_fault+0x47/0x81
      Oct  2 17:41:59 darkstar kernel: [  438.001468]  [<c033361f>] ? __copy_from_user_ll+0x11/0xce
      Oct  2 17:41:59 darkstar kernel: [  438.001472]  [<c04c9419>] sys_socketcall+0x82/0x17b
      Oct  2 17:41:59 darkstar kernel: [  438.001477]  [<c020329d>] syscall_call+0x7/0xb
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f74c77cb
    • J
      tcp: fix TCP_DEFER_ACCEPT retrans calculation · b103cf34
      Julian Anastasov 提交于
      Fix TCP_DEFER_ACCEPT conversion between seconds and
      retransmission to match the TCP SYN-ACK retransmission periods
      because the time is converted to such retransmissions. The old
      algorithm selects one more retransmission in some cases. Allow
      up to 255 retransmissions.
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b103cf34
    • J
      tcp: reduce SYN-ACK retrans for TCP_DEFER_ACCEPT · 0c3d79bc
      Julian Anastasov 提交于
      Change SYN-ACK retransmitting code for the TCP_DEFER_ACCEPT
      users to not retransmit SYN-ACKs during the deferring period if
      ACK from client was received. The goal is to reduce traffic
      during the deferring period. When the period is finished
      we continue with sending SYN-ACKs (at least one) but this time
      any traffic from client will change the request to established
      socket allowing application to terminate it properly.
      Also, do not drop acked request if sending of SYN-ACK fails.
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c3d79bc
    • J
      tcp: accept socket after TCP_DEFER_ACCEPT period · d1b99ba4
      Julian Anastasov 提交于
      Willy Tarreau and many other folks in recent years
      were concerned what happens when the TCP_DEFER_ACCEPT period
      expires for clients which sent ACK packet. They prefer clients
      that actively resend ACK on our SYN-ACK retransmissions to be
      converted from open requests to sockets and queued to the
      listener for accepting after the deferring period is finished.
      Then application server can decide to wait longer for data
      or to properly terminate the connection with FIN if read()
      returns EAGAIN which is an indication for accepting after
      the deferring period. This change still can have side effects
      for applications that expect always to see data on the accepted
      socket. Others can be prepared to work in both modes (with or
      without TCP_DEFER_ACCEPT period) and their data processing can
      ignore the read=EAGAIN notification and to allocate resources for
      clients which proved to have no data to send during the deferring
      period. OTOH, servers that use TCP_DEFER_ACCEPT=1 as flag (not
      as a timeout) to wait for data will notice clients that didn't
      send data for 3 seconds but that still resend ACKs.
      Thanks to Willy Tarreau for the initial idea and to
      Eric Dumazet for the review and testing the change.
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d1b99ba4
    • D
      Revert "tcp: fix tcp_defer_accept to consider the timeout" · a1a2ad91
      David S. Miller 提交于
      This reverts commit 6d01a026.
      
      Julian Anastasov, Willy Tarreau and Eric Dumazet have come up
      with a more correct way to deal with this.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a1a2ad91
  9. 19 10月, 2009 1 次提交
    • T
      AF_UNIX: Fix deadlock on connecting to shutdown socket · 77238f2b
      Tomoki Sekiyama 提交于
      I found a deadlock bug in UNIX domain socket, which makes able to DoS
      attack against the local machine by non-root users.
      
      How to reproduce:
      1. Make a listening AF_UNIX/SOCK_STREAM socket with an abstruct
          namespace(*), and shutdown(2) it.
       2. Repeat connect(2)ing to the listening socket from the other sockets
          until the connection backlog is full-filled.
       3. connect(2) takes the CPU forever. If every core is taken, the
          system hangs.
      
      PoC code: (Run as many times as cores on SMP machines.)
      
      int main(void)
      {
      	int ret;
      	int csd;
      	int lsd;
      	struct sockaddr_un sun;
      
      	/* make an abstruct name address (*) */
      	memset(&sun, 0, sizeof(sun));
      	sun.sun_family = PF_UNIX;
      	sprintf(&sun.sun_path[1], "%d", getpid());
      
      	/* create the listening socket and shutdown */
      	lsd = socket(AF_UNIX, SOCK_STREAM, 0);
      	bind(lsd, (struct sockaddr *)&sun, sizeof(sun));
      	listen(lsd, 1);
      	shutdown(lsd, SHUT_RDWR);
      
      	/* connect loop */
      	alarm(15); /* forcely exit the loop after 15 sec */
      	for (;;) {
      		csd = socket(AF_UNIX, SOCK_STREAM, 0);
      		ret = connect(csd, (struct sockaddr *)&sun, sizeof(sun));
      		if (-1 == ret) {
      			perror("connect()");
      			break;
      		}
      		puts("Connection OK");
      	}
      	return 0;
      }
      
      (*) Make sun_path[0] = 0 to use the abstruct namespace.
          If a file-based socket is used, the system doesn't deadlock because
          of context switches in the file system layer.
      
      Why this happens:
       Error checks between unix_socket_connect() and unix_wait_for_peer() are
       inconsistent. The former calls the latter to wait until the backlog is
       processed. Despite the latter returns without doing anything when the
       socket is shutdown, the former doesn't check the shutdown state and
       just retries calling the latter forever.
      
      Patch:
       The patch below adds shutdown check into unix_socket_connect(), so
       connect(2) to the shutdown socket will return -ECONREFUSED.
      Signed-off-by: NTomoki Sekiyama <tomoki.sekiyama.qu@hitachi.com>
      Signed-off-by: NMasanori Yoshida <masanori.yoshida.tv@hitachi.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      77238f2b