[OpenAFS-devel] Kernel panic with openafs 1.4.0

[Jeffrey Hutzelman]

On Thursday, August 24, 2006 05:16:00 PM -0400 chas williams - CONTRACTOR 
<chas@cmf.nrl.navy.mil> wrote:

> In message <6ADBBF2C8662EF0941226A0F@sirius.fac.cs.cmu.edu>,Jeffrey
> Hutzelman w rites:
>> There's nothing to fix.  osi_Panic _does_ print out the message string,
>> but  necessarily does so _before_ it calls BUG().  Which means that
>> users  habitually don't actually copy the message when sending in a
>> report.  Fixing this would require changes to Linux to allow something
>> calling BUG  to include a message that gets included _below_ the "cut
>> here" line.
>
> well could fix it by making BUG() do something else and actually point
> out the line where the trouble occurred.  so when we get these truncated
> kernel panics (they are following the directions after all) we might
> be able to do something with them.  we arent going to be able to
> change BUG() and we probably cant change all the users in the world.
>
> you could also make osi_Panic() print "REALLY CUT FROM HERE" but that's
> even sillier.
>
> i am particularly awed by AFS_ASSERT_GLOCK().  i had never seen that
> before.


Besides calling BUG() inline, which is a good thing, your code has the 
effect of changing the behavior on 2.4 so that we call BUG() instead of 
trying to dereference a NULL pointer.  I'm pretty sure there's a reason we 
haven't done that already, and I'd rather not make that change now unless 
you can prove it works on every AFS_LINUX24_ENV kernel out there.


Also, your change to AFS_ASSERT_GLOCK() means that the macro now expands to 
a statement instead of an expression, and a statement that might affect 
flow control at that.  Consider something like this:


  if (should_have_glock)
    AFS_ASSERT_GLOCK();
  else
    AFS_GLOCK();


Instead, I'd leave AFS_ASSERT_GLOCK() alone, and arrange for osi_Panic() to 
also expand to an expression.  Maybe something like

#define osi_Panic(msg...) (printk(KERN_CRIT "openafs: " msg), bug(), 0)


-- Jeff