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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>