On Sat, Dec 15, 2007 at 02:34:42PM +0800, Herbert Xu wrote:
> On Sat, Dec 15, 2007 at 05:31:30PM +1100, Benjamin Herrenschmidt wrote:
> >
> > That's something I've actually never quite liked... the fact that we
> > evaluate the expression anyway. I'm pretty happy with -not- evaluating
> > the expre
On Sat, Dec 15, 2007 at 02:52:11PM +0800, Herbert Xu wrote:
> On Sat, Dec 15, 2007 at 02:04:49PM +0800, Herbert Xu wrote:
> >
> > I suppose we'll have to either introduce a new primitive or just
> > go back to using BUG_ON.
>
> Let's do the conservative thing and add a new primitive.
>
> [PATCH]
On Sat, Dec 15, 2007 at 02:04:49PM +0800, Herbert Xu wrote:
>
> I suppose we'll have to either introduce a new primitive or just
> go back to using BUG_ON.
Let's do the conservative thing and add a new primitive.
[PATCH] Added BARF_ON/BARF_ON_ONCE
The description of CONFIG_BUG clearly states tha
On Fri, Dec 14, 2007 at 11:52:18PM -0600, Matt Mackall wrote:
> Then I kindly submit that you should instead withdraw the code that
> allows you to use WARN_ON in a condition in the first place.
>
> Note that Dave Jones is currently poking at making WARN_ON
> out-of-line, so you're liable t
On Sat, Dec 15, 2007 at 05:31:30PM +1100, Benjamin Herrenschmidt wrote:
>
> That's something I've actually never quite liked... the fact that we
> evaluate the expression anyway. I'm pretty happy with -not- evaluating
> the expression when CONFIG_BUG is on most of the time since whatever is
> in th
On Fri, 2007-12-14 at 21:27 +0800, Herbert Xu wrote:
> Hi:
>
> [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
>
> The description of CONFIG_BUG clearly states that both BUG and
> WARN_ON may be skipped. However, our actual implementation still
> checks the
On Sat, Dec 15, 2007 at 12:12:00AM -0600, Matt Mackall wrote:
>
> I tend to agree with this position, except when it comes to handling
> filesystems, where panic is often (but not always) the right thing to
> do.
Given the choice between crashing the machine or potentially giving
an attacker remot
On Fri, 2007-12-14 at 12:02 -0600, Matt Mackall wrote:
>
> I added CONFIG_BUG, and I think the current behavior is correct. As
> you've noticed, we have to evaluate condition, it may have
> side-effects. And if code does:
>
> /* this indicates a driver bug, report and fail gracefully */
On Sat, Dec 15, 2007 at 02:04:49PM +0800, Herbert Xu wrote:
> On Fri, Dec 14, 2007 at 11:52:18PM -0600, Matt Mackall wrote:
> >
> > No. The code as written above should reduce to:
> >
> > if (val == NULL)
> > return -EFAULT;
> >
> > If I hadn't wanted to return -EFAULT in this cas
On Fri, Dec 14, 2007 at 11:52:18PM -0600, Matt Mackall wrote:
>
> No. The code as written above should reduce to:
>
> if (val == NULL)
> return -EFAULT;
>
> If I hadn't wanted to return -EFAULT in this case, I would have just written:
>
> WARN_ON(val == NULL);
Well the
On Sat, Dec 15, 2007 at 12:16:59PM +0800, Herbert Xu wrote:
> On Fri, Dec 14, 2007 at 12:02:46PM -0600, Matt Mackall wrote:
> >
> > I added CONFIG_BUG, and I think the current behavior is correct. As
> > you've noticed, we have to evaluate condition, it may have
> > side-effects. And if code does:
On Fri, Dec 14, 2007 at 12:02:46PM -0600, Matt Mackall wrote:
>
> I added CONFIG_BUG, and I think the current behavior is correct. As
> you've noticed, we have to evaluate condition, it may have
> side-effects. And if code does:
>
> /* this indicates a driver bug, report and fail gracefully
On Fri, Dec 14, 2007 at 09:27:55PM +0800, Herbert Xu wrote:
> Hi:
>
> [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
>
> The description of CONFIG_BUG clearly states that both BUG and
> WARN_ON may be skipped. However, our actual implementation still
> ch
Hi:
[PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
The description of CONFIG_BUG clearly states that both BUG and
WARN_ON may be skipped. However, our actual implementation still
checks the condition on WARN_ON if it's used as part of an if
statement or such.
This patch
14 matches
Mail list logo
