Messages in this thread | | | From | Tomasz Stanislawski <> | Subject | [RFC 0/5] Optimizations for memory handling in smk_write_rules_list() | Date | Thu, 13 Jun 2013 17:29:07 +0200 |
| |
Hi everyone, This patchset focuses on optimizations for memory handling done in smk_write_rules_list(). Basically, all the patches try to avoid calling kmalloc(). I expect that there might be some controversy about these patches.
The first patch introduces a limit for length if SMACK rules in 'long' format. The limit was chosen to handle two long labels (SMK_LONGLABEL) plus access flags plus two separators. Passing a longer rule is likely an error due to too long labels or having a rule string that contains a ridiculous amount of whitespaces. Introducing the limit helps to protect the kernel if userspace (maybe privileged but still userspace) passed too large write(). Calling kmalloc() for a large size wull trigger a significant number of page reclaim actions or even OOM. Moreover, such an allocation is very likely to fail and it should be avoided. Calling vmalloc() would be a much safer idea. Anyway, the buffer is valid only during smk_write_rules_list() therefore allocating a buffer on stack simplifies memory management.
The second patch simplifies memory management in smk_parse_long_rule() and speeds up parsing.
The third patch fixes a potential memory leak in smk_write_rules_list(). I was not able to find any reference to smack_parsed_rule after the function is finished. Notice that smk_user_access() does not use dynamic any allocation for smack_parsed_rule. I kindly ask you to review the patch.
The last two patches uses kmem_cache to avoid wasting memory for padding bytes for the most frequently allocated structures in SMACK.
The patchset provides a small but observable performance improvement of SMACK initialization phase. The results below were collected for 17K rules and 500 labels using command 'time smackctl apply'.
| Run1 | Run2 | Run3 | Run4 | Run5 | Avg | Gain [ms] -------------------------------------------------------------- Ref | 1.177 | 1.174 | 1.177 | 1.179 | 1.171 | 1.176 | 0 patch1 | 1.165 | 1.177 | 1.178 | 1.167 | 1.175 | 1.172 | 3 patch2 | 1.145 | 1.142 | 1.140 | 1.139 | 1.137 | 1.141 | 35 patch3 | 1.117 | 1.128 | 1.126 | 1.129 | 1.124 | 1.125 | 51 patch4 | 1.097 | 1.120 | 1.119 | 1.112 | 1.120 | 1.114 | 62 patch5 | 1.092 | 1.102 | 1.090 | 1.108 | 1.091 | 1.097 | 79
Every patch introduces a tiny bit of speed improvement. Total gain is 7%. It will increase to 15% if the patch for label hashing [1] is applied.
I hope you find this patchset useful. Regards, Tomasz Stanislawski
References: [1] http://thread.gmane.org/gmane.linux.kernel.lsm/19609
Tomasz Stanislawski (5): security: smack: avoid kmalloc allocations while loading a rule string security: smack: avoid kmalloc() in smk_parse_long_rule() security: smack: fix memleak in smk_write_rules_list() security: smack: add kmem_cache for smack_rule allocations security: smack: add kmem_cache for smack_master_list allocations
security/smack/smack.h | 10 ++++ security/smack/smack_lsm.c | 19 ++++++- security/smack/smackfs.c | 122 +++++++++++++++++++------------------------- 3 files changed, 80 insertions(+), 71 deletions(-)
-- 1.7.9.5
| |