[English Page][Japanese Page]

A mystery of tmpfs

The tmpfs of SunOS 4.1.4 has three bugs that cause kernel panic. There are patches for the two bugs of them, but the symbolic-link bug which is the rest of them still remains and has no patch. Here, I explain how to solve these bugs and to avoid kernel panic.
* Make sure whether really using tmpfs

Solaris 2.x/7 uses tmpfs by default, but on SunOS 4.1.4, a description for using tmpfs in /etc/rc.local is commented out by default.

So we should make sure really using tmpfs. If we can see an output as follows, tmpfs is really being used.

  $ mount -p | grep swap
  swap      /tmp tmp rw           0 0
  $ df | grep swap
  swap                   90196      32    90164      0%   /tmp

If tmpfs is not being used, uncomment the following line in /etc/rc.local
# mount /tmp
and add a command for the safety,
mount -v /tmp; chmod +t /tmp
and add a line as follows in /etc/fstab
swap /tmp tmp rw 0 0
Now, if we reboot the machine or type a command directly "mount /tmp" then tmpfs becomes to be used.

* The three kinds of tmpfs bugs

* A bug, "hard-link of fifo"

How to repeat:
  $ cd /tmp
  $ mknod aaa p
  $ ln aaa bbb    # must be hard-link (not symbolic-link)
  $ ls -l



There is no patch for SunOS 4.1.4. (Why ?) But a patch for SunOS 4.1.3 or SunOS 4.1.3_U1 can be used for SunOS 4.1.4. So we apply it anyway.

We use only one kernel object binary tmp_vnodeops.o that is in the patch 100507-06 (for SunOS 4.1.3) or
102396-01 (for SunOS 4.1.3_U1).

There are some other binaries tmp_*.o in the patch, but we don't need them except tmp_vnodeops.o because they are already integrated in SunOS 4.1.4 (the release note says 100507-05 is integrated) or updated by other patches.

* A bug, "writing on a deleted directory"

How to repeat:
  $ mkdir /tmp/aaa
  $ cd /tmp/aaa
  $ rmdir /tmp/aaa
  $ touch bbb
  $ cd /

assertion failed: tp->tn_dir == NULL


There is a patch for SunOS 4.1.4.
Apply 103314-01 .
tmp_dir.o will be updated.

* A summary for the two kernel patches above
tmp_dir.o       --  replace by tmp_dir.o in 103314-01.
tmp_subr.o      --  no change
tmp_tnode.o     --  no change
tmp_vfsops.o    --  no change
tmp_vnodeops.o  --  replace by tmp_vnodeops.o in 100507-06 or 102396-01.

* A bug, "Read-only symbolic-link"

How to repeat:
  $ cd /tmp
  $ mkdir aaa
  $ chmod -w aaa
  $ cd aaa
  $ ln -s bbb ccc    # must be symbolic-link (not hard-link)

panic: kmem_free: block already free


There is no patch for this bug even now !

I explain to solve this bug using adb .

Check out the following assembler code looking at /vmunix by adb .

_tmp_symlink+0x164:             call    _tmp_memfree

When we are trying to create an symbolic-link on a read-only tmpfs directory, the CPU runs through this code. But at this point, tmp_memfree() is not necessary to be called, (it has already been kmem_free()'ed) I found out this call instruction is the source of the bug.

I'm sure this bug is fixed if this call instruction is replaced by nop instruction.

I recommend not to modify vmunix binary itself, but to run a shell-script as follows at the boot time from /etc/rc.local .


set - `echo 'tmp_symlink+164/i' | adb -k /vmunix /dev/mem | tail -1`

if [ "$1" = '_tmp_symlink+0x164:' -a "$2" = 'call' -a "$3" = '_tmp_memfree' ]
  echo \
/i' | adb -k -w /vmunix /dev/mem
  echo "$@" '-- not call _tmp_memfree'
I hope:

I hope Sun to release a formal patch for these tmpfs bugs.

Someday, if the SunOS 4.1.4 source code becomes open, I want to inspect the tmpfs bugs again.

To "SunOS 4.1.4 the mystery" Home