[PATCH 0/4] Re: NULL pointer dereference at s3cmci

Andy Green andy at openmoko.com
Sun Aug 10 10:34:21 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

| The first bug was this one, which was obvious on the oops output. But
| why didn't it happen before, since the code was always there? The answer
| would be that, as one would suspect, usually that code isn't preempted
| until well after everything is set up. The real reason it was happening
| became obvious once that initialization ordering bug was fixed (first
| two patches of this series): the oops disappeared, but still nothing
| happened. The driver had been failing its initialization the whole time!

Lol... good work on this Cesar.  This is extra appreciated because we
will also be using this on GTA03 eventually.

| What happened was that, due to a change on the return value of
| s3c2410_dma_request (see commit
| 3886ff5f63f33c801ed3af265ac0df20d3a8dcf5, cherry picked as the third
| patch of this series), s3cmci_probe was erroneously considering a
| successful return as a failure, and going through the error path.
| However, by this time host->detect has already been scheduled. Another
| mistake (fixed by commit 2de5f79d4dfcb1be16f0b873bc77d6ec74b0426d,
| cherry picked as the fourth commit of this series) made the delay before
| it finally executes longer, making it happen in the long pause just
| before "VFS: Mounted root (jffs2 filesystem)." (the real bug was before
| that pause, as can be seen by the attached dmesg). When it finally
| executed, it was not only following a NULL pointer, it was following a
| NULL pointer in a structure which had already been freed!


| The patch has been very lightly tested (it boots, 2007.2 automounts the
| card, and a ls -la /media/card shows expected values). I haven't tried
| writing or stress-testing it yet.

Sounds great.

| Given all that, I wonder whether it would be better to keep the current
| driver or to backport the 2.6.27 driver (applying whatever extra patches
| are needed; the first two patches of this series, for instance, should
| still be needed in some form).

I think we should use your patches in the first instance.  The reason I
say it is right now stable-tracking (2.6.27-rc1 +) doesn't succeed to
complete early boot even, besides unpicking the sequencing for this was
hard work on your part.

I added these on to stable-2.6.26 along with updating the recent
additions to stable / 2.6.24.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list