All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <srostedt@redhat.com>,
	George Spelvin <linux@horizon.com>,
	andi@firstfloor.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] globmatch() helper function
Date: Thu, 18 Dec 2008 01:45:44 +0900	[thread overview]
Message-ID: <49492CB8.4040303@kernel.org> (raw)
In-Reply-To: <1229531764.21171.0.camel@lappy.programming.kicks-ass.net>

Peter Zijlstra wrote:
> On Thu, 2008-12-18 at 01:33 +0900, Tejun Heo wrote:
>> Steven Rostedt wrote:
>>> On Thu, 2008-12-18 at 01:22 +0900, Tejun Heo wrote:
>>>> Hello,
>>>>
>>>> George Spelvin wrote:
>>>>> Do people think that would be, on balance, better?  It would be plenty
>>>>> good enough for the blacklist application.
>>>> Just pass a depth parameter and trigger WARN_ON() and return -EINVAL
>>>> when it exceeds ten.  It's a five minute change and should be enough
>>>> for kernel usages.
>>> If this is ever expected to be used by userspace, I would not include
>>> the WARN_ON. If this is a generic function, then I'll include in in
>>> ftrace as well, and that takes userspace input. The last thing I want is
>>> a DoS because of printk's to the serial console because some userspace
>>> app is constantly writing bad patterns to this file.
>> Well, then, how about printk_ratelimit()?  Having one too many
>> asterisk will be a very rare occasion and when it happens it's
>> something which can easily escape attention, so I think some form of
>> whining is in order.
> 
> having the write fail with -EINVAL seems suitably whiney..

Yeah, I suppose so but that makes return value handling weird.  -EINVAL
for error, 0 for mis-match and 1 for match.  Three-way returns are
usually very sucky to handle and error-prone, so I was thinking about
returning -EINVAL in the internal function and printing out the caller
address and pattern on ratelimit or once.

Thanks.

-- 
tejun

  reply	other threads:[~2008-12-17 16:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-17 10:42 [RFC] globmatch() helper function George Spelvin
2008-12-17 13:28 ` Andi Kleen
2008-12-17 15:15   ` Peter Zijlstra
2008-12-17 15:47     ` Steven Rostedt
2008-12-17 16:15       ` Andi Kleen
2008-12-18  8:00       ` George Spelvin
2008-12-18  8:55         ` George Spelvin
2008-12-18 19:53           ` Casey Dahlin
2008-12-18 21:53             ` George Spelvin
2008-12-17 16:04     ` George Spelvin
2008-12-17 16:13       ` Steven Rostedt
2008-12-17 16:22       ` Tejun Heo
2008-12-17 16:31         ` Steven Rostedt
2008-12-17 16:33           ` Tejun Heo
2008-12-17 16:36             ` Peter Zijlstra
2008-12-17 16:45               ` Tejun Heo [this message]
2008-12-17 16:37             ` Steven Rostedt
2008-12-17 16:51               ` Andi Kleen
2008-12-17 16:54                 ` Steven Rostedt
2008-12-17 15:37   ` George Spelvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49492CB8.4040303@kernel.org \
    --to=tj@kernel.org \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@horizon.com \
    --cc=peterz@infradead.org \
    --cc=srostedt@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.