Re: GPF in shm_lock ipc

From	Dmitry Vyukov <dvyukov@google.com>
Newsgroups	linux.kernel
Subject	Re: GPF in shm_lock ipc
Date	2016-01-02 13:30 +0100
Message-ID	<qMttM-83b-7@gated-at.bofh.it> (permalink)
References	(6 earlier) <qj721-6Fq-11@gated-at.bofh.it> <qoXt0-20k-3@gated-at.bofh.it> <qrtI6-7PQ-11@gated-at.bofh.it> <qIaSK-8ka-23@gated-at.bofh.it> <qMsHn-7xw-1@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Sat, Jan 2, 2016 at 12:33 PM, Manfred Spraul
<manfred@colorfullife.com> 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).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Thread

Re: GPF in shm_lock ipc Dmitry Vyukov <dvyukov@google.com> - 2015-12-21 16:50 +0100
  Re: GPF in shm_lock ipc Manfred Spraul <manfred@colorfullife.com> - 2016-01-02 12:40 +0100
    Re: GPF in shm_lock ipc Dmitry Vyukov <dvyukov@google.com> - 2016-01-02 13:30 +0100
      Re: GPF in shm_lock ipc Manfred Spraul <manfred@colorfullife.com> - 2016-01-02 17:00 +0100

csiph-web