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 16:27:17 +0000
From:   Jon Maloy <jon.maloy@...csson.com>
To:     Jiri Pirko <jiri@...nulli.us>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Mohan Krishna Ghanta Krishnamurthy 
        <mohan.krishna.ghanta.krishnamurthy@...csson.com>,
        Tung Quang Nguyen <tung.q.nguyen@...tech.com.au>,
        Hoang Huu Le <hoang.h.le@...tech.com.au>,
        Canh Duc Luu <canh.d.luu@...tech.com.au>,
        Ying Xue <ying.xue@...driver.com>,
        "tipc-discussion@...ts.sourceforge.net" 
        <tipc-discussion@...ts.sourceforge.net>
Subject: RE: [net-next 1/5] tipc: obsolete TIPC_ZONE_SCOPE

No, it won't. I just moved those functions and #defines to the bottom of the same file, and marked them as 'deprecated'.

BR
///jon

> -----Original Message-----
> From: Jiri Pirko [mailto:jiri@...nulli.us]
> Sent: Thursday, March 15, 2018 12:11
> To: Jon Maloy <jon.maloy@...csson.com>
> Cc: davem@...emloft.net; netdev@...r.kernel.org; Mohan Krishna Ghanta
> Krishnamurthy <mohan.krishna.ghanta.krishnamurthy@...csson.com>; Tung
> Quang Nguyen <tung.q.nguyen@...tech.com.au>; Hoang Huu Le
> <hoang.h.le@...tech.com.au>; Canh Duc Luu
> <canh.d.luu@...tech.com.au>; Ying Xue <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?