On Wed, 29 Nov 2017 11:33:28 +0100 Giuseppe Scrivano <gscri...@redhat.com> wrote:
> Andrew Morton <a...@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.
