Oops at lis_qdetach

<[email protected]>
Newsgroups gmane.linux.kernel.streams
Message-ID <[email protected]>
Hallo we need some help.

We have an Oops at lis_qdetach.  As far as we understand lis_qdetach was
called in some context before. We do not know which. Possible popping a
module?
At this call the associated control block struct stdata was freed and
some magic number is changed to make this visible to all, who try to
access this freed memory area.

Later on, in the context of a close, lis_qdetach is called again for the
same queue. At the beginning of lis_qdetach is checked, if the
controlblock is already freed. Finding the magic number corrupted, there
is a Debug Entry and the pointer hd is set to NULL. Setting hd to NULL
forces a crash some lines later.

We can reproduce the error as often as needed.

Detailed information is available at the attached file. 

The whole thing happens in this context: 
We use SUSE SLES8 at a SMP 586. LiS-2.18; strxnet-0.9.2-4 (with some
changes); After sending two or three data, the XTI-application decides
to stop of some unknown reason. Closing the devices forces the panic.
The protocoll-stack:
timod
rfc1006 /* our module */
inet
tcp
...



It looks like, as if somebody has inserted this trick with the
magic-number to detect this "happening". The solution for this
"happening" seemed not clear to him at that moment, otherwise he would
have fixed the possible problem. 
So for us it looks, as if it would be more complicate to solve this bug.

Just leaving the function after detecting, that the controlblock was
freed, is only a dirty solution and may leave things not finished. (To
get on with our tests, we changed lisqdetach to leave, if magic is
clobbered. This seems to results in other Oops at kmem_cache_create
called by lis_init_queues.)

We do also not know, if it was planned, that lis_qdetach runs two times
for one queue-pair.

A solution or hints to find the real cause of that Oops are welcome. 
Also questions concerning more information are welcome. We can inspect
the dump or reproduce the crash.


Klaus Golbach


Klaus Golbach
FSC EP SW RT 3
Fujitsu Siemens Computers

Telephone:	089 636 48835
Telefax:	089 636 48976
Email:	mailto:[email protected]
extr (application/octet-stream, 27.1 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.