1. 07 9月, 2016 8 次提交
    • D
      rxrpc: Calls shouldn't hold socket refs · 8d94aa38
      David Howells 提交于
      rxrpc calls shouldn't hold refs on the sock struct.  This was done so that
      the socket wouldn't go away whilst the call was in progress, such that the
      call could reach the socket's queues.
      
      However, we can mark the socket as requiring an RCU release and rely on the
      RCU read lock.
      
      To make this work, we do:
      
       (1) rxrpc_release_call() removes the call's call user ID.  This is now
           only called from socket operations and not from the call processor:
      
      	rxrpc_accept_call() / rxrpc_kernel_accept_call()
      	rxrpc_reject_call() / rxrpc_kernel_reject_call()
      	rxrpc_kernel_end_call()
      	rxrpc_release_calls_on_socket()
      	rxrpc_recvmsg()
      
           Though it is also called in the cleanup path of
           rxrpc_accept_incoming_call() before we assign a user ID.
      
       (2) Pass the socket pointer into rxrpc_release_call() rather than getting
           it from the call so that we can get rid of uninitialised calls.
      
       (3) Fix call processor queueing to pass a ref to the work queue and to
           release that ref at the end of the processor function (or to pass it
           back to the work queue if we have to requeue).
      
       (4) Skip out of the call processor function asap if the call is complete
           and don't requeue it if the call is complete.
      
       (5) Clean up the call immediately that the refcount reaches 0 rather than
           trying to defer it.  Actual deallocation is deferred to RCU, however.
      
       (6) Don't hold socket refs for allocated calls.
      
       (7) Use the RCU read lock when queueing a message on a socket and treat
           the call's socket pointer according to RCU rules and check it for
           NULL.
      
           We also need to use the RCU read lock when viewing a call through
           procfs.
      
       (8) Transmit the final ACK/ABORT to a client call in rxrpc_release_call()
           if this hasn't been done yet so that we can then disconnect the call.
           Once the call is disconnected, it won't have any access to the
           connection struct and the UDP socket for the call work processor to be
           able to send the ACK.  Terminal retransmission will be handled by the
           connection processor.
      
       (9) Release all calls immediately on the closing of a socket rather than
           trying to defer this.  Incomplete calls will be aborted.
      
      The call refcount model is much simplified.  Refs are held on the call by:
      
       (1) A socket's user ID tree.
      
       (2) A socket's incoming call secureq and acceptq.
      
       (3) A kernel service that has a call in progress.
      
       (4) A queued call work processor.  We have to take care to put any call
           that we failed to queue.
      
       (5) sk_buffs on a socket's receive queue.  A future patch will get rid of
           this.
      
      Whilst we're at it, we can do:
      
       (1) Get rid of the RXRPC_CALL_EV_RELEASE event.  Release is now done
           entirely from the socket routines and never from the call's processor.
      
       (2) Get rid of the RXRPC_CALL_DEAD state.  Calls now end in the
           RXRPC_CALL_COMPLETE state.
      
       (3) Get rid of the rxrpc_call::destroyer work item.  Calls are now torn
           down when their refcount reaches 0 and then handed over to RCU for
           final cleanup.
      
       (4) Get rid of the rxrpc_call::deadspan timer.  Calls are cleaned up
           immediately they're finished with and don't hang around.
           Post-completion retransmission is handled by the connection processor
           once the call is disconnected.
      
       (5) Get rid of the dead call expiry setting as there's no longer a timer
           to set.
      
       (6) rxrpc_destroy_all_calls() can just check that the call list is empty.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      8d94aa38
    • D
      rxrpc: Use rxrpc_is_service_call() rather than rxrpc_conn_is_service() · 6543ac52
      David Howells 提交于
      Use rxrpc_is_service_call() rather than rxrpc_conn_is_service() if the call
      is available just in case call->conn is NULL.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      6543ac52
    • D
      rxrpc: Pass the connection pointer to rxrpc_post_packet_to_call() · 8b7fac50
      David Howells 提交于
      Pass the connection pointer to rxrpc_post_packet_to_call() as the call
      might get disconnected whilst we're looking at it, but the connection
      pointer determined by rxrpc_data_read() is guaranteed by RCU for the
      duration of the call.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      8b7fac50
    • D
      rxrpc: Cache the security index in the rxrpc_call struct · 278ac0cd
      David Howells 提交于
      Cache the security index in the rxrpc_call struct so that we can get at it
      even when the call has been disconnected and the connection pointer
      cleared.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      278ac0cd
    • D
      rxrpc: Use call->peer rather than call->conn->params.peer · f4fdb352
      David Howells 提交于
      Use call->peer rather than call->conn->params.peer to avoid the possibility
      of call->conn being NULL and, whilst we're at it, check it for NULL before we
      access it.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      f4fdb352
    • D
      rxrpc: Improve the call tracking tracepoint · fff72429
      David Howells 提交于
      Improve the call tracking tracepoint by showing more differentiation
      between some of the put and get events, including:
      
        (1) Getting and putting refs for the socket call user ID tree.
      
        (2) Getting and putting refs for queueing and failing to queue the call
            processor work item.
      
      Note that these aren't necessarily used in this patch, but will be taken
      advantage of in future patches.
      
      An enum is added for the event subtype numbers rather than coding them
      directly as decimal numbers and a table of 3-letter strings is provided
      rather than a sequence of ?: operators.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      fff72429
    • D
      rxrpc: Delete unused rxrpc_kernel_free_skb() · e796cb41
      David Howells 提交于
      Delete rxrpc_kernel_free_skb() as it's unused.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      e796cb41
    • D
      rxrpc: Whitespace cleanup · 71a17de3
      David Howells 提交于
      Remove some whitespace.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      71a17de3
  2. 05 9月, 2016 5 次提交
  3. 04 9月, 2016 1 次提交
  4. 03 9月, 2016 2 次提交
  5. 02 9月, 2016 1 次提交
    • D
      rxrpc: Don't expose skbs to in-kernel users [ver #2] · d001648e
      David Howells 提交于
      Don't expose skbs to in-kernel users, such as the AFS filesystem, but
      instead provide a notification hook the indicates that a call needs
      attention and another that indicates that there's a new call to be
      collected.
      
      This makes the following possibilities more achievable:
      
       (1) Call refcounting can be made simpler if skbs don't hold refs to calls.
      
       (2) skbs referring to non-data events will be able to be freed much sooner
           rather than being queued for AFS to pick up as rxrpc_kernel_recv_data
           will be able to consult the call state.
      
       (3) We can shortcut the receive phase when a call is remotely aborted
           because we don't have to go through all the packets to get to the one
           cancelling the operation.
      
       (4) It makes it easier to do encryption/decryption directly between AFS's
           buffers and sk_buffs.
      
       (5) Encryption/decryption can more easily be done in the AFS's thread
           contexts - usually that of the userspace process that issued a syscall
           - rather than in one of rxrpc's background threads on a workqueue.
      
       (6) AFS will be able to wait synchronously on a call inside AF_RXRPC.
      
      To make this work, the following interface function has been added:
      
           int rxrpc_kernel_recv_data(
      		struct socket *sock, struct rxrpc_call *call,
      		void *buffer, size_t bufsize, size_t *_offset,
      		bool want_more, u32 *_abort_code);
      
      This is the recvmsg equivalent.  It allows the caller to find out about the
      state of a specific call and to transfer received data into a buffer
      piecemeal.
      
      afs_extract_data() and rxrpc_kernel_recv_data() now do all the extraction
      logic between them.  They don't wait synchronously yet because the socket
      lock needs to be dealt with.
      
      Five interface functions have been removed:
      
      	rxrpc_kernel_is_data_last()
          	rxrpc_kernel_get_abort_code()
          	rxrpc_kernel_get_error_number()
          	rxrpc_kernel_free_skb()
          	rxrpc_kernel_data_consumed()
      
      As a temporary hack, sk_buffs going to an in-kernel call are queued on the
      rxrpc_call struct (->knlrecv_queue) rather than being handed over to the
      in-kernel user.  To process the queue internally, a temporary function,
      temp_deliver_data() has been added.  This will be replaced with common code
      between the rxrpc_recvmsg() path and the kernel_rxrpc_recv_data() path in a
      future patch.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d001648e
  6. 30 8月, 2016 6 次提交
  7. 24 8月, 2016 4 次提交
    • D
      rxrpc: Improve management and caching of client connection objects · 45025bce
      David Howells 提交于
      Improve the management and caching of client rxrpc connection objects.
      From this point, client connections will be managed separately from service
      connections because AF_RXRPC controls the creation and re-use of client
      connections but doesn't have that luxury with service connections.
      
      Further, there will be limits on the numbers of client connections that may
      be live on a machine.  No direct restriction will be placed on the number
      of client calls, excepting that each client connection can support a
      maximum of four concurrent calls.
      
      Note that, for a number of reasons, we don't want to simply discard a
      client connection as soon as the last call is apparently finished:
      
       (1) Security is negotiated per-connection and the context is then shared
           between all calls on that connection.  The context can be negotiated
           again if the connection lapses, but that involves holding up calls
           whilst at least two packets are exchanged and various crypto bits are
           performed - so we'd ideally like to cache it for a little while at
           least.
      
       (2) If a packet goes astray, we will need to retransmit a final ACK or
           ABORT packet.  To make this work, we need to keep around the
           connection details for a little while.
      
       (3) The locally held structures represent some amount of setup time, to be
           weighed against their occupation of memory when idle.
      
      
      To this end, the client connection cache is managed by a state machine on
      each connection.  There are five states:
      
       (1) INACTIVE - The connection is not held in any list and may not have
           been exposed to the world.  If it has been previously exposed, it was
           discarded from the idle list after expiring.
      
       (2) WAITING - The connection is waiting for the number of client conns to
           drop below the maximum capacity.  Calls may be in progress upon it
           from when it was active and got culled.
      
           The connection is on the rxrpc_waiting_client_conns list which is kept
           in to-be-granted order.  Culled conns with waiters go to the back of
           the queue just like new conns.
      
       (3) ACTIVE - The connection has at least one call in progress upon it, it
           may freely grant available channels to new calls and calls may be
           waiting on it for channels to become available.
      
           The connection is on the rxrpc_active_client_conns list which is kept
           in activation order for culling purposes.
      
       (4) CULLED - The connection got summarily culled to try and free up
           capacity.  Calls currently in progress on the connection are allowed
           to continue, but new calls will have to wait.  There can be no waiters
           in this state - the conn would have to go to the WAITING state
           instead.
      
       (5) IDLE - The connection has no calls in progress upon it and must have
           been exposed to the world (ie. the EXPOSED flag must be set).  When it
           expires, the EXPOSED flag is cleared and the connection transitions to
           the INACTIVE state.
      
           The connection is on the rxrpc_idle_client_conns list which is kept in
           order of how soon they'll expire.
      
      A connection in the ACTIVE or CULLED state must have at least one active
      call upon it; if in the WAITING state it may have active calls upon it;
      other states may not have active calls.
      
      As long as a connection remains active and doesn't get culled, it may
      continue to process calls - even if there are connections on the wait
      queue.  This simplifies things a bit and reduces the amount of checking we
      need do.
      
      
      There are a couple flags of relevance to the cache:
      
       (1) EXPOSED - The connection ID got exposed to the world.  If this flag is
           set, an extra ref is added to the connection preventing it from being
           reaped when it has no calls outstanding.  This flag is cleared and the
           ref dropped when a conn is discarded from the idle list.
      
       (2) DONT_REUSE - The connection should be discarded as soon as possible and
           should not be reused.
      
      
      This commit also provides a number of new settings:
      
       (*) /proc/net/rxrpc/max_client_conns
      
           The maximum number of live client connections.  Above this number, new
           connections get added to the wait list and must wait for an active
           conn to be culled.  Culled connections can be reused, but they will go
           to the back of the wait list and have to wait.
      
       (*) /proc/net/rxrpc/reap_client_conns
      
           If the number of desired connections exceeds the maximum above, the
           active connection list will be culled until there are only this many
           left in it.
      
       (*) /proc/net/rxrpc/idle_conn_expiry
      
           The normal expiry time for a client connection, provided there are
           fewer than reap_client_conns of them around.
      
       (*) /proc/net/rxrpc/idle_conn_fast_expiry
      
           The expedited expiry time, used when there are more than
           reap_client_conns of them around.
      
      
      Note that I combined the Tx wait queue with the channel grant wait queue to
      save space as only one of these should be in use at once.
      
      Note also that, for the moment, the service connection cache still uses the
      old connection management code.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      45025bce
    • D
      rxrpc: Dup the main conn list for the proc interface · 4d028b2c
      David Howells 提交于
      The main connection list is used for two independent purposes: primarily it
      is used to find connections to reap and secondarily it is used to list
      connections in procfs.
      
      Split the procfs list out from the reap list.  This allows us to stop using
      the reap list for client connections when they acquire a separate
      management strategy from service collections.
      
      The client connections will not be on a management single list, and sometimes
      won't be on a management list at all.  This doesn't leave them floating,
      however, as they will also be on an rb-tree rooted on the socket so that the
      socket can find them to dispatch calls.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      4d028b2c
    • D
      rxrpc: Make /proc/net/rxrpc_calls safer · df5d8bf7
      David Howells 提交于
      Make /proc/net/rxrpc_calls safer by stashing a copy of the peer pointer in
      the rxrpc_call struct and checking in the show routine that the peer
      pointer, the socket pointer and the local pointer obtained from the socket
      pointer aren't NULL before we use them.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      df5d8bf7
    • D
      rxrpc: Fix conn-based retransmit · 2266ffde
      David Howells 提交于
      If a duplicate packet comes in for a call that has just completed on a
      connection's channel then there will be an oops in the data_ready handler
      because it tries to examine the connection struct via a call struct (which
      we don't have - the pointer is unset).
      
      Since the connection struct pointer is available to us, go direct instead.
      
      Also, the ACK packet to be retransmitted needs three octets of padding
      between the soft ack list and the ackinfo.
      
      Fixes: 18bfeba5 ("rxrpc: Perform terminal call ACK/ABORT retransmission from conn processor")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      2266ffde
  8. 23 8月, 2016 8 次提交
    • D
      rxrpc: Perform terminal call ACK/ABORT retransmission from conn processor · 18bfeba5
      David Howells 提交于
      Perform terminal call ACK/ABORT retransmission in the connection processor
      rather than in the call processor.  With this change, once last_call is
      set, no more incoming packets will be routed to the corresponding call or
      any earlier calls on that channel (call IDs must only increase on a channel
      on a connection).
      
      Further, if a packet's callNumber is before the last_call ID or a packet is
      aimed at successfully completed service call then that packet is discarded
      and ignored.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      18bfeba5
    • D
      rxrpc: Calculate serial skew on packet reception · 563ea7d5
      David Howells 提交于
      Calculate the serial number skew in the data_ready handler when a packet
      has been received and a connection looked up.  The skew is cached in the
      sk_buff's priority field.
      
      The connection highest received serial number is updated at this time also.
      This can be done without locks or atomic instructions because, at this
      point, the code is serialised by the socket.
      
      This generates more accurate skew data because if the packet is offloaded
      to a work queue before this is determined, more packets may come in,
      bumping the highest serial number and thereby increasing the apparent skew.
      
      This also removes some unnecessary atomic ops.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      563ea7d5
    • D
      rxrpc: Set connection expiry on idle, not put · f51b4480
      David Howells 提交于
      Set the connection expiry time when a connection becomes idle rather than
      doing this in rxrpc_put_connection().  This makes the put path more
      efficient (it is likely to be called occasionally whilst a connection has
      outstanding calls because active workqueue items needs to be given a ref).
      
      The time is also preset in the connection allocator in case the connection
      never gets used.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      f51b4480
    • D
      rxrpc: Use a tracepoint for skb accounting debugging · df844fd4
      David Howells 提交于
      Use a tracepoint to log various skb accounting points to help in debugging
      refcounting errors.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      df844fd4
    • D
      rxrpc: Drop channel number field from rxrpc_call struct · 01a90a45
      David Howells 提交于
      Drop the channel number (channel) field from the rxrpc_call struct to
      reduce the size of the call struct.  The field is redundant: if the call is
      attached to a connection, the channel can be obtained from there by AND'ing
      with RXRPC_CHANNELMASK.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      01a90a45
    • D
      rxrpc: When clearing a socket, clear the call sets in the right order · f36b5e44
      David Howells 提交于
      When clearing a socket, we should clear the securing-in-progress list
      first, then the accept queue and last the main call tree because that's the
      order in which a call progresses.  Not that a call should move from the
      accept queue to the main tree whilst we're shutting down a socket, but it a
      call could possibly move from sequreq to acceptq whilst we're clearing up.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      f36b5e44
    • D
      rxrpc: Tidy up the rxrpc_call struct a bit · dabe5a79
      David Howells 提交于
      Do a little tidying of the rxrpc_call struct:
      
       (1) in_clientflag is no longer compared against the value that's in the
           packet, so keeping it in this form isn't necessary.  Use a flag in
           flags instead and provide a pair of wrapper functions.
      
       (2) We don't read the epoch value, so that can go.
      
       (3) Move what remains of the data that were used for hashing up in the
           struct to be with the channel number.
      
       (4) Get rid of the local pointer.  We can get at this via the socket
           struct and we only use this in the procfs viewer.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      dabe5a79
    • D
      rxrpc: Remove RXRPC_CALL_PROC_BUSY · 26164e77
      David Howells 提交于
      Remove RXRPC_CALL_PROC_BUSY as work queue items are now 100% non-reentrant.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      26164e77
  9. 10 8月, 2016 5 次提交
    • D
      rxrpc: Free packets discarded in data_ready · 992c273a
      David Howells 提交于
      Under certain conditions, the data_ready handler will discard a packet.
      These need to be freed.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      992c273a
    • D
      rxrpc: Fix a use-after-push in data_ready handler · 50fd85a1
      David Howells 提交于
      Fix a use of a packet after it has been enqueued onto the packet processing
      queue in the data_ready handler.  Once on a call's Rx queue, we mustn't
      touch it any more as it may be dequeued and freed by the call processor
      running on a work queue.
      
      Save the values we need before enqueuing.
      
      Without this, we can get an oops like the following:
      
      BUG: unable to handle kernel NULL pointer dereference at 000000000000009c
      IP: [<ffffffffa01854e8>] rxrpc_fast_process_packet+0x724/0xa11 [af_rxrpc]
      PGD 0 
      Oops: 0000 [#1] SMP
      Modules linked in: kafs(E) af_rxrpc(E) [last unloaded: af_rxrpc]
      CPU: 2 PID: 0 Comm: swapper/2 Tainted: G            E   4.7.0-fsdevel+ #1336
      Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
      task: ffff88040d6863c0 task.stack: ffff88040d68c000
      RIP: 0010:[<ffffffffa01854e8>]  [<ffffffffa01854e8>] rxrpc_fast_process_packet+0x724/0xa11 [af_rxrpc]
      RSP: 0018:ffff88041fb03a78  EFLAGS: 00010246
      RAX: ffffffffffffffff RBX: ffff8803ff195b00 RCX: 0000000000000001
      RDX: ffffffffa01854d1 RSI: 0000000000000008 RDI: ffff8803ff195b00
      RBP: ffff88041fb03ab0 R08: 0000000000000000 R09: 0000000000000001
      R10: ffff88041fb038c8 R11: 0000000000000000 R12: ffff880406874800
      R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff88041fb00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000000000000009c CR3: 0000000001c14000 CR4: 00000000001406e0
      Stack:
       ffff8803ff195ea0 ffff880408348800 ffff880406874800 ffff8803ff195b00
       ffff880408348800 ffff8803ff195ed8 0000000000000000 ffff88041fb03af0
       ffffffffa0186072 0000000000000000 ffff8804054da000 0000000000000000
      Call Trace:
       <IRQ> 
       [<ffffffffa0186072>] rxrpc_data_ready+0x89d/0xbae [af_rxrpc]
       [<ffffffff814c94d7>] __sock_queue_rcv_skb+0x24c/0x2b2
       [<ffffffff8155c59a>] __udp_queue_rcv_skb+0x4b/0x1bd
       [<ffffffff8155e048>] udp_queue_rcv_skb+0x281/0x4db
       [<ffffffff8155ea8f>] __udp4_lib_rcv+0x7ed/0x963
       [<ffffffff8155ef9a>] udp_rcv+0x15/0x17
       [<ffffffff81531d86>] ip_local_deliver_finish+0x1c3/0x318
       [<ffffffff81532544>] ip_local_deliver+0xbb/0xc4
       [<ffffffff81531bc3>] ? inet_del_offload+0x40/0x40
       [<ffffffff815322a9>] ip_rcv_finish+0x3ce/0x42c
       [<ffffffff81532851>] ip_rcv+0x304/0x33d
       [<ffffffff81531edb>] ? ip_local_deliver_finish+0x318/0x318
       [<ffffffff814dff9d>] __netif_receive_skb_core+0x601/0x6e8
       [<ffffffff814e072e>] __netif_receive_skb+0x13/0x54
       [<ffffffff814e082a>] netif_receive_skb_internal+0xbb/0x17c
       [<ffffffff814e1838>] napi_gro_receive+0xf9/0x1bd
       [<ffffffff8144eb9f>] rtl8169_poll+0x32b/0x4a8
       [<ffffffff814e1c7b>] net_rx_action+0xe8/0x357
       [<ffffffff81051074>] __do_softirq+0x1aa/0x414
       [<ffffffff810514ab>] irq_exit+0x3d/0xb0
       [<ffffffff810184a2>] do_IRQ+0xe4/0xfc
       [<ffffffff81612053>] common_interrupt+0x93/0x93
       <EOI> 
       [<ffffffff814af837>] ? cpuidle_enter_state+0x1ad/0x2be
       [<ffffffff814af832>] ? cpuidle_enter_state+0x1a8/0x2be
       [<ffffffff814af96a>] cpuidle_enter+0x12/0x14
       [<ffffffff8108956f>] call_cpuidle+0x39/0x3b
       [<ffffffff81089855>] cpu_startup_entry+0x230/0x35d
       [<ffffffff810312ea>] start_secondary+0xf4/0xf7
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      50fd85a1
    • D
      rxrpc: Once packet posted in data_ready, don't retry posting · 2e7e9758
      David Howells 提交于
      Once a packet has been posted to a connection in the data_ready handler, we
      mustn't try reposting if we then find that the connection is dying as the
      refcount has been given over to the dying connection and the packet might
      no longer exist.
      
      Losing the packet isn't a problem as the peer will retransmit.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      2e7e9758
    • D
      rxrpc: Don't access connection from call if pointer is NULL · f9dc5757
      David Howells 提交于
      The call state machine processor sets up the message parameters for a UDP
      message that it might need to transmit in advance on the basis that there's
      a very good chance it's going to have to transmit either an ACK or an
      ABORT.  This requires it to look in the connection struct to retrieve some
      of the parameters.
      
      However, if the call is complete, the call connection pointer may be NULL
      to dissuade the processor from transmitting a message.  However, there are
      some situations where the processor is still going to be called - and it's
      still going to set up message parameters whether it needs them or not.
      
      This results in a NULL pointer dereference at:
      
      	net/rxrpc/call_event.c:837
      
      To fix this, skip the message pre-initialisation if there's no connection
      attached.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      f9dc5757
    • D
      rxrpc: Need to flag call as being released on connect failure · 17b963e3
      David Howells 提交于
      If rxrpc_new_client_call() fails to make a connection, the call record that
      it allocated needs to be marked as RXRPC_CALL_RELEASED before it is passed
      to rxrpc_put_call() to indicate that it no longer has any attachment to the
      AF_RXRPC socket.
      
      Without this, an assertion failure may occur at:
      
      	net/rxrpc/call_object:635
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      17b963e3