public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [RFC 0/5] Optimizations for memory handling in smk_write_rules_list()
@ 2013-06-13 15:29 Tomasz Stanislawski
  2013-06-13 15:29 ` [RFC 1/5] security: smack: avoid kmalloc allocations while loading a rule string Tomasz Stanislawski
                   ` (5 more replies)
  0 siblings, 6 replies; 16+ messages in thread
From: Tomasz Stanislawski @ 2013-06-13 15:29 UTC (permalink / raw)
  To: linux-security-module
  Cc: m.szyprowski, kyungmin.park, r.krypa, linux-kernel, casey,
	Tomasz Stanislawski

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


^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2013-08-01 20:01 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-13 15:29 [RFC 0/5] Optimizations for memory handling in smk_write_rules_list() Tomasz Stanislawski
2013-06-13 15:29 ` [RFC 1/5] security: smack: avoid kmalloc allocations while loading a rule string Tomasz Stanislawski
2013-06-15 19:32   ` Casey Schaufler
2013-06-17 11:24     ` Tomasz Stanislawski
2013-06-17 22:38       ` Casey Schaufler
2013-06-13 15:29 ` [RFC 2/5] security: smack: avoid kmalloc() in smk_parse_long_rule() Tomasz Stanislawski
2013-06-15 19:41   ` Casey Schaufler
2013-06-13 15:29 ` [RFC 3/5] security: smack: fix memleak in smk_write_rules_list() Tomasz Stanislawski
2013-06-15 19:54   ` Casey Schaufler
2013-06-13 15:29 ` [RFC 4/5] security: smack: add kmem_cache for smack_rule allocations Tomasz Stanislawski
2013-06-15 20:00   ` Casey Schaufler
2013-06-13 15:29 ` [RFC 5/5] security: smack: add kmem_cache for smack_master_list allocations Tomasz Stanislawski
2013-06-15 20:08   ` Casey Schaufler
2013-06-19 14:08 ` [PATCH] security: smack: fix memleak in smk_write_rules_list() Tomasz Stanislawski
2013-06-28 19:33   ` Casey Schaufler
2013-08-01 20:01   ` Casey Schaufler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox