[Cluster-devel] [PATCH] Fixing an invalid return error code, which leads to a panic in 64 bits.

[Mathieu Avila <mathieu.avila@seanodes.com>]

Hello,

I did not get any response for this patch. Is this because GULM is
definitively abandonned ? It was ripped out of the CVS tree recently,
it seems:

"Removed gulm directory as it is no longer used.":
http://sources.redhat.com/ml/cluster-cvs/2006-q2/msg00048.html

If so, does the current CMAN/DLM now has the same functionnality that
Gulm had ? I'm referring to this :
http://www.redhat.com/archives/linux-cluster/2006-July/msg00155.html
("In the mean time all I suggest is that you use gulm for clusters with
>= 32 nodes")

--
Mathieu Avila

Le Tue, 17 Oct 2006 11:39:26 +0200,
Mathieu Avila <mathieu.avila@seanodes.com> a ?crit :

> Hello GFS folks,
> 
> Sometimes, i get a panic at mount time, following messages saying it
> cannot start the threads:
> lock_gulm: ERROR Faild to send lock login. -111
> lock_gulm: ERROR glq_startup failed. 111
> lock_gulm: ERROR Got a 111 trying to start the threads.
> 
> A few lines later, a panic occurs in "do_kern_mount", because the
> return value of "fill_super" is interpreted as a pointer and
> dereferenced, instead of being interpreted as an error code.
> 
> This is due to the way "fs/super.c" interprets pointer return values,
> using "ERR_PTR(ptr)", defined in include/linux/err.h
> To detect that a pointer is in fact an error code, the return value
> must be negative, at least on 64 bits.
> returning a positive error code leads to considering the value as a
> pointer, not an error code and the panic follows.
> 
> The first time the error is reported in GULM, it is
> negative, then it is changed to a positive value. The patch doesn't
> change it to a positive value.
> 
> 
> 
> diff src/gulm/gulm_lock_queue.c src-b/gulm/gulm_lock_queue.c
> 813c813
> <               return -err;
> ---
> >               return err;
> 
> 
> Please tell me if this is the good way to fix this bug,
> 
> Thanks in advance,
> 
> --
> Mathieu Avila
>