RE: [PATCH v2 net-next 6/7] net: dsa: netc: add PTP two-step timestamping support

> > +static void netc_port_txtstamp_twostep(struct netc_port *np,
> > +				       struct sk_buff *nskb)
> > +{
> > +	DECLARE_BITMAP(ts_req_id_bitmap, NETC_NUM_TS_REQ_ID);
> > +	struct sk_buff *clone = skb_clone_sk(nskb);
> > +	struct netc_switch *priv = np->switch_priv;
> > +	struct sk_buff_head free_list;
> > +	struct sk_buff *skb, *skb_tmp;
> > +	unsigned long ts_req_id;
> > +	int err = 0;
> > +
> > +	if (unlikely(!clone))
> > +		return;
> > +
> > +	bitmap_zero(ts_req_id_bitmap, NETC_NUM_TS_REQ_ID);
> > +	__skb_queue_head_init(&free_list);
> > +	spin_lock_bh(&np->tstamp_lock);
> > +
> > +	skb_queue_walk_safe(&np->skb_txtstamp_queue, skb, skb_tmp) {
> > +		if (time_before(NETC_SKB_CB(skb)->ptp_tx_time +
> > +				NETC_TXTSTAMP_TIMEOUT, jiffies)) {
> 
> [Severity: High]
> Does this lazy garbage collection of timed-out TX SKBs permanently leak
> sockets
> and network namespaces?
> 
> When a frame requests a two-step hardware TX timestamp, skb_clone_sk() is
> used,
> which takes a reference on the socket. If the frame is dropped in software
> (e.g., due to qdisc drops or congestion) before reaching the hardware, the
> hardware never generates a timestamp response, and the clone remains in
> np->skb_txtstamp_queue.
> 
> Because the driver only lazily checks for timed-out SKBs here when a new PTP
> packet is transmitted, the queue will not be purged if the application stops
> transmitting or closes the socket. The stranded clone holds a reference to the
> socket indefinitely, which in turn prevents the associated network namespace
> from being destroyed.

When tx_type is set to HWTSTAMP_TX_OFF, np->skb_txtstamp_queue will
be cleared. If the application closes the socket, tx_type should be set to
HWTSTAMP_TX_OFF. In this case, I don't think it is an issue.