Message-id: <1371137352-31273-1-git-send-email-t.stanislaws@samsung.com>
Date:	Thu, 13 Jun 2013 17:29:07 +0200
From:	Tomasz Stanislawski <t.stanislaws@...sung.com>
To:	linux-security-module@...r.kernel.org
Cc:	m.szyprowski@...sung.com, kyungmin.park@...sung.com,
	r.krypa@...sung.com, linux-kernel@...r.kernel.org,
	casey@...aufler-ca.com,
	Tomasz Stanislawski <t.stanislaws@...sung.com>
Subject: [RFC 0/5] Optimizations for memory handling in smk_write_rules_list()

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists