0921857772
instead of the result from getcwd(). The works around locking panics caused by namei calling VOP_READLINK while holding on to a directory lock and getcwd() trying to acquire that lock. The real fix would be to get rid of getcwd() calls within VOPs (not locking safe), but that's not a viable option in the netbsd-4 timeframe. Suggestion for workaround from David Holland. |
||
---|---|---|
.. | ||
files.procfs | ||
Makefile | ||
procfs_cmdline.c | ||
procfs_ctl.c | ||
procfs_fd.c | ||
procfs_fpregs.c | ||
procfs_linux.c | ||
procfs_map.c | ||
procfs_mem.c | ||
procfs_note.c | ||
procfs_regs.c | ||
procfs_status.c | ||
procfs_subr.c | ||
procfs_vfsops.c | ||
procfs_vnops.c | ||
procfs.h |