1. 30 11月, 2007 9 次提交
  2. 29 11月, 2007 13 次提交
    • V
      SCTP: Fix build issues with SCTP AUTH. · b7e0fe9f
      Vlad Yasevich 提交于
      SCTP-AUTH requires selection of CRYPTO, HMAC and SHA1 since
      SHA1 is a MUST requirement for AUTH.  We also support SHA256,
      but that's optional, so fix the code to treat it as such.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      b7e0fe9f
    • V
      SCTP: Fix chunk acceptance when no authenticated chunks were listed. · 555d3d5d
      Vlad Yasevich 提交于
      In the case where no autheticated chunks were specified, we were still
      trying to verify that a given chunk needs authentication and doing so
      incorrectly.  Add a check for parameter length to make sure we don't
      try to use an empty auth_chunks parameter to verify against.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      555d3d5d
    • V
      SCTP: Fix the supported extensions paramter · 8ee4be37
      Vlad Yasevich 提交于
      Supported extensions parameter was not coded right and ended up
      over-writing memory or causing skb overflows.  First, remove
      the FWD_TSN support from as it shouldn't be there and also fix
      the paramter encoding.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      8ee4be37
    • V
      SCTP: Fix SCTP-AUTH to correctly add HMACS paramter. · 9baffaa6
      Vlad Yasevich 提交于
      There was a typo that cleared the HMACS parameters when no
      authenticated chunks were specified.  We whould be clearing
      the chunks pointer instead of the hmacs.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      9baffaa6
    • V
      SCTP: Fix the number of HB transmissions. · fd10279b
      Vlad Yasevich 提交于
      Our treatment of Heartbeats is special in that the inital HB chunk
      counts against the error count for the association, where as for
      other chunks, only retransmissions or timeouts count against us.
      As a result, we had an off-by-1 situation with a number of
      Heartbeats we could send.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      fd10279b
    • S
      [TCP] illinois: Incorrect beta usage · a357dde9
      Stephen Hemminger 提交于
      Lachlan Andrew observed that my TCP-Illinois implementation uses the
      beta value incorrectly:
        The parameter  beta  in the paper specifies the amount to decrease
        *by*:  that is, on loss,
           W <-  W -  beta*W
        but in   tcp_illinois_ssthresh() uses  beta  as the amount
        to decrease  *to*: W <- beta*W
      
      This bug makes the Linux TCP-Illinois get less-aggressive on uncongested network,
      hurting performance. Note: since the base beta value is .5, it has no
      impact on a congested network.
      Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      a357dde9
    • H
      [IPSEC]: Fix uninitialised dst warning in __xfrm_lookup · 5e5234ff
      Herbert Xu 提交于
      Andrew Morton reported that __xfrm_lookup generates this warning:
      
      net/xfrm/xfrm_policy.c: In function '__xfrm_lookup':
      net/xfrm/xfrm_policy.c:1449: warning: 'dst' may be used uninitialized in this function
      
      This is because if policy->action is of an unexpected value then dst will
      not be initialised.  Of course, in practice this should never happen since
      the input layer xfrm_user/af_key will filter out all illegal values.  But
      the compiler doesn't know that of course.
      
      So this patch fixes this by taking the conservative approach and treat all
      unknown actions the same as a blocking action.
      
      Thanks to Andrew for finding this and providing an initial fix.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5e5234ff
    • P
      [INET]: Fix inet_diag register vs rcv race · 07693198
      Pavel Emelyanov 提交于
      The following race is possible when one cpu unregisters the handler
      while other one is trying to receive a message and call this one:
      
      CPU1:                                                 CPU2:
      inet_diag_rcv()                                       inet_diag_unregister()
        mutex_lock(&inet_diag_mutex);
        netlink_rcv_skb(skb, &inet_diag_rcv_msg);
          if (inet_diag_table[nlh->nlmsg_type] == 
                                     NULL) /* false handler is still registered */
          ...
          netlink_dump_start(idiagnl, skb, nlh,
                                 inet_diag_dump, NULL);
                 cb = kzalloc(sizeof(*cb), GFP_KERNEL);
                         /* sleep here freeing memory 
                          * or preempt
                          * or sleep later on nlk->cb_mutex
                          */
                                                               spin_lock(&inet_diag_register_lock);
                                                               inet_diag_table[type] = NULL;
          ...                                                  spin_unlock(&inet_diag_register_lock);
                                                               synchronize_rcu();
                                                               /* CPU1 is sleeping - RCU quiescent
                                                                * state is passed
                                                                */
                                                               return;
          /* inet_diag_dump is finally called: */
          inet_diag_dump()
            handler = inet_diag_table[cb->nlh->nlmsg_type];
            BUG_ON(handler == NULL); 
            /* OOPS! While we slept the unregister has set
             * handler to NULL :(
             */
      
      Grep showed, that the register/unregister functions are called
      from init/fini module callbacks for tcp_/dccp_diag, so it's OK
      to use the inet_diag_mutex to synchronize manipulations with the
      inet_diag_table and the access to it.
      
      Besides, as Herbert pointed out, asynchronous dumps should hold 
      this mutex as well, and thus, we provide the mutex as cb_mutex one.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      07693198
    • P
      [BRIDGE]: Properly dereference the br_should_route_hook · 82de382c
      Pavel Emelyanov 提交于
      This hook is protected with the RCU, so simple
      
      	if (br_should_route_hook)
      		br_should_route_hook(...)
      
      is not enough on some architectures.
      
      Use the rcu_dereference/rcu_assign_pointer in this case.
      
      Fixed Stephen's comment concerning using the typeof().
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      82de382c
    • P
      [BRIDGE]: Lost call to br_fdb_fini() in br_init() error path · 17efdd45
      Pavel Emelyanov 提交于
      In case the br_netfilter_init() (or any subsequent call) 
      fails, the br_fdb_fini() must be called to free the allocated
      in br_fdb_init() br_fdb_cache kmem cache.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      17efdd45
    • F
      [UNIX]: EOF on non-blocking SOCK_SEQPACKET · 0a112258
      Florian Zumbiehl 提交于
      I am not absolutely sure whether this actually is a bug (as in: I've got
      no clue what the standards say or what other implementations do), but at
      least I was pretty surprised when I noticed that a recv() on a
      non-blocking unix domain socket of type SOCK_SEQPACKET (which is connection
      oriented, after all) where the remote end has closed the connection
      returned -1 (EAGAIN) rather than 0 to indicate end of file.
      
      This is a test case:
      
      | #include <sys/types.h>
      | #include <unistd.h>
      | #include <sys/socket.h>
      | #include <sys/un.h>
      | #include <fcntl.h>
      | #include <string.h>
      | #include <stdlib.h>
      | 
      | int main(){
      | 	int sock;
      | 	struct sockaddr_un addr;
      | 	char buf[4096];
      | 	int pfds[2];
      | 
      | 	pipe(pfds);
      | 	sock=socket(PF_UNIX,SOCK_SEQPACKET,0);
      | 	addr.sun_family=AF_UNIX;
      | 	strcpy(addr.sun_path,"/tmp/foobar_testsock");
      | 	bind(sock,(struct sockaddr *)&addr,sizeof(addr));
      | 	listen(sock,1);
      | 	if(fork()){
      | 		close(sock);
      | 		sock=socket(PF_UNIX,SOCK_SEQPACKET,0);
      | 		connect(sock,(struct sockaddr *)&addr,sizeof(addr));
      | 		fcntl(sock,F_SETFL,fcntl(sock,F_GETFL)|O_NONBLOCK);
      | 		close(pfds[1]);
      | 		read(pfds[0],buf,sizeof(buf));
      | 		recv(sock,buf,sizeof(buf),0); // <-- this one
      | 	}else accept(sock,NULL,NULL);
      | 	exit(0);
      | }
      
      If you try it, make sure /tmp/foobar_testsock doesn't exist.
      
      The marked recv() returns -1 (EAGAIN) on 2.6.23.9. Below you find a
      patch that fixes that.
      Signed-off-by: NFlorian Zumbiehl <florz@florz.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      0a112258
    • J
      [VLAN]: Fix nested VLAN transmit bug · 6ab3b487
      Joonwoo Park 提交于
      Fix misbehavior of vlan_dev_hard_start_xmit() for recursive encapsulations.
      Signed-off-by: NJoonwoo Park <joonwpark81@gmail.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6ab3b487
    • J
      [SUNGEM]: Fix NAPI regression with reset work · dde655c9
      Johannes Berg 提交于
      sungem's gem_reset_task() will unconditionally try to disable NAPI even
      when it's called while the interface is not operating and hence the NAPI
      struct isn't enabled. Make napi_disable() depend on gp->running.
      
      Also removes a superfluous test of gp->running in the same function.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      dde655c9
  3. 27 11月, 2007 2 次提交
  4. 26 11月, 2007 4 次提交
    • A
      [IPV4]: Remove bogus ifdef mess in arp_process · 3660019e
      Adrian Bunk 提交于
      The #ifdef's in arp_process() were not only a mess, they were also wrong 
      in the CONFIG_NET_ETHERNET=n and (CONFIG_NETDEV_1000=y or 
      CONFIG_NETDEV_10000=y) cases.
      
      Since they are not required this patch removes them.
      
      Also removed are some #ifdef's around #include's that caused compile 
      errors after this change.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      3660019e
    • H
      [SKBUFF]: Free old skb properly in skb_morph · 2d4baff8
      Herbert Xu 提交于
      The skb_morph function only freed the data part of the dst skb, but leaked
      the auxiliary data such as the netfilter fields.  This patch fixes this by
      moving the relevant parts from __kfree_skb to skb_release_all and calling
      it in skb_morph.
      
      It also makes kfree_skbmem static since it's no longer called anywhere else
      and it now no longer does skb_release_data.
      
      Thanks to Yasuyuki KOZAKAI for finding this problem and posting a patch for
      it.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      2d4baff8
    • P
      [IPV4]: Fix memory leak in inet_hashtables.h when NUMA is on · 218ad12f
      Pavel Emelyanov 提交于
      The inet_ehash_locks_alloc() looks like this:
      
      #ifdef CONFIG_NUMA
      	if (size > PAGE_SIZE)
      		x = vmalloc(...);
      	else
      #endif
      		x = kmalloc(...);
      
      Unlike it, the inet_ehash_locks_alloc() looks like this:
      
      #ifdef CONFIG_NUMA
      	if (size > PAGE_SIZE)
      		vfree(x);
      	else
      #else
      		kfree(x);
      #endif
      
      The error is obvious - if the NUMA is on and the size
      is less than the PAGE_SIZE we leak the pointer (kfree is
      inside the #else branch).
      
      Compiler doesn't warn us because after the kfree(x) there's
      a "x = NULL" assignment, so here's another (minor?) bug: we 
      don't set x to NULL under certain circumstances.
      
      Boring explanation, I know... Patch explains it better.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      218ad12f
    • H
      [IPSEC]: Temporarily remove locks around copying of non-atomic fields · 8053fc3d
      Herbert Xu 提交于
      The change 050f009e
      
      	[IPSEC]: Lock state when copying non-atomic fields to user-space
      
      caused a regression.
      
      Ingo Molnar reports that it causes a potential dead-lock found by the
      lock validator as it tries to take x->lock within xfrm_state_lock while
      numerous other sites take the locks in opposite order.
      
      For 2.6.24, the best fix is to simply remove the added locks as that puts
      us back in the same state as we've been in for years.  For later kernels
      a proper fix would be to reverse the locking order for every xfrm state
      user such that if x->lock is taken together with xfrm_state_lock then
      it is to be taken within it.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      8053fc3d
  5. 23 11月, 2007 2 次提交
  6. 22 11月, 2007 5 次提交
  7. 21 11月, 2007 5 次提交