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
Received on Thu Jun 19 13:40:50 2014