<div dir="ltr">Maybe fsfreeze can avoid the race condition. (if this works with the involved FS)<div><a href="http://linux.die.net/man/8/fsfreeze">http://linux.die.net/man/8/fsfreeze</a><br></div><div><a href="https://github.com/karelzak/util-linux/blob/master/sys-utils/fsfreeze.c">https://github.com/karelzak/util-linux/blob/master/sys-utils/fsfreeze.c</a><br></div><div><br></div><div>Or just temporary remount source fs as ro. It might make some writing process unhappy but I'll keep file filesystem state.<br></div><div><br></div><div>My two cents.<br></div><div><br></div><div>Regards,</div><div><br><div class="gmail_quote"><div dir="ltr">Em seg, 7 de mar de 2016 às 10:10, John Crispin <<a href="mailto:blogic@openwrt.org">blogic@openwrt.org</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 07/03/2016 14:03, Roman Yeryomin wrote:<br>
> There is a race between `cp -a /tmp/root/* /rom/overlay` from<br>
> libfstools/overlay.c and a process creating new file(s) before<br>
> pivot(/rom, /mnt) occured.<br>
> That is a process can create a file and it will not be copied.<br>
><br>
> Currently I do additional copy after jffs2 is ready, which is kind of<br>
> cumbersome (see attached patch), but there are still few potentially<br>
> erroneous scenarios:<br>
> 1. a process may recreate the file by the time second cp occurs<br>
> 2. a process may delete a file (not existing at that moment) and<br>
> second cp will copy it again<br>
> 3. a process may want to read created file before second cp occurs<br>
><br>
> If attached patch is the way to go I will properly submit it.<br>
> Otherwise there should be a more fundamental fix but I don't see a way<br>
> to fix this properly.<br>
><br>
><br>
<br>
Hi Roman<br>
<br>
that race has been there since the day we do overlayfs. i am always<br>
surprised that it has not exploded in a big way yet. the only way i see<br>
are workarounds such as yours or sending out lots of SIGSTOP and the<br>
continues when we copied the files. either way it will be ugly and<br>
require protective gear.<br>
<br>
i'll ponder this and see if we can find a better way<br>
<br>
        John<br>
_______________________________________________<br>
openwrt-devel mailing list<br>
<a href="mailto:openwrt-devel@lists.openwrt.org" target="_blank">openwrt-devel@lists.openwrt.org</a><br>
<a href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel" rel="noreferrer" target="_blank">https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel</a><br>
</blockquote></div></div></div><div dir="ltr">-- <br></div><p dir="ltr">Luiz Angelo Daros de Luca<br>
<a href="mailto:luizluca@gmail.com">luizluca@gmail.com</a></p>