Protect fork() against dll- and exe-updates.
Corinna Vinschen
corinna-cygwin@cygwin.com
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?
Thanks,
Corinna
--
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: <http://cygwin.com/pipermail/cygwin-developers/attachments/20151114/305f8b88/attachment.sig>
More information about the Cygwin-developers
mailing list