Date: Thu, 07 Feb 2013 15:43:37 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Rick Macklem <rmacklem@uoguelph.ca> 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: <5113AF89.4070303@FreeBSD.org> In-Reply-To: <1137922035.2777364.1360203187367.JavaMail.root@erie.cs.uoguelph.ca> References: <1137922035.2777364.1360203187367.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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. I am also not sure if doing actual zfs_zget only to check zp_gen != fid_gen or z_unlinked is required. Probably not. Sergey, could you please test Rick's patch? -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5113AF89.4070303>