Re: [PATCH v2 1/2] f2fs: complete dropbehind write bios in safe task context

[Barry Song]

On Thu, Aug 20, 2026 at 3:21 PM Wenjie Qi <qwjhust@xxxxxxxxx> wrote:
>
> Buffered RWF_DONTCACHE writes invalidate dropbehind folios from writeback
> completion. Keep normal and dropbehind folios in separate write bios, and
> defer a dropbehind bio to sbi->wq unless completion runs in
> preemptible task context.
>
> Use the same eligibility conditions as the proposed bio_in_atomic() helper.
> Unlike !in_task(), this also covers disabled preemption and preemptible RCU
> read-side critical sections.
>
> Keep the existing large-ATC deferral unchanged.
>
> Link: https://lore.kernel.org/linux-mm/20260730-blk-dontcache-v7-0-3e8e6850068d@xxxxxxxxxxxx/
> Signed-off-by: Wenjie Qi <qiwenjie@xxxxxxxxxx>
> ---
>  fs/f2fs/data.c | 50 ++++++++++++++++++++++++++++++++++++++++++--------
>  1 file changed, 42 insertions(+), 8 deletions(-)
>
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 6ae0eb37d20..774a3e2d8e3 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -21,6 +21,7 @@
>  #include <linux/fiemap.h>
>  #include <linux/iomap.h>
>  #include <linux/fserror.h>
> +#include <linux/rcupdate.h>
>
>  #include "f2fs.h"
>  #include "node.h"
> @@ -43,9 +44,29 @@ struct f2fs_folio_state {
>
>  struct f2fs_bio {
>         struct work_struct work;
> +       bool dropbehind;
>         struct bio bio;
>  };
>
> +static struct f2fs_bio *to_f2fs_bio(struct bio *bio)
> +{
> +       return container_of(bio, struct f2fs_bio, bio);
> +}
> +
> +/* Keep in sync with the proposed block-layer bio_in_atomic(). */
> +static bool f2fs_bio_in_atomic(void)
> +{
> +#ifdef CONFIG_PREEMPTION
> +       if (rcu_preempt_depth())
> +               return true;
> +#endif
> +#ifndef CONFIG_PREEMPT_COUNT
> +       return true;
> +#else
> +       return !preemptible();
> +#endif
> +}
> +

Hi Wenjie,

I see that this [1] has already been included in the pull request [2],
so perhaps you can use bio_in_atomic() directly once it lands.

Also, I feel that something is quite odd with mm/filemap.c.
It shouldn't require everyone to reinvent their own workqueues, as I
mentioned here [3]. I also noticed that Alexandre is adding a workqueue
in filemap.c[4], which might be extended to file page cache handling as
well in the future.

[1] https://lore.kernel.org/all/20260730-blk-dontcache-v7-1-3e8e6850068d@xxxxxxxxxxxx/
[2] https://lore.kernel.org/all/8787a176-6f4b-47fc-a309-867acf9fbdff@xxxxxxxxx/
[3] https://lore.kernel.org/all/CAGsJ_4wUvLoKGafR3U-ji1kUUaz6K_QdN6QxMT-apSaO5tXp0A@xxxxxxxxxxxxxx/
[4] https://lore.kernel.org/all/20260818163221.589352-3-alex@xxxxxxxx/

Thanks
Barry