From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18035 invoked by alias); 23 Feb 2007 20:57:29 -0000 Received: (qmail 18014 invoked by uid 9582); 23 Feb 2007 20:57:29 -0000 Date: Fri, 23 Feb 2007 20:57:00 -0000 Message-ID: <20070223205729.18013.qmail@sourceware.org> From: rpeterso@sourceware.org To: cluster-cvs@sources.redhat.com Subject: cluster/gfs-kernel/src/gfs diaper.c ops_fstype.c Mailing-List: contact cluster-cvs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: cluster-cvs-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00473.txt.bz2 CVSROOT: /cvs/cluster Module name: cluster Branch: STABLE Changes by: rpeterso@sourceware.org 2007-02-23 20:57:29 Modified files: gfs-kernel/src/gfs: diaper.c ops_fstype.c Log message: This fixes some issues reported on linux-cluster. Essentially, the previous code was deadlocking in some cases, primarily, when you run the sync command. That's because sync does a down_read on the s_umount semaphore. The deadlock was caused by some code I removed with the port to the 2.6.20 kernel. However, I removed it because s_umount was needed in the down state for unmounts. That's because the diaper device isn't managed by the normal mount path in vfs. I also fixed a kernel panic I discovered in testing when trying to mount an invalid fs; for example, trying to mount a gfs2 file system as gfs. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/diaper.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.1.2.1.4.1.2.2&r2=1.1.2.1.4.1.2.3 http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_fstype.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.13.2.1.4.2.2.4&r2=1.13.2.1.4.2.2.5