netdev - Re: [PATCH iproute2-next 0/4] RAW format dumps through RDMAtool

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: <20200527025921.GH100179@unreal>
Date:   Wed, 27 May 2020 05:59:21 +0300
From:   Leon Romanovsky <leon@...nel.org>
To:     David Ahern <dsahern@...il.com>
Cc:     netdev <netdev@...r.kernel.org>,
        RDMA mailing list <linux-rdma@...r.kernel.org>,
        Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: [PATCH iproute2-next 0/4] RAW format dumps through RDMAtool

On Tue, May 26, 2020 at 06:00:17PM -0600, David Ahern wrote:
> On 5/20/20 4:25 AM, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@...lanox.com>
> >
> > Hi,
> >
> > The following series adds support to get the RDMA resource data in RAW
> > format. The main motivation for doing this is to enable vendors to
> > return the entire QP/CQ/MR data without a need from the vendor to set
> > each field separately.
> >
> > User-space part of the kernel series [1].
> >
> > Thanks
> >
> > [1] https://lore.kernel.org/linux-rdma/20200513095034.208385-1-leon@kernel.org
> >
> > Maor Gottlieb (4):
> >   rdma: Refactor res_qp_line
> >   rdma: Add support to get QP in raw format
> >   rdma: Add support to get CQ in raw format
> >   rdma: Add support to get MR in raw format
> >
>
> The set depends on UAPI files not visible in either Dave or Linus' tree
> yet. We moved rdma uapi files under rdma/include/uapi/ and as I recall
> the expectation is that you submit updates with your patches once they
> are accepted and that the headers are in sync with Linus' tree once the
> code arrives there.

Yes, you remember correctly.

What should I write in the series to make it clear that the patches
need to be reviewed but not merged yet due to on-going kernel
submission?

We are not merging any code in RDMA that doesn't have corresponding
parts in iproute2 or rdma-core.

Thanks