In article <[EMAIL PROTECTED]>,
Jean Tourrilhes <[EMAIL PROTECTED]> wrote:
>
> I agree that the IrDA stack is full of irq/locking bugs (there
>is a patch of mine waiting in Dag's mailbox), but this one is not a
>bug, it's a false positive.
> The restore_flags(flags); will restore the
On Thu, Mar 22, 2001 at 03:49:31PM -0800, Junfeng Yang wrote:
>
> Sometimes the line number reported by the checker is not correct.
> But if you go into the function, you can find the bug.
Gotcha. It in fact indicate the error at the end of the
function instead of the place where the
Junfeng Yang wrote :
> Hi,
>
> Here are yet more results from the MC project. This checker looks for
> inconsistent usage of interrupt functions.
[...]
> -
> [BUG] error path
>
>
On Thu, Mar 22, 2001 at 03:49:31PM -0800, Junfeng Yang wrote:
Sometimes the line number reported by the checker is not correct.
But if you go into the function, you can find the bug.
Gotcha. It in fact indicate the error at the end of the
function instead of the place where the error
In article [EMAIL PROTECTED],
Jean Tourrilhes [EMAIL PROTECTED] wrote:
I agree that the IrDA stack is full of irq/locking bugs (there
is a patch of mine waiting in Dag's mailbox), but this one is not a
bug, it's a false positive.
The restore_flags(flags); will restore the state of
> Request: can the checker check for skb's being freed correctly? The
> rules:
>
> If an skb is in interrupt context, call dev_kfree_skb_irq.
> If an skb might be in interrupt context, call dev_kfree_skb_any.
> If an skb is not in interrupt context, call dev_kfree_skb.
It shouldn't be hard to
On Sun, 18 Mar 2001, Andrew Morton wrote:
> I'm planning on poking through everything which has been
> identified as a posible problem. But I won't start for
> several weeks - give the maintainers (if any) time to
> address these things.
I took a look at the ISDN issues, here's a patch which
On Sun, 18 Mar 2001, Andrew Morton wrote:
> There's another thing which needs doing to n_r3964.c, BTW - the
> abuse of task queues in r3964_close(). This is, I think, the
> only client of task queues which needs to poke so deeply into
> the implementation internals and Linus has mentioned
Junfeng Yang wrote:
> [BUG] error path
>
> /u2/acc/oses/linux/2.4.1/drivers/net/appletalk/cops.c:776:cops_rx:
>ERROR:INTR:763:804: Interrupts inconsistent, severity `20':804
Fixed.
Request: can the checker check for skb's being freed correctly? The
rules:
If an skb is in interrupt context,
Junfeng Yang wrote:
[BUG] error path
/u2/acc/oses/linux/2.4.1/drivers/net/appletalk/cops.c:776:cops_rx:
ERROR:INTR:763:804: Interrupts inconsistent, severity `20':804
Fixed.
Request: can the checker check for skb's being freed correctly? The
rules:
If an skb is in interrupt context,
On Sun, 18 Mar 2001, Andrew Morton wrote:
There's another thing which needs doing to n_r3964.c, BTW - the
abuse of task queues in r3964_close(). This is, I think, the
only client of task queues which needs to poke so deeply into
the implementation internals and Linus has mentioned something
On Sun, 18 Mar 2001, Andrew Morton wrote:
I'm planning on poking through everything which has been
identified as a posible problem. But I won't start for
several weeks - give the maintainers (if any) time to
address these things.
I took a look at the ISDN issues, here's a patch which
Request: can the checker check for skb's being freed correctly? The
rules:
If an skb is in interrupt context, call dev_kfree_skb_irq.
If an skb might be in interrupt context, call dev_kfree_skb_any.
If an skb is not in interrupt context, call dev_kfree_skb.
It shouldn't be hard to check
David Woodhouse wrote:
>
> [ n_r3964.c stuff ]
> ...
> akpm, were you looking at this?
I'm planning on poking through everything which has been
identified as a posible problem. But I won't start for
several weeks - give the maintainers (if any) time to
address these things.
So.. please go
On Fri, 16 Mar 2001, Junfeng Yang wrote:
> -
> [BUG] return with int disabled in an error path
>
> /u2/acc/oses/linux/2.4.1/drivers/char/n_r3964.c:1036:add_msg: ERROR:INTR:990:995:
>Interrupts inconsistent, severity `20':995
>
>
>
> Your reporting is a little misleading here.
Thanks for verifying these bugs ;)
The interrupt checker checks for inconsistent interrupt states. For
example, if a function has one exit point with interrupt disabled, and
another exit point with interrupt enabled, the checker will report an
error
Junfeng Yang wrote:
>
> ...
>
> [BUG] sleep_or_timeout will call interruptible_sleep_on, which will save disabled
>flags and then restore them.
>
> /u2/acc/oses/linux/2.4.1/drivers/cdrom/cm206.c:474:send_command: ERROR:INTR:462:474:
>Interrupts inconsistent, severity `20':474
>
> if
Junfeng Yang wrote:
...
[BUG] sleep_or_timeout will call interruptible_sleep_on, which will save disabled
flags and then restore them.
/u2/acc/oses/linux/2.4.1/drivers/cdrom/cm206.c:474:send_command: ERROR:INTR:462:474:
Interrupts inconsistent, severity `20':474
if
Your reporting is a little misleading here.
Thanks for verifying these bugs ;)
The interrupt checker checks for inconsistent interrupt states. For
example, if a function has one exit point with interrupt disabled, and
another exit point with interrupt enabled, the checker will report an
error
On Fri, 16 Mar 2001, Junfeng Yang wrote:
-
[BUG] return with int disabled in an error path
/u2/acc/oses/linux/2.4.1/drivers/char/n_r3964.c:1036:add_msg: ERROR:INTR:990:995:
Interrupts inconsistent, severity `20':995
David Woodhouse wrote:
[ n_r3964.c stuff ]
...
akpm, were you looking at this?
I'm planning on poking through everything which has been
identified as a posible problem. But I won't start for
several weeks - give the maintainers (if any) time to
address these things.
So.. please go ahead
Hi,
Here are yet more results from the MC project. This checker looks for
inconsistent usage of interrupt functions. For example, it notices when
interrupts can be either on or off when a function exits. It tracks
cli(), sti(), save_flags() and so forth. We've hand-inspected the results
to
22 matches
Mail list logo
