Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1300060
| From | Manfred Spraul <manfred@colorfullife.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: GPF in shm_lock ipc |
| Date | 2016-01-02 12:40 +0100 |
| Message-ID | <qMsHn-7xw-1@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <qiYi5-2kQ-5@gated-at.bofh.it> <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> |
| Organization | linux.* mail to news gateway |
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()?
--
Manfred
--
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/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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