linux-kernel - Re: [PATCH mm-unstable v1] mm/truncate: batch-clear shadow entries

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20240708151619.dc738d16d3b2d56d6c4fe285@linux-foundation.org>
Date: Mon, 8 Jul 2024 15:16:19 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Yu Zhao <yuzhao@...gle.com>
Cc: Bharata B Rao <bharata@....com>, "Matthew Wilcox (Oracle)"
 <willy@...radead.org>, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 Mel Gorman <mgorman@...hsingularity.net>, Johannes Weiner
 <hannes@...xchg.org>
Subject: Re: [PATCH mm-unstable v1] mm/truncate: batch-clear shadow entries

On Mon,  8 Jul 2024 15:27:53 -0600 Yu Zhao <yuzhao@...gle.com> wrote:

> Make clear_shadow_entry() clear shadow entries in `struct folio_batch`
> so that it can reduce contention on i_lock and i_pages locks, e.g.,
> 
>   watchdog: BUG: soft lockup - CPU#29 stuck for 11s! [fio:2701649]
>     clear_shadow_entry+0x3d/0x100
>     mapping_try_invalidate+0x117/0x1d0
>     invalidate_mapping_pages+0x10/0x20
>     invalidate_bdev+0x3c/0x50
>     blkdev_common_ioctl+0x5f7/0xa90
>     blkdev_ioctl+0x109/0x270

This will clearly reduce lock traffic a lot, but does it truly fix the
issue?  Is it the case that sufficiently extreme loads will still run
into problems?

> --- a/mm/truncate.c
> +++ b/mm/truncate.c
> @@ -39,12 +39,24 @@ static inline void __clear_shadow_entry(struct address_space *mapping,
>  	xas_store(&xas, NULL);
>  }
>  
> -static void clear_shadow_entry(struct address_space *mapping, pgoff_t index,
> -			       void *entry)
> +static void clear_shadow_entry(struct address_space *mapping,
> +			       struct folio_batch *fbatch, pgoff_t *indices)
>  {
> +	int i;
> +
> +	if (shmem_mapping(mapping) || dax_mapping(mapping))
> +		return;

We lost the comment which was in invalidate_exceptional_entry() and
elsewhere.  It wasn't a terribly good one but I do think a few words
which explain why we're testing for these things would be helpful.

I expect we should backport this.  But identifying a Fixes: target
looks to be challenging.