Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
In-Reply-To: <CAMuHMdVh8dwd=77mHTqG80_D8DK+EtVGewRUJuaJzK1qRYrB+w@mail.gmail.com>
Subject: Re:  Re: [PATCH] RDMA/siw: Fix compiler warnings on 32-bit due to u64/pointer
 abuse
From:   "Bernard Metzler" <BMT@zurich.ibm.com>
To:     "Geert Uytterhoeven" <geert@linux-m68k.org>
Cc:     "Joe Perches" <joe@perches.com>,
        "Doug Ledford" <dledford@redhat.com>,
        "Jason Gunthorpe" <jgg@ziepe.ca>,
        "linux-rdma" <linux-rdma@vger.kernel.org>,
        "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Date:   Mon, 19 Aug 2019 17:26:53 +0000
MIME-Version: 1.0
Sensitivity: 
Importance: Normal
References: <CAMuHMdVh8dwd=77mHTqG80_D8DK+EtVGewRUJuaJzK1qRYrB+w@mail.gmail.com>,<20190819100526.13788-1-geert@linux-m68k.org>
 <581e7d79ed75484beb227672b2695ff14e1f1e34.camel@perches.com>
Content-Transfer-Encoding: 8BIT
Content-Type: text/plain; charset=UTF-8
Message-Id: <OF7DF1711D.F2EB24AC-ON0025845B.005FD8A6-0025845B.005FD8AD@notes.na.collabserv.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


---
Bernard Metzler, PhD
Tech. Leader High Performance I/O, Principal Research Staff
IBM Zurich Research Laboratory
Saeumerstrasse 4
CH-8803 Rueschlikon, Switzerland
+41 44 724 8605

-----"Geert Uytterhoeven" <geert@linux-m68k.org> wrote: -----

>To: "Joe Perches" <joe@perches.com>
>From: "Geert Uytterhoeven" <geert@linux-m68k.org>
>Date: 08/19/2019 07:15PM
>Cc: "Bernard Metzler" <bmt@zurich.ibm.com>, "Doug Ledford"
><dledford@redhat.com>, "Jason Gunthorpe" <jgg@ziepe.ca>, "linux-rdma"
><linux-rdma@vger.kernel.org>, "Linux Kernel Mailing List"
><linux-kernel@vger.kernel.org>
>Subject: [EXTERNAL] Re: [PATCH] RDMA/siw: Fix compiler warnings on
>32-bit due to u64/pointer abuse
>
>Hi Joe,
>
>On Mon, Aug 19, 2019 at 6:56 PM Joe Perches <joe@perches.com> wrote:
>> On Mon, 2019-08-19 at 12:05 +0200, Geert Uytterhoeven wrote:
>> > When compiling on 32-bit:
>> >
>> >     drivers/infiniband/sw/siw/siw_cq.c:76:20: warning: cast to
>pointer from integer of different size [-Wint-to-pointer-cast]
>> >     drivers/infiniband/sw/siw/siw_qp.c:952:28: warning: cast from
>pointer to integer of different size [-Wpointer-to-int-cast]
>> []
>> > Fix this by applying the following rules:
>> >   1. When printing a u64, the %llx format specififer should be
>used,
>> >      instead of casting to a pointer, and printing the latter.
>> >   2. When assigning a pointer to a u64, the pointer should be
>cast to
>> >      uintptr_t, not u64,
>> >   3. When casting from u64 to pointer, an intermediate cast to
>uintptr_t
>> >      should be added,
>>
>> I think a cast to unsigned long is rather more common.
>>
>> uintptr_t is used ~1300 times in the kernel.
>> I believe a cast to unsigned long is much more common.
>
>That is true, as uintptr_t was introduced in C99.
>Similarly, unsigned long was used before size_t became common.
>
>However, nowadays size_t and uintptr_t are preferred.
>
>> It might be useful to add something to the Documentation
>> for this style.  Documentation/process/coding-style.rst
>>
>> And trivia:
>>
>> > > diff --git a/drivers/infiniband/sw/siw/siw_verbs.c
>b/drivers/infiniband/sw/siw/siw_verbs.c
>> []
>> > @@ -842,8 +842,8 @@ int siw_post_send(struct ib_qp *base_qp,
>const struct ib_send_wr *wr,
>> >                       rv = -EINVAL;
>> >                       break;
>> >               }
>> > -             siw_dbg_qp(qp, "opcode %d, flags 0x%x, wr_id
>0x%p\n",
>> > -                        sqe->opcode, sqe->flags, (void
>*)sqe->id);
>> > +             siw_dbg_qp(qp, "opcode %d, flags 0x%x, wr_id
>0x%llx\n",
>> > +                        sqe->opcode, sqe->flags, sqe->id);
>>
>> Printing possible pointers as %llx is generally not a good idea
>> given the desire for %p obfuscation.
>
>Are they pointers? Difficult to know with all the casting...
>

You are right. This one is not a pointer. It is an application
assigned unsigned 64bit. Just something (typically a pointer or
array index) assigned by the application to match work completions
with original work requests. So %llx would more correct here,
and the cast is not needed then.

Only problem that a kernel application typically puts a pointer
into here (a pointer to a local context etc.). With the aim
to support obfuscating the pointer for printout, we would be
back to the cast plus %p formatting....?


>Gr{oetje,eeting}s,
>
>                        Geert
>
>-- 
>Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
>geert@linux-m68k.org
>
>In personal conversations with technical people, I call myself a
>hacker. But
>when I'm talking to journalists I just say "programmer" or something
>like that.
>                                -- Linus Torvalds
>
>