lkml.org 
[lkml]   [2016]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: GPF in shm_lock ipc
From
Date
Hi Dmitry,

On 01/02/2016 01:19 PM, Dmitry Vyukov wrote:
> 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).
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


\
 
 \ /
  Last update: 2016-01-02 17:41    [W:0.111 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site