kit memory use ...
Gabriel Masei
gabriel.masei at 1and1.ro
Thu Apr 23 10:43:30 UTC 2020
Hi Michael,
I've uploaded a patch for this: https://gerrit.libreoffice.org/c/online/+/92752. Can you take a look into it ?
Best Regards,
Gabriel Masei
Senior C/C++ Developer, Free Products Development Romania
Phone: +40 31 223 90 62
Mobile: +40 721 934 131
gabriel.masei at 1and1.ro
1&1 Internet Development Romania SRL
Sky Tower, 246C Calea Floreasca,
13th Floor, 014476, RO Bucharest
________________________________________
From: Michael Meeks <michael.meeks at collabora.com>
Sent: Monday, February 3, 2020 3:17 PM
To: Gabriel Masei
Cc: libreoffice-dev; Ashod Nakashian
Subject: kit memory use ...
Hi Gabriel,
As discussed, this is a fun one =)
We have to open the /proc/self/smaps file just after we fork the
loolkit worker, and just before we drop capabilities - cf. kit/Kit.cpp.
Any attempts to open it after that, or from wsd will not succeed due to
kernel paranoia: fair enough.
In a unipoll world - we could have a second local thread to read that
data from the kit and send it to wsd / Admin code.
But - that's painful around making our existing (rather pleasant)
single-threaded, easy to reason about lock-free poll loop far more complex.
The approach I'd love to see here is a simpler one:
* we pass the fd across the unix socket the kit has
to WSD using:
https://stackoverflow.com/questions/28003921/sending-file-descriptor-by-linux-socket?answertab=votes#tab-top
* then move the memory polling magic from the Kit
process to the Admin socket poll - which is where
it belongs. Then we can kill bad guys based
on policy from the Admin poll.
That should be beautiful, simplify the IPC logging we have
significantly, make logs shorter, cleaner, and prettier.
And life should be cleaner & prettier =)
Sounds good ?
Michael.
--
michael.meeks at collabora.com <><, GM Collabora Productivity
Hangout: mejmeeks at gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
More information about the LibreOffice
mailing list