Protect fork() against dll- and exe-updates.

Corinna Vinschen
Sat Nov 14 10:25:00 GMT 2015

Hi Michael,

On Nov 13 17:12, Michael Haubenwallner wrote:
> Hi Corinna,
> have reworked the hardlink-creation from scratch as discussed before,
> now using /var/run/cygfork/ as the top-level hardlinks directory.
> * At process start and during LoadLibrary, handles to all the loaded
>   dlls (including cygwin1.dll) and the main executable are opened.
> * At fork(), immediately before that CreateProcessW, all the dlls
>   registered above are checked by filesystem if they still are
>   identical as loaded in the current process - as long as the
>   /var/run/ directory is on NTFS and the cygfork directory exists.
> * If they are not identical (any more), hardlinks to these dlls are
>   created in subdirectories into /var/run/cygfork/<sid>/.

This description puzzles me a bit.  If the DLLs have changed, isn't
it too late to create the hardlink?!?  I guess I'm missing something.

> * The name of that subdirs is mangled using the /path/to.exe and the
>   most recent ftLastWriteTime found in the list of loaded dlls.
>   This is necessary to allow for one dll to be used by concurrent
>   processes when started before and after that dll's update.
> * The creation and removal of these directories and hardlinks is
>   synchronized via some mutex, which's name contains the same names as
>   the directories created.
> * The removal is done by iterating over all the directories found in
>   /var/run/cygfork/, recreating the mutex-names along these directory
>   names, and removing them only if the named mutex does not exist any
>   more. This ensures to clean up even in case of power-loss or similar.
> * For debugging purpose, if the /var/run/cygfork/.needed file does
>   exist, the hardlinks are created even if the dlls were up-to-date.
> * For inheriting the open file handles and the mutex handle during fork
>   only, their inheritance flag is set before that fork's CreateProcessW,
>   and reset afterwards both in parent and child.
> * For the timing: Building cygwin-2.4.0-0.2 three times, the duration
>   difference is in the range of measuring fault - almost identical for
>   each possible variant vanilla,disabled,enabled,forced.

Wow.  Really?

> More thoughts?

Yes, but I'm not sure yet.  I'm just wondering if /var/run or any
other such dir is such a good idea after all.  I have this vague
notion that a subdir of the directory the DLL is installed in might
be safer in the log run (for DLLs in /bin a subdir of /bin, etc).

> More to discuss?

I'm a bit swamped ATM, but I'll try to take a look into your patch next
week or the week after.  As for discussing, yes, I think so.  Please
keep in mind that your patch is pretty intrusive, so there's certainly
something to discuss :}

I'm planning to fold in the cygwin-acl branch the week after and then
release 2.4.0.  From there on we should create a feature branch from
mainline and apply your changes to perform further testing and tweaking
as necessary.

Sounds ok?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <>

More information about the Cygwin-developers mailing list