1. 06 7月, 2016 14 次提交
    • D
      rxrpc: Use RCU to access a peer's service connection tree · 8496af50
      David Howells 提交于
      Move to using RCU access to a peer's service connection tree when routing
      an incoming packet.  This is done using a seqlock to trigger retrying of
      the tree walk if a change happened.
      
      Further, we no longer get a ref on the connection looked up in the
      data_ready handler unless we queue the connection's work item - and then
      only if the refcount > 0.
      
      
      Note that I'm avoiding the use of a hash table for service connections
      because each service connection is addressed by a 62-bit number
      (constructed from epoch and connection ID >> 2) that would allow the client
      to engage in bucket stuffing, given knowledge of the hash algorithm.
      Peers, however, are hashed as the network address is less controllable by
      the client.  The total number of peers will also be limited in a future
      commit.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      8496af50
    • D
      rxrpc: Move data_ready peer lookup into rxrpc_find_connection() · 1291e9d1
      David Howells 提交于
      Move the peer lookup done in input.c by data_ready into
      rxrpc_find_connection().
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      1291e9d1
    • D
      rxrpc: Prune the contents of the rxrpc_conn_proto struct · e8d70ce1
      David Howells 提交于
      Prune the contents of the rxrpc_conn_proto struct.  Most of the fields aren't
      used anymore.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      e8d70ce1
    • D
      rxrpc: Maintain an extra ref on a conn for the cache list · 001c1122
      David Howells 提交于
      Overhaul the usage count accounting for the rxrpc_connection struct to make
      it easier to implement RCU access from the data_ready handler.
      
      The problem is that currently we're using a lock to prevent the garbage
      collector from trying to clean up a connection that we're contemplating
      unidling.  We could just stick incoming packets on the connection we find,
      but we've then got a problem that we may race when dispatching a work item
      to process it as we need to give that a ref to prevent the rxrpc_connection
      struct from disappearing in the meantime.
      
      Further, incoming packets may get discarded if attached to an
      rxrpc_connection struct that is going away.  Whilst this is not a total
      disaster - the client will presumably resend - it would delay processing of
      the call.  This would affect the AFS client filesystem's service manager
      operation.
      
      To this end:
      
       (1) We now maintain an extra count on the connection usage count whilst it
           is on the connection list.  This mean it is not in use when its
           refcount is 1.
      
       (2) When trying to reuse an old connection, we only increment the refcount
           if it is greater than 0.  If it is 0, we replace it in the tree with a
           new candidate connection.
      
       (3) Two connection flags are added to indicate whether or not a connection
           is in the local's client connection tree (used by sendmsg) or the
           peer's service connection tree (used by data_ready).  This makes sure
           that we don't try and remove a connection if it got replaced.
      
           The flags are tested under lock with the removal operation to prevent
           the reaper from killing the rxrpc_connection struct whilst someone
           else is trying to effect a replacement.
      
           This could probably be alleviated by using memory barriers between the
           flag set/test and the rb_tree ops.  The rb_tree op would still need to
           be under the lock, however.
      
       (4) When trying to reap an old connection, we try to flip the usage count
           from 1 to 0.  If it's not 1 at that point, then it must've come back
           to life temporarily and we ignore it.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      001c1122
    • D
      rxrpc: Move peer lookup from call-accept to new-incoming-conn · d991b4a3
      David Howells 提交于
      Move the lookup of a peer from a call that's being accepted into the
      function that creates a new incoming connection.  This will allow us to
      avoid incrementing the peer's usage count in some cases in future.
      
      Note that I haven't bother to integrate rxrpc_get_addr_from_skb() with
      rxrpc_extract_addr_from_skb() as I'm going to delete the former in the very
      near future.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      d991b4a3
    • D
      rxrpc: Split service connection code out into its own file · 7877a4a4
      David Howells 提交于
      Split the service-specific connection code out into into its own file.  The
      client-specific code has already been split out.  This will leave just the
      common code in the original file.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      7877a4a4
    • D
      rxrpc: Split client connection code out into its own file · c6d2b8d7
      David Howells 提交于
      Split the client-specific connection code out into its own file.  It will
      behave somewhat differently from the service-specific connection code, so
      it makes sense to separate them.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      c6d2b8d7
    • D
      rxrpc: Call channels should have separate call number spaces · a1399f8b
      David Howells 提交于
      Each channel on a connection has a separate, independent number space from
      which to allocate callNumber values.  It is entirely possible, for example,
      to have a connection with four active calls, each with call number 1.
      
      Note that the callNumber values for any particular channel don't have to
      start at 1, but they are supposed to increment monotonically for that
      channel from a client's perspective and may not be reused once the call
      number is transmitted (until the epoch cycles all the way back round).
      
      Currently, however, call numbers are allocated on a per-connection basis
      and, further, are held in an rb-tree.  The rb-tree is redundant as the four
      channel pointers in the rxrpc_connection struct are entirely capable of
      pointing to all the calls currently in progress on a connection.
      
      To this end, make the following changes:
      
       (1) Handle call number allocation independently per channel.
      
       (2) Get rid of the conn->calls rb-tree.  This is overkill as a connection
           may have a maximum of four calls in progress at any one time.  Use the
           pointers in the channels[] array instead, indexed by the channel
           number from the packet.
      
       (3) For each channel, save the result of the last call that was in
           progress on that channel in conn->channels[] so that the final ACK or
           ABORT packet can be replayed if necessary.  Any call earlier than that
           is just ignored.  If we've seen the next call number in a packet, the
           last one is most definitely defunct.
      
       (4) When generating a RESPONSE packet for a connection, the call number
           counter for each channel must be included in it.
      
       (5) When parsing a RESPONSE packet for a connection, the call number
           counters contained therein should be used to set the minimum expected
           call numbers on each channel.
      
      To do in future commits:
      
       (1) Replay terminal packets based on the last call stored in
           conn->channels[].
      
       (2) Connections should be retired before the callNumber space on any
           channel runs out.
      
       (3) A server is expected to disregard or reject any new incoming call that
           has a call number less than the current call number counter.  The call
           number counter for that channel must be advanced to the new call
           number.
      
           Note that the server cannot just require that the next call that it
           sees on a channel be exactly the call number counter + 1 because then
           there's a scenario that could cause a problem: The client transmits a
           packet to initiate a connection, the network goes out, the server
           sends an ACK (which gets lost), the client sends an ABORT (which also
           gets lost); the network then reconnects, the client then reuses the
           call number for the next call (it doesn't know the server already saw
           the call number), but the server thinks it already has the first
           packet of this call (it doesn't know that the client doesn't know that
           it saw the call number the first time).
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      a1399f8b
    • D
      rxrpc: Add RCU destruction for connections and calls · dee46364
      David Howells 提交于
      Add RCU destruction for connections and calls as the RCU lookup from the
      transport socket data_ready handler is going to come along shortly.
      
      Whilst we're at it, move the cleanup workqueue flushing and RCU barrierage
      into the destruction code for the objects that need it (locals and
      connections) and add the extra RCU barrier required for connection cleanup.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      dee46364
    • D
      rxrpc: Move usage count getting into rxrpc_queue_conn() · 2c4579e4
      David Howells 提交于
      Rather than calling rxrpc_get_connection() manually before calling
      rxrpc_queue_conn(), do it inside the queue wrapper.
      
      This allows us to do some important fixes:
      
       (1) If the usage count is 0, do nothing.  This prevents connections from
           being reanimated once they're dead.
      
       (2) If rxrpc_queue_work() fails because the work item is already queued,
           retract the usage count increment which would otherwise be lost.
      
       (3) Don't take a ref on the connection in the work function.  By passing
           the ref through the work item, this is unnecessary.  Doing it in the
           work function is too late anyway.  Previously, connection-directed
           packets held a ref on the connection, but that's not really the best
           idea.
      
      And another useful changes:
      
       (*) Don't need to take a refcount on the connection in the data_ready
           handler unless we invoke the connection's work item.  We're using RCU
           there so that's otherwise redundant.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      2c4579e4
    • D
      rxrpc: Check that the client conns cache is empty before module removal · eb9b9d22
      David Howells 提交于
      Check that the client conns cache is empty before module removal and bug if
      not, listing any offending connections that are still present.  Unfortunately,
      if there are connections still around, then the transport socket is still
      unexpectedly open and active, so we can't just unallocate the connections.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      eb9b9d22
    • D
      rxrpc: Turn connection #defines into enums and put outside struct def · bba304db
      David Howells 提交于
      Turn the connection event and state #define lists into enums and move
      outside of the struct definition.
      
      Whilst we're at it, change _SERVER to _SERVICE in those identifiers and add
      EV_ into the event name to distinguish them from flags and states.
      
      Also add a symbol indicating the number of states and use that in the state
      text array.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      bba304db
    • D
      rxrpc: Provide queuing helper functions · 5acbee46
      David Howells 提交于
      Provide queueing helper functions so that the queueing of local and
      connection objects can be fixed later.
      
      The issue is that a ref on the object needs to be passed to the work queue,
      but the act of queueing the object may fail because the object is already
      queued.  Testing the queuedness of an object before hand doesn't work
      because there can be a race with someone else trying to queue it.  What
      will have to be done is to adjust the refcount depending on the result of
      the queue operation.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      5acbee46
    • H
      rxrpc: Avoid using stack memory in SG lists in rxkad · a263629d
      Herbert Xu 提交于
      rxkad uses stack memory in SG lists which would not work if stacks were
      allocated from vmalloc memory.  In fact, in most cases this isn't even
      necessary as the stack memory ends up getting copied over to kmalloc
      memory.
      
      This patch eliminates all the unnecessary stack memory uses by supplying
      the final destination directly to the crypto API.  In two instances where a
      temporary buffer is actually needed we also switch use a scratch area in
      the rxrpc_call struct (only one DATA packet will be being secured or
      verified at a time).
      
      Finally there is no need to split a split-page buffer into two SG entries
      so code dealing with that has been removed.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      a263629d
  2. 22 6月, 2016 8 次提交
    • D
      rxrpc: Kill off the rxrpc_transport struct · aa390bbe
      David Howells 提交于
      The rxrpc_transport struct is now redundant, given that the rxrpc_peer
      struct is now per peer port rather than per peer host, so get rid of it.
      
      Service connection lists are transferred to the rxrpc_peer struct, as is
      the conn_lock.  Previous patches moved the client connection handling out
      of the rxrpc_transport struct and discarded the connection bundling code.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      aa390bbe
    • D
      rxrpc: Kill the client connection bundle concept · 999b69f8
      David Howells 提交于
      Kill off the concept of maintaining a bundle of connections to a particular
      target service to increase the number of call slots available for any
      beyond four for that service (there are four call slots per connection).
      
      This will make cleaning up the connection handling code easier and
      facilitate removal of the rxrpc_transport struct.  Bundling can be
      reintroduced later if necessary.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      999b69f8
    • D
      rxrpc: Provide more refcount helper functions · 5627cc8b
      David Howells 提交于
      Provide refcount helper functions for connections so that the code doesn't
      touch local or connection usage counts directly.
      
      Also make it such that local and peer put functions can take a NULL
      pointer.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      5627cc8b
    • D
      rxrpc: Make rxrpc_send_packet() take a connection not a transport · 985a5c82
      David Howells 提交于
      Make rxrpc_send_packet() take a connection not a transport as part of the
      phasing out of the rxrpc_transport struct.
      
      Whilst we're at it, rename the function to rxrpc_send_data_packet() to
      differentiate it from the other packet sending functions.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      985a5c82
    • D
      rxrpc: Use IDR to allocate client conn IDs on a machine-wide basis · 4a3388c8
      David Howells 提交于
      Use the IDR facility to allocate client connection IDs on a machine-wide
      basis so that each client connection has a unique identifier.  When the
      connection ID space wraps, we advance the epoch by 1, thereby effectively
      having a 62-bit ID space.  The IDR facility is then used to look up client
      connections during incoming packet routing instead of using an rbtree
      rooted on the transport.
      
      This change allows for the removal of the transport in the future and also
      means that client connections can be looked up directly in the data-ready
      handler by connection ID.
      
      The ID management code is placed in a new file, conn-client.c, to which all
      the client connection-specific code will eventually move.
      
      Note that the IDR tree gets very expensive on memory if the connection IDs
      are widely scattered throughout the number space, so we shall need to
      retire connections that have, say, an ID more than four times the maximum
      number of client conns away from the current allocation point to try and
      keep the IDs concentrated.  We will also need to retire connections from an
      old epoch.
      
      Also note that, for the moment, a pointer to the transport has to be passed
      through into the ID allocation function so that we can take a BH lock to
      prevent a locking issue against in-BH lookup of client connections.  This
      will go away later when RCU is used for server connections also.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      4a3388c8
    • D
      rxrpc: Pass sk_buff * rather than rxrpc_host_header * to functions · 42886ffe
      David Howells 提交于
      Pass a pointer to struct sk_buff rather than struct rxrpc_host_header to
      functions so that they can in the future get at transport protocol parameters
      rather than just RxRPC parameters.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      42886ffe
    • D
      rxrpc: Fix exclusive connection handling · cc8feb8e
      David Howells 提交于
      "Exclusive connections" are meant to be used for a single client call and
      then scrapped.  The idea is to limit the use of the negotiated security
      context.  The current code, however, isn't doing this: it is instead
      restricting the socket to a single virtual connection and doing all the
      calls over that.
      
      This is changed such that the socket no longer maintains a special virtual
      connection over which it will do all the calls, but rather gets a new one
      each time a new exclusive call is made.
      
      Further, using a socket option for this is a poor choice.  It should be
      done on sendmsg with a control message marker instead so that calls can be
      marked exclusive individually.  To that end, add RXRPC_EXCLUSIVE_CALL
      which, if passed to sendmsg() as a control message element, will cause the
      call to be done on an single-use connection.
      
      The socket option (RXRPC_EXCLUSIVE_CONNECTION) still exists and, if set,
      will override any lack of RXRPC_EXCLUSIVE_CALL being specified so that
      programs using the setsockopt() will appear to work the same.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc8feb8e
    • D
      rxrpc: Use structs to hold connection params and protocol info · 19ffa01c
      David Howells 提交于
      Define and use a structure to hold connection parameters.  This makes it
      easier to pass multiple connection parameters around.
      
      Define and use a structure to hold protocol information used to hash a
      connection for lookup on incoming packet.  Most of these fields will be
      disposed of eventually, including the duplicate local pointer.
      
      Whilst we're at it rename "proto" to "family" when referring to a protocol
      family.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      19ffa01c
  3. 15 6月, 2016 5 次提交
    • D
      rxrpc: Rework local endpoint management · 4f95dd78
      David Howells 提交于
      Rework the local RxRPC endpoint management.
      
      Local endpoint objects are maintained in a flat list as before.  This
      should be okay as there shouldn't be more than one per open AF_RXRPC socket
      (there can be fewer as local endpoints can be shared if their local service
      ID is 0 and they share the same local transport parameters).
      
      Changes:
      
       (1) Local endpoints may now only be shared if they have local service ID 0
           (ie. they're not being used for listening).
      
           This prevents a scenario where process A is listening of the Cache
           Manager port and process B contacts a fileserver - which may then
           attempt to send CM requests back to B.  But if A and B are sharing a
           local endpoint, A will get the CM requests meant for B.
      
       (2) We use a mutex to handle lookups and don't provide RCU-only lookups
           since we only expect to access the list when opening a socket or
           destroying an endpoint.
      
           The local endpoint object is pointed to by the transport socket's
           sk_user_data for the life of the transport socket - allowing us to
           refer to it directly from the sk_data_ready and sk_error_report
           callbacks.
      
       (3) atomic_inc_not_zero() now exists and can be used to only share a local
           endpoint if the last reference hasn't yet gone.
      
       (4) We can remove rxrpc_local_lock - a spinlock that had to be taken with
           BH processing disabled given that we assume sk_user_data won't change
           under us.
      
       (5) The transport socket is shut down before we clear the sk_user_data
           pointer so that we can be sure that the transport socket's callbacks
           won't be invoked once the RCU destruction is scheduled.
      
       (6) Local endpoints have a work item that handles both destruction and
           event processing.  The means that destruction doesn't then need to
           wait for event processing.  The event queues can then be cleared after
           the transport socket is shut down.
      
       (7) Local endpoints are no longer available for resurrection beyond the
           life of the sockets that had them open.  As soon as their last ref
           goes, they are scheduled for destruction and may not have their usage
           count moved from 0.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      4f95dd78
    • D
      rxrpc: Separate local endpoint event handling out into its own file · 87563616
      David Howells 提交于
      Separate local endpoint event handling out into its own file preparatory to
      overhauling the object management aspect (which remains in the original
      file).
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      87563616
    • D
      rxrpc: Use the peer record to distribute network errors · f66d7490
      David Howells 提交于
      Use the peer record to distribute network errors rather than the transport
      object (which I want to get rid of).  An error from a particular peer
      terminates all calls on that peer.
      
      For future consideration:
      
       (1) For ICMP-induced errors it might be worth trying to extract the RxRPC
           header from the offending packet, if one is returned attached to the
           ICMP packet, to better direct the error.
      
           This may be overkill, though, since an ICMP packet would be expected
           to be relating to the destination port, machine or network.  RxRPC
           ABORT and BUSY packets give notice at RxRPC level.
      
       (2) To also abort connection-level communications (such as CHALLENGE
           packets) where indicted by an error - but that requires some revamping
           of the connection event handling first.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      f66d7490
    • D
      rxrpc: Rename rxrpc_UDP_error_report() to rxrpc_error_report() · abe89ef0
      David Howells 提交于
      Rename rxrpc_UDP_error_report() to rxrpc_error_report() as it might get
      called for something other than UDP.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      abe89ef0
    • D
      rxrpc: Rework peer object handling to use hash table and RCU · be6e6707
      David Howells 提交于
      Rework peer object handling to use a hash table instead of a flat list and
      to use RCU.  Peer objects are no longer destroyed by passing them to a
      workqueue to process, but rather are just passed to the RCU garbage
      collector as kfree'able objects.
      
      The hash function uses the local endpoint plus all the components of the
      remote address, except for the RxRPC service ID.  Peers thus represent a
      UDP port on the remote machine as contacted by a UDP port on this machine.
      
      The RCU read lock is used to handle non-creating lookups so that they can
      be called from bottom half context in the sk_error_report handler without
      having to lock the hash table against modification.
      rxrpc_lookup_peer_rcu() *does* take a reference on the peer object as in
      the future, this will be passed to a work item for error distribution in
      the error_report path and this function will cease being used in the
      data_ready path.
      
      Creating lookups are done under spinlock rather than mutex as they might be
      set up due to an external stimulus if the local endpoint is a server.
      
      Captured network error messages (ICMP) are handled with respect to this
      struct and MTU size and RTT are cached here.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      be6e6707
  4. 13 6月, 2016 1 次提交
  5. 11 6月, 2016 1 次提交
    • D
      rxrpc: Limit the listening backlog · 0e119b41
      David Howells 提交于
      Limit the socket incoming call backlog queue size so that a remote client
      can't pump in sufficient new calls that the server runs out of memory.  Note
      that this is partially theoretical at the moment since whilst the number of
      calls is limited, the number of packets trying to set up new calls is not.
      This will be addressed in a later patch.
      
      If the caller of listen() specifies a backlog INT_MAX, then they get the
      current maximum; anything else greater than max_backlog or anything
      negative incurs EINVAL.
      
      The limit on the maximum queue size can be set by:
      
      	echo N >/proc/sys/net/rxrpc/max_backlog
      
      where 4<=N<=32.
      
      Further, set the default backlog to 0, requiring listen() to be called
      before we start actually queueing new calls.  Whilst this kind of is a
      change in the UAPI, the caller can't actually *accept* new calls anyway
      unless they've first called listen() to put the socket into the LISTENING
      state - thus the aforementioned new calls would otherwise just sit there,
      eating up kernel memory.  (Note that sockets that don't have a non-zero
      service ID bound don't get incoming calls anyway.)
      
      Given that the default backlog is now 0, make the AFS filesystem call
      kernel_listen() to set the maximum backlog for itself.
      
      Possible improvements include:
      
       (1) Trimming a too-large backlog to max_backlog when listen is called.
      
       (2) Trimming the backlog value whenever the value is used so that changes
           to max_backlog are applied to an open socket automatically.  Note that
           the AFS filesystem opens one socket and keeps it open for extended
           periods, so would miss out on changes to max_backlog.
      
       (3) Having a separate setting for the AFS filesystem.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0e119b41
  6. 10 6月, 2016 1 次提交
    • D
      rxrpc: Simplify connect() implementation and simplify sendmsg() op · 2341e077
      David Howells 提交于
      Simplify the RxRPC connect() implementation.  It will just note the
      destination address it is given, and if a sendmsg() comes along with no
      address, this will be assigned as the address.  No transport struct will be
      held internally, which will allow us to remove this later.
      
      Simplify sendmsg() also.  Whilst a call is active, userspace refers to it
      by a private unique user ID specified in a control message.  When sendmsg()
      sees a user ID that doesn't map to an extant call, it creates a new call
      for that user ID and attempts to add it.  If, when we try to add it, the
      user ID is now registered, we now reject the message with -EEXIST.  We
      should never see this situation unless two threads are racing, trying to
      create a call with the same ID - which would be an error.
      
      It also isn't required to provide sendmsg() with an address - provided the
      control message data holds a user ID that maps to a currently active call.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2341e077
  7. 04 6月, 2016 1 次提交
    • J
      rxrpc: Use pr_<level> and pr_fmt, reduce object size a few KB · 9b6d5398
      Joe Perches 提交于
      Use the more common kernel logging style and reduce object size.
      
      The logging message prefix changes from a mixture of
      "RxRPC:" and "RXRPC:" to "af_rxrpc: ".
      
      $ size net/rxrpc/built-in.o*
         text	   data	    bss	    dec	    hex	filename
        64172	   1972	   8304	  74448	  122d0	net/rxrpc/built-in.o.new
        67512	   1972	   8304	  77788	  12fdc	net/rxrpc/built-in.o.old
      
      Miscellanea:
      
      o Consolidate the ASSERT macros to use a single pr_err call with
        decimal and hexadecimal output and a stringified #OP argument
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9b6d5398
  8. 12 4月, 2016 6 次提交
  9. 14 3月, 2016 1 次提交
  10. 04 3月, 2016 2 次提交
    • D
      rxrpc: Adjust some whitespace and comments · b4f1342f
      David Howells 提交于
      Remove some excess whitespace, insert some missing spaces and adjust a
      couple of comments.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      b4f1342f
    • D
      rxrpc: Keep the skb private record of the Rx header in host byte order · 0d12f8a4
      David Howells 提交于
      Currently, a copy of the Rx packet header is copied into the the sk_buff
      private data so that we can advance the pointer into the buffer,
      potentially discarding the original.  At the moment, this copy is held in
      network byte order, but this means we're doing a lot of unnecessary
      translations.
      
      The reasons it was done this way are that we need the values in network
      byte order occasionally and we can use the copy, slightly modified, as part
      of an iov array when sending an ack or an abort packet.
      
      However, it seems more reasonable on review that it would be better kept in
      host byte order and that we make up a new header when we want to send
      another packet.
      
      To this end, rename the original header struct to rxrpc_wire_header (with
      BE fields) and institute a variant called rxrpc_host_header that has host
      order fields.  Change the struct in the sk_buff private data into an
      rxrpc_host_header and translate the values when filling it in.
      
      This further allows us to keep values kept in various structures in host
      byte order rather than network byte order and allows removal of some fields
      that are byteswapped duplicates.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      0d12f8a4