NetBSD Problem Report #43002
From www@NetBSD.org Thu Mar 18 17:08:30 2010
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by www.NetBSD.org (Postfix) with ESMTP id 00EEB63B86C
for <gnats-bugs@gnats.NetBSD.org>; Thu, 18 Mar 2010 17:08:30 +0000 (UTC)
Message-Id: <20100318170829.BFF8F63B11D@www.NetBSD.org>
Date: Thu, 18 Mar 2010 17:08:29 +0000 (UTC)
From: pooka@iki.fi
Reply-To: pooka@iki.fi
To: gnats-bugs@NetBSD.org
Subject: required>0 module autounload timestamp race
X-Send-Pr-Version: www-1.0
>Number: 43002
>Category: kern
>Synopsis: required>0 module autounload timestamp race
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Mar 18 17:10:16 +0000 2010
>Originator: Antti Kantee
>Release:
>Organization:
>Environment:
>Description:
module autounload is attempted at exactly t_now + module_autotime
from load.
Let's say mod_a depends on mod_b. When loading mod_a, mod_b is
loaded first. Let's assume mod_b gets timestamp t and mod_a gets
timestamp t+1.
When the autounload thread runs, unload of mod_b is attempted at
t, but it fails since mod_a is still loaded. mod_a is unloaded at
t+1, but autounload of mod_b will not be attempted anymore. In
the worst case, n-1 modules in the dependency chain well be left
lingering.
mod_b will be autounloaded when the system is short on memory
(if it's not in use then), so this might be more of a cosmetic
issue. At least I'm not aware of any application depending
on the module_autotime behavior.
>How-To-Repeat:
you lose some, you get unlucky now and then
>Fix:
tinker with timestamping or change autounload semantics
(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.