Re: GPF in shm_lock ipc

[Manfred Spraul]

Hi Dmitry,

On 01/02/2016 01:19 PM, Dmitry Vyukov wrote:
> On Sat, Jan 2, 2016 at 12:33 PM, Manfred Spraul
> <manfred@xxxxxxxxxxxxxxxx> wrote:
> > Hi Dmitry,
> >
> > shm locking differs too much from msg/sem locking, I never looked at it in
> > depth, so I'm not able to perform a proper review.
> >
> > Except for the obvious: Races that can be triggered from user space are
> > inacceptable.
> > Regardless if there is a BUG_ON, a WARN_ON or nothing at all.
> >
> > On 12/21/2015 04:44 PM, Dmitry Vyukov wrote:
> > > > +
> > > > +/* This is called by fork, once for every shm attach. */
> > > > +static void shm_open(struct vm_area_struct *vma)
> > > > +{
> > > > +       int err = __shm_open(vma);
> > > > +       /*
> > > > +        * We raced in the idr lookup or with shm_destroy().
> > > > +        * Either way, the ID is busted.
> > > > +        */
> > > > +       WARN_ON_ONCE(err);
> > > >    }
> > Is it possible to trigger this race? Parallel IPC_RMID & fork()?
> Hi Manfred,
>
> As far as I see my reproducer triggers exactly this warning (and later a crash).
Do I understand it right, shm_open() is also called by remap()?
Then please update the comment above shm_open().

And: If this is something that userspace can trigger, why a WARN_ON_ONCE()?
If the WARN_ON doesn't indicate a bug, then I would remove it entirely.

--
    Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/