[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5ba055e9-5221-bff2-fdd2-d4b837c95ce1@oracle.com>
Date: Mon, 29 Apr 2019 21:25:15 -0700
From: "santosh.shilimkar@...cle.com" <santosh.shilimkar@...cle.com>
To: Nicholas Mc Guire <hofrat@...dl.org>
Cc: "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
linux-rdma@...r.kernel.org, rds-devel@....oracle.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2] rds: ib: force endiannes annotation
On 4/29/19 8:12 PM, Nicholas Mc Guire wrote:
> While the endiannes is being handled correctly as indicated by the comment
> above the offending line - sparse was unhappy with the missing annotation
> as be64_to_cpu() expects a __be64 argument. To mitigate this annotation
> all involved variables are changed to a consistent __le64 and the
> conversion to uint64_t delayed to the call to rds_cong_map_updated().
>
> Signed-off-by: Nicholas Mc Guire <hofrat@...dl.org>
> ---
>
> Problem located by an experimental coccinelle script to locate
> patters that make sparse unhappy (false positives):
> net/rds/ib_recv.c:827:23: warning: cast to restricted __le64
>
> V2: Edward Cree <ecree@...arflare.com> rejected the need for using __force
> here - instead solve the sparse issue by updating all of the involved
> variables - which results in an identical binary as well without using
> the __force "solution" to the sparse warning. Thanks !
>
> Patch was compile-tested with: x86_64_defconfig + INFINIBAND=m, RDS_RDMA=m
>
> Patch was verified not to change the binary by diffing the
> generated object code before and after applying the patch.
>
Thanks. I was worried about this macro magic o.w
Acked-by: Santosh Shilimkar <santosh.shilimkar@...cle.com>
Powered by blists - more mailing lists