A grad student here discovered that doing this:
mkdir /tmp/test (note: we are using tmpfs)
chmod 555 .
ln -s /etc
immediately causes this:
panic [on cpu 0]: kmem_free: block already free
syncing file systems... done
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.)
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
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).
email@example.com (Andrew Beckett)
firstname.lastname@example.org (Chris Ciolorito)
email@example.com (Robert Wolf)
Robert Haddick <firstname.lastname@example.org>
Smokey Bear <email@example.com>
Bottom line: the bug is present in all 4.1. 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.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:31 CDT