netdev - Re: [PATCH net-next v21 1/1] mctp pcc: Implement MCTP over PCC Transport

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: <20250430094725.000031ac@huawei.com>
Date: Wed, 30 Apr 2025 09:47:25 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: <admiyo@...amperecomputing.com>
CC: Jeremy Kerr <jk@...econstruct.com.au>, 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>,
	<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>, Sudeep Holla
	<sudeep.holla@....com>, Huisong Li <lihuisong@...wei.com>
Subject: Re: [PATCH net-next v21 1/1] mctp pcc: Implement MCTP over PCC
 Transport

On Tue, 29 Apr 2025 18:27:58 -0400
admiyo@...amperecomputing.com wrote:

> From: Adam Young <admiyo@...amperecomputing.com>
> 
> Implementation of network driver for
> Management Control Transport Protocol(MCTP)
> over Platform Communication Channel(PCC)
Hi Adam,

> 
> DMTF DSP:0292
> https://www.dmtf.org/sites/default/files/standards/documents/\
> DSP0292_1.0.0WIP50.pdf

Don't line break a link.

Is the WIP status something we should be concerned about?


> 
> MCTP devices are specified via ACPI by entries
> in DSDT/SDST and reference channels specified
> in the PCCT.  Messages are sent on a type 3 and
> received on a type 4 channel.  Communication with
> other devices use the PCC based doorbell mechanism;
> a shared memory segment with a corresponding
> interrupt and a memory register used to trigger
> remote interrupts.
> 

Very short wrap.  Convention for patch descriptions tends to be around
75 chars.

> Signed-off-by: Adam Young <admiyo@...amperecomputing.com>

A couple more trivial things on a final look through from me.
Obviously the netdev and mctp bits aren't my specialty as I only dip
into them occasionally, but with that in mind and some concerns
about possibility for this getting abused as a work around for things
should have more specific kernel level support...

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>


> diff --git a/drivers/net/mctp/mctp-pcc.c b/drivers/net/mctp/mctp-pcc.c
> new file mode 100644
> index 000000000000..aa5c5701d581
> --- /dev/null
> +++ b/drivers/net/mctp/mctp-pcc.c
> @@ -0,0 +1,305 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * mctp-pcc.c - Driver for MCTP over PCC.
> + * Copyright (c) 2024, Ampere Computing LLC
> + */
> +
> +/* Implementation of MCTP over PCC DMTF Specification DSP0256
> + * https://www.dmtf.org/sites/default/files/standards/documents/DSP0256_2.0.0WIP50.pdf

https://www.dmtf.org/sites/default/files/standards/documents/DSP0256_2.0.0.pdf

Looks to be final version of that doc, but it's not what your title says...




> +static netdev_tx_t mctp_pcc_tx(struct sk_buff *skb, struct net_device *ndev)
> +{
> +	struct mctp_pcc_ndev *mpnd = netdev_priv(ndev);
> +	struct mctp_pcc_hdr *mctp_pcc_header;
> +	void __iomem *buffer;
> +	unsigned long flags;
> +	int len = skb->len;
> +	int rc;
> +
> +	rc = skb_cow_head(skb, sizeof(*mctp_pcc_header));
> +	if (rc)
> +		goto err_drop;
> +
> +	mctp_pcc_header = skb_push(skb, sizeof(mctp_pcc_header));
> +	mctp_pcc_header->signature = cpu_to_le32(PCC_SIGNATURE | mpnd->outbox.index);
> +	mctp_pcc_header->flags = cpu_to_le32(PCC_CMD_COMPLETION_NOTIFY);
> +	memcpy(mctp_pcc_header->mctp_signature, MCTP_SIGNATURE,
> +	       MCTP_SIGNATURE_LENGTH);
> +	mctp_pcc_header->length = cpu_to_le32(len + MCTP_SIGNATURE_LENGTH);
> +
> +	spin_lock_irqsave(&mpnd->lock, flags);
> +	buffer = mpnd->outbox.chan->shmem;
> +	memcpy_toio(buffer, skb->data, skb->len);
> +	rc = mpnd->outbox.chan->mchan->mbox->ops->send_data
> +		(mpnd->outbox.chan->mchan, NULL);

Not the most readable of line wraps. I'd just go long on this one for readability.
It's still < 100 chars. Or use a local pointer to outbox chan.
That will shorten this and at least one other place.


	rc = mpnd->outbox.chan->mchan->mbox->ops->send_data(mpnd->outbox.chan->mchan, NULL);


> +	spin_unlock_irqrestore(&mpnd->lock, flags);
> +	if ACPI_FAILURE(rc)
> +		goto err_drop;
> +	dev_dstats_tx_add(ndev, len);
> +	dev_consume_skb_any(skb);
> +	return NETDEV_TX_OK;
> +err_drop:
> +	dev_dstats_tx_dropped(ndev);
> +	kfree_skb(skb);
> +	return NETDEV_TX_OK;
> +}

> +
> +static acpi_status lookup_pcct_indices(struct acpi_resource *ares,
> +				       void *context)
> +{
> +	struct mctp_pcc_lookup_context *luc = context;
> +	struct acpi_resource_address32 *addr;
> +
> +	if (ares->type != PCC_DWORD_TYPE)
> +		return AE_OK;
> +
> +	addr = ACPI_CAST_PTR(struct acpi_resource_address32, &ares->data);
> +	switch (luc->index) {
> +	case 0:
> +		luc->outbox_index = addr[0].address.minimum;
Really trivial but as this is a walk of the resources, I'd expect it
to be conceptually providing one resource per walk iteration.
As such, is 
		luc->outbox_index = addr->address.minimum;

more representative of what is going on here than an array look up?

> +		break;
> +	case 1:
> +		luc->inbox_index = addr[0].address.minimum;
> +		break;
> +	}
> +	luc->index++;
> +	return AE_OK;
> +}