This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

Attachment: pgpSoJbEAm95S.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]