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>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-MW
Content-Transfer-Encoding: 8bit
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
Precedence: bulk

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.