From: Manfred Spraul <manfred@colorfullife.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH, RESEND] ipc/shm: handle removed segments gracefully in shm_mmap()
Date: Sat, 2 Jan 2016 12:45:07 +0100 [thread overview]
Message-ID: <5687B843.2040804@colorfullife.com> (raw)
In-Reply-To: <20151113192310.GC3502@linux-uzut.site>
On 11/13/2015 08:23 PM, Davidlohr Bueso wrote:
>
> So considering EINVAL, even your approach to bumping up nattach by
> calling
> _shm_open earlier isn't enough. Races exposed to user called rmid can
> still
> occur between dropping the lock and doing ->mmap(). Ultimately this
> leads to
> all ipc_valid_object() checks, as we totally ignore SHM_DEST segments
> nowadays
> since we forbid mapping previously removed segments.
>
> I think this is the first thing we must decide before going forward
> with this
> mess. ipc currently defines invalid objects by merely checking the
> deleted flag.
>
> Manfred, any thoughts?
>
With regards to locking: Sorry, shm is too different to msg/sem/mqueue.
With regards to EIDRM / EINVAL:
When all kernel memory was released, then the kernel cannot find out if
the ID was valid at one time or not.
Thus EIDRM can only be a hint, the OS (kernel/libc) cannot guarantee
that user space will never see something else.
(trivial example: user space sleeps just before the syscall)
So I would not create special code to optimize EIDRM handling for races.
If we sometimes report EINVAL, it would be probably ok as well.
--
Manfred
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Manfred Spraul <manfred@colorfullife.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH, RESEND] ipc/shm: handle removed segments gracefully in shm_mmap()
Date: Sat, 2 Jan 2016 12:45:07 +0100 [thread overview]
Message-ID: <5687B843.2040804@colorfullife.com> (raw)
In-Reply-To: <20151113192310.GC3502@linux-uzut.site>
On 11/13/2015 08:23 PM, Davidlohr Bueso wrote:
>
> So considering EINVAL, even your approach to bumping up nattach by
> calling
> _shm_open earlier isn't enough. Races exposed to user called rmid can
> still
> occur between dropping the lock and doing ->mmap(). Ultimately this
> leads to
> all ipc_valid_object() checks, as we totally ignore SHM_DEST segments
> nowadays
> since we forbid mapping previously removed segments.
>
> I think this is the first thing we must decide before going forward
> with this
> mess. ipc currently defines invalid objects by merely checking the
> deleted flag.
>
> Manfred, any thoughts?
>
With regards to locking: Sorry, shm is too different to msg/sem/mqueue.
With regards to EIDRM / EINVAL:
When all kernel memory was released, then the kernel cannot find out if
the ID was valid at one time or not.
Thus EIDRM can only be a hint, the OS (kernel/libc) cannot guarantee
that user space will never see something else.
(trivial example: user space sleeps just before the syscall)
So I would not create special code to optimize EIDRM handling for races.
If we sometimes report EINVAL, it would be probably ok as well.
--
Manfred
next prev parent reply other threads:[~2016-01-02 11:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-11 8:57 [PATCH, RESEND] ipc/shm: handle removed segments gracefully in shm_mmap() Kirill A. Shutemov
2015-11-11 8:57 ` Kirill A. Shutemov
2015-11-11 17:03 ` Davidlohr Bueso
2015-11-11 17:03 ` Davidlohr Bueso
2015-11-11 19:50 ` Kirill A. Shutemov
2015-11-11 19:50 ` Kirill A. Shutemov
2015-11-13 5:31 ` Davidlohr Bueso
2015-11-13 5:31 ` Davidlohr Bueso
2015-11-13 9:12 ` Kirill A. Shutemov
2015-11-13 9:12 ` Kirill A. Shutemov
2015-11-13 19:23 ` Davidlohr Bueso
2015-11-13 19:23 ` Davidlohr Bueso
2015-11-13 19:58 ` Davidlohr Bueso
2015-11-13 19:58 ` Davidlohr Bueso
2015-11-16 9:32 ` Kirill A. Shutemov
2015-11-16 9:32 ` Kirill A. Shutemov
2016-01-02 11:45 ` Manfred Spraul [this message]
2016-01-02 11:45 ` Manfred Spraul
2016-01-04 14:11 ` Kirill A. Shutemov
2016-01-04 14:11 ` Kirill A. Shutemov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5687B843.2040804@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.