From nobody Sat Feb 4 23:15:19 2023 X-Original-To: bugs@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 4P8Szr1vwtz3kWsP for ; Sat, 4 Feb 2023 23:15:20 +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 4P8Szr0vnLz3xyn for ; Sat, 4 Feb 2023 23:15:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1675552520; 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=m1+tU0ClCf9k4576lg/c/7aJQ8AuOCteCih5VYfOid0=; b=IUkWBfzrvqxCYCXj6mUDVn6vnMunQr8ByxwxUO3F+gc1xjFWi0snkfedV1D1L2UR7RoYGx nEVeOj73iSaJd5iIWIK8RKgf5EriMkfe7F1Ed8tDFEVP2VxNG+jukFgd/fgAU8iJli4eJP b4sHZvLbuHUTmJt9bzY9g/Yv+xtql5bJhEiq4SakQc7/WSoAi25yAh0sQr/norpMcR3R2Z BZgUNtxnUEvEBcq68mDjha23+Yw4fVkW6C7j47UjR+RFOXI7/hXxxCHMPr7xlsml7D/hu2 qeC0xOIFxnavxzOnx72dd9bqJYV2//czaLkfkN9vzH/8jpoBeBAgpBrrGTigBA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1675552520; a=rsa-sha256; cv=none; b=lBDZY9SMnIv8bEkFjrbtcGh3CctXiqERO8IDSBUZq5uOvBMSI2cDsLlT7vmCRhdMwIdobI M5Dc/DjtuW2A6SWq+gTteGAM5yIsxQaDQyR2VnAAQAO4/IBn0kyNKXySZzdAnCJZe/Lktq ih/1c588gOdmaPw4ZQUNHEkWPVIA9wEZV9i7vPh5XnrQbr8vcaPvw2FqY5xHFRyZxuNqSD 5YLBfEaq739kmd9MjyQnX5uNUbnjzoRBftayM7Z453+azR69T+Hy9zdfi36YC1R+Cnkgae rJAYn+05+iOfDuK+dqWVscRaPQeoZtDTB8/3vwgQD8WfP4AkXFshgx7lUzy4ZA== 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 4P8Szq6zFNzY49 for ; Sat, 4 Feb 2023 23:15:19 +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 314NFJOn031071 for ; Sat, 4 Feb 2023 23:15:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 314NFJpd031070 for bugs@FreeBSD.org; Sat, 4 Feb 2023 23:15:19 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: bugs@FreeBSD.org Subject: [Bug 269330] fusefs: data corruption with mmap and either o_direct or fspacectl Date: Sat, 04 Feb 2023 23:15:19 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269330 Konstantin Belousov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org --- Comment #1 from Konstantin Belousov --- I am confused by your question, quite possibly because you are confused by buffer cache vs. page cache difference. B_CACHE is the flag for buffers (as in struct buf). For vnodes which have non-NULL vp->v_object AKA VMIO buffers, the buffer is only a header referen= cing some number of pages belonging to v_object. It is not necessary for a buff= er to exist for each page on the object queue. In fact, since number of buffers is fixed, it is usual for buffers to be deconstructed shortly after all i/o requested through the buffer finished. Dirty pages (pages which have the dirty/PG_M bits set) are converted into dirty buffers by vm_object_page_clean() when page clean is requested in asy= nc mode. Then the dirty buffers are written out by buffer daemon. This is significant simplification, but it catches the intent. Hopefully this answers the question 1. For question 2, what do you mean by 'finding' the dirty pages? If there is a possibility that vnode has a dirty page on its queue, then vm_object_mightbedirty() returns true. To find actual dirty pages, you must iterate over the page queue for the object and see which page is dirty, either from PoV of MI VM layer (m->dirty) or pmap (PG_M etc). Note that si= nce writable mappings could exist accessed by other threads, some exercises are needed to have PG_M reading not racy, like pmap_remove_write() call which invalidates all managed writable mappings. See vm_object_page_clean() for = all the details. And note that the fact that the page is clean from VM PoV (either MI or pma= p) does not mean that the page data really hit the storage. As I wrote above, page daemon only converts dirty pages into dirty buffers, clearing the dirty bits in vm_page. The content is still dirty but now tracked by the buffer cache. --=20 You are receiving this mail because: You are the assignee for the bug.=