linux-kernel - infiniband: cxgb4: GCC warnings for 32 bit

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

Date:	Tue, 05 Feb 2013 11:15:58 +0100
From:	Paul Bolle <pebolle@...cali.nl>
To:	Steve Wise <swise@...lsio.com>, Roland Dreier <roland@...nel.org>,
	Sean Hefty <sean.hefty@...el.com>,
	Hal Rosenstock <hal.rosenstock@...il.com>
Cc:	linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: infiniband: cxgb4: GCC warnings for 32 bit

0) Compiling cm.o for 32 bit triggers these GCC warnings:
    drivers/infiniband/hw/cxgb4/cm.c: In function ‘passive_ofld_conn_reply’:
    drivers/infiniband/hw/cxgb4/cm.c:2803:12: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
    drivers/infiniband/hw/cxgb4/cm.c: In function ‘send_fw_pass_open_req’:
    drivers/infiniband/hw/cxgb4/cm.c:2941:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
    [last line repeated a number of times]

1) These two lines were added in commit
1cab775c3e75f1250c965feafd061d696df36e53 ("RDMA/cxgb4: Fix LE hash
collision bug for passive open connection"). That commit was first
released in v3.8-rc1. It's not obvious to me how to fix these warnings,
since these lines are a bit puzzling.

2) These lines read:
   rpl_skb = (struct sk_buff *)cpu_to_be64(req->cookie);

and:
   req->cookie = cpu_to_be64((u64)skb);

3) It is odd that both use cpu_to_be64(). It seems the first one should
have been be64_to_cpu().

But 'cookie' is of type __u64 (see struct
cpl_fw6_msg_ofld_connection_wr_rpl in
drivers/net/ethernet/chelsio/cxgb4/t4_msg.h). So the use of both that
type and the cpu_to_be64() macro looks a bit odd too.

And why is 'cookie' __u64? Is struct cpl_fw6_msg_ofld_connection_wr_rpl
used in userspace code? Can't 'cookie' be of type "struct sk_buff *"? Is
there a requirement for it to be 64 bits wide on both 32 bit and 64 bit?

Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/