Another tmpfs bug?
2007-12-25 8:36:00
A grad student here discovered that doing this:
mkdir /tmp/test (note: we are using tmpfs)
cd /tmp/test
chmod 555 .
ln -s /etc
immediately causes this:
panic [on cpu 0]: kmem_free: block already free
syncing file systems... done
(machine reboots...)
We've noticed this on a several of our SPARCs, including:
4/280 running 4.1.2
SS1+ running 4.1.2
SS10/30 running 4.1.3
(I stopped there--didn't want to crash everything testing for the
presence of this bug.)
I had not yet applied patch 100507-04, titled "fixes for several tmpfs
bugs," so I made a new sun4c kernel. No improvement on the SS1+.
The only reference to a kmem_free panic in the Sun Manager's archives
seemed to point to improperly seated memory cards as the problem.
Obviously this is something different.
Has anyone seen this problem, and, better yet, a fix? ("Don't use
tmpfs" doesn't count as a fix.)
Warren Jessop
University of Washington Computer Science
I should have pointed out also that the bug is exposed only when there
is a permissions violation, i.e. if you are root then there is no
panic.
One person asked why one would want to do such a thing. In this case
the student was working on a class project having to do with file
systems. He precipitated the error by testing to see what error
messages result with all combinations of permission bits on a
directory and file creation commands in that directory (the kind of
regression testing one would expect to have been done before a new
type of file system is released).
Thanks to
abeckett@fmlrnd.co.uk (Andrew Beckett)
cciolori@tatca.tc.faa.gov (Chris Ciolorito)
rwolf@dretor.dciem.dnd.ca (Robert Wolf)
Robert Haddick <rhaddick@us.oracle.com>
Smokey Bear <elekokws@ee.nus.sg>
for responding.
Bottom line: the bug is present in all 4.1.[23] systems (or at least
mine and the respondents') and no one has heard of a patch for it.
Robert Haddick has mailed a report to Sun about it, as will I.
Comments
Got something to say?
You must be logged in to post a comment.
