On Sun, Oct 14, 2012 at 3:32 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
>
> The client-side XDR encoder functions don't return a return value. Upper layers can not find out there was a problem if marshalling fails. That's why we use BUG_ON here
The above is STILL pure bull.
Use a WARN_ON_ONCE() so that people can actually *report* the bugs
sanely (see this very thread about why BUG_ON causes problems for
reporters).
If you are so damned certain that you mustn't continue, make the damn
function return the error code, and stop marshalling. If you don't do
error handling, that's no excuse for BUG_ON.
And if you think the code gets too complicated from that, then that
*still* isn't a reason to do BUG_ON(). See above.
What part of this thread do you have problems acknowledging? The
undeniable *facts* (that you seem to be in total denial about) from
this very thread are:
- the BUG_ON() caused an otherwise *benign* bug to result in a unusable system.
Your "to avoid crapping on other parts of memory or posting data"
argument is pretty much f*cked up, when you instead cause a fatal
error!
- the BUG_ON() caused the debug data to be almost totally useless.
Look at the screen shots. Look at the lack of debug info. Just look at it.
Why are you denying reality, and bringing up arguments that are purely
theoretical and shown to be wrong in reality?
BUG_ON() in a filesystem or random service is pure and utter garbage.
There is no way it is ever the right thing to do. Get rid of them, and
stop posting excuses for them.
Christ, we had THIS VERY SAME issue not more than a month or two ago,
when the locking code had a BUG() in it that turned what should have
been a simple error return into a DoS attack by normal users. See
commit 8d657eb3b438.
The whole "it's better to BUG_ON() than do something unexpected" is a
disease. It may be well-intentioned, but the road to hell is paved
with good intentions, and saying "I don't want to do odd things" is
stupid to do, when the BUG_ON() itself just causes *different*
catastrophic odd things to happen.
Really: killing the machine IS NOT ANY BETTER than sending out odd packets.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
