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] [day] [month] [year] [list]
Date:   Mon, 7 May 2018 07:45:30 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     David Ahern <dsahern@...il.com>
Cc:     swise@...ngridcomputing.com, netdev@...r.kernel.org
Subject: Re: [PATCH iproute2] rdma: fix header files

On Sat, 5 May 2018 09:17:31 -0600
David Ahern <dsahern@...il.com> wrote:

> On 5/4/18 10:58 PM, Stephen Hemminger wrote:
> > On Fri, 4 May 2018 16:13:07 -0600
> > David Ahern <dsahern@...il.com> wrote:
> >   
> >> On 5/4/18 3:56 PM, Stephen Hemminger wrote:  
> >>> All user api headers in iproute2 should be in include/uapi
> >>> so that script can be used to put correct sanitized kernel headers
> >>> there. And the header files for rdma must be a complete set; if one
> >>> header file includes another, all must be present.
> >>>
> >>> This fixes build on older distributions, and Windows Services
> >>> for Linux.
> >>>
> >>> Signed-off-by: Stephen Hemminger <stephen@...workplumber.org>
> >>> ---
> >>>  include/uapi/rdma/ib_user_sa.h                |   77 ++
> >>>  include/uapi/rdma/ib_user_verbs.h             | 1210 +++++++++++++++++
> >>>  .../uapi/rdma/rdma_netlink.h                  |   13 +
> >>>  .../uapi/rdma/rdma_user_cm.h                  |    6 +-
> >>>  4 files changed, 1303 insertions(+), 3 deletions(-)
> >>>  create mode 100644 include/uapi/rdma/ib_user_sa.h
> >>>  create mode 100644 include/uapi/rdma/ib_user_verbs.h
> >>>  rename {rdma/include => include}/uapi/rdma/rdma_netlink.h (95%)
> >>>  rename {rdma/include => include}/uapi/rdma/rdma_user_cm.h (98%)
> >>>     
> >>
> >> Stephen:
> >>
> >> Per a recent discussion the RDMA folks need to take ownership of the
> >> uapi files. RDMA features do not hit Dave's net-next tree so the rdma
> >> code can never hit iproute2-next during a dev cycle.  
> > 
> > I want all uapi headers in include/uapi because it avoids possible overlap problems,
> > During the linux-net/linus release cycle they should match what is Linus's tree.
> > 
> > During the net-next they can come from two sources.
> >   
> 
> That creates extra work for me for no reason.
> 
> You state above "user api headers in iproute2 should be in include/uapi
> so that script can be used to put correct sanitized kernel headers there."
> 
> With RDMA's development cycle that will *never* happen. With the
> exception of RDMA, all iproute2 features go through net-next and it is
> the right tree to pull updates from. Every time I sync from net-next the
> header files for rdma will have to be ignored, so they will never be
> updated through this mechanism which means the stated goal is not
> achievable.
> 
> As for linux-next, I will not sync header files to a tree that
> disappears; it breaks all traceability. Further, it seems to me that it
> does not really solve the problem. I forget the steps now but RDMA
> features have to hit some development tree before going to Linus, so
> there will be a delay with the headers.
> 
> Back in March we discussed options. iproute2 is nothing more than a
> delivery vehicle for rdmatool. Since it breaks everything else about the
> iproute2 and net-next association, the simplest option for everyone is
> for the rdma group to control syncing their own headers and putting them
> under rdma directory.

There are three different issues here:
1. What directory should rdma files be in. It really doesn't matter that much
   so lets keep them in rdma/incude/uapi.
2. For current master branch the set of include files does not match Linus's current
   tree.
3. The header files for rdma do not include all the referenced headers. My rule has
   been if foo.c includes uapi/foo.h and foo.h includes bar.h then bar.h must also
   be in the include/uapi directory.

I will spin a new patch addressing #2 and #3.

Powered by blists - more mailing lists