From nobody Tue Nov 14 18:51:39 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 4SVFl161Vfz50Y3B for ; Tue, 14 Nov 2023 18:51:41 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 4SVFl14MSyz4KVK; Tue, 14 Nov 2023 18:51:41 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-x235.google.com with SMTP id 5614622812f47-3b566ee5f1dso3490041b6e.0; Tue, 14 Nov 2023 10:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699987900; x=1700592700; darn=freebsd.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4v7QXHe5aoXi30g0I7JM4laOLDYhIU6ZkjpeUvyr5sY=; b=FIiete8SupyBOKYfr93TcPKv7f+peRzmdIsYYnNACe7lNmBI7t3OIZKsZzC2qJTaF+ 6+ZhdbSRCfmvGD9Ygfsp912BxHz78PuKHNQw76duQlHKN7buof9jhQWnhdI01t0FNxoC lcE0ZAnVdkBrH566YhAJic1oXV8IxsHwXTsCmZL1h0Sj9OmSb8yl/Ai/AgD6aVnRWwhS 6A+rJeW/TPjooJM4YL9UhgNy/60cf9hLW6L2qBVfdIuOZcZoz/IL9omcpfw2IF+JYiNr zAFiMtpW8PVnZPYo7w6Ub9G0BgoCjUgSMfb/KWAJdAVWPHGeOxfZy8eNU7Kq9kaXq/+B 7Ahg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699987900; x=1700592700; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4v7QXHe5aoXi30g0I7JM4laOLDYhIU6ZkjpeUvyr5sY=; b=Hk2xA000TIQG41IoM5Xca9wjLSZR7DOXpLL5sA4rFwmtkVTy+sBjrv38jvY4l86UvO aNVA4oDSvezr1P4WZgWQC6cOl0aakS8u2Fa2JVctDiJ4A2fcnLgtM1m8q4VeKzRZ5ZlF s4ngEKA0HVhrHOqyOn1Z0pwZDF97thj7EZdYA/TVjTjOT3/0np9WZHxTWVM/8n8WVpRC AuQLPTjnskowLDYXxB3yQh/tzyrLBJt4JkWgqXOAqhsxvRLJxg0bwDjdSWWTkNDSPesI roE66G/wnIboTDlbuFmabO2Lpa0ECxuythPCpFulwYznbWKiIkRK9AGVNIME7Uip4MNK 2tlg== X-Gm-Message-State: AOJu0YzDFDlX315nep9PRdqUs0aG875d598jT4fYg+Vd4JoJiHskg/uJ cbiCjGroY0mQ+7JuAICraQ7zKk/kyaAFM0elu1FDjSdTo4k= X-Google-Smtp-Source: AGHT+IFQ4jfyVSskwjzLiafsVfuNUvRI1KjKAbJfNMoFl7V7pgickP9jKpgdgj5z696mtNbdNeaJbyZcyLsOEO4E1wk= X-Received: by 2002:a05:6808:2a0b:b0:3a7:b4e8:563e with SMTP id ez11-20020a0568082a0b00b003a7b4e8563emr12290950oib.38.1699987900306; Tue, 14 Nov 2023 10:51:40 -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 Received: by 2002:ac9:57d4:0:b0:4f0:1250:dd51 with HTTP; Tue, 14 Nov 2023 10:51:39 -0800 (PST) In-Reply-To: References: <349700057.3452.1699611152405@localhost> <1900239445.5968.1699966796547@localhost> From: Mateusz Guzik Date: Tue, 14 Nov 2023 19:51:39 +0100 Message-ID: Subject: Re: crash zfs_clone_range() To: Alexander Motin Cc: Ronald Klop , Konstantin Belousov , current@freebsd.org Content-Type: text/plain; charset="UTF-8" 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] X-Rspamd-Queue-Id: 4SVFl14MSyz4KVK On 11/14/23, 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 != outvp->v_mount->mnt_vfc) { >>> + goto bad_write_fallback; >>> + } >>> + >>> if (invp == outvp) { >>> if (vn_lock(outvp, LK_EXCLUSIVE) != 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 = len; >> if (inmp == outmp || strcmp(inmp->mnt_vfc->vfc_name, >> outmp->mnt_vfc->vfc_name) == 0) >> error = VOP_COPY_FILE_RANGE(invp, inoffp, outvp, >> outoffp, >> lenp, flags, incred, outcred, fsize_td); >> else >> error = vn_generic_copy_file_range(invp, inoffp, outvp, >> 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? > I already advocated for not trying to guess for filesystems what they can or cannot handle internally. That is to say vn_copy_file_range should call VOP_COPY_FILE_RANGE, that can try to figure out what to do and if it got nothing punt to a fallback. This already happens for some of the cases. -- Mateusz Guzik