On Thu, Jun 19, 2014 at 09:13:01AM +0300, Mika Korhonen wrote: > 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 b37199e626b31e1175fb06764c5d1d687723aac2 Jan > 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? The main question is, does it work as expected with the hunk left out or do you get strange effects inside a guest when coming near / or trying to cross it upwards? I will look into this soon. Thanks, Herbert > -- > Mika Korhonen > SW specialist, Symbio