Messages in this thread | | | Subject | Re: GPF in shm_lock ipc | From | Manfred Spraul <> | Date | Sat, 2 Jan 2016 16:58:52 +0100 |
| |
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
| |