From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E8F0D439F7F for ; Fri, 24 Jul 2026 14:17:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784902636; cv=none; b=prkjsGmUSA/F/GJWA5Ecpw3plPJNtS9sg61dcKzglySPYjQ6VoWe+J0HoTWpK9vqp6pEw6XACyAm0BRpkFQbekRahVnf0U5a1Vgvav8FApKrt82nJYd46aEraDwtZyOJwhcTMuh5cr+C6nEKJjKOZAa5QCIt1QaSpbjAVrrcUfE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784902636; c=relaxed/simple; bh=K0P2A4ke5xWo/sYd8EkZChv4Y+SnzhSlyuYBQw3ccfs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=I4Et8AI3VgC5BVurcjFDLZjGfZHHZep56EHJ7hxPyQDW3wA5fF8f70cZPoXl0NmCa8WZZBNjlJ67CHZzKSP2I3aPX6dw8z+WHres8MltUEcoNvwlzeonbe4A78GivW56C3CqkTZqAfPFSnwotguQxfhB41BFG7B/7DuobKO7S8g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=aBY5MYTP; arc=none smtp.client-ip=209.85.222.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="aBY5MYTP" Received: by mail-qk1-f172.google.com with SMTP id af79cd13be357-92e622cc874so30276285a.0 for ; Fri, 24 Jul 2026 07:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784902634; x=1785507434; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=VJ3zA63AAiUBP2Wllc8EOHaRvaq+RtVwiSTRNH9bZts=; b=aBY5MYTPrHHx7EeYYjIks0yWv7xld9vlH5io+iy2w6L2V8KGZce9DumqYyjcdyjsIq bKuR7EtqVOfpI/Pgg6oeFkVJSqfOWCWqdiiyaA9QjkfPbZfLemAFbrWoKvkd0P4yU7wb Qd4hOpTaSaKt5yelBKzfW5Xbfurk3iiM8v6skX7S24nDD1LoZ16Baa6fMfFeR6aXkuIh hZ7JzKbpOlYSAY8WfcuO0CHV0UE063bC+mAZi7+t8Vxr7e9DgqnT+Cu4LX72MAwKsMAu 0YULqAH3DPD/h9AnBkWnOg1muGzzxYwHWBigcjH2Na+w7n8rvEkPK5a97/B9w9nmOqdk RfVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784902634; x=1785507434; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=VJ3zA63AAiUBP2Wllc8EOHaRvaq+RtVwiSTRNH9bZts=; b=VBOkP6KUPq5kESvhN0B99NiM4a7DVYX6uE7318DU8yodzkyNLTJiJb1+92SkMD2Mrj t5shoKgLo7fobBJfGh93MS6ec907A+PgLKd0HzuQIEPjJAxV6KykSIh/8QRYQlfWe5wI cbSHpFIZ/X7UwP9yyr8EgJHQM0uqsK2JEprwbYu6DosYTilmIyjdraqk6RFd1Lw1uj+F euVqiN0ulD1zP8Yc6wCzv89f5aSrvynJHTwxWEKr5v+LY4TOFkodFEtDW8IUUgGK/rFj Xp9196OepeT02OjAYPIt+F8YwUxlfE3Smd6bBAXjXeLTQv2fhwfc3HF5frFegQasLW7x ktVw== X-Forwarded-Encrypted: i=1; AHgh+RoROywkO6sbvkcJnKdJNj/361D6bKUMEcWUqbN9FrZLIwPQIZmn62WWcit42001W3Ulb8iOKQtXZv1ghho=@vger.kernel.org X-Gm-Message-State: AOJu0YwL9sGxPr6NEjYH2KvsR8kZQ/XQEq22aySicDtQLrLBM0zfcLXm b4phL7WLEEQ2Trzijb6vKdSHG9JuvtSfxsditf82Hb+qThCjN6/T2UFV X-Gm-Gg: AR+sD10j/aAmv9/NQ3QTJ44HJRDrcTNJ0KIAYmsSNae0rPzmy3CbQjxHm2g4T03eLPq nOcgIKPDlOUx/juw9K7Db5a44Y5krOp+atoyP60+JeKy0n3tEua4DU36IEBZph012Go2RpnnKw/ 5Gpq0rtdlYNDlEnGyszUIhwiOUL3WZynN+GqAspwjsbFr6jRGa9R5hFpVfTh0Yn8S7KdkmeqAhc c8jPbsgnK2t8ORrJUy0Mg3mku2fsiH1iKDAq6Vecdc8wGcZ03j8qatAEZ1roAD5xiSdqusYKDs1 /Ns0oaNN918ZHt0vGVmkyaEhw2hpqQ38vFJwZV+PZnFbveL1gcG0ikurVkp44kR2pDN86msq8L0 Ovce3Q7UD+pG9j2p/y3INo4rnyWkBfA+jw/C0sBFCHeL8NOfx8PwJc/vi+KMJbpM40UPzdxCiH2 CVJy3VI6+dLDJpUDCtVUZRlYB+XpOw/kIEyhei9a4vq49cqKOPxnC9o7qWvLhsjTR+6b5zpUqkB Q== X-Received: by 2002:a05:620a:44cf:b0:930:f941:ca74 with SMTP id af79cd13be357-931036eab67mr758335485a.43.1784902633520; Fri, 24 Jul 2026 07:17:13 -0700 (PDT) Received: from Ai-Server.tail94eb8c.ts.net (131-193-45-111.cs.uic.edu. [131.193.45.111]) by smtp.gmail.com with ESMTPSA id af79cd13be357-930f68a7fffsm664165685a.11.2026.07.24.07.17.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jul 2026 07:17:11 -0700 (PDT) From: Luyao Bai To: Theodore Ts'o , Christian Brauner Cc: linux-ext4@vger.kernel.org, Andreas Dilger , Jan Kara , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , "Darrick J . Wong" , linux-kernel@vger.kernel.org Subject: Re: [PATCH] ext4: do not WARN when starting a journal on a frozen filesystem Date: Fri, 24 Jul 2026 14:16:59 +0000 Message-ID: <20260724141659.669079-1-bailuyao1997@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Fri, Jul 24, 2026, Theodore Ts'o wrote: > And it's not just fsync(). Any caller of ext4_journal_start() will > end falling into this codepath, which means most ext4 operations > happening during a freeze could very well fail with an EROFS error. Thank you both for the review. The Sashiko findings are correct, and I now believe this patch is wrong; please consider it withdrawn. When I reviewed the change, I took the neighbouring checks as precedent: the sb_rdonly() check just above and the aborted-journal check below both fail with -EROFS, so I assumed the frozen case should be handled the same way. What I missed is that those two are permanent conditions, for which failing is correct, while a freeze is transient: callers that legitimately reach this point while frozen should block until thaw, not get an error. The existing WARN_ON() is diagnostic only and lets the transaction proceed, so replacing it with a hard -EROFS changes the behavior of every journal start during a freeze. The race you point out is also real: the check is lockless, so a task can pass it during SB_FREEZE_FS, block on the journal barrier held by ext4_freeze(), and then start its transaction right after the freeze completes. And the underlying report (dirty pages surviving the freeze when writeback errors are swallowed during sync) looks like it needs to be handled in the VFS/writeback path, not here. > Luyao, I'm curious what (if any) testing you performed before > submitting this patch? I ran the syzbot C reproducer under QEMU on a clean mainline build to confirm the WARNING fires, and again with the patch applied to confirm it no longer does, plus a build of fs/ext4/ and checkpatch. I did not exercise fsync-during-freeze or the freeze/thaw transition (e.g. the fstests freeze tests), which is why the problems above escaped me. > And I'm curious if some AI / LLM was used in > the preparation of this patch? Yes. The patch was prepared with the assistance of LLM-based tooling I am experimenting with for kernel bug fixing; I reviewed the change, built it and ran the reproducer myself, and I take full responsibility for it under the DCO. I should have included an Assisted-by: tag per Documentation/process/coding-assistants.rst, and I apologize for omitting it. Future submissions from me will carry the tag. Thanks again for the careful review, and sorry for the noise. Luyao