From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752725AbdK2WRr (ORCPT <rfc822;w@1wt.eu>);
        Wed, 29 Nov 2017 17:17:47 -0500
Received: from mail.linuxfoundation.org ([140.211.169.12]:46642 "EHLO
        mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752157AbdK2WRq (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 29 Nov 2017 17:17:46 -0500
Date: Wed, 29 Nov 2017 14:17:44 -0800
From: Andrew Morton <akpm@linux-foundation.org>
To: Giuseppe Scrivano <gscrivan@redhat.com>
Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,
        mingo@kernel.org, dave@stgolabs.net
Subject: Re: [RFC PATCH] ipc, mqueue: lazy call kern_mount_data in new
 namespaces
Message-Id: <20171129141744.5d401ff613116b0bde02cff3@linux-foundation.org>
In-Reply-To: <87wp29l6h3.fsf@redhat.com>
References: <20171127125550.15514-1-gscrivan@redhat.com>
        <20171128135316.6d7bba7fe909ba3d90e318db@linux-foundation.org>
        <87wp29l6h3.fsf@redhat.com>
X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 29 Nov 2017 11:33:28 +0100 Giuseppe Scrivano <gscrivan@redhat.com> wrote:

> Andrew Morton <akpm@linux-foundation.org> writes:
> 
> > OK, but this simply moves the expense so it happens later on.  Why is
> > that better?
> 
> the optimization is for new IPC namespaces that don't use mq_open.  In
> this case there won't be any kern_mount_data cost at all.
> 

Fair enough.  Please add this paragraph (or similar) to the changelog:

: This is a net saving for new IPC namespaces that don't use mq_open().  In
: this case there won't be any kern_mount_data() cost at all

And..  the patch calls
kern_mount_data()->vfs_kern_mount()->...->kmem_cache_zalloc(GFP_KERNEL)
under spin_lock().  This should have created a might_sleep() warning in
your testing, but obviously did not.

Could you please find out why?  Do you have
CONFIG_DEBUG_ATOMIC_SLEEP=n, I hope?  Please peruse
Documentation/process/submit-checklist.rst, section 12...

I assume a suitable fix would be to create a new mutex (static to
do_mq_open()) to prevent concurrent mounting.