A mystery of tmpfs

* 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 BAD TRAP:

Solution:

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

Solution:

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

Solution:

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+164?i _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 .

tmp_symlink-fix

#!/bin/sh 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' ] then echo \ 'tmp_symlink+164/i /W1000000 /i' | adb -k -w /vmunix /dev/mem else echo "$@" '-- not call _tmp_memfree' fi

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.