lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 16 Feb 2016 23:46:49 +0000 From: Edward Cree <ec429@...tab.net> To: linux-kernel@...r.kernel.org Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org> Subject: Idea for reducing sysfs memory usage Sorry if this has been suggested before, but if so I couldn't find it. Short version: could a sysfs dir reference a list of default attributes rather than having to instantiate them all? Long version: If I'm understanding correctly, when creating a sysfs dir for a kobject, we call populate_dir() and create a sysfs file for each of its default_attrs. This leads to some memory allocations, which apparently can really add up when, for instance, using a large number of netdevices (mostly software devices like VLANs and bonds whose sysfs files will probably never actually be used anyway). At netdev1.1, a use case was presented for thousands - perhaps even hundreds of thousands - of such netdevices, at which point the memory overhead for all those sysfs files becomes quite significant. Thus I was wondering if it would be feasible to replace the instantiation of these default attributes with, in principle, a pointer to the default_attr list, which already contains the methods needed to show or store the attribute, and need not be duplicated for each sysfs dir referring to it. In practice it would probably make sense to build a fast-lookup data structure from the list when the latter is first created, since the list is (as I understand it) never changed. Then for instance, a lookup on the directory would search both the default attrs list and the rbtree of runtime-added nodes. I don't think it would ever be necessary for runtime code to _remove_ a default attribute from a dir, but if it were, then perhaps a negative entry could be added to the rbtree, and that tree could always be searched first - then, if the negative entry was found, the search of the default list would be skipped. Of course, all the other operations on the directory would similarly have to be modified to take account of there being two places in which an attribute could be defined, but I believe (perhaps naïvely) that this would not be excessively painful. This could potentially save memory whenever large numbers of directories of the same 'type' are created in sysfs; not just netdevices, but also for instance PCI devices and their 'power' subdirectories. While it would slightly slow down sysfs accesses, I can't quite imagine a situation in which the speed of sysfs would be critical to system performance - though perhaps that is just my ignorance. Is there an obvious reason why I can't do this, or should I dive in and try to implement it? (Or should I first just try to estimate how much memory it would save, to find out whether it would be worth the complexity?) Not subscribed to list; please Cc on replies. -- -ed
Powered by blists - more mailing lists