Sorry for spamming you guys with my ugly, poorly formatted hack.
I had to change something due to my shallow knowledge of how
multiprocessors / multiple threads sharing a filter would behave.
There may have been a possibility for the deferred integer to rollover
and ruin everything? just in case someone tries to use it....
From: Michael R Tirado <mtirado...@gmail.com>
Date: Thu, 10 Sep 2015 23:06:55 +0000
Subject: [PATCH 2/2] changed to signed integer, due to multiprocesor
uncertainty.
---
kernel/seccomp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index dc2a5af..e39e8c2 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -58,7 +58,7 @@ struct seccomp_filter {
atomic_t usage;
struct seccomp_filter *prev;
struct bpf_prog *prog;
- unsigned int deferred;
+ int deferred;
};
/* Limit any path through the tree to 256KB worth of instructions. */
@@ -198,7 +198,7 @@ static u32 seccomp_run_filters(struct seccomp_data *sd)
*/
for (; f; f = f->prev) {
u32 cur_ret;
- if (unlikely(f->deferred)) {
+ if (unlikely(f->deferred > 0)) {
--f->deferred;
continue;
}
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
