Re: [Myrinet] kernel panic initiated by gm driver version 1.5.2

Hi Susan,

thank you for the fast reply. Our Myrinet is now up and running
again with the patch applied to gm-1.5.2_Linux.

I discovered though that a new message appears when the driver module
is loaded:
kernel: GM: kernel does not export get_user_pages

Is this ok or may we expect some problems later?

Thanks again for the fast reaction.
Reagrds

Willy

Susan Blackford wrote:
> 
> Hi,
> 
> On Tuesday 25 June 2002 08:53 am, you wrote:
> > When running a user program the system went into a kernel
> > hung state after issuing the following messages:
> >
> > kernel: GM: PANIC:
> > libgm/_gm_assertion_failed.c:27:_gm_assertion_failed():kernel
> > kernel: GM: drivers/linux/gm/gm_arch_fork.c:126: failed assertion:
> > "!pmd_none (*src_pmd) && !pmd_bad (*src_pmd)".
> > kernel: Kernel panic: gm_arch_abort() called
> >
> > Our system is running Linux kernel version 2.4.17.
> 
> This is a bug related to the recently introduced fork() support
> in gm-1.5.2, and unfortunately passed through our tests.  This
> bug affects only the driver, so you should apply the
> patch, recompile the driver, and reload the gm module.
> 
> This patch will be available on the Linux Download page, and will
> be included in the next release of GM.
> 
> Attached is the patch and the analysis from the developer.
> 
>  (cd <gmsrcdir>;patch -p1 < .../fork4.diff)
> 
> When creating a new mapping that just perfectly fits the hole between two
> previous mapping, Linux merge the two old areas and the new one into one
> into just one chunk, and although the original right area is removed (its
> range now being part of the big reunited chunk), Linux never calls the
> ->close method on it, which causes the GM driver to lose track of the areas
> on which it has registered hooks.
> 
> The reason Linux does not care to call the close method is because areas
> susceptible to be merged are anonymous and normally never have a "->close"
> method anyway, but this is no longer the case with the GM driver where we
> use the vm_area open and close method for fork() support, (and they are
> actually generally called in all other creation/destruction cases), there is
> just this weird corner case that I hadn't noticed before :-(.
> 
> The fix is to make any vm area with registered page "non-mergeable" (see
> can_vma_merge in include/linux/mm.h), by attaching them to a pseudo file.
> Using the vm_file attribute. We have the shmem_file_setup function starting
> with 2.4.4 that can be used to creates the dumb file used for this purpose
> (and there is no problem for earlier 2.4 kernels where no vm merge is ever
> done, 2.2 kernels always call the vm_area->open/close method before
> creating/destroying them).
> 
> We increase the dependence on Linux internals when we have to
> insert/deinsert the vm areas from the mapping list attached to the
> pseudo-inode of the pseudo-file, but all 2.4 kernels(included redhat or
> other variant) seems to use exactly the same simple linked list for this
> purpose.
> 
> We apologize for the inconvenience.  Please confirm with us that this
> patch solves your problem.
> 
> Susan
> 
> --
> 
> ------------------------------------------
> Susan Blackford
> Member of Technical Staff
> Myricom Inc.
> ------------------------------------------
> 
>   --------------------------------------------------------------------------------
>                  Name: fork4.diff
>    fork4.diff    Type: Plain Text (text/plain)
>              Encoding: 8bit

-- 
-----------------------------------------------------------
Willy Weisz

European Centre for Parallel Computing at Vienna (VCPC)
                 Liechtensteinstrasse 22
                 A-1090 Wien
Tel: (+43 1) 4277 - 38824       Fax: (+43 1) 4277 - 38818
                e-mail: [email protected]