Re: panic: LK_RETRY set with incompatible flags

Andriy Gapon wrote:
> on 07/02/2013 04:13 Rick Macklem said the following:
> > Andriy Gapon wrote:
> >> on 06/02/2013 17:15 Rick Macklem said the following:
> >>> Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server
> >>> knows to
> >>> switch over to using VOP_LOOKUP(). If the .zfs/snapshot and
> >>> .zfs/share
> >>> do the same thing, that should be fine, at least for the NFS
> >>> server,
> >>> I think.
> >>
> >> Ah, right, but again this is done only for .zfs and .zfs/snapshot.
> >> .zfs/shares is not special-cased and thus is problematic here too
> >> in
> >> the same
> >> fashion as zfs_fhtovp.
> >>
> > Well, I have no way to test this, but maybe the attached patch is a
> > start in the right direction.
> >
> > Maybe you can take a look at it and/or Sergey could test it?
> >
> > Thanks for all your help with this, rick
> 
> Rick,
> the patch looks 99% percent good to me :-)
> I am not sure if I am overly paranoid here, but I would add a check
> for
> zfsvfs->z_shares_dir being non-zero before comparing anything with it.

Yes, I think checking that it is non-zero sounds like a good idea.

> I am also not sure if doing actual zfs_zget only to check zp_gen !=
> fid_gen or
> z_unlinked is required. Probably not.
> 
I don't think so, either. At least w.r.t. NFS, all the generation # does
is check for a recycled i-node.

The other thing I wondered about is "can zfsvfs->z_shares_dir ever not
fit in 32bits?". I notice it is a uint64_t, but ino_t is still 32bits for
FreeBSD. If it didn't fit in 32bits, the check in zfs_vget() wouldn't
work. (I have a hunch that, for now, the ZFS code doesn't exceed 32bit
fids, but haven't looked at the code to try and see. I'll take a closer
look at that, too.)

Thanks for looking at it, rick

> Sergey,
> could you please test Rick's patch?
> 
> --
> Andriy Gapon
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe_at_freebsd.org"