On Mon, Jun 06, 2016 at 11:42:38PM +0300, Dan Carpenter wrote:
> It's fairly tricky to follow actually. Here is one caller:
>
> net/sctp/outqueue.c
> 706 static int sctp_outq_flush(struct sctp_outq *q, int rtx_timeout, gfp_t gfp)
> 707 {
> 708 struct sctp_packet *packet;
> 709 struct sctp_packet singleton;
> 710 struct sctp_association *asoc = q->asoc;
> ^^^^^^^^^^^^^^
> asoc is set here.
>
> 711 __u16 sport = asoc->base.bind_addr.port;
> 712 __u16 dport = asoc->peer.port;
> 713 __u32 vtag = asoc->peer.i.init_tag;
> 714 struct sctp_transport *transport = NULL;
> 715 struct sctp_transport *new_transport;
> 716 struct sctp_chunk *chunk, *tmp;
> 717 sctp_xmit_t status;
>
> [ snip ]
>
> 800
> 801 /* Are we switching transports?
> 802 * Take care of transport locks.
> 803 */
> 804 if (new_transport != transport) {
> 805 transport = new_transport;
> 806 if (list_empty(&transport->send_ready)) {
> 807 list_add_tail(&transport->send_ready,
> 808 &transport_list);
> 809 }
> 810 packet = &transport->packet;
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> packet is set here. How do we know that "packect->transport->asoc" and
> "asoc" are the same? It's complicated.
Yes agreed, very tricky. It's somewhat redundant information, but that
makes life easier during different stages of its life cycle.
It's like: packets are created at sctp_outq_flush (and some other
places), and then sits on an outq which belongs to a given asoc, just
like the transport. But transports doesn't have queues yet that packet
created is arranged to be sent through a given transport.
And transports always belong to a single asoc, so it's two different
ways of reaching to the same info.
v
packet->transport->asoc == packet->transport->asoc.outq->asoc
^----------´
And to make it even more complicated, with have sctp_do_peeloff(), which
will take all packets belonging to a given asoc from one socket and move
to another, potentially updating asoc pointer during that.
> 811 sctp_packet_config(packet, vtag,
> 812 asoc->peer.ecn_capable);
> 813 }
>
> Anyway, maybe eventually we'll figure out a way to make it work but even
> just reading it manually is quite complicated....
>
> For now, just ignore the false postive.
Okay. Let me know if I can help any further.
Thanks,
Marcelo
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
