From owner-freebsd-hackers Thu Jul 30 08:10:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA14494 for freebsd-hackers-outgoing; Thu, 30 Jul 1998 08:10:54 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from att.com (cagw1.att.com [192.128.52.89]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA14489 for ; Thu, 30 Jul 1998 08:10:51 -0700 (PDT) (envelope-from sbabkin@dcn.att.com) From: sbabkin@dcn.att.com Received: from caig1.att.att.com by cagw1.att.com (AT&T/UPAS) for freebsd.org!hackers sender dcn.att.com!sbabkin (dcn.att.com!sbabkin); Thu Jul 30 11:02 EDT 1998 Received: from dcn71.dcn.att.com ([135.44.192.112]) by caig1.att.att.com (AT&T/GW-1.0) with ESMTP id LAA09372 for ; Thu, 30 Jul 1998 11:10:36 -0400 (EDT) Received: by dcn71.dcn.att.com with Internet Mail Service (5.0.1458.49) id ; Thu, 30 Jul 1998 11:10:33 -0400 Message-ID: To: hackers@FreeBSD.ORG Subject: MP, interlocks and vfs_busy Date: Thu, 30 Jul 1998 11:10:31 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! I'm reading the VFS code and I don't quite understand the following piece of code in vfs_busy(): if (mp->mnt_kern_flag & MNTK_UNMOUNT) { if (flags & LK_NOWAIT) return (ENOENT); mp->mnt_kern_flag |= MNTK_MWAIT; if (interlkp) { simple_unlock(interlkp); } /* * Since all busy locks are shared except the exclusive * lock granted when unmounting, the only place that a * wakeup needs to be done is at the release of the * exclusive lock at the end of dounmount. */ tsleep((caddr_t)mp, PVFS, "vfs_busy", 0); if (interlkp) { simple_lock(interlkp); } return (ENOENT); } The interlocks are used for multiprocessor systems, right ? Then what would be if another CPU that is holding unmount lock will obtain simple lock and call wakeup() when our CPU is running around the comment: in end of simple_unlock() and beginning of tsleep() ? Is not it a race condition (of course, with low probablility because this code will probably take less time to execute than the code on another CPU, but still a possible race condition) ? Must not be the simple lock properly released inside tsleep(), after adding a request to sleep hash ? -Sergey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message