All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Alexandra Winter <wintera@linux.ibm.com>
Cc: Wenjia Zhang <wenjia@linux.ibm.com>,
	Jan Karcher <jaka@linux.ibm.com>,
	Gerd Bayer <gbayer@linux.ibm.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	"D. Wythe" <alibuda@linux.alibaba.com>,
	Tony Lu <tonylu@linux.alibaba.com>,
	Wen Gu <guwen@linux.alibaba.com>,
	Peter Oberparleiter <oberpar@linux.ibm.com>,
	David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	Julian Ruess <julianr@linux.ibm.com>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	Thorsten Winkler <twinkler@linux.ibm.com>,
	netdev@vger.kernel.org, linux-s390@vger.kernel.org,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>
Subject: Re: [RFC net-next 3/7] net/ism: Use uuid_t for ISM GID
Date: Mon, 20 Jan 2025 17:18:20 +0000	[thread overview]
Message-ID: <20250120171820.GC6206@kernel.org> (raw)
In-Reply-To: <20250115195527.2094320-4-wintera@linux.ibm.com>

On Wed, Jan 15, 2025 at 08:55:23PM +0100, Alexandra Winter wrote:
> SMC uses 64 Bit and 128 Bit Global Identifiers (GIDs)
> that need to be sent via the SMC protocol.
> When integers are used network endianness and host endianness
> need to be considered.
> 
> Avoid this in the ISM layer by using uuid_t byte arrays.
> Follow on patches could do the same change for SMC, for now
> conversion helper functions are introduced.
> 
> ISM-vPCI devices provide 64 Bit GIDs. Map them to ISM uuid_t GIDs
> like this:
>  _________________________________________
> | 64 Bit ISM-vPCI GID | 00000000_00000000 |
>  -----------------------------------------
> If interpreted as UUID, this would be interpreted as th UIID variant,
> that is reserved for NCS backward compatibility. So it will not collide
> with UUIDs that were generated according to the standard.
> 
> Future ISM devices, shall use real UUIDs as 128 Bit GIDs.
> 
> Note:
> - In this RFC patch smcd_gid is now moved back to smc.h,
>   future patchset should avoid that.
> - ism_dmb and ism_event structs still contain 64 Bit rgid and info
>   fields. A future patch could change them to uuid_t gids. This
>   does not break anything, because ism_loopback does not use them.
> 
> Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>

...

> diff --git a/net/smc/smc_ism.h b/net/smc/smc_ism.h
> index 6763133dd8d0..d041e5a7c459 100644
> --- a/net/smc/smc_ism.h
> +++ b/net/smc/smc_ism.h
> @@ -12,6 +12,7 @@
>  #include <linux/uio.h>
>  #include <linux/types.h>
>  #include <linux/mutex.h>
> +#include <linux/ism.h>
>  
>  #include "smc.h"
>  
> @@ -94,4 +95,24 @@ static inline bool smc_ism_is_loopback(struct smcd_dev *smcd)
>  	return (smcd->ops->get_chid(smcd) == 0xFFFF);
>  }
>  
> +static inline void copy_to_smcdgid(struct smcd_gid *sgid, uuid_t *igid)
> +{
> +	__be64 temp;
> +
> +	memcpy(&temp, igid, sizeof(sgid->gid));
> +	sgid->gid = ntohll(temp);
> +	memcpy(&temp, igid + sizeof(sgid->gid), sizeof(sgid->gid_ext));

Hi Alexandra,

The stride of the pointer arithmetic is the width of igid
so this write will be at an offset of:

   sizeof(igid) + sizeof(sgid->gid) = 128 bytes

Which is beyond the end of *igid.

I think the desired operation is to write at an offset of 8 bytes, so
perhaps this is a way to achieve that, as the bi field is a
16 byte array of u8:

	memcpy(&temp, igid->b + sizeof(sgid->gid), sizeof(sgid->gid_ext));


Flagged by W=1 builds with gcc-14 and clang-19, and by Smatch.

> +	sgid->gid_ext = ntohll(temp);
> +}
> +
> +static inline void copy_to_ismgid(uuid_t *igid, struct smcd_gid *sgid)
> +{
> +	__be64 temp;
> +
> +	temp = htonll(sgid->gid);
> +	memcpy(igid, &temp, sizeof(sgid->gid));
> +	temp = htonll(sgid->gid_ext);
> +	memcpy(igid + sizeof(sgid->gid), &temp, sizeof(sgid->gid_ext));

I believe there is a similar problem here too.

> +}
> +
>  #endif
> -- 
> 2.45.2
> 

  reply	other threads:[~2025-01-20 17:18 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-15 19:55 [RFC net-next 0/7] Provide an ism layer Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 1/7] net/ism: Create net/ism Alexandra Winter
