Hi Bart,
On 4/13/2017 11:29 AM, Bart Van Assche wrote:
> On Thu, 2017-04-13 at 10:48 -0400, Hal Rosenstock wrote:
>> %d is not good as LIDs above 32K print as negative numbers.
>> %#x seems to be the right choice here; %u was used by IB
>> management tools for unicast LID printing.
>
> Hello Hal,
>
> Although the patch itself looks fine to me: LIDs are converted from network
> to host format using be16toh(). That function returns an unsigned 16-bit
> number. These numbers are converted to type "int" before pr_err() is called.
> The type "int" is at least 32 bits on all architectures supported by Linux.
> So how could using %d result in a negative number being printed?
I'll fix up the commit description to just say consistent LID printing
and remove the negative issue which was only in IB management area.
I'll also remove the superfluous cast you mentioned.
Thanks.
-- Hal
>> diff --git a/srp_daemon/srp_daemon.c b/srp_daemon/srp_daemon.c
>> index 59a6137..4d8476e 100644
>> --- a/srp_daemon/srp_daemon.c
>> +++ b/srp_daemon/srp_daemon.c
>> @@ -632,7 +632,7 @@ recv:
>> ret = umad_status(in_mad);
>> if (ret) {
>> pr_err(
>> - "bad MAD status (%u) from lid %d\n",
>> + "bad MAD status (%u) from lid %#x\n",
>> ret, (uint16_t) be16toh(out_mad->hdr.addr.lid));
>> return -ret;
>
> If you have to repost this patch, please remove the (uint16_t) cast since it's
> superfluous.
>
> Thanks,
>
> Bart.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
