NetBSD Problem Report #38039

From martin@duskware.de  Fri Feb 15 23:12:23 2008
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 06A2A63B101
	for <gnats-bugs@gnats.netbsd.org>; Fri, 15 Feb 2008 23:12:23 +0000 (UTC)
Message-Id: <20080215215531.2B3EC63BD28@narn.NetBSD.org>
Date: Fri, 15 Feb 2008 19:31:37 +0000 (UTC)
From: ad@netbsd.org
Reply-To: ad@netbsd.org
To: netbsd-bugs-owner@NetBSD.org
Subject: genfs+ufs inode locking problem
X-Send-Pr-Version: www-1.0

>Number:         38039
>Category:       kern
>Synopsis:       genfs+ufs inode locking problem
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 15 23:15:00 +0000 2008
>Last-Modified:  Sat Feb 16 15:40:00 +0000 2008
>Originator:     Andrew Doran
>Release:        4.99.54
>Organization:
The NetBSD Project
>Environment:
n/a
>Description:
ufs_gop_markupdate modifies inode::i_flag without holding the vnode lock.
Under the right circumstances inode updates could be delayed or never
flushed to disk. 

>How-To-Repeat:
Code inspection.
>Fix:
Using atomics to maintain i_flag seems too expensive. We could introduce
another field to be maintained using atomic ops, and combine it with
i_flag in ffs_itimes(). If we had inode locks it would probably make
sense to use those. 

>Audit-Trail:
From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/38039: genfs+ufs inode locking problem
Date: Sat, 16 Feb 2008 15:39:07 +0000

 There are more problems:

 o VOP_READ() needs to do atomic updates of the inode status.

 o It seems that VOP_READ() with IO_SYNC should be called with an exclusive
   vnode lock held, so it's safe to update the itimes and flush the inode to
   disk after the read has completed.

 o ufs_gop_alloc() will be called to fill holes in a file if we are trying
   to resolve a write fault. The vnode lock is not held at this point, but in
   principle it should be fine since we hold the genfs_node lock. It updates
   many fields in the in-core inode. These updates are not co-ordinated with
   e.g. ffs_update().

 o ffs_alloc() calls through to the disk quota code, which looks like it
   expects the vnode lock held.

 Andrew

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.