[OpenAFS-devel] Re: BUG: unable to handle kernel NULL pointer

Markus Suvanto markus.suvanto@gmail.com
Tue, 28 May 2013 20:57:56 +0300


2013/5/28 Andrew Deason <adeason@sinenomine.net>:
> On Fri, 24 May 2013 19:49:30 +0300
> Markus Suvanto <markus.suvanto@gmail.com> wrote:
>
>> I have updated my openafs to the lates .6.3pre2 and I have not seen
>> any crash/NULL
>> dereference problems  anymore.
>>
>> Previous version was 1.6.3pre1, it might be so that commit
>> a71cc5511c115c1b6cb4a6a2997a846bab6e19e2
>> also solves problems what I have seen.
>
> Your original post said you were trying with 1.6.3pre2....? The NULL
> pointer dereference and stack trace you mentioned is pretty clearly
> elsewhere, and should be solved by something like
> <http://gerrit.openafs.org/#change,9928>.
>
> Unless you're talking about the btrfs RCU hangs...? I left your
> mentioned test running on a vm for a while here, but hadn't seen it hang
> yet.

Sorry, my bad,  the story goes like this

My host (real computer) was using 1.6.3pre1 and btrfs file cache and
I certainly have NULL pointer dereference issues. But It was very hard
to reproduce.

I change my host cache to use memcache and it still hangs and log file
was reporting
NULL pointer deference stuff. But again it was very hand to reproduce.

After that I change my host to use tmpfs file cache and hang was easy
to reproduce.
I assume  that this was the same problem than before but tmpfs make it
easy to reproduce.

This point I create my kvm virtual machine to debug this problem. I
compile openafs
from git and that time it was 1.6.3pre2. KVM using tmpfs file cache
hangs and I report it here.
After that I change virtual machine cache to use btrfs and everything works OK.

Then my host computer hangs "INFO: rcu_schedself-detected stall on CPU"
and I report it here but my host was using 1.6.3pre1.

After that I upgrade my host to use 1.6.3pre2 and everything has work great.
No hangs or NULL deference problems anymore. I think that
a71cc5511c115c1b6cb4a6a2997a846bab6e19e2 was my original problem
and tmpfs was my attempt to create reliable test case but it was different bug.

-Markus



> --
> Andrew Deason
> adeason@sinenomine.net
>
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel