[BUG] zfs panic in dsl_dir_open_spa() because of NULL ptr

Samir Desai hellosamirdesai at gmail.com
Tue Oct 4 09:12:44 UTC 2011


hi Pawel

thanks a lot for this patch. It seems to be holding up so far for us.
In case we still see issues, I will get back to you.

regards
Samir

On Thu, Sep 29, 2011 at 6:50 PM, Pawel Jakub Dawidek <pjd at freebsd.org>wrote:

> On Thu, Sep 29, 2011 at 05:53:43PM +0530, Samir Desai wrote:
> > hi
> >
> > We are seeing ZFS v28 panic on FreeBSD, which seems to be caused by a
> race
> > condition between a thread loading spa and another trying to access it.
> The
> > two thread stacks trace these paths
> >
> > 1. zfs_ioc_snapshot -> zfs_unmount_snap -> ...-> spa_load ->vdev_open
> .....
> > -> vdev_geom_open ......-> biowait
> > 2. zfs_secpolicy_write_perms -> ...-> dmu_objset_snapshot -> ...
> > ->dsl_dir_open_spa -> _sx_slock
> >
> > the two threads should be serialized by spa_namespace_lock, but
> apparently
> > the first thread, which is initializing spa, drops the lock in
> > vdev_geom_open(). This lets the second thread come in and see and
> > uninitialized spa. The spa->spa_dsl_pool pointer is NULL. The second
> thread
> > tries to take lock in dsl_dir_open_spa()          dp = spa_get_dsl(spa);
> > rw_enter(&dp->dp_config_rwlock, RW_READER); This panics because "dp" is
> NULL
> >
> >
> > Should we be dropping the spa_namespace_lock in vdev_geom_open() ? What
> > serializes the spa operations ?
>
> Could you try this patch:
>
>        http://people.freebsd.org/~pjd/patches/zfsdev_state_lock.patch
>
> It eliminates dropping spa_namespace_lock in vdev_geom.c.
>
> --
> Pawel Jakub Dawidek                       http://www.wheelsystems.com
> FreeBSD committer                         http://www.FreeBSD.org
> Am I Evil? Yes, I Am!                     http://yomoli.com
>


More information about the zfs-devel mailing list