From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pedro Fonseca Subject: Re: Data races in generic_fillattr() Date: Thu, 24 Apr 2014 13:55:24 +0200 Message-ID: <5358FBAC.5060207@mpi-sws.org> References: <534C27E0.9040401@mpi-sws.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: viro@zeniv.linux.org.uk, Theodore Ts'o To: linux-fsdevel@vger.kernel.org Return-path: Received: from hera.mpi-klsb.mpg.de ([139.19.1.49]:43587 "EHLO hera.mpi-klsb.mpg.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753868AbaDXLz3 (ORCPT ); Thu, 24 Apr 2014 07:55:29 -0400 In-Reply-To: <534C27E0.9040401@mpi-sws.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Anybody had a chance to look at this? Pedro On 04/14/2014 08:24 PM, Pedro Fonseca wrote: > Hi, > > I've noticed that the function generic_fillattr() (fs/stat.c) in > involved in multiple data races. Initially I reported this problem on > the ext4 mailing list but it seems to be more general to the VFS layer. > > Because of limited locking, when the inodes are updated and a stat() > system call is concurrently executed, several 64-bit fields (e.g., > atime, mtime, ctime, blocks) can potentially get incorrect values on > 32-bit architectures. In addition, it seems that it can also cause > inconsistencies between the "blocks" field and the "size" field. > > I would be glad if you could have a look at this problem and let me > know if it's going to be fixed. > > Thanks, > Pedro