[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Linux-cluster] Re: cluster/gfs-kernel/src/gfs ops_address.c ops_f ...



On Mon, 2006-01-02 at 10:59 +0100, Fabio Massimo Di Nitto wrote:
> wcheng sourceware org wrote:
> > CVSROOT:	/cvs/cluster
> > Module name:	cluster
> > Branch: 	RHEL4
> > Changes by:	wcheng sourceware org	2005-12-14 20:38:41
> > 
> > Modified files:
> > 	gfs-kernel/src/gfs: ops_address.c ops_file.c 
> > 
> > Log message:
> > 	This gfs change (bugzilla 173913) pairs with kernel (bugzilla 173912)
> > 	2.6.9-25 that requires an updated version of linux/fs.h. We move the
> > 	locking of i_sem and i_alloc_sem out of kernel directIO routine into
> > 	gfs read/write path. This is to re-arrange lock order so we don't get
> > 	into deadlock situation as described in the bugzilla.
> > 
> > Patches:
> > http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_address.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.5.2.2&r2=1.5.2.3
> > http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.16.2.6&r2=1.16.2.7
> 
> Hi Wendy,
> 
> doesn't this patch require porting to the STABLE branch as well?
> 
> I can't find a direct_IO_cluster_locking on vanilla kernels so i assume this is
> a specific redhat extension.
> 
> if i understand the problem right, shouldn't the stable branch get the patch
> using blockdev_direct_IO_own_locking ?
> 

It requires base kernel changes and we haven't decided what to do with
it yet. 

-- Wendy 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]