linux-kernel - Re: [PATCH v3 2/5] net: qrtr: Implement outgoing flow control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <18c9b140-61d4-13b1-f10e-af3321dfca38@codeaurora.org>
Date:   Thu, 9 Jan 2020 19:07:59 -0800
From:   Chris Lew <clew@...eaurora.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        "David S. Miller" <davem@...emloft.net>
Cc:     Arun Kumar Neelakantam <aneela@...eaurora.org>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v3 2/5] net: qrtr: Implement outgoing flow control

Hey Bjorn,

Some minor comments.

On 1/6/2020 9:47 PM, Bjorn Andersson wrote:
> +/**
> + * qrtr_tx_flow_failed() - flag that tx of confirm_rx flagged messages failed
> + * @node:	qrtr_node that the packet is to be send to
> + * @dest_node:	node id of the destination
> + * @dest_port:	port number of the destination
> + *
> + * Signal that the transmission of a message with confirm_rx flag failed. The
> + * flow's "pending" counter will keep incrementing towards QRTR_TX_FLOW_HIGH,
> + * at which point transmission would stall forever waiting for the resume TX
> + * message associated with the dropped confirm_rx message.
> + * Work around this by marking the flow as having a failed transmission and
> + * cause the next transmission attempt to be sent with the confirm_rx.
> + */
> +static void qrtr_tx_flow_failed(struct qrtr_node *node, int dest_node,
> +				int dest_port)
> +{
> +	unsigned long key = (u64)dest_node << 32 | dest_port;
> +	struct qrtr_tx_flow *flow;
> +
> +	flow = radix_tree_lookup(&node->qrtr_tx_flow, key);
> +	if (flow) {
> +		spin_lock_irq(&flow->resume_tx.lock);
> +		flow->tx_failed = 1;
> +		spin_unlock_irq(&flow->resume_tx.lock);
> +	}

Might be good to take qrtr_tx_lock when accessing the qrtr_tx_flow radix 
tree here.

> @@ -408,6 +570,8 @@ int qrtr_endpoint_register(struct qrtr_endpoint *ep, unsigned int nid)
>   	node->nid = QRTR_EP_NID_AUTO;
>   	node->ep = ep;
>   
> +	INIT_RADIX_TREE(&node->qrtr_tx_flow, GFP_KERNEL);
> +

mutex_init(&node->qrtr_tx_lock);

>   	qrtr_node_assign(node, nid);
>   
>   	mutex_lock(&qrtr_node_lock);

Thanks,

Chris

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project