1. 05 2月, 2008 6 次提交
    • D
      bluetooth: hidp_process_hid_control remove unnecessary parameter dealing · eff001e3
      Dave Young 提交于
      According to the bluetooth HID spec v1.0 chapter 7.4.2
      
      "This code requests a major state change in a BT-HID device.  A HID_CONTROL
      request does not generate a HANDSHAKE response."
      
      "A HID_CONTROL packet with a parameter of VIRTUAL_CABLE_UNPLUG is the only
      HID_CONTROL packet a device can send to a host.  A host will ignore all other
      packets."
      
      So in the hidp_precess_hid_control function, we just need to deal with the
      UNLUG packet.
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eff001e3
    • W
      [SCTP]: Fix kernel panic while received AUTH chunk with BAD shared key identifier · 7cc08b55
      Wei Yongjun 提交于
      If SCTP-AUTH is enabled, received AUTH chunk with BAD shared key 
      identifier will cause kernel panic.
      
      Test as following:
      step1: enabled /proc/sys/net/sctp/auth_enable
      step 2:  connect  to SCTP server with auth capable. Association is 
      established between endpoints. Then send a AUTH chunk with a bad 
      shareid, SCTP server will kernel panic after received that AUTH chunk.
      
      SCTP client                   SCTP server
        INIT         ---------->  
          (with auth capable)
                     <----------    INIT-ACK
                                    (with auth capable)
        COOKIE-ECHO  ---------->
                     <----------    COOKIE-ACK
        AUTH         ---------->
      
      
      AUTH chunk is like this:
        AUTH chunk
          Chunk type: AUTH (15)
          Chunk flags: 0x00
          Chunk length: 28
          Shared key identifier: 10
          HMAC identifier: SHA-1 (1)
          HMAC: 0000000000000000000000000000000000000000
      
      The assignment of NULL to key can safely be removed, since key_for_each 
      (which is just list_for_each_entry under the covers does an initial 
      assignment to key anyway).
      
      If the endpoint_shared_keys list is empty, or if the key_id being 
      requested does not exist, the function as it currently stands returns 
      the actuall list_head (in this case endpoint_shared_keys.  Since that 
      list_head isn't surrounded by an actuall data structure, the last 
      iteration through list_for_each_entry will do a container_of on key, and 
      we wind up returning a bogus pointer, instead of NULL, as we should.
      
      > Neil Horman wrote:
      >> On Tue, Jan 22, 2008 at 05:29:20PM +0900, Wei Yongjun wrote:
      >>
      >> FWIW, Ack from me.  The assignment of NULL to key can safely be 
      >> removed, since
      >> key_for_each (which is just list_for_each_entry under the covers does 
      >> an initial
      >> assignment to key anyway).
      >> If the endpoint_shared_keys list is empty, or if the key_id being 
      >> requested does
      >> not exist, the function as it currently stands returns the actuall 
      >> list_head (in
      >> this case endpoint_shared_keys.  Since that list_head isn't 
      >> surrounded by an
      >> actuall data structure, the last iteration through 
      >> list_for_each_entry will do a
      >> container_of on key, and we wind up returning a bogus pointer, 
      >> instead of NULL,
      >> as we should.  Wei's patch corrects that.
      >>
      >> Regards
      >> Neil
      >>
      >> Acked-by: Neil Horman <nhorman@tuxdriver.com>
      >>
      >
      > Yep, the patch is correct.
      >
      > Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
      >
      > -vlad
      >
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7cc08b55
    • W
      [SCTP]: Fix kernel panic while received AUTH chunk while enabled auth · d2f19fa1
      Wei Yongjun 提交于
      If STCP is started while /proc/sys/net/sctp/auth_enable is set 0 and
      association is established between endpoints. Then if
      /proc/sys/net/sctp/auth_enable is set 1, a received AUTH chunk will
      cause kernel panic.
      
      Test as following:
      step 1: echo 0> /proc/sys/net/sctp/auth_enable
      step 2:
      
         SCTP client                  SCTP server
            INIT          --------->
                          <---------   INIT-ACK
            COOKIE-ECHO   --------->
                          <---------   COOKIE-ACK
      step 3:
          echo 1> /proc/sys/net/sctp/auth_enable
      step 4:
         SCTP client                  SCTP server
             AUTH        ----------->  Kernel Panic
      
      
      This patch fix this probleam to treat AUTH chunk as unknow chunk if peer 
      has initialized with no auth capable.
      
      > Sorry for the delay.  Was on vacation without net access.
      >
      > Wei Yongjun wrote:
      >>
      >>
      >> This patch fix this probleam to treat AUTH chunk as unknow chunk if 
      >> peer has initialized with no auth capable.
      >>
      >> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
      >
      > Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
      >
      >>
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Acked-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d2f19fa1
    • D
      [IPV4]: Formatting fix for /proc/net/fib_trie. · b9c4d82a
      Denis V. Lunev 提交于
      The line in the /proc/net/fib_trie for route with TOS specified
      - has extra \n at the end
      - does not have a space after route scope
      like below.
                 |-- 1.1.1.1
                    /32 universe UNICASTtos =1
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9c4d82a
    • R
      [NET_SCHED]: Add #ifdef CONFIG_NET_EMATCH in net/sched/cls_flow.c (latest git broken build) · 0aead543
      Rami Rosen 提交于
      The 2.6 latest git build was broken when using the following
      configuration options:
      CONFIG_NET_EMATCH=n
      CONFIG_NET_CLS_FLOW=y
      
      with the following error:
      net/sched/cls_flow.c: In function 'flow_dump':
      net/sched/cls_flow.c:598: error: 'struct tcf_ematch_tree' has no
      member named 'hdr'
      make[2]: *** [net/sched/cls_flow.o] Error 1
      make[1]: *** [net/sched] Error 2
      make: *** [net] Error 2
      
      
      see the recent post by Li Zefan:
        http://www.spinics.net/lists/netdev/msg54434.html
      
      The reason for this crash is that struct tcf_ematch_tree
      (net/pkt_cls.h) is empty when CONFIG_NET_EMATCH is not defined.
      
      When CONFIG_NET_EMATCH is defined, the tcf_ematch_tree structure
      indeed holds a struct tcf_ematch_tree_hdr (hdr) as flow_dump()
      expects.
      
      This patch adds #ifdef CONFIG_NET_EMATCH in flow_dump to avoid this.
      Signed-off-by: NRami Rosen <ramirose@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0aead543
    • A
      [IPSEC] xfrm4_beet_input(): fix an if() · 322c8a3c
      Adrian Bunk 提交于
      A bug every C programmer makes at some point in time...
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      322c8a3c
  2. 04 2月, 2008 3 次提交
  3. 03 2月, 2008 4 次提交
    • O
      typo fixes in net/core/net_namespace.c · 53379e57
      Oliver Pinter 提交于
      Signed-off-by: NOliver Pinter <oliver.pntr@gmail.com>
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      53379e57
    • O
      typo fix in net/rfkill/rfkill.c · 1dbede87
      Oliver Pinter 提交于
      Signed-off-by: NOliver Pinter <oliver.pntr@gmail.com>
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      1dbede87
    • O
      typo fixes in net/sctp/sm_statefuns.c · ac461a03
      Oliver Pinter 提交于
      Signed-off-by: NOliver Pinter <oliver.pntr@gmail.com>
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      ac461a03
    • A
      [SOCK] proto: Add hashinfo member to struct proto · ab1e0a13
      Arnaldo Carvalho de Melo 提交于
      This way we can remove TCP and DCCP specific versions of
      
      sk->sk_prot->get_port: both v4 and v6 use inet_csk_get_port
      sk->sk_prot->hash:     inet_hash is directly used, only v6 need
                             a specific version to deal with mapped sockets
      sk->sk_prot->unhash:   both v4 and v6 use inet_hash directly
      
      struct inet_connection_sock_af_ops also gets a new member, bind_conflict, so
      that inet_csk_get_port can find the per family routine.
      
      Now only the lookup routines receive as a parameter a struct inet_hashtable.
      
      With this we further reuse code, reducing the difference among INET transport
      protocols.
      
      Eventually work has to be done on UDP and SCTP to make them share this
      infrastructure and get as a bonus inet_diag interfaces so that iproute can be
      used with these protocols.
      
      net-2.6/net/ipv4/inet_hashtables.c:
        struct proto			     |   +8
        struct inet_connection_sock_af_ops |   +8
       2 structs changed
        __inet_hash_nolisten               |  +18
        __inet_hash                        | -210
        inet_put_port                      |   +8
        inet_bind_bucket_create            |   +1
        __inet_hash_connect                |   -8
       5 functions changed, 27 bytes added, 218 bytes removed, diff: -191
      
      net-2.6/net/core/sock.c:
        proto_seq_show                     |   +3
       1 function changed, 3 bytes added, diff: +3
      
      net-2.6/net/ipv4/inet_connection_sock.c:
        inet_csk_get_port                  |  +15
       1 function changed, 15 bytes added, diff: +15
      
      net-2.6/net/ipv4/tcp.c:
        tcp_set_state                      |   -7
       1 function changed, 7 bytes removed, diff: -7
      
      net-2.6/net/ipv4/tcp_ipv4.c:
        tcp_v4_get_port                    |  -31
        tcp_v4_hash                        |  -48
        tcp_v4_destroy_sock                |   -7
        tcp_v4_syn_recv_sock               |   -2
        tcp_unhash                         | -179
       5 functions changed, 267 bytes removed, diff: -267
      
      net-2.6/net/ipv6/inet6_hashtables.c:
        __inet6_hash |   +8
       1 function changed, 8 bytes added, diff: +8
      
      net-2.6/net/ipv4/inet_hashtables.c:
        inet_unhash                        | +190
        inet_hash                          | +242
       2 functions changed, 432 bytes added, diff: +432
      
      vmlinux:
       16 functions changed, 485 bytes added, 492 bytes removed, diff: -7
      
      /home/acme/git/net-2.6/net/ipv6/tcp_ipv6.c:
        tcp_v6_get_port                    |  -31
        tcp_v6_hash                        |   -7
        tcp_v6_syn_recv_sock               |   -9
       3 functions changed, 47 bytes removed, diff: -47
      
      /home/acme/git/net-2.6/net/dccp/proto.c:
        dccp_destroy_sock                  |   -7
        dccp_unhash                        | -179
        dccp_hash                          |  -49
        dccp_set_state                     |   -7
        dccp_done                          |   +1
       5 functions changed, 1 bytes added, 242 bytes removed, diff: -241
      
      /home/acme/git/net-2.6/net/dccp/ipv4.c:
        dccp_v4_get_port                   |  -31
        dccp_v4_request_recv_sock          |   -2
       2 functions changed, 33 bytes removed, diff: -33
      
      /home/acme/git/net-2.6/net/dccp/ipv6.c:
        dccp_v6_get_port                   |  -31
        dccp_v6_hash                       |   -7
        dccp_v6_request_recv_sock          |   +5
       3 functions changed, 5 bytes added, 38 bytes removed, diff: -33
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab1e0a13
  4. 02 2月, 2008 27 次提交