Re: [RESEND PATCH] gfs2: do not evict glocks with populated address spaces

Guilherme Giacomo Simoes <[email protected]>
Newsgroups dev.linux.lists.gfs2,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
Guilherme Giacomo Simoes wrotes:
> Sorry, yes has two GLOCK_BUG_ON() assertions. I talk about the second
> GLOCK_BUG_ON on __gfs2_glock_put(): 
> `GLOCK_BUG_ON(gl, !mapping_empty(mapping))`. 
> 
> NOT ABOUT `GLOCK_BUG_ON(gl, !list_empty(&gl->gl_holders));` (the first
> GLOCK_BUG_ON())
> 
> The dump_stack() indicates a memory pressure and the
> gfs2_glock_put_eventually() on fs/gfs2/super.c is called.
> But when the __gfs2_glock_put() was called, the glock was has a private folios. 
> I test by this way:
> ```
> struct address_space *mapping = ...;
> pgoff_t index;
> struct folio *folio;
> xa_for_each(&mapping->i_pages, index, folio) {
> 	if (folio_test_private(folio)) 
> 		pr_err("I have private folios")
> }
> ```
> 
> And, I can see the glock is about metadata:
> `gl->gl_name.ln_type != LM_TYPE_INODE`
> 
> the truncate_inode_pages_final() failed silently when the folio is private.
> 
> I guess maybe evict metadata (or locked) glock is not a good idea.

Andreas, thoughs?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.