netdev - RE: [EXT] Re: [PATCH v6 rdma-next 1/6] RDMA/core: Create mmap database and cookie helper functions

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]

Message-ID: <MN2PR18MB31829FDCF4FB29CCA3059930A1DD0@MN2PR18MB3182.namprd18.prod.outlook.com>
Date:   Mon, 29 Jul 2019 15:26:49 +0000
From:   Michal Kalderon <mkalderon@...vell.com>
To:     Jason Gunthorpe <jgg@...pe.ca>, Gal Pressman <galpress@...zon.com>
CC:     Ariel Elior <aelior@...vell.com>,
        "dledford@...hat.com" <dledford@...hat.com>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [EXT] Re: [PATCH v6 rdma-next 1/6] RDMA/core: Create mmap
 database and cookie helper functions

> From: Jason Gunthorpe <jgg@...pe.ca>
> Sent: Monday, July 29, 2019 5:05 PM
> 
> External Email
> 
> ----------------------------------------------------------------------
> On Mon, Jul 29, 2019 at 04:53:38PM +0300, Gal Pressman wrote:
> > On 29/07/2019 15:58, Michal Kalderon wrote:
> > >> From: linux-rdma-owner@...r.kernel.org <linux-rdma-
> > >> owner@...r.kernel.org> On Behalf Of Jason Gunthorpe
> > >>
> > >>> +	xa_lock(&ucontext->mmap_xa);
> > >>> +	if (check_add_overflow(ucontext->mmap_xa_page,
> > >>> +			       (u32)(length >> PAGE_SHIFT),
> > >>> +			       &next_mmap_page))
> > >>> +		goto err_unlock;
> > >>
> > >> I still don't like that this algorithm latches into a permanent
> > >> failure when the xa_page wraps.
> > >>
> > >> It seems worth spending a bit more time here to tidy this.. Keep
> > >> using the mmap_xa_page scheme, but instead do something like
> > >>
> > >> alloc_cyclic_range():
> > >>
> > >> while () {
> > >>    // Find first empty element in a cyclic way
> > >>    xa_page_first = mmap_xa_page;
> > >>    xa_find(xa, &xa_page_first, U32_MAX, XA_FREE_MARK)
> > >>
> > >>    // Is there a enough room to have the range?
> > >>    if (check_add_overflow(xa_page_first, npages, &xa_page_end)) {
> > >>       mmap_xa_page = 0;
> > >>       continue;
> > >>    }
> > >>
> > >>    // See if the element before intersects
> > >>    elm = xa_find(xa, &zero, xa_page_end, 0);
> > >>    if (elm && intersects(xa_page_first, xa_page_last, elm->first, elm-
> >last)) {
> > >>       mmap_xa_page = elm->last + 1;
> > >>       continue
> > >>    }
> > >>
> > >>    // xa_page_first -> xa_page_end should now be free
> > >>    xa_insert(xa, xa_page_start, entry);
> > >>    mmap_xa_page = xa_page_end + 1;
> > >>    return xa_page_start;
> > >> }
> > >>
> > >> Approximately, please check it.
> > > Gal & Jason,
> > >
> > > Coming back to the mmap_xa_page algorithm. I couldn't find some
> background on this.
> > > Why do you need the length to be represented in the mmap_xa_page ?
> > > Why not simply use xa_alloc_cyclic ( like in siw )
> 
> I think siw is dealing with only PAGE_SIZE objects, efa had variable sized
> ones.
> 
> > > This is simply a key to a mmap object...
> >
> > The intention was that the entry would "occupy" number of xarray
> > elements according to its size (in pages). It wasn't initially like
> > this, but IIRC this was preferred by Jason.
> 
> It is not so critical, maybe we could drop it if it is really simplifiying. But it
> doesn't look so hard to make an xa algorithm that will be OK.
> 
> The offset/length is shown in things like lsof and what not, and from a
> debugging perspective it makes a lot more sense if the offset/length are
> sensible, ie they should not overlap.
> 
Thanks for the clarification 

> Jason