On Wed, Jan 16, 2019 at 09:06:12AM -0800, Matthew Wilcox wrote:
> On Wed, Jan 16, 2019 at 05:02:59PM +0000, Jason Gunthorpe wrote:
> > On Wed, Jan 16, 2019 at 08:00:26AM -0800, Davidlohr Bueso wrote:
> > > On Tue, 15 Jan 2019, Jason Gunthorpe wrote:
> > >
> > > > On Tue, Jan 15, 2019 at 01:12:07PM -0800, Matthew Wilcox wrote:
> > > > > On Tue, Jan 15, 2019 at 08:53:16PM +0000, Jason Gunthorpe wrote:
> > > > > > > - new_pinned = atomic_long_read(&mm->pinned_vm) + npages;
> > > > > > > + new_pinned = atomic_long_add_return(npages, &mm->pinned_vm);
> > > > > > > if (new_pinned > lock_limit && !capable(CAP_IPC_LOCK)) {
> > > > > >
> > > > > > I thought a patch had been made for this to use check_overflow...
> > > > >
> > > > > That got removed again by patch 1 ...
> > > >
> > > > Well, that sure needs a lot more explanation. :(
> > >
> > > What if we just make the counter atomic64?
> >
> > That could work.
>
> atomic_long, perhaps? No need to use 64-bits on 32-bit architectures.
Well, there is, the point is to protect from user triggered overflow..
Say I'm on 32 bit and try to mlock 2G from 100 threads in parallel, I
can't allow the atomic_inc to wrap.
A 64 bit value works OK because I can't create enough threads to push
a 64 bit value into wrapping with at most a 32 bit add.
If you want to use a 32 bit, then I think the algo needs to use a compare
and swap loop with the check_overflow.
Jason
