On Fri 2021-12-10 11:00 +0100, Petr Mladek wrote: > > If someone enables this feature I can't think of a reason why they > > would want to limit this to some arbitrary number. So my preference > > is to remove that limitation completely. I see no point to it. > > I agree with Luis here. We could always add the limit later when > people report some real life problems with too long list. It is > always good to know that someone did some heavy lifting in > the system. Fair enough. > It might be even interesting to remember timestamp of the removal > to match it with another events reported in the system log. I'm not so sure about this. We could gather such details already via Ftrace (e.g. see load_module()). Personally, I'd prefer to maintain a simple list. > > If you just bump the count then its not duplication, it just adds > > more information that the same module name with the same taint flag > > has been unloaded now more than once. > > Please, do not remove records that a module was removed. IMHO, it > might be useful to track all removed module, including the non-tainted > ones. Module removal is always tricky and not much tested. The tain > flags might be just shown as extra information in the output. This is an interesting suggestion. Albeit, as per the subject, I prefer to just keep track of any module that tainted the kernel. That being said, Petr, if you'd prefer to track each module unload/or deletion event, then I would suggest for instance to remove a module once it has been reintroduced or maintain an unload count as suggested by Luis. Please let me know your thoughts. Kind regards, -- Aaron Tomlin
