[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1156102407.4051.47.camel@localhost.localdomain>
Date: Sun, 20 Aug 2006 20:33:27 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Willy Tarreau <w@....eu>
Cc: Solar Designer <solar@...nwall.com>,
Alex Riesen <fork0@...rs.sourceforge.net>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits
Ar Sul, 2006-08-20 am 21:01 +0200, ysgrifennodd Willy Tarreau:
> 2.4 has no printk_ratelimit() function and I'm not sure it's worth adding
> one for only this user. One could argue that once it's implemented, we can
> uncomment some other warnings that are currently disabled due to lack of
> ratelimit.
Agreed. But if it isnt ratelimited then people will be able to use it
flush other "interesting" log messages out of existance...
>
> In this special case (set*uid), the only reason we might fail is because
> kmem_cache_alloc(uid_cachep, SLAB_KERNEL) would return NULL. Do you think
> it could intentionnally be tricked into failing, or that under OOM we might
> bother about the excess of messages ?
>
> If so I can backport the printk_ratelimit() function, I would just like an
> advice on this.
If there are multiple potential users then a backport might be sensible
-
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