2025-01-16 20:08   ` Andrew Lunn
2025-01-17 12:06     ` Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 2/7] net/ism: Remove dependencies between ISM_VPCI and SMC Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 3/7] net/ism: Use uuid_t for ISM GID Alexandra Winter
2025-01-20 17:18   ` Simon Horman [this message]
2025-01-22 14:46     ` Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 4/7] net/ism: Add kernel-doc comments for ism functions Alexandra Winter
2025-01-15 22:06   ` Halil Pasic
2025-01-20  6:32   ` Dust Li
2025-01-20  9:56     ` Alexandra Winter
2025-01-20 10:07       ` Julian Ruess
2025-01-20 11:35         ` Alexandra Winter
2025-01-20 10:34     ` Niklas Schnelle
2025-01-22 15:02       ` Dust Li
2025-01-15 19:55 ` [RFC net-next 5/7] net/ism: Move ism_loopback to net/ism Alexandra Winter
2025-01-20  3:55   ` Dust Li
2025-01-20  9:31     ` Alexandra Winter
2025-02-06 17:36   ` Julian Ruess
2025-02-10 10:39     ` Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 6/7] s390/ism: Define ismvp_dev Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 7/7] net/smc: Use only ism_ops Alexandra Winter
2025-01-16  9:32 ` [RFC net-next 0/7] Provide an ism layer Dust Li
2025-01-16 11:55   ` Julian Ruess
2025-01-16 16:17     ` Alexandra Winter
2025-01-16 17:08       ` Julian Ruess
2025-01-17  2:13       ` Dust Li
2025-01-17 10:38         ` Niklas Schnelle
2025-01-17 15:02           ` Andrew Lunn
2025-01-17 16:00             ` Niklas Schnelle
2025-01-17 16:33               ` Andrew Lunn
2025-01-17 16:57                 ` Niklas Schnelle
2025-01-17 20:29                   ` Andrew Lunn
2025-01-20  6:21                     ` Dust Li
2025-01-20 12:03                       ` Alexandra Winter
2025-01-20 16:01                         ` Andrew Lunn
2025-01-20 17:25                           ` Alexandra Winter
2025-01-18 15:31           ` Dust Li
2025-01-28 16:04             ` Alexandra Winter
2025-02-10  5:08               ` Dust Li
2025-02-10  9:38                 ` Alexandra Winter
2025-02-11  1:57                   ` Dust Li
2025-02-16 15:40                   ` Wen Gu
2025-02-19 11:25                     ` [RFC net-next 0/7] Provide an ism layer - naming Alexandra Winter
2025-02-25  1:36                       ` Dust Li
2025-02-25  8:40                         ` Alexandra Winter
2025-01-17 13:00         ` [RFC net-next 0/7] Provide an ism layer Alexandra Winter
2025-01-17 15:10           ` Andrew Lunn
2025-01-17 16:20             ` Alexandra Winter
2025-01-20 10:28           ` Alexandra Winter
2025-01-22  3:04             ` Dust Li
2025-01-22 12:02               ` Alexandra Winter
2025-01-22 12:05                 ` Alexandra Winter
2025-01-22 14:10                   ` Dust Li
2025-01-17 15:06       ` Andrew Lunn
2025-01-17 15:38         ` Alexandra Winter
2025-02-16 15:38       ` Wen Gu
2025-01-17 11:04   ` Alexandra Winter
2025-01-18 15:24     ` Dust Li
2025-01-20 11:45       ` Alexandra Winter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250120171820.GC6206@kernel.org \
    --to=horms@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=alibuda@linux.alibaba.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=borntraeger@linux.ibm.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gbayer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=guwen@linux.alibaba.com \
    --cc=hca@linux.ibm.com \
    --cc=jaka@linux.ibm.com \
    --cc=julianr@linux.ibm.com \
    --cc=kuba@kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oberpar@linux.ibm.com \
    --cc=pabeni@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=schnelle@linux.ibm.com \
    --cc=svens@linux.ibm.com \
    --cc=tonylu@linux.alibaba.com \
    --cc=twinkler@linux.ibm.com \
    --cc=wenjia@linux.ibm.com \
    --cc=wintera@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.