netdev - Re: [net-next 1/5] tipc: obsolete TIPC_ZONE

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 15 Mar 2018 17:11:22 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jon Maloy <jon.maloy@...csson.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org,
        mohan.krishna.ghanta.krishnamurthy@...csson.com,
        tung.q.nguyen@...tech.com.au, hoang.h.le@...tech.com.au,
        canh.d.luu@...tech.com.au, ying.xue@...driver.com,
        tipc-discussion@...ts.sourceforge.net
Subject: Re: [net-next 1/5] tipc: obsolete TIPC_ZONE_SCOPE

Thu, Mar 15, 2018 at 04:48:51PM CET, jon.maloy@...csson.com wrote:
>Publications for TIPC_CLUSTER_SCOPE and TIPC_ZONE_SCOPE are in all
>aspects handled the same way, both on the publishing node and on the
>receiving nodes.
>
>Despite previous ambitions to the contrary, this is never going to change,
>so we take the conseqeunce of this and obsolete TIPC_ZONE_SCOPE and related
>macros/functions. Whenever a user is doing a bind() or a sendmsg() attempt
>using ZONE_SCOPE we translate this internally to CLUSTER_SCOPE, while we
>remain compatible with users and remote nodes still using ZONE_SCOPE.
>
>Furthermore, the non-formalized scope value 0 has always been permitted
>for use during lookup, with the same meaning as ZONE_SCOPE/CLUSTER_SCOPE.
>We now permit it even as binding scope, but for compatibility reasons we
>choose to not change the value of TIPC_CLUSTER_SCOPE.
>
>Acked-by: Ying Xue <ying.xue@...driver.com>
>Signed-off-by: Jon Maloy <jon.maloy@...csson.com>

[...]


>diff --git a/include/uapi/linux/tipc.h b/include/uapi/linux/tipc.h
>index 14bacc7..4ac9f1f 100644
>--- a/include/uapi/linux/tipc.h
>+++ b/include/uapi/linux/tipc.h
>@@ -61,50 +61,6 @@ struct tipc_name_seq {
> 	__u32 upper;
> };
> 
>-/* TIPC Address Size, Offset, Mask specification for Z.C.N
>- */
>-#define TIPC_NODE_BITS          12
>-#define TIPC_CLUSTER_BITS       12
>-#define TIPC_ZONE_BITS          8
>-
>-#define TIPC_NODE_OFFSET        0
>-#define TIPC_CLUSTER_OFFSET     TIPC_NODE_BITS
>-#define TIPC_ZONE_OFFSET        (TIPC_CLUSTER_OFFSET + TIPC_CLUSTER_BITS)
>-
>-#define TIPC_NODE_SIZE          ((1UL << TIPC_NODE_BITS) - 1)
>-#define TIPC_CLUSTER_SIZE       ((1UL << TIPC_CLUSTER_BITS) - 1)
>-#define TIPC_ZONE_SIZE          ((1UL << TIPC_ZONE_BITS) - 1)
>-
>-#define TIPC_NODE_MASK		(TIPC_NODE_SIZE << TIPC_NODE_OFFSET)
>-#define TIPC_CLUSTER_MASK	(TIPC_CLUSTER_SIZE << TIPC_CLUSTER_OFFSET)
>-#define TIPC_ZONE_MASK		(TIPC_ZONE_SIZE << TIPC_ZONE_OFFSET)
>-
>-#define TIPC_ZONE_CLUSTER_MASK (TIPC_ZONE_MASK | TIPC_CLUSTER_MASK)
>-
>-static inline __u32 tipc_addr(unsigned int zone,
>-			      unsigned int cluster,
>-			      unsigned int node)
>-{
>-	return (zone << TIPC_ZONE_OFFSET) |
>-		(cluster << TIPC_CLUSTER_OFFSET) |
>-		node;
>-}
>-
>-static inline unsigned int tipc_zone(__u32 addr)
>-{
>-	return addr >> TIPC_ZONE_OFFSET;
>-}
>-
>-static inline unsigned int tipc_cluster(__u32 addr)
>-{
>-	return (addr & TIPC_CLUSTER_MASK) >> TIPC_CLUSTER_OFFSET;
>-}
>-
>-static inline unsigned int tipc_node(__u32 addr)
>-{
>-	return addr & TIPC_NODE_MASK;
>-}

If someone includes tipc.h and uses any of this, your patch is going to
break his compilation. Would anyone have good reason to use any of this?