Received: by 10.223.164.202 with SMTP id h10csp581639wrb; Thu, 30 Nov 2017 04:20:45 -0800 (PST) X-Google-Smtp-Source: AGs4zMbxLdaiaz2CYOy6ak8yjltHzB1zQEqs5ReP+DkVgvPQV/uycd7Ol9ESnTlu3yDfOw6seGSn X-Received: by 10.159.229.200 with SMTP id t8mr2506125plq.346.1512044445619; Thu, 30 Nov 2017 04:20:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512044445; cv=none; d=google.com; s=arc-20160816; b=mH3xrya8QWvDhc+blJqAarBqNrsLfxvVjGWOYEJ6AqBWUJasg3lgk51X4SIidQ9i9q rDuppWypFkYGJWFHGQI5jC9XLSVNQ9ozscTmojA7Bc2cayhcMwldO7ZcUuma2/ioHkTD Q53Bs+NBWwD3T8EtL5LHm/WtN2nS+E8JWcEgTsWJHHxnNcrc3F+81BARxolUzrQU4PJP /Pvn0pS78L0SR+e9gY0t64R4GiJqcdgqfH+OSQ3PXYxFNM0cn053CSdG0ELuyvI7BoQk lgFGox0R45gOvbs9BJ1bkhZlhE4Nb73SvBf1ayMwA1bRGFn6lrGrYt7lGtFo4kKJm2vZ KodQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from :arc-authentication-results; bh=bywhgPzMjyvHoHLwcWXgr7y26MoFZA8CjFIRQSMnOCo=; b=X5BD4OOxGHXVBpgPZb+wKjzvAcDI3NywyvpdzPmgWDh/+3dc2ErL9y5i6j0knC9oKI ahPU5dxRALlmT9Rn476xBbHsM4yeHCgY9GOawtHl4uOBQMNkzVv28zUiFegCFSIkI7nw zYnw48MuQLwONrI2g6mBdSlCpc42LSbZ/zEi+lHMBvXzPORIsJSRLlesPu2PlSrhJkKi ANOyd+XGPM/Wmwc8EDHiUmedYA2zTCoQa5I/UnblkWbH7LqbzNM/91mAtamEAyxQBpGi 41svZMjaovnGNm+Xhbbgi+boFCD+Ue3XbTMLHny/SFL/34Vq3ZGM+aQ2EAR4Is9QvncG 38bA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 202si2946661pge.274.2017.11.30.04.20.31; Thu, 30 Nov 2017 04:20:45 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752123AbdK3MUP (ORCPT + 99 others); Thu, 30 Nov 2017 07:20:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58512 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750891AbdK3MUO (ORCPT ); Thu, 30 Nov 2017 07:20:14 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 91F7E76A06; Thu, 30 Nov 2017 12:20:14 +0000 (UTC) Received: from helium (unknown [10.36.118.58]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1C3546031E; Thu, 30 Nov 2017 12:20:12 +0000 (UTC) From: Giuseppe Scrivano To: Andrew Morton 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 References: <20171127125550.15514-1-gscrivan@redhat.com> <20171128135316.6d7bba7fe909ba3d90e318db@linux-foundation.org> <87wp29l6h3.fsf@redhat.com> <20171129141744.5d401ff613116b0bde02cff3@linux-foundation.org> Date: Thu, 30 Nov 2017 13:20:11 +0100 In-Reply-To: <20171129141744.5d401ff613116b0bde02cff3@linux-foundation.org> (Andrew Morton's message of "Wed, 29 Nov 2017 14:17:44 -0800") Message-ID: <87o9nkj6v8.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 30 Nov 2017 12:20:14 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andrew Morton writes: > On Wed, 29 Nov 2017 11:33:28 +0100 Giuseppe Scrivano wrote: > >> Andrew Morton 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. thanks for the hints. Indeed, that was a mistake on my side as I didn't use CONFIG_DEBUG_ATOMIC_SLEEP=y. The might_sleep() warning is correctly raised once I enable CONFIG_DEBUG_ATOMIC_SLEEP (and the other options suggested in submit-checklist.rst). Giuseppe From 1585440525566939419@xxx Wed Nov 29 22:18:29 +0000 2017 X-GM-THRID: 1585224021535347143 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread