Subject: Re: vserver enabled 3.13.9+ and 3.14+ kernels hang on boot
From: Mika Korhonen <mika.korhonen@symbio.com>
Date: Thu, 19 Jun 2014 09:13:01 +0300

On 25/04/14 22:52, Jan Rękorajski wrote:
> Hi, The upstream commit  b37199e626b31e1175fb06764c5d1d687723aac2
 > (rcuwalk: recheck mount_lock after mountpoint crossing attempts) in
 > 3.14 and 3.13.9 functionally invalidated one of the changes to
 > fs/namei.c in vserver patch:
 >
 > @@ -1238,7 +1335,8 @@ static void follow_dotdot(struct nameida
 >
 > if (nd->path.dentry == nd->root.dentry && nd->path.mnt ==
 > nd->root.mnt) { -                       break; +
 > /* for sane '/' avoid follow_mount() */ +
 > return; } if (nd->path.dentry != nd->path.mnt->mnt_root) { /* rare
 > case of legitimate dget_parent()... */
 >
 > With the above hunk applied vserver enabled 3.13.9 or 3.14.x kernel
 > hangs on boot when udev is started from initrd. Reverting it fixes
 > the problem.
 >
 > Does this change serve any purpose other than code path
 > optimization? Should I expect any breakege after removing it?
 >

Hi,

I can confirm that: devtmpfs mounted at /dev is empty with 3.13.11 with 
VServer patch 2.3.6.11
while without the patch it gets populated. This happens on initramfs and 
can be reproduced
by creating a simple initramfs that drops to shell and lets one do mounting:
# mount -t devtmpfs none /dev

New udev relies on devtmpfs and e.g. Ubuntu 14.04 cannot find devices to 
continue to real
root. The commit b37199e626b31e1175fb06764c5d1d687723aac2Jan Rękorajski 
mentions,
changes the behavior so that VServer change breaks the functionality 
from 3.13.9 onwards.

Can the change (break->return) be simply dropped or does it play an 
essential role?

-- 
Mika Korhonen
SW specialist, Symbio