Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Feb 2013 10:04:24 -0500 (EST)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        Andriy Gapon <avg@FreeBSD.org>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, Sergey Kandaurov <pluknet@gmail.com>, FreeBSD Current <freebsd-current@FreeBSD.org>
Subject:   Re: panic: LK_RETRY set with incompatible flags
Message-ID:  <236652418.2788560.1360249464612.JavaMail.root@erie.cs.uoguelph.ca>
In-Reply-To: <5113AF89.4070303@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?236652418.2788560.1360249464612.JavaMail.root>