Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 9 Dec 2001 00:38:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 9 Dec 2001 00:38:22 -0500 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:28306 "EHLO vindaloo.ras.ucalgary.ca") by vger.kernel.org with ESMTP id ; Sun, 9 Dec 2001 00:38:08 -0500 Date: Sat, 8 Dec 2001 22:38:04 -0700 Message-Id: <200112090538.fB95c4G06607@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Alexander Viro Cc: linux-kernel@vger.kernel.org Subject: Devfs races with block devices In-Reply-To: In-Reply-To: <200111060701.fA671hL20646@vindaloo.ras.ucalgary.ca> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org [Finally, after other things have stabilised, I'm ready to tackle this issue] Alexander Viro writes: > BTW, here's one more devfs rmmod race: check_disk_changed() in > fs/devfs/base.c. Calling ->check_media_change() with no protection > whatsoever. If rmmod happens at that point... How about if I do this sequence: lock_kernel(); devfs checks; if (bd_op->owner) __MOD_INC_USE_COUNT(bd_op->owner); revalidate(); if (bd_op->owner) __MOD_DEC_USE_COUNT(bd_op->owner); unlock_kernel(); Is there any reason why that won't work? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/