On Fri, 2018-07-06 at 11:33 -0600, Jason Gunthorpe wrote:
> container_of is not const preserving, so it happily strips the const
> off the input pointer, which is what the inline wrappers would do if they
> were marked to accept a const - so why convert them to #define's?
As mentioned in the description of patch 1/13, there is code upstream that
modifies the data the returned pointer points at.
> I'm actually a bit surprised this works, I think it might be a bug in
> the container_of macro's type checking that it is ignoring the const
> qualifier on the input pointer - not totally sure I want to rely on that
>
> I'd like this alot better if container_of could propogate const, but
> can't think of a way to achieve that.
How about keeping the inline functions, to declare the argument and return
types const, and to use container_of() directly in the iSER driver?
> Considering these limitations, why are you making this series?
To improve readability of RDMA driver code. This patch series is something
I came up with while analyzing a KASAN complaint about the rdma_rxe function
init_send_wr(). The const annotations make it more clear which work request
pointer is the input work request and which one is the output work request.
Thanks,
Bart.
��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
