From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Xin Zhao" Subject: Why generic_fillattr() is not protected with a lock? Date: Thu, 24 Aug 2006 22:08:20 -0400 Message-ID: <4ae3c140608241908v7a181b38yedc16183ddf44960@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from py-out-1112.google.com ([64.233.166.179]:62123 "EHLO py-out-1112.google.com") by vger.kernel.org with ESMTP id S1751630AbWHYCI2 (ORCPT ); Thu, 24 Aug 2006 22:08:28 -0400 Received: by py-out-1112.google.com with SMTP id n25so996212pyg for ; Thu, 24 Aug 2006 19:08:20 -0700 (PDT) To: linux-kernel , linux-fsdevel@vger.kernel.org Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Hi, I noticed that almost all local disk file systems use the default vfs_getattr()->generic_fillattr() to get file attributes. However, vfs_getattr()->generic_fillattr() is not protected by a lock. Is this problematic? Suppose process A is getting file attributes, after it read the "mtime" and before it read the i_size, the process is scheduled out, and another process B cuts in, change the file, and cause the change on file size. After A is switched back, it goes ahead to read the rest fields. Now it will have an old "mtime" but a new "i_size". Is this scenario possible? If so, will this cause serious problem to the file system? Thanks, Xin