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

[Roman Yeryomin]

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
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel