Date: Tue, 14 Nov 2023 13:30:25 -0800 From: Rick Macklem <rick.macklem@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Mateusz Guzik <mjguzik@gmail.com>, Alexander Motin <mav@freebsd.org>, Ronald Klop <ronald-lists@klop.ws>, current@freebsd.org Subject: Re: crash zfs_clone_range() Message-ID: <CAM5tNy4O7kTz%2Bua4pAmGPbHf%2BHc0X4VfSvSZ5NmLyQCUYNZ%2BRw@mail.gmail.com> In-Reply-To: <ZVO5PCUt8PTgUv_h@kib.kiev.ua> References: <349700057.3452.1699611152405@localhost> <c9c8ab33-efce-5ed0-1f3f-311fa3cf1338@FreeBSD.org> <ZVEdyHFJyTg0cqCo@kib.kiev.ua> <1900239445.5968.1699966796547@localhost> <CAGudoHGdhaea9mkF3RZSCgXuEGNesb9AtkLXrYQNncgreYsv=g@mail.gmail.com> <ea3b2421-a07c-e7c2-68eb-908185dbb98f@FreeBSD.org> <CAGudoHE7QmwCY-yyZDR=H9knz3pUTQ1bQbUq3=LZ1Ei-cNqd_A@mail.gmail.com> <ZVO5PCUt8PTgUv_h@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 14, 2023 at 1:20=E2=80=AFPM Konstantin Belousov <kostikbel@gmai=
l.com> wrote:
>
> On Tue, Nov 14, 2023 at 06:47:46PM +0100, Mateusz Guzik wrote:
> > On 11/14/23, Alexander Motin <mav@freebsd.org> wrote:
> > > On 14.11.2023 12:39, Mateusz Guzik wrote:
> > >> One of the vnodes is probably not zfs, I suspect this will do it
> > >> (untested):
> > >>
> > >> diff --git a/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.=
c
> > >> b/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
> > >> index 107cd69c756c..e799a7091b8e 100644
> > >> --- a/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
> > >> +++ b/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
> > >> @@ -6270,6 +6270,11 @@ zfs_freebsd_copy_file_range(struct
> > >> vop_copy_file_range_args *ap)
> > >> goto bad_write_fallback;
> > >> }
> > >> }
> > >> +
> > >> + if (invp->v_mount->mnt_vfc !=3D outvp->v_mount->mnt_vfc) {
> > >> + goto bad_write_fallback;
> > >> + }
> > >> +
> > >> if (invp =3D=3D outvp) {
> > >> if (vn_lock(outvp, LK_EXCLUSIVE) !=3D 0) {
> > >> goto bad_write_fallback;
> > >>
> > >
> > > vn_copy_file_range() verifies for that:
> > >
> > > /*
> > > * If the two vnodes are for the same file system type, call
> > > * VOP_COPY_FILE_RANGE(), otherwise call
> > > vn_generic_copy_file_range()
> > > * which can handle copies across multiple file system types=
.
> > > */
> > > *lenp =3D len;
> > > if (inmp =3D=3D outmp || strcmp(inmp->mnt_vfc->vfc_name,
> > > outmp->mnt_vfc->vfc_name) =3D=3D 0)
> > > error =3D VOP_COPY_FILE_RANGE(invp, inoffp, outvp, o=
utoffp,
> > > lenp, flags, incred, outcred, fsize_td);
> > > else
> > > error =3D vn_generic_copy_file_range(invp, inoffp, o=
utvp,
> > > outoffp, lenp, flags, incred, outcred, fsize_td)=
;
> > >
> > >
> >
> > The crash at hand comes from nullfs. If "outward" vnodes are both
> > nullfs, but only one underlying vnode is zfs, you get the above.
>
> If this is the reason, the check must be done by nullfs bypass for
> vop_copy_file_range().
I suppose this is a reasonable alternative, although it means that
all stacked file systems will need the check.
It just seems easier to do it in the actual VOPs, but it is up to others.
Btw, the stuff above the VOP_COPY_FILE_RANGE() that busies the
mounts and checks mnt_vfc being the same could be dropped, if the
VOP_COPY_FILE_RANGE() calls like NFS were careful to lock the
vnodes before doing a "same fs type or same mount" check.
(I suppose that would be a subtle change in VOP semantics that
is arguably not allowed for a minor version.)
Anyhow, I am happy with whatever others decide.
rick
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy4O7kTz%2Bua4pAmGPbHf%2BHc0X4VfSvSZ5NmLyQCUYNZ%2BRw>