Hi Arnaldo,
| Thanks, applied.
many thanks for applying this; it was sooner as expected and I think it would
be good to tidy this up and make it consistent throughout the code. Since I initiated this,
I feel a bit obliged to improve this.
In particular, I have thought about the following scheme which divides warning messages into
two (plus debug) categories
a) GRADE 1: Severe Protocol/Internal Faults
This includes
* violated pre- / postconditions,
* illegal states
* malfunctioning (something is NULL)
I think these messages should not be rate-limited and, catching up on the discussion,
should dump the stack after the warning message.
b) GRADE 2: Plain Misbehaviour
* out-of-memory messages
* Request floods
* protocol violations (wrong message/option format)
To make this consistent, I would like input whether the following is ok with you:
1) use DCCP_BUG for all Grade 1 type of messages, i.e. it would replace
* BUG()
* WARN_ON() (of course with the appropriate message)
* all sections using 'printk(KERN_CRIT ... ); dump_stack()'
2) either keep the LIMIT_NETDEBUG(KERN_WARNING ... ) for Grade 2 or
put it into a macro which would add the __FUNCTION__ thing to it
The point is that, if it is done consistently, (1) can later be replaced with the more
conventional BUG() or WARN_ON() once everyone is sure that the code behaves exactly as it shoulds.
For the moment, as Ian has pointed out, bringing the machine to a grinding halt for every little
problem is probably too much of a nuisance (in the same vein, I would really like to suggest the
return of Unload Hack :0).
If you are ok with this basic scheme, I shall set about and tidy things up, otherwise please let
me know what the constraints should be with regard to warning/bug messages.
Best,
Gerrit
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
