1. 20 10月, 2009 2 次提交
  2. 19 10月, 2009 5 次提交
  3. 18 10月, 2009 4 次提交
  4. 16 10月, 2009 1 次提交
  5. 15 10月, 2009 6 次提交
  6. 14 10月, 2009 1 次提交
  7. 13 10月, 2009 10 次提交
    • R
      x25: bit and/or confusion in x25_ioctl()? · 06a96b33
      roel kluin 提交于
      Looking at commit ebc3f64b it appears that this was intended
      and not the original, equivalent to `if (facilities.reverse & ~0x81)'.
      
      In x25_parse_facilities() that patch changed how facilities->reverse
      was set. No other bits were set than 0x80 and/or 0x01.
      Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      06a96b33
    • E
      tcp: replace ehash_size by ehash_mask · f373b53b
      Eric Dumazet 提交于
      Storing the mask (size - 1) instead of the size allows fast path to be
      a bit faster.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f373b53b
    • C
      c3faca05
    • E
      udp: Fix udp_poll() and ioctl() · 85584672
      Eric Dumazet 提交于
      udp_poll() can in some circumstances drop frames with incorrect checksums.
      
      Problem is we now have to lock the socket while dropping frames, or risk
      sk_forward corruption.
      
      This bug is present since commit 95766fff
      ([UDP]: Add memory accounting.)
      
      While we are at it, we can correct ioctl(SIOCINQ) to also drop bad frames.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      85584672
    • W
      tcp: fix tcp_defer_accept to consider the timeout · 6d01a026
      Willy Tarreau 提交于
      I was trying to use TCP_DEFER_ACCEPT and noticed that if the
      client does not talk, the connection is never accepted and
      remains in SYN_RECV state until the retransmits expire, where
      it finally is deleted. This is bad when some firewall such as
      netfilter sits between the client and the server because the
      firewall sees the connection in ESTABLISHED state while the
      server will finally silently drop it without sending an RST.
      
      This behaviour contradicts the man page which says it should
      wait only for some time :
      
             TCP_DEFER_ACCEPT (since Linux 2.4)
                Allows a listener to be awakened only when data arrives
                on the socket.  Takes an integer value  (seconds), this
                can  bound  the  maximum  number  of attempts TCP will
                make to complete the connection. This option should not
                be used in code intended to be portable.
      
      Also, looking at ipv4/tcp.c, a retransmit counter is correctly
      computed :
      
              case TCP_DEFER_ACCEPT:
                      icsk->icsk_accept_queue.rskq_defer_accept = 0;
                      if (val > 0) {
                              /* Translate value in seconds to number of
                               * retransmits */
                              while (icsk->icsk_accept_queue.rskq_defer_accept < 32 &&
                                     val > ((TCP_TIMEOUT_INIT / HZ) <<
                                             icsk->icsk_accept_queue.rskq_defer_accept))
                                      icsk->icsk_accept_queue.rskq_defer_accept++;
                              icsk->icsk_accept_queue.rskq_defer_accept++;
                      }
                      break;
      
      ==> rskq_defer_accept is used as a counter of retransmits.
      
      But in tcp_minisocks.c, this counter is only checked. And in
      fact, I have found no location which updates it. So I think
      that what was intended was to decrease it in tcp_minisocks
      whenever it is checked, which the trivial patch below does.
      Signed-off-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d01a026
    • A
      net: Introduce recvmmsg socket syscall · a2e27255
      Arnaldo Carvalho de Melo 提交于
      Meaning receive multiple messages, reducing the number of syscalls and
      net stack entry/exit operations.
      
      Next patches will introduce mechanisms where protocols that want to
      optimize this operation will provide an unlocked_recvmsg operation.
      
      This takes into account comments made by:
      
      . Paul Moore: sock_recvmsg is called only for the first datagram,
        sock_recvmsg_nosec is used for the rest.
      
      . Caitlin Bestler: recvmmsg now has a struct timespec timeout, that
        works in the same fashion as the ppoll one.
      
        If the underlying protocol returns a datagram with MSG_OOB set, this
        will make recvmmsg return right away with as many datagrams (+ the OOB
        one) it has received so far.
      
      . Rémi Denis-Courmont & Steven Whitehouse: If we receive N < vlen
        datagrams and then recvmsg returns an error, recvmmsg will return
        the successfully received datagrams, store the error and return it
        in the next call.
      
      This paves the way for a subsequent optimization, sk_prot->unlocked_recvmsg,
      where we will be able to acquire the lock only at batch start and end, not at
      every underlying recvmsg call.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a2e27255
    • N
      net: Generalize socket rx gap / receive queue overflow cmsg · 3b885787
      Neil Horman 提交于
      Create a new socket level option to report number of queue overflows
      
      Recently I augmented the AF_PACKET protocol to report the number of frames lost
      on the socket receive queue between any two enqueued frames.  This value was
      exported via a SOL_PACKET level cmsg.  AFter I completed that work it was
      requested that this feature be generalized so that any datagram oriented socket
      could make use of this option.  As such I've created this patch, It creates a
      new SOL_SOCKET level option called SO_RXQ_OVFL, which when enabled exports a
      SOL_SOCKET level cmsg that reports the nubmer of times the sk_receive_queue
      overflowed between any two given frames.  It also augments the AF_PACKET
      protocol to take advantage of this new feature (as it previously did not touch
      sk->sk_drops, which this patch uses to record the overflow count).  Tested
      successfully by me.
      
      Notes:
      
      1) Unlike my previous patch, this patch simply records the sk_drops value, which
      is not a number of drops between packets, but rather a total number of drops.
      Deltas must be computed in user space.
      
      2) While this patch currently works with datagram oriented protocols, it will
      also be accepted by non-datagram oriented protocols. I'm not sure if thats
      agreeable to everyone, but my argument in favor of doing so is that, for those
      protocols which aren't applicable to this option, sk_drops will always be zero,
      and reporting no drops on a receive queue that isn't used for those
      non-participating protocols seems reasonable to me.  This also saves us having
      to code in a per-protocol opt in mechanism.
      
      3) This applies cleanly to net-next assuming that commit
      97775007 (my af packet cmsg patch) is reverted
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b885787
    • J
      mac80211: document ieee80211_rx() context requirement · d20ef63d
      Johannes Berg 提交于
      ieee80211_rx() must be called with softirqs disabled
      since the networking stack requires this for netif_rx()
      and some code in mac80211 can assume that it can not
      be processing its own tasklet and this call at the same
      time.
      
      It may be possible to remove this requirement after a
      careful audit of mac80211 and doing any needed locking
      improvements in it along with disabling softirqs around
      netif_rx(). An alternative might be to push all packet
      processing to process context in mac80211, instead of
      to the tasklet, and add other synchronisation.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d20ef63d
    • J
      mac80211: fix ibss race · 51f98f13
      Johannes Berg 提交于
      When a scan completes, we call ieee80211_sta_find_ibss(),
      which is also called from other places. When the scan was
      done in software, there's no problem as both run from the
      single-threaded mac80211 workqueue and are thus serialised
      against each other, but with hardware scan the completion
      can be in a different context and race against callers of
      this function from the workqueue (e.g. due to beacon RX).
      So instead of calling ieee80211_sta_find_ibss() directly,
      just arm the timer and have it fire, scheduling the work,
      which will invoke ieee80211_sta_find_ibss() (if that is
      appropriate in the current state).
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      51f98f13
    • F
  8. 12 10月, 2009 5 次提交
  9. 09 10月, 2009 1 次提交
  10. 08 10月, 2009 5 次提交