netdev - Re: [PATCH v1 iproute2-next 2/3] rdma: print driver resource attributes

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

Message-ID: <a8493ed9-f16c-eb71-55db-f27bd1331521@opengridcomputing.com>
Date:   Mon, 14 May 2018 17:04:26 -0500
From:   Steve Wise <swise@...ngridcomputing.com>
To:     Jason Gunthorpe <jgg@...pe.ca>
Cc:     dsahern@...il.com, leon@...nel.org, stephen@...workplumber.org,
        netdev@...r.kernel.org, linux-rdma@...r.kernel.org
Subject: Re: [PATCH v1 iproute2-next 2/3] rdma: print driver resource
 attributes



On 5/14/2018 3:41 PM, Jason Gunthorpe wrote:
> On Mon, May 07, 2018 at 08:53:16AM -0700, Steve Wise wrote:
>> This enhancement allows printing rdma device-specific state, if provided
>> by the kernel.  This is done in a generic manner, so rdma tool doesn't
>> need to know about the details of every type of rdma device.
>>
>> Driver attributes for a rdma resource are in the form of <key,
>> [print_type], value> tuples, where the key is a string and the value can
>> be any supported driver attribute.  The print_type attribute, if present,
>> provides a print format to use vs the standard print format for the type.
>> For example, the default print type for a PROVIDER_S32 value is "%d ",
>> but "0x%x " if the print_type of PRINT_TYPE_HEX is included inthe tuple.
>>
>> Driver resources are only printed when the -dd flag is present.
>> If -p is present, then the output is formatted to not exceed 80 columns,
>> otherwise it is printed as a single row to be grep/awk friendly.
>>
>> Example output:
>>
>> # rdma resource show qp lqpn 1028 -dd -p
>> link cxgb4_0/- lqpn 1028 rqpn 0 type RC state RTS rq-psn 0 sq-psn 0 path-mig-state MIGRATED pid 0 comm [nvme_rdma]
>>     sqid 1028 flushed 0 memsize 123968 cidx 85 pidx 85 wq_pidx 106 flush_cidx 85 in_use 0
>>     size 386 flags 0x0 rqid 1029 memsize 16768 cidx 43 pidx 41 wq_pidx 171 msn 44 rqt_hwaddr 0x2a8a5d00
>>     rqt_size 256 in_use 128 size 130 idx 43 wr_id 0xffff881057c03408 idx 40 wr_id 0xffff881057c033f0
> Hey some of these look like kernel pointers.. That is a no-no.. What
> is up there?

Nothing is defined as a kernel pointer.  But wr_id is often a pointer to
the kernel rdma application's context...

> The wr_id often contains a pointer, right? So we cannot just pass it
> to user space..

Hmm.  It is useful for debugging kernel rdma applications.  Perhaps
these attrs can be only be sent up by the kernel if the capabilities
allow.  But previous review comments of the kernel series, which is now
merged, forced me to remove passing the capabilities information to the
driver resource fill functions. 

So what's the right way to do this?

Steve.