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

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


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.":

If so, does the current CMAN/DLM now has the same functionnality that
Gulm had ? I'm referring to this :
("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

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