Your condensed explanation had me a little confused, how does vn_rele() access the mi? However, I realize that is the async_inactive that uses the vnode to get the mi.
The changes look good. Jim Marcel Telka wrote: >Hi all, > > >The bug: >-------- > >6672480 NFSv2 and NFSv3 client panic in nfs_async_inactive() when mounted with >rsize=0 > > >Problem description: >-------------------- > >Commands like ># mount -o vers=3,rsize=0 server:/export/dir /mnt >or ># mount -o vers=2,rsize=0 server:/export/dir /mnt > >will immediatelly panic the machine when kmem_flags is set. >NFSv4 is not affected. > > >Root cause: >----------- > >NFSv3: > >nfs3_mount() calls nfs_setopts() and this function failed (returned non zero). >Then nfs3_mount() freed mi of a vnode using nfs_free_mi() call. After that the >nfs3_mount() tried to release the vnode using vn_rele(). Unfortunatelly, the >vn_rele() is accessing mi (previously freed) of the vnode. > >NFSv2: > >The root cause is same as for NFSv3, with one exception: All is happening in >nfs_mount() instead of nfs3_mount(). > >Detailed root cause analysis (>30k chars) is available at >http://cr.opensolaris.org/~aragorn/6672480.analysis > > >The fix: >-------- > >The fix move VN_RELE() call before the nfs_free_mi() call in both nfs3_mount() >and nfs_mount() functions. For example, the similar order of calls is already >in nfs3rootvp(). > >The webrev is available at <http://cr.opensolaris.org/~aragorn/6672480/>. >Please note it contains a lot of formatting fixes so as a starting point I >recommend the real fix at <http://cr.opensolaris.org/~aragorn/6672480.realfix>. > > >The finale: >----------- > >Please review my fix. Should you have any questions just ask. > > >Thank you. > > >
