linux-kernel - Re:[PATCH v2] bcache: enhancing the security of dirty data writeback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <tencent_09D8A9E34CEA74AC70E3901C@qq.com>
Date: Wed, 13 Aug 2025 15:11:48 +0800
From: "Zhou Jifeng" <zhoujifeng@...inos.com.cn>
To: "周继峰" <zhoujifeng@...inos.com.cn>, "Coly Li" <colyli@...nel.org>
Cc: "kent.overstreet" <kent.overstreet@...ux.dev>, "linux-bcache" <linux-bcache@...r.kernel.org>, "linux-kernel" <linux-kernel@...r.kernel.org>
Subject: Re:[PATCH v2] bcache: enhancing the security of dirty data writeback

On Wed, 13 Aug 2025 at 10:14, Zhou Jifeng <zhoujifeng@...inos.com.cn> wrote:
>
> There is a potential data consistency risk in bcache's writeback mode:when
> the application calls fsync, bcache returns success after completing the
> log write, persisting the cache disk data, and persisting the HDD internal
> cache. However, at this point, the actual application data may still be in
> a dirty state and remain stuck in the cache disk. when these data are
> subsequently written back to the HDD asynchronously through REQ_OP_WRITE,
> there is no forced refresh mechanism to ensure physical placement on the
> disk, and there may be no power-off protection measures, which poses a risk
> of data loss. This mechanism may cause the application to misjudge that the
> data has been persisted, which is different from the actual storage state,
> and also violates the semantic agreement that fsync should ensure data
> persistence.
>
> This patch aims to enhance the reliability of dirty data writeback through
> PREFLUSH, ensuring that the dirty data mark in the cache device is cleared
> only after the dirty data is written to the disk. Double triggering
> conditions for PREFLUSH:
> 1、When the cumulative number of dirty bkeys written back reaches the
> threshold(Dynamic control parameters:/sys/block/bcache0/bcache/
> flush_interval, the default value is 20000. by increasing the value of this
> parameter, the impact of flush on performance can be reduced.)
> 2、When the interval since the last refresh exceeds 30 seconds
> If any of the conditions are met, the system will send a PREFLUSH command
> to the backend HDD, and clear the corresponding dirty bkey mark only after
> confirming that the PREFLUSH is executed successfully.
>
> Signed-off-by: Zhou Jifeng <zhoujifeng@...inos.com.cn>
> ---
> v1 -> v2: Make revisions according to the review comments.
>
>
> [snipped]
>
>
> diff --git a/drivers/md/bcache/bcache_ondisk.h b/drivers/md/bcache/bcache_ondisk.h
> index 6620a7f8fffc..df5800838e40 100644
> --- a/drivers/md/bcache/bcache_ondisk.h
> +++ b/drivers/md/bcache/bcache_ondisk.h
> @@ -294,6 +294,10 @@ BITMASK(BDEV_CACHE_MODE,           struct cache_sb, flags, 0, 4);
>  #define CACHE_MODE_WRITEBACK           1U
>  #define CACHE_MODE_WRITEAROUND         2U
>  #define CACHE_MODE_NONE                        3U
> +BITMASK(BDEV_WRITEBACK_FLUSH,          struct cache_sb, flags, 4, 1);
> +#define WRITEBACK_FLUSH_OFF            0U
> +#define WRITEBACK_FLUSH_ON             1U
> +
>  BITMASK(BDEV_STATE,                    struct cache_sb, flags, 61, 2);
>  #define BDEV_STATE_NONE                        0U
>  #define BDEV_STATE_CLEAN               1U

Sorry, the inspection was not thorough enough. This is an invalid code. It was left over
from the past and was forgotten to be deleted.