From nobody Tue Nov 14 21:10:14 2023 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SVJq74BTbz50rpR for ; Tue, 14 Nov 2023 21:10:27 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SVJq63ZWTz4fHm; Tue, 14 Nov 2023 21:10:26 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x531.google.com with SMTP id 41be03b00d2f7-5bde80aad05so4889071a12.2; Tue, 14 Nov 2023 13:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699996225; x=1700601025; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=c8sYlcqU5uErCmBPFA2HRUfpGnY0BiSsvcgVrmFhNWo=; b=gtd00OyH6K7uRtkD+4DpFgtQA4XKeEK7A/m2548+GPlFSwOdtFPdYNdW8njSfKj1zp 8LdUl1UT/uAzeDYOknlgSTL+4E2pIb5bmL9dw41g6iAWL5Nv6An9NfYBSM4J9sfQUyAM EhhIIvS3dKOorXmHF+5jh+yCwitdvPpuXzJ8Yu/hk6vsoGETQ8/63nVi4uUM0ItKcMDf AoLKodOx9k153BT4ZvQQ/485UARFfP+qqAHzWKTIo/HEdaqsVIaJgs8faDIzxQTpYECd nQmwD/fW1c8+WWyu5/FoPVOVMZaY9+5OZhH57oPZmnRxMCgL8GET8F62UuceuiF6WwpA dDcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699996225; x=1700601025; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=c8sYlcqU5uErCmBPFA2HRUfpGnY0BiSsvcgVrmFhNWo=; b=MLoB9eyiDYQwvgCsMDyR3LfPmAIFdVb2PkdG6/pTLE6EipX7LIyOwMBp3tAtu6MC2G 9J3mw9wuIiQJJYHrSS1wNRCog3sqpQAHoW4JFb6eYmeQShklcI0/bN5BXDuRolWd/ewz QB75rzFsqjgNXvsL6B0hQoA6GeQ11OzbrseL7MqfwM6fzzDzzXdzB+ONeORD0OZ6OPXm IHMddHRJPD6PfermiDfZUWbGDMOq7rX7pr4DWvc+ISubptLrky8KhIB4uALnGK4cpirt Tr6+oUBlrcL6/T3BJT/RUemdThydcAKrb8Qgk67I3CmQtKpzpJdb+aHsQxVOXaheOvIP bCNQ== X-Gm-Message-State: AOJu0Yzg7FzAGnG37+uzLIm8EnBNBfnh6mrOeBARfxOwoZZEWWsIWIFL FvYm7sTQmqnzI+rniinfn3wBBMo8X9XFc9Kg2oofXNvN0w== X-Google-Smtp-Source: AGHT+IFSx5uX5GoHlq760NOG2GSvNPT1BDMwbpZB7R5PWiksIK/IFqoyRNtoP7vfyvFsOljlVKih916uDZGLyH2cRTM= X-Received: by 2002:a17:90b:4f4e:b0:281:3a4:2220 with SMTP id pj14-20020a17090b4f4e00b0028103a42220mr10386882pjb.36.1699996225124; Tue, 14 Nov 2023 13:10:25 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <349700057.3452.1699611152405@localhost> <1900239445.5968.1699966796547@localhost> In-Reply-To: From: Rick Macklem Date: Tue, 14 Nov 2023 13:10:14 -0800 Message-ID: Subject: Re: crash zfs_clone_range() To: Alexander Motin Cc: Mateusz Guzik , Ronald Klop , Konstantin Belousov , current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Queue-Id: 4SVJq63ZWTz4fHm On Tue, Nov 14, 2023 at 10:46=E2=80=AFAM Alexander Motin = wrote: > > On 14.11.2023 12:44, Alexander Motin 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, out= offp, > > lenp, flags, incred, outcred, fsize_td); > > else > > error =3D vn_generic_copy_file_range(invp, inoffp, out= vp, > > outoffp, lenp, flags, incred, outcred, fsize_td); > > Thinking again, what happen if there are two nullfs mounts on top of two > different file systems, one of which is indeed not ZFS? Do we need to > add those checks to all ZFS, NFS and FUSE, implementing > VOP_COPY_FILE_RANGE, or it is responsibility of nullfs or VFS? Although it would be nice to do the check before the VOP call, I don't see an easy way to do that. It looks like the simple solution is to add a check in each of the VOP_COPY_FILE_RANGE() calls, such as mjg@ has proposed for ZFS. At this point there is only the three and I can easily do the NFS one. rick > > -- > Alexander Motin >