mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Zhihao Cheng <chengzhihao1@huawei.com>
To: Nickolai Zeldovich <nickolai@csail.mit.edu>,
	Richard Weinberger <richard@nod.at>
Cc: <linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1] ubifs: drop the obsolete ULONG_MAX assertion on the wbuf timer delta
Date: Sat, 17 Oct 2026 12:15:57 +0800	[thread overview]
Message-ID: <9c7ffefb-a180-4220-4f09-1fc267b090fd@huawei.com> (raw)
In-Reply-To: <20261017022116.792684-1-nickolai@csail.mit.edu>

在 2026/10/17 10:21, Nickolai Zeldovich 写道:
> On a 32-bit kernel, once root sets vm.dirty_writeback_centisecs to 4295
> or more (43 s; raised on flash-based systems to reduce wear), the next
> journal write of every mounted UBIFS file system fails its write-buffer
> timer assertion and, with the default assert=read-only, switches the file
> system to read-only mode:
> 
>    UBIFS error (ubi0:0 pid 1): ubifs_assert_failed: UBIFS assert failed: delta <= ULONG_MAX, in fs/ubifs/io.c:516
>    UBIFS warning (ubi0:0 pid 1): ubifs_ro_mode.part.0: switched to read-only mode, error -22
> 
> The create, write, unlink or fsync that started the timer returns EROFS
> and so does every later one until the file system is remounted; with
> assert=panic the machine crashes instead. 64-bit kernels are not
> affected. The assertion has been reachable since v4.10, when the timer
> started to follow the sysctl.
> 
> new_wbuf_timer_nolock() computes the timer slack as
> 
> 	delta = dirty_writeback_interval * 10^6 ns
> 
> in an unsigned long long and asserts delta <= ULONG_MAX. On 32-bit
> ULONG_MAX is 4294967295, exceeded from 4295 centiseconds on. The check
> dates from commit 2a35a3a8ab3e ("UBIFS: set write-buffer timout to 3-5
> seconds"), when hrtimer_start_range_ns() took the slack as an unsigned
> long and the value was a compile-time constant that could only be checked
> against truncation. Commit da8b44d5a9f8 ("timer: convert timer_slack_ns
> from unsigned long to u64") widened the parameter to u64, so nothing is
> truncated any more, and commit 1b7fc2c0069f ("ubifs: Use
> dirty_writeback_interval value for wbuf timer") then derived the value
> from the sysctl, which has no upper bound. The assertion no longer guards
> anything and fails on a legitimate setting.
> 

Right, the assertion is not necessary since da8b44d5a9f8(“timer: 将 
timer_slack_ns 从 unsigned long 转换为 u64”).
> Remove it. The timer is started with the full 64-bit slack exactly as
> before.
> 
> Tested on a riscv32 QEMU kernel with UBIFS on an mtdram-backed UBI
> volume: after "vm.dirty_writeback_centisecs = 4295" the first
> open(O_CREAT) fails with EROFS and the assertion is logged; with this
> patch the open and fsync succeed and the log is clean. 4294 works on
> both.
> 
> Found while reviewing the users of dirty_writeback_interval for the
> formal verification of the periodic writeback code.
> 
> Fixes: 1b7fc2c0069f ("ubifs: Use dirty_writeback_interval value for wbuf timer")
> Assisted-by: LLM
> Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
> ---
> 
> Notes:
>      The write-buffer timer start is the only user of the value in fs/ubifs; the
>      softlimit next to it, ms_to_ktime(dirty_writeback_interval * 10), is a 32-bit
>      product on all architectures and wraps above 429496729 centiseconds (49.7 days),
>      the same wrap that fs/fs-writeback.c has at its two msecs_to_jiffies() sites;
>      that is a separate issue of the sysctl's range, not touched here.
>      
>      Reproducer (32-bit kernel, any UBIFS mount, root):
>      
>        sysctl -w vm.dirty_writeback_centisecs=4295
>        touch /mnt/ubifs/f
>      
>      Before: touch fails with EROFS; the log shows "UBIFS assert failed: delta <=
>      ULONG_MAX, in fs/ubifs/io.c:516" and "switched to read-only mode, error -22";
>      every later write to the file system fails with EROFS until it is remounted.
>      After: touch succeeds, nothing is logged. 4294 works on both; a 64-bit kernel
>      never trips the assertion.
>      
>      Run here as a freestanding init on qemu-system-riscv32 (-M virt,
>      CONFIG_MTD_MTDRAM=y with a 16 MiB device and 128 KiB erase blocks,
>      CONFIG_MTD_UBI=y, CONFIG_UBIFS_FS=y, "ubi.mtd=0" on the command line): the init
>      creates a 4 MiB dynamic UBI volume with UBI_IOCMKVOL, mounts "ubi0:v" (UBIFS
>      formats the empty volume), creates /mnt/a at 4294 (ok, fsync ok), sets 4295 and
>      creates /mnt/b: open returns -30 unpatched, 0 patched.
> 
>   fs/ubifs/io.c | 1 -
>   1 file changed, 1 deletion(-)

Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
> 
> diff --git a/fs/ubifs/io.c b/fs/ubifs/io.c
> index 6c6d68242779..da4eb0a82e62 100644
> --- a/fs/ubifs/io.c
> +++ b/fs/ubifs/io.c
> @@ -513,7 +513,6 @@ static void new_wbuf_timer_nolock(struct ubifs_info *c, struct ubifs_wbuf *wbuf)
>   	delta *= 10ULL * NSEC_PER_MSEC / 10ULL;
>   
>   	ubifs_assert(c, !hrtimer_active(&wbuf->timer));
> -	ubifs_assert(c, delta <= ULONG_MAX);
>   
>   	if (wbuf->no_timer)
>   		return;
> 
> base-commit: 70dd4ee72eb2d5793c62e71c14e3aba78e5a4e56
> 


      reply	other threads:[~2026-10-17  4:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-17  2:21 Nickolai Zeldovich
2026-10-17  4:15 ` Zhihao Cheng [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9c7ffefb-a180-4220-4f09-1fc267b090fd@huawei.com \
    --to=chengzhihao1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nickolai@csail.mit.edu \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®