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
(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.