X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1566074871;
	bh=XFwB0y7HMq78VroivPs01RU2EQY0Y8saCuluA4N1QdI=;
	h=In-Reply-To:From:Date:References:To:Subject:Message-ID;
	b=ss4hfifLCbV2ut350pl7NrslD9marEwu2jUDUGzPJ/aIC/nGkRUnWZqTs49Da58KU
	ohNRMQzCg0nrMYcJ0zkdmuak10mxv1P166rLJQOna2m/omo67dtxnirh0oIN+biYpH
	ZKqVqJfUZhdS+reAJ4tAr02nod1GAMxNhEitquHI=
Authentication-Results:	mxback9o.mail.yandex.net; dkim=pass header.i=@yandex.ru
Subject:	Re: [PATCH] exec: fix inversions in leak detection logic
To:	djgpp AT delorie DOT com
References:	<964e3268-2f75-ee73-ab5a-b01bf1aadb98 AT yandex DOT ru>
	<qj9iq5$1iqb$2 AT gioia DOT aioe DOT org>
From:	"stsp (stsp2 AT yandex DOT ru) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Message-ID:	<7551dfde-01be-7633-3d12-aab8533b66c7@yandex.ru>
Date:	Sat, 17 Aug 2019 23:47:50 +0300
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
	Thunderbird/60.6.1
MIME-Version:	1.0
In-Reply-To:	<qj9iq5$1iqb$2@gioia.aioe.org>
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id x7HKmURm007967
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

17.08.2019 22:02, Rod Pemberton пишет:
> I'm confused by this patch, but I'm also not familiar with what the
> code does.
In fact, the leaks I am aware of, are coming from
the fact that many DPMI servers do not do the
automatic clean-up of all resources that were
allocated _and not freed_ by the _non-first_ DPMI
client. I.e. if some client frees his resources - no
leak. If he doesn't, and terminates, and there are
no more DPMI clients - the server will free everything.
But if the client terminates w/o freeing its descriptors
and some other DPMI client is still there - the servers
just defer the clean-ups to the time when the last
client exits. This is a quite common practice, and
I suppose this is what that djgpp code was supposed
to fight.
Which means, it was testing __dpmi_free_ldt_descriptor()
to see if it works at all, and if not - disable the work-around
completely as you can't work around the leak if even
__dpmi_free_ldt_descriptor() doesn't work.
If they found __dpmi_free_ldt_descriptor() to work,
they enable work-around to later wipe the "leaked"
descriptors, but the only check if the workaround is
needed at all, is this one:
---
     ret = __dpmi_get_capabilities(&flags, dpmi_vendor);
     if (ret == 0 && strcmp(dpmi_vendor + 2, "CWSDPMI") == 0)
       workaround_descriptor_leaks = 0;
     else
---
For everything else they enable the work-around
if __dpmi_free_ldt_descriptor() works (which means always).

So now as this starting to make some sense, I would
propose the following:
- Stop testing __dpmi_free_ldt_descriptor(), it always works.
- Make the work-around conditional on the user-supplied
flags, rather than on some guess work (and disabled by
default of course).

I'll send the new patch.

- Raw text -