On 7 March 2016 at 15:09, John Crispin <[email protected]> wrote: > > > On 07/03/2016 14:03, Roman Yeryomin wrote: >> There is a race between `cp -a /tmp/root/* /rom/overlay` from >> libfstools/overlay.c and a process creating new file(s) before >> pivot(/rom, /mnt) occured. >> That is a process can create a file and it will not be copied. >> >> Currently I do additional copy after jffs2 is ready, which is kind of >> cumbersome (see attached patch), but there are still few potentially >> erroneous scenarios: >> 1. a process may recreate the file by the time second cp occurs >> 2. a process may delete a file (not existing at that moment) and >> second cp will copy it again >> 3. a process may want to read created file before second cp occurs >> >> If attached patch is the way to go I will properly submit it. >> Otherwise there should be a more fundamental fix but I don't see a way >> to fix this properly. >> >> > > Hi Roman > > that race has been there since the day we do overlayfs. i am always > surprised that it has not exploded in a big way yet. the only way i see > are workarounds such as yours or sending out lots of SIGSTOP and the > continues when we copied the files. either way it will be ugly and > require protective gear. > > i'll ponder this and see if we can find a better way
Actually I met this long ago, just didn't understand/investigate it was exactly this. What will happen if a process opens a file (t.i. it will have an open descriptor) in tmp root, writes to it and then, in the process of writing, pivot_root() executes? Regards, Roman _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
