linux-kernel - Please assist in locating NFS race in old vendor kernel

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-next>] [day] [month] [year] [list]

Message-Id: <200705092114.29041@sercond.localdomain>
Date:	Wed, 9 May 2007 21:14:23 +0400
From:	"Nikita V. Youshchenko" <yoush@...msu.su>
To:	linux-kernel@...r.kernel.org
Subject: Please assist in locating NFS race in old vendor kernel

Hello.

I'm currently working with an embedded system based on very old, 
2.4.17-based, vendor kernel.

Among other issues, there is a race in NFS code, that I'm currently trying 
to understand and fix.

The race is the following.
Some i/o is done on a file located on NFS-mounted filesystem. At some 
moment, ftruncate() is called. And in very rare but still reproducable 
cases:
- first inode->i_size is set to the new value, in process context
- then inode->i_size is restored to old value, in rpciod context.
I was able to catch this by adding some logging to the point where 
__nfs_refresh_inode() updates inode->i_size.

Looks like inode size is being broken (by restore of old value) by 
completeion handler of RPC operation that was started before ftruncate().

The test on which the race is reproduced more or less reliably, 
is "fsx-linux" from LTP suite.

System in question is SMP - thus making race happen more often.

I guess the race is long fixed in more modern kernels.
But I'm not familiar with NFS code, and after some attempts to find 
something I feel lost.

Could someone more familiar with NFS implementaion please point me where to 
look?

Nikita

Content of type "application/pgp-signature" skipped