linux-kernel - Re: [PATCH rdma-next 01/10] RDMA: Add access flags to ib_alloc_mr() and ib_mr_pool

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: <20210406121312.GK7405@nvidia.com>
Date:   Tue, 6 Apr 2021 09:13:12 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     Christoph Hellwig <hch@....de>,
        Bart Van Assche <bvanassche@....org>,
        Doug Ledford <dledford@...hat.com>,
        Avihai Horon <avihaih@...dia.com>,
        Adit Ranadive <aditr@...are.com>,
        Anna Schumaker <anna.schumaker@...app.com>,
        Ariel Elior <aelior@...vell.com>,
        Bernard Metzler <bmt@...ich.ibm.com>,
        Chuck Lever <chuck.lever@...cle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Dennis Dalessandro <dennis.dalessandro@...nelisnetworks.com>,
        Devesh Sharma <devesh.sharma@...adcom.com>,
        Faisal Latif <faisal.latif@...el.com>,
        Jack Wang <jinpu.wang@...os.com>,
        Jakub Kicinski <kuba@...nel.org>,
        "J. Bruce Fields" <bfields@...ldses.org>,
        Jens Axboe <axboe@...com>,
        Karsten Graul <kgraul@...ux.ibm.com>,
        Keith Busch <kbusch@...nel.org>, Lijun Ou <oulijun@...wei.com>,
        linux-cifs@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-nfs@...r.kernel.org, linux-nvme@...ts.infradead.org,
        linux-rdma@...r.kernel.org, linux-s390@...r.kernel.org,
        Max Gurtovoy <maxg@...lanox.com>,
        Max Gurtovoy <mgurtovoy@...dia.com>,
        "Md. Haris Iqbal" <haris.iqbal@...os.com>,
        Michael Guralnik <michaelgur@...dia.com>,
        Michal Kalderon <mkalderon@...vell.com>,
        Mike Marciniszyn <mike.marciniszyn@...nelisnetworks.com>,
        Naresh Kumar PBS <nareshkumar.pbs@...adcom.com>,
        netdev@...r.kernel.org, Potnuri Bharat Teja <bharat@...lsio.com>,
        rds-devel@....oracle.com, Sagi Grimberg <sagi@...mberg.me>,
        samba-technical@...ts.samba.org,
        Santosh Shilimkar <santosh.shilimkar@...cle.com>,
        Selvin Xavier <selvin.xavier@...adcom.com>,
        Shiraz Saleem <shiraz.saleem@...el.com>,
        Somnath Kotur <somnath.kotur@...adcom.com>,
        Sriharsha Basavapatna <sriharsha.basavapatna@...adcom.com>,
        Steve French <sfrench@...ba.org>,
        Trond Myklebust <trond.myklebust@...merspace.com>,
        VMware PV-Drivers <pv-drivers@...are.com>,
        Weihang Li <liweihang@...wei.com>,
        Yishai Hadas <yishaih@...dia.com>,
        Zhu Yanjun <zyjzyj2000@...il.com>
Subject: Re: [PATCH rdma-next 01/10] RDMA: Add access flags to ib_alloc_mr()
 and ib_mr_pool_init()

On Tue, Apr 06, 2021 at 08:58:54AM +0300, Leon Romanovsky wrote:
> On Tue, Apr 06, 2021 at 07:27:17AM +0200, Christoph Hellwig wrote:
> > On Tue, Apr 06, 2021 at 08:23:28AM +0300, Leon Romanovsky wrote:
> > > The same proposal (enable unconditionally) was raised during
> > > submission preparations and we decided to follow same pattern
> > > as other verbs objects which receive flag parameter.
> > 
> > A flags argument can be added when it actually is needed.  Using it
> > to pass an argument enabled by all ULPs just gets us back to the bad
> > old days of complete crap APIs someone drew up on a whiteboard.
> 
> Let's wait till Jason wakes up, before jumping to conclusions.
> It was his request to update all ULPs.

We are stuck in a bad spot here

Only the kernel can universally support ACCESS_RELAXED_ORDERING
because all the ULPs are required to work sanely already, but
userspace does not have this limitation and we know of enough popular
verbs users that will break if we unconditionally switch on
ACCESS_RELAXED_ORDERING.

Further, we have the problem with the FMR interface that technically
lets the caller control the entire access_flags, including
ACCESS_RELAXED_ORDERING.

So we broadly have two choice
 1) Diverge the kernel and user interfaces and make the RDMA drivers
    special case all the kernel stuff to force
    ACCESS_RELAXED_ORDERING when they are building MRs and processing
    FMR WQE's
 2) Keep the two interfaces the same and push the
    ACCESS_RELAXED_ORDERING to a couple of places in the ULPs so the
    drivers see a consistent API

They are both poor choices, but I think #2 has a greater chance of
everyone doing their parts correctly.

Jason