The LoadPersistent*()/SavePersistent*() functions caused moddata to be
tagged with ->unloaded=1. Though it seems it caused no real issues this
is not good... we now properly tag them as 0 and the like. Also did a
code cleanup / overhaul on that system as well.
For other ModData we now handle the case where a module is loaded with
with a newer version and that newer version is no longer having certain
moddata, eg the name changed or it no longer needs it.
KNOWN ISSUE:
Unfortunately we cannot call the free function for the old moddata that
is no longer being handled by the newer version of the module, since the
module is already unloaded. So this will result in a memory leak, but
not in a crash.
KNOWN ISSUE:
Similarly, for SavePersistentPointer() there is a free function, again
this is called just fine if the module is permanently unloaded but NOT
if the module is reloaded with the same name and no longer is interested
in the persistent pointer object. Again, here too, that would result
in a memory leak but not in a crash.
Fortunately the "known issues" are rare. Fixing these is impossible
with the current module API because modules are unloaded after MOD_TEST
and before MOD_INIT, and only after MOD_INIT we know which moddata
is handled by the new version of the module. To change that we would
need to keep the old module around until after MOD_INIT of the new
module (so we can call free functions in the old module), but that
means delaying the MOD_UNLOAD for the old modules until after MOD_INIT
of the new modules, which changes the sequence too much that i don't
dare to do that. For example, it would mean a database save routine
in the old module would only be called after MOD_INIT finished in the
new module, which may be unexpected since right now MOD_UNLOAD is
called before MOD_INIT and maybe the db loading is done in MOD_INIT,
which would need to be moved to MOD_LOAD. That's just one example,
there may be others. I think such a change can only be done on a major
UnrealIRCd version change, so we will have to live this for now.
As said, fortunately it is a corner case.
When a module was unloaded (for good) that used MODDATATYPE_CLIENT
or MODDATATYPE_LOCAL_CLIENT we walked the client_list/lclient_list
and freed the moddata entry for all these clients, but we did not
walk the unknown_list, so connections in process.
That's bad, because sometimes such moddata is allocated in
HOOKTYPE_HANDSHAKE or in other routines pre-connect and since
we skipped freeing them while the module was still loaded, it
means we leak memory since it is also not freed on user exit.
Since unloading modules permanently is not a common procedure,
combined with the timing of it happening during a handshake, it
took a while before this issue was found (and then easily fixed).
There's also another moddata issue, but that is for next commit.
[skip ci]
This broke SASL services autodetection and also sasl=x,y,z in CAP.
Reported by Valware in https://bugs.unrealircd.org/view.php?id=5960
Of course the easiest solution would be just to set .remote_write=1
for this, which is what I've just done for the 5.2.1.1 release.
But there seems to be a pattern here. When a server wants to write
its own object (irc1.example.net writing to the MD object of
irc1.example.net) we have the problem that that object is both
"our client" and from the other server POV it is "themselves".
On one hand you may want to allow that (eg for 'saslmechlist'), on
the other hand a server writing its own 'certfp' sounds like a bad
idea in principle.
So we now add a new option for the 'self' case and make some MD
objects use it. In fact, in the core we now have zero MD objects
using remote_write. We keep the option available though, for example
for k4be's geoip modules and possibly future features.
Module API change:
* .self_write added which allows a server to write to its own object
(irc1.example.net writing to the MD object of irc1.example.net)
* .remote_write still exists too if you want to allow remote servers
to write to your own objects
* Note that in all cases, servers can always write to their own
(child) client objects.
Changes:
* The link-security MD changed from .remote_write=1 to .self_write=1
* The salmechslist MD now has .self_write=1, this fixes the actual bug
Modules can still opt-in via mreq.remote_write=1 to allow it for
certain moddata.
For example, k4be may want to do this for his geoip-base module which
allows a single server to set moddata "geoip" for all connecting clients,
including remote clients.
If you are a moddata provider then you can enable it like this:
ModDataInfo mreq;
[..]
#if UNREAL_VERSION_TIME >= 202125
mreq.remote_write = 1;
#endif
[..]
See discussion on https://github.com/unrealircd/unrealircd/pull/142
This was a FIXME item that should have been addressed earlier.
We didn't use any MODDATATYPE_CHANNEL in the core up to now so
this was overlooked. We do use it from now on, though, and it
may very well have been used in 3rd party modules already.
This so I - and others - don't constantly have to wonder whether the client
is called sptr, cptr or acptr in a simple routine.
Insane --> 212 files changed, 6814 insertions(+), 6945 deletions(-)
Couldn't just mass-replace of course since there are places where there
are multiple clients involved. So had to check each function.
Also renamed some 'acptr' to 'target' and such.
I will write a page with new style rules later.. but in short if there is
only 1 client involved it will now be called 'client'.
This so we have a few simple concepts:
Client: this can be a user, server, or something unknown yet
Then the type of clients:
User: this is a user, someone with a nick name.
Server: this is a server
Etc.
aChannel to Channel, and some more. Third party module coders will
love this. But.. it makes things more logical and the doxygen output
will look more clean and logical as well.
(More changes will follow)
Bram Matthys