[<prev] [next>] [day] [month] [year] [list]
Message-ID: <b254a359-0ca8-463b-b666-e34ba357bd09@amperemail.onmicrosoft.com>
Date: Wed, 23 Apr 2025 14:25:57 -0400
From: Adam Young <admiyo@...eremail.onmicrosoft.com>
To: Jeremy Kerr <jk@...econstruct.com.au>, admiyo@...amperecomputing.com,
Matt Johnston <matt@...econstruct.com.au>,
Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Sudeep Holla <sudeep.holla@....com>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>,
Huisong Li <lihuisong@...wei.com>
Subject: Re: [PATCH net-next v19 1/1] mctp pcc: Implement MCTP over PCC
Transport
On 4/22/25 10:15, Jeremy Kerr wrote:
> > + spin_lock_irqsave(&mpnd->lock, flags);
> > + rc = skb_cow_head(skb, sizeof(struct mctp_pcc_hdr));
> > + if (rc)
> > + return rc;
> This will return with mpdn->lock still held.
> And should this return the raw rc value? Or NETDEV_TX_OK?
I based my code off the other drivers in the same directory:
rc = skb_cow_head(skb, sizeof(struct mctp_i2c_hdr));
if (rc)
return rc;
rc = skb_cow_head(skb, sizeof(struct mctp_i3c_internal_hdr));
if (rc)
return rc;
However, I just noticed the USB one, that went in last release, does
this (using a goto)
err_drop:
dev_dstats_tx_dropped(dev);
kfree_skb(skb);
return NETDEV_TX_OK;
Seems strange to returning NETDEV_TX_OK for what is essentially a memory
allocation failure? However, I am going to assume that this most recent
one represents the current wisdom, and will follow suit.
Powered by blists - more mailing lists