From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751591AbcABLpM (ORCPT ); Sat, 2 Jan 2016 06:45:12 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:33403 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751197AbcABLpK (ORCPT ); Sat, 2 Jan 2016 06:45:10 -0500 Subject: Re: [PATCH, RESEND] ipc/shm: handle removed segments gracefully in shm_mmap() To: "Kirill A. Shutemov" , "Kirill A. Shutemov" , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Dmitry Vyukov References: <1447232220-36879-1-git-send-email-kirill.shutemov@linux.intel.com> <20151111170347.GA3502@linux-uzut.site> <20151111195023.GA17310@node.shutemov.name> <20151113053137.GB3502@linux-uzut.site> <20151113091259.GB28904@node.shutemov.name> <20151113192310.GC3502@linux-uzut.site> From: Manfred Spraul Message-ID: <5687B843.2040804@colorfullife.com> Date: Sat, 2 Jan 2016 12:45:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151113192310.GC3502@linux-uzut.site> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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