[PATCH 5/6] forkables: Keep hardlinks disabled via shared mem.

2016-03-30 Thread Michael Haubenwallner
To avoid the need for each process to check the filesystem to detect that hardlink creation is impossible or disabled, cache this fact in shared memory. Removing cygfork directory while in use does disable hardlinks creation. To (re-)enable hardlinks creation, the cygfork directory has to exist

Re: [PATCH 4/6] forkables: Protect fork against dll-, exe-updates.

2016-03-30 Thread Michael Haubenwallner
On 03/30/2016 09:04 PM, Yaakov Selkowitz wrote: > On 2016-03-30 13:53, Michael Haubenwallner wrote: >> To support in-cygwin package managers, the fork() implementation must >> not rely on .exe and .dll files to stay in their original location, as >> the package manager's job is to replace these

Re: [PATCH 0/6] Protect fork() against dll- and exe-updates.

2016-03-30 Thread Michael Haubenwallner
On 03/30/2016 08:55 PM, Daniel Colascione wrote: > > > On 03/30/2016 11:53 AM, Michael Haubenwallner wrote: >> Hi, >> >> this is the updated and split series of patches to use hardlinks >> for creating the child process by fork(), in reply to >>

Re: [PATCH 4/6] forkables: Protect fork against dll-, exe-updates.

2016-03-30 Thread Yaakov Selkowitz
On 2016-03-30 13:53, Michael Haubenwallner wrote: To support in-cygwin package managers, the fork() implementation must not rely on .exe and .dll files to stay in their original location, as the package manager's job is to replace these files. Instead, we use the hardlinks to the original

Re: [PATCH 0/6] Protect fork() against dll- and exe-updates.

2016-03-30 Thread Daniel Colascione
On 03/30/2016 11:53 AM, Michael Haubenwallner wrote: > Hi, > > this is the updated and split series of patches to use hardlinks > for creating the child process by fork(), in reply to > https://cygwin.com/ml/cygwin-developers/2016-01/msg2.html >

[PATCH 3/6] forkables: Create forkable hardlinks, yet unused.

2016-03-30 Thread Michael Haubenwallner
In preparation to protect fork() against dll- and exe-updates, create hardlinks to the main executable and each loaded dll in subdirectories of /var/run/cygfork/, if that one exists on the NTFS file system. The directory names consist of the user sid, the main executable's NTFS IndexNumber, and

[PATCH 1/6] forkables: Store dll file name as full NT path.

2016-03-30 Thread Michael Haubenwallner
In preparation to protect fork() against dll- and exe-updates, store any dll file name as full NT path. Additionally, keep a file handle open for each loaded dll file for subsequent hardlink creation. The earlier we open a handle to the dll file, the lower is the chance the dll file has been

[PATCH 0/6] Protect fork() against dll- and exe-updates.

2016-03-30 Thread Michael Haubenwallner
Hi, this is the updated and split series of patches to use hardlinks for creating the child process by fork(), in reply to https://cygwin.com/ml/cygwin-developers/2016-01/msg2.html https://cygwin.com/ml/cygwin-developers/2016-03/msg5.html http://thread.gmane.org/gmane.os.cygwin.devel/1378

[PATCH 4/6] forkables: Protect fork against dll-, exe-updates.

2016-03-30 Thread Michael Haubenwallner
To support in-cygwin package managers, the fork() implementation must not rely on .exe and .dll files to stay in their original location, as the package manager's job is to replace these files. Instead, we use the hardlinks to the original binaries in /var/run/cygfork/ to create the child process

[PATCH 2/6] forkables: Track main executable and cygwin1.dll.

2016-03-30 Thread Michael Haubenwallner
In preparation to protect fork() against dll- and exe-updates, even for the main executable and cygwin1.dll store the file name as full NT path, and keep handles to the files open for subsequent hardlink creation. Create the child process using the main executable's file name converted from the

Re: [PATCH 3/3] Use just-built gcc for windres

2016-03-30 Thread Corinna Vinschen
On Mar 23 09:34, Peter Foley wrote: > When building cygwin in a combined tree with binutils, > the just-built windres cannot find the just-buit gcc automatically. > Parse the CC env variable to use the correct compiler, rather then > falling back to the build-system's gcc which does not define the

Re: [PATCH] fix typo in netinit/ip.h

2016-03-30 Thread Corinna Vinschen
On Mar 30 09:15, Peter Foley wrote: > The type for the ip_tos member was typoed, fix it. > > winsup/cygwin/ChangeLog: > include/netinet/ip.h: fix type of ip_tos Thanks for catching. Applied. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin

[PATCH] fix typo in netinit/ip.h

2016-03-30 Thread Peter Foley
The type for the ip_tos member was typoed, fix it. winsup/cygwin/ChangeLog: include/netinet/ip.h: fix type of ip_tos Signed-off-by: Peter Foley --- winsup/cygwin/include/netinet/ip.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 06/11] Remove always true nonnull check on "this" pointer.

2016-03-30 Thread Peter Foley
On Wed, Mar 30, 2016 at 7:24 AM, Corinna Vinschen wrote: > Hi Peter, > > On Mar 19 13:45, Peter Foley wrote: >> G++ 6.0 can assert that the this pointer is non-null for member functions. > > Maybe, but if it compains, it's bound to find false positives... > Alright,

Re: [PATCH v2 1/3] Add option to not build mingw programs when cross compiling.

2016-03-30 Thread Peter Foley
On Wed, Mar 30, 2016 at 8:11 AM, Corinna Vinschen wrote: > Applied with changes. The below check was skewed. > >> +if test "x$with_mingw_progs" != xyes; then >> +AC_CONFIG_SUBDIRS([utils lsaauth]) >> +fi Whoops, good catch.

Re: [PATCH 3/3] Use just-built gcc for windres

2016-03-30 Thread Peter Foley
On Wed, Mar 30, 2016 at 8:31 AM, Corinna Vinschen wrote: > Are you sure this works as desired? In my standard cross build > environment, the only -B option added here is > > --preprocessor-arg=-B/build/cygwin/x86_64/vanilla/x86_64-pc-cygwin/newlib/ The only case in

Re: [PATCH 3/3] Use just-built gcc for windres

2016-03-30 Thread Corinna Vinschen
On Mar 23 09:34, Peter Foley wrote: > When building cygwin in a combined tree with binutils, > the just-built windres cannot find the just-buit gcc automatically. > Parse the CC env variable to use the correct compiler, rather then > falling back to the build-system's gcc which does not define the

Re: [PATCH v2 1/3] Add option to not build mingw programs when cross compiling.

2016-03-30 Thread Corinna Vinschen
On Mar 23 09:34, Peter Foley wrote: > Add an option to not require a mingw compiler when bootstrapping a cross > toolchain. > Defaults to existing behavior. > Also update some obsolete macros. Applied with changes. The below check was skewed. > +if test "x$with_mingw_progs" != xyes; then > +