From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12944 invoked by alias); 14 Feb 2007 23:15:45 -0000 Received: (qmail 12910 invoked by uid 9572); 14 Feb 2007 23:15:44 -0000 Date: Wed, 14 Feb 2007 23:15:00 -0000 Message-ID: <20070214231544.12909.qmail@sourceware.org> From: wcheng@sourceware.org To: cluster-cvs@sources.redhat.com Subject: cluster/gfs-kernel/src/gfs inode.c inode.h ops ... 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/msg00403.txt.bz2 CVSROOT: /cvs/cluster Module name: cluster Branch: RHEL4 Changes by: wcheng@sourceware.org 2007-02-14 23:15:44 Modified files: gfs-kernel/src/gfs: inode.c inode.h ops_inode.c Log message: Final patch for bugzilla 1904745 - there is a deadlock documented in the bugzilla entry comment #26 that is messy to get around under current GFS lock order rule. To compromise the issue, we will fail the rename with the original error return code (-ENOENT), if the new ino has any possibility to cause deadlock. This implies, if GFS ino number is allocated via true random manner, we only reduce this error return code by 25%. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/inode.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.20.2.3&r2=1.20.2.4 http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/inode.h.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.3.2.1&r2=1.3.2.2 http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_inode.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.6.2.5&r2=1.6.2.6