From nobody Mon Jan 01 22:21:24 2024 X-Original-To: fs@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 4T3r6s36Gkz55jfq for ; Mon, 1 Jan 2024 22:21:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T3r6s26N6z4RTT for ; Mon, 1 Jan 2024 22:21:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704147685; a=rsa-sha256; cv=none; b=vqihzryJISZsSCsz/KuPAW+yCe7oRFDsOI3pyvn4kmrtHEHZvfGkJwwr21Rfp08ZKrOO2L g1oHYLYA8nciDC7fSZFWMM92TybBE6qo0DDnDQohVMj1AvUsMRjSI5AAuSoUI1S2ltWBjF 6WbhuXoUGGbAifXYm7jTDRHRy5Or7f0tvzAasbdFKn9Fc9tPm9zkgCuKvQBs8aMp2TFtKU dtTS7t9aiJFpz3PN8ny1sqgUojrgNlwoJtZRJA1aXea0TQgiiN7xU9FD4yLT10QzEHqRod vG6CpeYtGKpQl3kEUadd+z4jhgEYFVQItsOTe/LbBSVHH3AVs82QQzYfPmgXUQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704147685; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5CBtDXdbcBF7TjjN3Qxdu5/lRVJKTB0x/k1csJdiaM8=; b=h1QirA9Cr7f/hF6KpRm4OBM0QfPX9UZeD8fv5UYjaeLQqX8T3bT7Uo+hSCUEp+Ikg3HA4B GHawrZMTebhqsm1dk9ARAhuKYV/J60d9tyKKpBI2Ikarv0AZXrQgMvzdDf41kU97G/FUfj kdWgzeHkfRTr9y1Lt1Gx8+y3u/7Hdp/SBDcQiPKERCH0uOuaoKqXCIF9NjCED9F0fDudd2 DJutP5F2vDAvZkur1QZH8+qaAt7SyysToo4cFBlrvNzSdmKHI9THfeQszW+yetvjFYAo9q Cst9r3BYED4H2N1Zi74mrwcc4EQMRvFRwD8eZ7tjvl29DdxSty8h04EPz57nNQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4T3r6s1B7zzb8l for ; Mon, 1 Jan 2024 22:21:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 401MLP4F076114 for ; Mon, 1 Jan 2024 22:21:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 401MLPY0076113 for fs@FreeBSD.org; Mon, 1 Jan 2024 22:21:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 276002] nfscl: data corruption using both copy_file_range and mmap'd I/O Date: Mon, 01 Jan 2024 22:21:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276002 --- Comment #37 from Rick Macklem --- Going back to my example case (which sounds like what net-p2p/rtorrent might be doing), it is possible for the NFS client VOP_READ() to do a vm_object_page_clean() which should ensure that mmap(2)'d writing (as in modifying bytes within mmapped address space) is written to the server. This would not handle the case where mmap(2)'d writing is intermixed with read(2)s. Does that sound worth doing? And, is it likely that vm_object_mightbedirty() will return true when this is not needed? (If this is the case, a flag on the vnode that indicates it has been mmap(2)'d would be helpful.) --=20 You are receiving this mail because: You are the assignee for the bug.=