Andrew Morton <a...@linux-foundation.org> writes: > 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.
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
