Message-ID: <20081217153704.4238.qmail@science.horizon.com>
From: "George Spelvin" <linux@horizon.com>
Date: Wed, 17 Dec 2008 10:37:04 -0500
To: linux@horizon.com, andi@firstfloor.org
Cc: tj@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] globmatch() helper function
References: <20081217104247.28440.qmail@science.horizon.com>
 <87hc530w39.fsf@basil.nowhere.org>
In-Reply-To: <87hc530w39.fsf@basil.nowhere.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

Andi Kleen <andi@firstfloor.org> wrote:

> I'm uneasy with the unbounded recursion. Sure currently all the users
> are controlled in kernel source code and expect to put in sane patterns.
> But if someone ever adds a user controlled glob in some way it will be 
> trivial to crash/overwrite memory with the limited kernel stack.
> And with such a generalized function it's likely to be used more
> in the future.

I was just trying to keep the code small and elegant, and adding a
recursion counter or explicit stack would complicate it.

Further, even ignoring the stack space issue, allowing uncontrolled
patterns exposes a second, more insidious bug: due to the naive
backtracking, the run time is (potentially) exponential in the number
of *s present.  That could itself crash a non-preemptive kernel with a
watchdog enabled.

The simple fix is a very low limit on non-trailing * patterns (like
maybe 2), but then it's not generalized any more...


I'm willing to be persuaded, but the cost of making it robust against
pathological patterns is significant.  Is it really worth it?
And if it's not actually robust, why include a half-assed solution?

Does anyone else have an opinion on the matter?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/