linux-ext4 - Re: [BUG REPORT] potential deadlock in inode evicting under the inode lru traversing context on ext4 and ubifs

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: <10db909b-1b42-82f1-4ca3-3079e66ac7d3@huawei.com>
Date: Thu, 18 Jul 2024 15:30:25 +0800
From: Zhihao Cheng <chengzhihao1@...wei.com>
To: Ryder Wang <rydercoding@...mail.com>, Theodore Ts'o <tytso@....edu>,
	Zhihao Cheng <chengzhihao@...weicloud.com>
CC: linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>, LKML
	<linux-kernel@...r.kernel.org>, Jan Kara <jack@...e.cz>, Christoph Hellwig
	<hch@...radead.org>, linux-mtd <linux-mtd@...ts.infradead.org>, Richard
 Weinberger <richard@....at>, "zhangyi (F)" <yi.zhang@...wei.com>, yangerkun
	<yangerkun@...wei.com>, "wangzhaolong (A)" <wangzhaolong1@...wei.com>
Subject: Re: [BUG REPORT] potential deadlock in inode evicting under the inode
 lru traversing context on ext4 and ubifs

在 2024/7/18 11:04, Ryder Wang 写道:
Hi, Ryder
>> Um, I don't see how this can happen.  If the ea_inode is in use,
>> i_count will be greater than zero, and hence the inode will never be
>> go down the rest of the path in inode_lru_inode():
>>
>>          if (atomic_read(&inode->i_count) ||
>>              ...) {
>>                  list_lru_isolate(lru, &inode->i_lru);
>>                  spin_unlock(&inode->i_lock);
>>                  this_cpu_dec(nr_unused);
>>                  return LRU_REMOVED;
>>          }
> 
> Yes, in the function inode_lru_inode (in case of clearing cache), there has been such inode->i_state check mechanism to avoid double-removing the inode which is being removed by another process. Unluckily, no such similar inode->i_state check mechanism in the function iput_final (in case of removing file), so double-removing inode can still appear.

I'm a little confused about the process of inode double-removing, can 
you provide a detailed case about how double-revemoving happens? I can't 
find the relationship between inode double-removing and the problem i 
described.
> 
> It looks we need to add some inode->i_state check in iput_final() , if we want to fix this race condition bug.