[OpenWrt-Devel] [RFC] fstools/overlayfs race condition

John Crispin blogic at openwrt.org
Mon Mar 7 08:36:58 EST 2016

On 07/03/2016 14:34, Roman Yeryomin wrote:
> On 7 March 2016 at 15:09, John Crispin <blogic at openwrt.org> 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

at best only the changes get lost, at worste it hangs and burns ...
would need to look in detail but we most likely do a lazy unount so
changes will simply get lost
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list