-
This looks good to me. My only request is that you add a short comment in xattr_dir_inactive at line 1339 explaining the rele and how this interacts with the overall vnode holding.
-
-
usr/src/uts/common/fs/xattr.c (Diff revision 1) Jerry Jelinek asked:
...add a short comment [here] explaining the rele and how this interacts with the overall vnode holding.
Change Summary:
Added some comments at the request of Jerry Jelinek. (Thanks for the review!)
Diff: |
Revision 2 (+205 -107) |
---|
Change Summary:
I noticed my previous was not quite right for file systems that have SYSATTR but not XATTR. Fixed.
Diff: |
Revision 4 (+217 -106) |
---|
-
-
usr/src/uts/common/fs/xattr.c (Diff revision 7) Just to explain why this function went back to how it was before: While it would "make sense" to try to get the "real" XATTR directory here (immediately after we get the GFS XATTR directory), getting the real XATTR directory can legitimately fail, i.e. if the real FS supports SYSATTR but not XATTR, or if the real FS chooses to create the XATTR directory only when the CREATE_XATTRDIR flag is set.
If the real FS declines to give us the XATTR directory for any reason, we still need to create the GFS directory because at this point we know we support (at least) SYSATTR, and the GFS XATTR dir. is needed for those.Given all that, there's not really any point trying to get the real XATTR dir here. That can just as well wait until we really need it, in xattr_dir_realdir.
So that part of the code is like it was before.
The remaining (important) differences is that: once we obtain the real XATTR directory, we "keep" it (VN_HOLD) via the reference saved in the GFS dir xattrdir_realvp.
That fixes the problem where the real FS saw an artificially short lifetime of the XATTR directory.