1. 23 3月, 2008 1 次提交
    • H
      [TCP]: Let skbs grow over a page on fast peers · 69d15067
      Herbert Xu 提交于
      While testing the virtio-net driver on KVM with TSO I noticed
      that TSO performance with a 1500 MTU is significantly worse
      compared to the performance of non-TSO with a 16436 MTU.  The
      packet dump shows that most of the packets sent are smaller
      than a page.
      
      Looking at the code this actually is quite obvious as it always
      stop extending the packet if it's the first packet yet to be
      sent and if it's larger than the MSS.  Since each extension is
      bound by the page size, this means that (given a 1500 MTU) we're
      very unlikely to construct packets greater than a page, provided
      that the receiver and the path is fast enough so that packets can
      always be sent immediately.
      
      The fix is also quite obvious.  The push calls inside the loop
      is just an optimisation so that we don't end up doing all the
      sending at the end of the loop.  Therefore there is no specific
      reason why it has to do so at MSS boundaries.  For TSO, the
      most natural extension of this optimisation is to do the pushing
      once the skb exceeds the TSO size goal.
      
      This is what the patch does and testing with KVM shows that the
      TSO performance with a 1500 MTU easily surpasses that of a 16436
      MTU and indeed the packet sizes sent are generally larger than
      16436.
      
      I don't see any obvious downsides for slower peers or connections,
      but it would be prudent to test this extensively to ensure that
      those cases don't regress.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69d15067
  2. 22 3月, 2008 3 次提交
  3. 21 3月, 2008 12 次提交
    • J
      [NET] ifb: set separate lockdep classes for queue locks · 94833dfb
      Jarek Poplawski 提交于
      [   10.536424] =======================================================
      [   10.536424] [ INFO: possible circular locking dependency detected ]
      [   10.536424] 2.6.25-rc3-devel #3
      [   10.536424] -------------------------------------------------------
      [   10.536424] swapper/0 is trying to acquire lock:
      [   10.536424]  (&dev->queue_lock){-+..}, at: [<c0299b4a>] 
      dev_queue_xmit+0x175/0x2f3
      [   10.536424]
      [   10.536424] but task is already holding lock:
      [   10.536424]  (&p->tcfc_lock){-+..}, at: [<f8a67154>] tcf_mirred+0x20/0x178 
      [act_mirred]
      [   10.536424]
      [   10.536424] which lock already depends on the new lock.
      
      lockdep warns of locking order while using ifb with sch_ingress and
      act_mirred: ingress_lock, tcfc_lock, queue_lock (usually queue_lock
      is at the beginning). This patch is only to tell lockdep that ifb is
      a different device (e.g. from eth) and has its own pair of queue
      locks. (This warning is a false-positive in common scenario of using
      ifb; yet there are possible situations, when this order could be
      dangerous; lockdep should warn in such a case.) (With suggestions by
      David S. Miller)
      Reported-and-tested-by: NDenys Fedoryshchenko <denys@visp.net.lb>
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Acked-by: NJamal Hadi Salim <hadi@cyberus.ca>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      94833dfb
    • Y
      [IPV6] KCONFIG: Fix description about IPV6_TUNNEL. · 38fe999e
      YOSHIFUJI Hideaki 提交于
      Based on notice from "Colin" <colins@sjtu.edu.cn>.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      38fe999e
    • P
      [TCP]: Fix shrinking windows with window scaling · 607bfbf2
      Patrick McHardy 提交于
      When selecting a new window, tcp_select_window() tries not to shrink
      the offered window by using the maximum of the remaining offered window
      size and the newly calculated window size. The newly calculated window
      size is always a multiple of the window scaling factor, the remaining
      window size however might not be since it depends on rcv_wup/rcv_nxt.
      This means we're effectively shrinking the window when scaling it down.
      
      
      The dump below shows the problem (scaling factor 2^7):
      
      - Window size of 557 (71296) is advertised, up to 3111907257:
      
      IP 172.2.2.3.33000 > 172.2.2.2.33000: . ack 3111835961 win 557 <...>
      
      - New window size of 514 (65792) is advertised, up to 3111907217, 40 bytes
        below the last end:
      
      IP 172.2.2.3.33000 > 172.2.2.2.33000: . 3113575668:3113577116(1448) ack 3111841425 win 514 <...>
      
      The number 40 results from downscaling the remaining window:
      
      3111907257 - 3111841425 = 65832
      65832 / 2^7 = 514
      65832 % 2^7 = 40
      
      If the sender uses up the entire window before it is shrunk, this can have
      chaotic effects on the connection. When sending ACKs, tcp_acceptable_seq()
      will notice that the window has been shrunk since tcp_wnd_end() is before
      tp->snd_nxt, which makes it choose tcp_wnd_end() as sequence number.
      This will fail the receivers checks in tcp_sequence() however since it
      is before it's tp->rcv_wup, making it respond with a dupack.
      
      If both sides are in this condition, this leads to a constant flood of
      ACKs until the connection times out.
      
      Make sure the window is never shrunk by aligning the remaining window to
      the window scaling factor.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      607bfbf2
    • J
      netpoll: zap_completion_queue: adjust skb->users counter · 8a455b08
      Jarek Poplawski 提交于
      zap_completion_queue() retrieves skbs from completion_queue where they have
      zero skb->users counter.  Before dev_kfree_skb_any() it should be non-zero
      yet, so it's increased now.
      Reported-and-tested-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a455b08
    • F
      bridge: use time_before() in br_fdb_cleanup() · 2bec008c
      Fabio Checconi 提交于
      In br_fdb_cleanup() next_timer and this_timer are in jiffies, so they
      should be compared using the time_after() macro.
      Signed-off-by: NFabio Checconi <fabio@gandalf.sssup.it>
      Signed-off-by: NStephen Hemminger <stephen.hemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2bec008c
    • D
      [TG3]: Fix build warning on sparc32. · 7582a335
      David S. Miller 提交于
      Sparc MAC address support should be protected consistently
      with CONFIG_SPARC, but there was a stray CONFIG_SPARC64
      case.
      
      Bump driver version and release date.
      
      Reported by Andrew Morton.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7582a335
    • P
      MAINTAINERS: bluez-devel is subscribers-only · 781c2844
      Pavel Machek 提交于
      Signed-off-by: NPavel Machek <pavel@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      781c2844
    • P
      audit: netlink socket can be auto-bound to pid other than current->pid (v2) · 75c0371a
      Pavel Emelyanov 提交于
      From:	Pavel Emelyanov <xemul@openvz.org>
      
      This patch is based on the one from Thomas.
      
      The kauditd_thread() calls the netlink_unicast() and passes 
      the audit_pid to it. The audit_pid, in turn, is received from 
      the user space and the tool (I've checked the audit v1.6.9) 
      uses getpid() to pass one in the kernel. Besides, this tool 
      doesn't bind the netlink socket to this id, but simply creates 
      it allowing the kernel to auto-bind one.
      
      That's the preamble.
      
      The problem is that netlink_autobind() _does_not_ guarantees
      that the socket will be auto-bound to the current pid. Instead
      it uses the current pid as a hint to start looking for a free
      id. So, in case of conflict, the audit messages can be sent
      to a wrong socket. This can happen (it's unlikely, but can be)
      in case some task opens more than one netlink sockets and then
      the audit one starts - in this case the audit's pid can be busy
      and its socket will be bound to another id.
      
      The proposal is to introduce an audit_nlk_pid in audit subsys,
      that will point to the netlink socket to send packets to. It
      will most often be equal to audit_pid. The socket id can be 
      got from the skb's netlink CB right in the audit_receive_msg.
      The audit_nlk_pid reset to 0 is not required, since all the
      decisions are taken based on audit_pid value only.
      
      Later, if the audit tools will bind the socket themselves, the
      kernel will have to provide a way to setup the audit_nlk_pid
      as well.
      
      A good side effect of this patch is that audit_pid can later 
      be converted to struct pid, as it is not longer safe to use 
      pid_t-s in the presence of pid namespaces. But audit code still 
      uses the tgid from task_struct in the audit_signal_info and in
      the audit_filter_syscall.
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Acked-by: NEric Paris <eparis@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      75c0371a
    • A
      [NET]: Fix permissions of /proc/net · 4f42c288
      Andre Noll 提交于
      commit e9720acd ([NET]: Make /proc/net a symlink on /proc/self/net (v3))
      broke ganglia and probably other applications that read /proc/net/dev.
      
      This is due to the change of permissions of /proc/net that was
      introduced in that commit.
      
      Before: dr-xr-xr-x 5 root root 0 Mar 19 11:30 /proc/net
      After: dr-xr--r-- 5 root root 0 Mar 19 11:29 /proc/self/net
      
      This patch restores the permissions to the old value which makes
      ganglia happy again.
      
      Pavel Emelyanov says:
      
      	This also broke the postfix, as it was reported in bug #10286
      	and described in detail by Benjamin.
      Signed-off-by: NAndre Noll <maan@systemlinux.org>
      Acked-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f42c288
    • V
      [SCTP]: Fix a race between module load and protosw access · 270637ab
      Vlad Yasevich 提交于
      There is a race is SCTP between the loading of the module
      and the access by the socket layer to the protocol functions.
      In particular, a list of addresss that SCTP maintains is
      not initialized prior to the registration with the protosw.
      Thus it is possible for a user application to gain access
      to SCTP functions before everything has been initialized.
      The problem shows up as odd crashes during connection
      initializtion when we try to access the SCTP address list.
      
      The solution is to refactor how we do registration and
      initialize the lists prior to registering with the protosw.
      Care must be taken since the address list initialization
      depends on some other pieces of SCTP initialization.  Also
      the clean-up in case of failure now also needs to be refactored.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Acked-by: NSridhar Samudrala <sri@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      270637ab
    • D
      [NETFILTER]: ipt_recent: sanity check hit count · d0ebf133
      Daniel Hokka Zakrisson 提交于
      If a rule using ipt_recent is created with a hit count greater than
      ip_pkt_list_tot, the rule will never match as it cannot keep track
      of enough timestamps. This patch makes ipt_recent refuse to create such
      rules.
      
      With ip_pkt_list_tot's default value of 20, the following can be used
      to reproduce the problem.
      
      nc -u -l 0.0.0.0 1234 &
      for i in `seq 1 100`; do echo $i | nc -w 1 -u 127.0.0.1 1234; done
      
      This limits it to 20 packets:
      iptables -A OUTPUT -p udp --dport 1234 -m recent --set --name test \
               --rsource
      iptables -A OUTPUT -p udp --dport 1234 -m recent --update --seconds \
               60 --hitcount 20 --name test --rsource -j DROP
      
      While this is unlimited:
      iptables -A OUTPUT -p udp --dport 1234 -m recent --set --name test \
               --rsource
      iptables -A OUTPUT -p udp --dport 1234 -m recent --update --seconds \
               60 --hitcount 21 --name test --rsource -j DROP
      
      With the patch the second rule-set will throw an EINVAL.
      Reported-by: NSean Kennedy <skennedy@vcn.com>
      Signed-off-by: NDaniel Hokka Zakrisson <daniel@hozac.com>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0ebf133
    • R
      [NETFILTER]: nf_conntrack_h323: logical-bitwise & confusion in process_setup() · 6aebb9b2
      Roel Kluin 提交于
      logical-bitwise & confusion
      Signed-off-by: NRoel Kluin <12o3l@tiscali.nl>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6aebb9b2
  4. 19 3月, 2008 1 次提交
  5. 18 3月, 2008 13 次提交
  6. 17 3月, 2008 10 次提交