Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 07 12月, 2007 7 次提交
  3. 05 12月, 2007 8 次提交
  5. 03 12月, 2007 1 次提交
  7. 30 11月, 2007 11 次提交
  9. 29 11月, 2007 12 次提交
    • 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
  11. 27 11月, 2007 1 次提交