1. 31 3月, 2006 1 次提交
  2. 29 3月, 2006 1 次提交
    • D
      [NET]: deinline 200+ byte inlines in sock.h · f0088a50
      Denis Vlasenko 提交于
      Sizes in bytes (allyesconfig, i386) and files where those inlines
      are used:
      
      238 sock_queue_rcv_skb 2.6.16/net/x25/x25_in.o
      238 sock_queue_rcv_skb 2.6.16/net/rose/rose_in.o
      238 sock_queue_rcv_skb 2.6.16/net/packet/af_packet.o
      238 sock_queue_rcv_skb 2.6.16/net/netrom/nr_in.o
      238 sock_queue_rcv_skb 2.6.16/net/llc/llc_sap.o
      238 sock_queue_rcv_skb 2.6.16/net/llc/llc_conn.o
      238 sock_queue_rcv_skb 2.6.16/net/irda/af_irda.o
      238 sock_queue_rcv_skb 2.6.16/net/ipx/af_ipx.o
      238 sock_queue_rcv_skb 2.6.16/net/ipv6/udp.o
      238 sock_queue_rcv_skb 2.6.16/net/ipv6/raw.o
      238 sock_queue_rcv_skb 2.6.16/net/ipv4/udp.o
      238 sock_queue_rcv_skb 2.6.16/net/ipv4/raw.o
      238 sock_queue_rcv_skb 2.6.16/net/ipv4/ipmr.o
      238 sock_queue_rcv_skb 2.6.16/net/econet/econet.o
      238 sock_queue_rcv_skb 2.6.16/net/econet/af_econet.o
      238 sock_queue_rcv_skb 2.6.16/net/bluetooth/sco.o
      238 sock_queue_rcv_skb 2.6.16/net/bluetooth/l2cap.o
      238 sock_queue_rcv_skb 2.6.16/net/bluetooth/hci_sock.o
      238 sock_queue_rcv_skb 2.6.16/net/ax25/ax25_in.o
      238 sock_queue_rcv_skb 2.6.16/net/ax25/af_ax25.o
      238 sock_queue_rcv_skb 2.6.16/net/appletalk/ddp.o
      238 sock_queue_rcv_skb 2.6.16/drivers/net/pppoe.o
      
      276 sk_receive_skb 2.6.16/net/decnet/dn_nsp_in.o
      276 sk_receive_skb 2.6.16/net/dccp/ipv6.o
      276 sk_receive_skb 2.6.16/net/dccp/ipv4.o
      276 sk_receive_skb 2.6.16/net/dccp/dccp_ipv6.o
      276 sk_receive_skb 2.6.16/drivers/net/pppoe.o
      
      209 sk_dst_check 2.6.16/net/ipv6/ip6_output.o
      209 sk_dst_check 2.6.16/net/ipv4/udp.o
      209 sk_dst_check 2.6.16/net/decnet/dn_nsp_out.o
      
      Large inlines with multiple callers:
      Size  Uses Wasted Name and definition
      ===== ==== ====== ================================================
        238   21   4360 sock_queue_rcv_skb    include/net/sock.h
        109   10    801 sock_recv_timestamp   include/net/sock.h
        276    4    768 sk_receive_skb        include/net/sock.h
         94    8    518 __sk_dst_check        include/net/sock.h
        209    3    378 sk_dst_check  include/net/sock.h
        131    4    333 sk_setup_caps include/net/sock.h
        152    2    132 sk_stream_alloc_pskb  include/net/sock.h
        125    2    105 sk_stream_writequeue_purge    include/net/sock.h
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f0088a50
  3. 25 3月, 2006 1 次提交
  4. 21 3月, 2006 3 次提交
    • A
      [NET]: Identation & other cleanups related to compat_[gs]etsockopt cset · 543d9cfe
      Arnaldo Carvalho de Melo 提交于
      No code changes, just tidying up, in some cases moving EXPORT_SYMBOLs
      to just after the function exported, etc.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      543d9cfe
    • D
      [NET]: {get|set}sockopt compatibility layer · 3fdadf7d
      Dmitry Mishin 提交于
      This patch extends {get|set}sockopt compatibility layer in order to
      move protocol specific parts to their place and avoid huge universal
      net/compat.c file in the future.
      Signed-off-by: NDmitry Mishin <dim@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3fdadf7d
    • C
      [SECURITY]: TCP/UDP getpeersec · 2c7946a7
      Catherine Zhang 提交于
      This patch implements an application of the LSM-IPSec networking
      controls whereby an application can determine the label of the
      security association its TCP or UDP sockets are currently connected to
      via getsockopt and the auxiliary data mechanism of recvmsg.
      
      Patch purpose:
      
      This patch enables a security-aware application to retrieve the
      security context of an IPSec security association a particular TCP or
      UDP socket is using.  The application can then use this security
      context to determine the security context for processing on behalf of
      the peer at the other end of this connection.  In the case of UDP, the
      security context is for each individual packet.  An example
      application is the inetd daemon, which could be modified to start
      daemons running at security contexts dependent on the remote client.
      
      Patch design approach:
      
      - Design for TCP
      The patch enables the SELinux LSM to set the peer security context for
      a socket based on the security context of the IPSec security
      association.  The application may retrieve this context using
      getsockopt.  When called, the kernel determines if the socket is a
      connected (TCP_ESTABLISHED) TCP socket and, if so, uses the dst_entry
      cache on the socket to retrieve the security associations.  If a
      security association has a security context, the context string is
      returned, as for UNIX domain sockets.
      
      - Design for UDP
      Unlike TCP, UDP is connectionless.  This requires a somewhat different
      API to retrieve the peer security context.  With TCP, the peer
      security context stays the same throughout the connection, thus it can
      be retrieved at any time between when the connection is established
      and when it is torn down.  With UDP, each read/write can have
      different peer and thus the security context might change every time.
      As a result the security context retrieval must be done TOGETHER with
      the packet retrieval.
      
      The solution is to build upon the existing Unix domain socket API for
      retrieving user credentials.  Linux offers the API for obtaining user
      credentials via ancillary messages (i.e., out of band/control messages
      that are bundled together with a normal message).
      
      Patch implementation details:
      
      - Implementation for TCP
      The security context can be retrieved by applications using getsockopt
      with the existing SO_PEERSEC flag.  As an example (ignoring error
      checking):
      
      getsockopt(sockfd, SOL_SOCKET, SO_PEERSEC, optbuf, &optlen);
      printf("Socket peer context is: %s\n", optbuf);
      
      The SELinux function, selinux_socket_getpeersec, is extended to check
      for labeled security associations for connected (TCP_ESTABLISHED ==
      sk->sk_state) TCP sockets only.  If so, the socket has a dst_cache of
      struct dst_entry values that may refer to security associations.  If
      these have security associations with security contexts, the security
      context is returned.
      
      getsockopt returns a buffer that contains a security context string or
      the buffer is unmodified.
      
      - Implementation for UDP
      To retrieve the security context, the application first indicates to
      the kernel such desire by setting the IP_PASSSEC option via
      getsockopt.  Then the application retrieves the security context using
      the auxiliary data mechanism.
      
      An example server application for UDP should look like this:
      
      toggle = 1;
      toggle_len = sizeof(toggle);
      
      setsockopt(sockfd, SOL_IP, IP_PASSSEC, &toggle, &toggle_len);
      recvmsg(sockfd, &msg_hdr, 0);
      if (msg_hdr.msg_controllen > sizeof(struct cmsghdr)) {
          cmsg_hdr = CMSG_FIRSTHDR(&msg_hdr);
          if (cmsg_hdr->cmsg_len <= CMSG_LEN(sizeof(scontext)) &&
              cmsg_hdr->cmsg_level == SOL_IP &&
              cmsg_hdr->cmsg_type == SCM_SECURITY) {
              memcpy(&scontext, CMSG_DATA(cmsg_hdr), sizeof(scontext));
          }
      }
      
      ip_setsockopt is enhanced with a new socket option IP_PASSSEC to allow
      a server socket to receive security context of the peer.  A new
      ancillary message type SCM_SECURITY.
      
      When the packet is received we get the security context from the
      sec_path pointer which is contained in the sk_buff, and copy it to the
      ancillary message space.  An additional LSM hook,
      selinux_socket_getpeersec_udp, is defined to retrieve the security
      context from the SELinux space.  The existing function,
      selinux_socket_getpeersec does not suit our purpose, because the
      security context is copied directly to user space, rather than to
      kernel space.
      
      Testing:
      
      We have tested the patch by setting up TCP and UDP connections between
      applications on two machines using the IPSec policies that result in
      labeled security associations being built.  For TCP, we can then
      extract the peer security context using getsockopt on either end.  For
      UDP, the receiving end can retrieve the security context using the
      auxiliary data mechanism of recvmsg.
      Signed-off-by: NCatherine Zhang <cxzhang@watson.ibm.com>
      Acked-by: NJames Morris <jmorris@namei.org>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2c7946a7
  5. 12 1月, 2006 1 次提交
  6. 04 1月, 2006 1 次提交
  7. 09 11月, 2005 1 次提交
  8. 28 10月, 2005 1 次提交
  9. 09 10月, 2005 1 次提交
  10. 28 9月, 2005 1 次提交
    • F
      [NET]: Fix module reference counts for loadable protocol modules · a79af59e
      Frank Filz 提交于
      I have been experimenting with loadable protocol modules, and ran into
      several issues with module reference counting.
      
      The first issue was that __module_get failed at the BUG_ON check at
      the top of the routine (checking that my module reference count was
      not zero) when I created the first socket. When sk_alloc() is called,
      my module reference count was still 0. When I looked at why sctp
      didn't have this problem, I discovered that sctp creates a control
      socket during module init (when the module ref count is not 0), which
      keeps the reference count non-zero. This section has been updated to
      address the point Stephen raised about checking the return value of
      try_module_get().
      
      The next problem arose when my socket init routine returned an error.
      This resulted in my module reference count being decremented below 0.
      My socket ops->release routine was also being called. The issue here
      is that sock_release() calls the ops->release routine and decrements
      the ref count if sock->ops is not NULL. Since the socket probably
      didn't get correctly initialized, this should not be done, so we will
      set sock->ops to NULL because we will not call try_module_get().
      
      While searching for another bug, I also noticed that sys_accept() has
      a possibility of doing a module_put() when it did not do an
      __module_get so I re-ordered the call to security_socket_accept().
      Signed-off-by: NFrank Filz <ffilzlnx@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a79af59e
  11. 07 9月, 2005 2 次提交
    • P
      [NET]: proto_unregister: fix sleeping while atomic · 0a3f4358
      Patrick McHardy 提交于
      proto_unregister holds a lock while calling kmem_cache_destroy, which
      can sleep.
      
      Noticed by Daniele Orlandi <daniele@orlandi.com>.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0a3f4358
    • E
      [NET]: Make sure l_linger is unsigned to avoid negative timeouts · 9261c9b0
      Eric Dumazet 提交于
      One of my x86_64 (linux 2.6.13) server log is filled with :
      
      schedule_timeout: wrong timeout value ffffffffffffff06 from ffffffff802e63ca
      schedule_timeout: wrong timeout value ffffffffffffff06 from ffffffff802e63ca
      schedule_timeout: wrong timeout value ffffffffffffff06 from ffffffff802e63ca
      schedule_timeout: wrong timeout value ffffffffffffff06 from ffffffff802e63ca
      schedule_timeout: wrong timeout value ffffffffffffff06 from ffffffff802e63ca
      
      This is because some application does a
      
      struct linger li;
      li.l_onoff = 1;
      li.l_linger = -1;
      setsockopt(sock, SOL_SOCKET, SO_LINGER, &li, sizeof(li));
      
      And unfortunatly l_linger is defined as a 'signed int' in
      include/linux/socket.h:
      
      struct linger {
               int             l_onoff;        /* Linger active                */
               int             l_linger;       /* How long to linger for       */
      };
      
      I dont know if it's safe to change l_linger to 'unsigned int' in the
      include file (It might be defined as int in ABI specs)
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9261c9b0
  12. 06 9月, 2005 1 次提交
  13. 30 8月, 2005 4 次提交
  14. 28 7月, 2005 1 次提交
  15. 09 7月, 2005 1 次提交
  16. 19 6月, 2005 1 次提交
    • A
      [NET] Generalise TCP's struct open_request minisock infrastructure · 2e6599cb
      Arnaldo Carvalho de Melo 提交于
      Kept this first changeset minimal, without changing existing names to
      ease peer review.
      
      Basicaly tcp_openreq_alloc now receives the or_calltable, that in turn
      has two new members:
      
      ->slab, that replaces tcp_openreq_cachep
      ->obj_size, to inform the size of the openreq descendant for
        a specific protocol
      
      The protocol specific fields in struct open_request were moved to a
      class hierarchy, with the things that are common to all connection
      oriented PF_INET protocols in struct inet_request_sock, the TCP ones
      in tcp_request_sock, that is an inet_request_sock, that is an
      open_request.
      
      I.e. this uses the same approach used for the struct sock class
      hierarchy, with sk_prot indicating if the protocol wants to use the
      open_request infrastructure by filling in sk_prot->rsk_prot with an
      or_calltable.
      
      Results? Performance is improved and TCP v4 now uses only 64 bytes per
      open request minisock, down from 96 without this patch :-)
      
      Next changeset will rename some of the structs, fields and functions
      mentioned above, struct or_calltable is way unclear, better name it
      struct request_sock_ops, s/struct open_request/struct request_sock/g,
      etc.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e6599cb
  17. 06 5月, 2005 2 次提交
  18. 01 5月, 2005 1 次提交
    • P
      [PATCH] DocBook: changes and extensions to the kernel documentation · 4dc3b16b
      Pavel Pisa 提交于
      I have recompiled Linux kernel 2.6.11.5 documentation for me and our
      university students again.  The documentation could be extended for more
      sources which are equipped by structured comments for recent 2.6 kernels.  I
      have tried to proceed with that task.  I have done that more times from 2.6.0
      time and it gets boring to do same changes again and again.  Linux kernel
      compiles after changes for i386 and ARM targets.  I have added references to
      some more files into kernel-api book, I have added some section names as well.
       So please, check that changes do not break something and that categories are
      not too much skewed.
      
      I have changed kernel-doc to accept "fastcall" and "asmlinkage" words reserved
      by kernel convention.  Most of the other changes are modifications in the
      comments to make kernel-doc happy, accept some parameters description and do
      not bail out on errors.  Changed <pid> to @pid in the description, moved some
      #ifdef before comments to correct function to comments bindings, etc.
      
      You can see result of the modified documentation build at
        http://cmp.felk.cvut.cz/~pisa/linux/lkdb-2.6.11.tar.gz
      
      Some more sources are ready to be included into kernel-doc generated
      documentation.  Sources has been added into kernel-api for now.  Some more
      section names added and probably some more chaos introduced as result of quick
      cleanup work.
      Signed-off-by: NPavel Pisa <pisa@cmp.felk.cvut.cz>
      Signed-off-by: NMartin Waitz <tali@admingilde.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4dc3b16b
  19. 26 4月, 2005 2 次提交
    • A
      [NET]: kill gratitious includes of major.h · 5523662c
      Al Viro 提交于
      	A lot of places in there are including major.h for no reason
      whatsoever.  Removed.  And yes, it still builds.
      
      	The history of that stuff is often amusing.  E.g. for net/core/sock.c
      the story looks so, as far as I've been able to reconstruct it: we used to
      need major.h in net/socket.c circa 1.1.early.  In 1.1.13 that need had
      disappeared, along with register_chrdev(SOCKET_MAJOR, "socket", &net_fops)
      in sock_init().  Include had not.  When 1.2 -> 1.3 reorg of net/* had moved
      a lot of stuff from net/socket.c to net/core/sock.c, this crap had followed...
      Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5523662c
    • A
      [PATCH] kill gratitious includes of major.h under net/* · b453257f
      Al Viro 提交于
      A lot of places in there are including major.h for no reason whatsoever.
      Removed.  And yes, it still builds. 
      
      The history of that stuff is often amusing.  E.g.  for net/core/sock.c
      the story looks so, as far as I've been able to reconstruct it: we used
      to need major.h in net/socket.c circa 1.1.early.  In 1.1.13 that need
      had disappeared, along with register_chrdev(SOCKET_MAJOR, "socket",
      &net_fops) in sock_init().  Include had not.  When 1.2 -> 1.3 reorg of
      net/* had moved a lot of stuff from net/socket.c to net/core/sock.c,
      this crap had followed... 
      Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b453257f
  20. 20 4月, 2005 1 次提交
  21. 17 4月, 2005 2 次提交