Hi folks, I''m Google Summer of Code student which work on a zfs port for a NetBSD operating system. My mentor is a NetBSD developer Andrew Doran. We are working on zfs port for a some time and we was able to get zfs into that state that we can compile kernel on NetBSD. There are still bugs left but we have been very successful with our progress for now. During our work we have found some bugs in zfs source tree, which we have fixed and we would like to submit them to upstream. The first patch called locks.diff initializes and destroys many locks which have been freed undestroyed. Condition variables, mutexes and other types of sync object are slightly more contrived on NetBSD than on Solaris so this is a problem for us. The second patch fixes two issues with zfs direntlocks: 1) Avoids recursive RW_READ z_rename_lock acquiring from zfs_rename. When zfs_rename was called within same dir. dzp->z_name_lock was acquired twice. Now ZSAMEDIR flag should be passed to zfs_direntlock/unlock. This is a problem because a recursive RW_READ lock attempt will deadlock if a writer is waiting to acquire the lock. NetBSD''s reader-writer locks are very similar to Solaris'' so we believe this is a problem for Solaris, too. 2) Second issue is race condition in direntlock/direntunlock where one thread can wait on dl->dl_cv while another one destroys this cv by calling zfs_dirent_unlock. I have fixed this issue by adding reference counter to the zfs_direntlock structure. This is a problem because: if there is a thread waiting on a CV, it may later access and modify the CV, which could cause memory corruption or access to unmapped memory. -- Regards. Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: zfs_dirlock.diff Type: application/octet-stream Size: 13204 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-code/attachments/20090818/1ec40452/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: locks.diff Type: application/octet-stream Size: 5569 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-code/attachments/20090818/1ec40452/attachment-0001.obj>