Hi,
can you please elaborate on your considerations of using
lis_spin_lock_t vs. spinlock_t more?
What happens here, is that I had a strange deadlock between
my driver open routine and its scheduled timeout() processing
routine. When I did a printk in every lock acquisition and
release, I saw that those are paired (each acquisition is followed
by a release with the same lock addr). The deadlock happens
when both the open routine and the timeout handler are doing
a lock acquire operation (lis_spin_lock) on the same address.
The lock is not locked before they both start, but then they 2
block inside the lis_spin_lock() call forever!
When I changed my locking wrapper to use the kernel spinlock
instead, with spin_lock_irq_save()/spin_unlock_irq_restore(),
the problem disappeared. I was able to run now with both
the tracing and no tracing, and nothing got hanged. This made
me think of a possible bug in LiS locking wrapping. Of course,
there's a possibility I am missing my own bug in my locking
wrapping logic, which has disappeared just due to different timing,
but I find this very unlikely - the trace in case when it does hang
with lis_... locking is very straitforward:
{addr}[addr]{addr}[addr]{addr}[addr]{addr{addr
addr being the same addr throughout the test,
and a printk of an opening bracket+addr done before the lock/unlock
call, and the closing done after it returns. There are other printouts
indicating that indeed the timeout handler and the open are conflicting,
i.e. it is not a recursive deadlock of one of them.
My machine is a 2.2.17 SMP kernel on a single-CPU system,
with LiS 2.11 compiled as a module.
As said, I am not stuck (just reverted to kernel spinlocks), so that's not
critical; but, with a possibility of a bug in LiS, I felt I must share this
with
you. I'll be happy to debug into it further if you give me some clues.
Overall, I would like to thank everyone involved for the thing
LiS has become. Porting progress is just amazing with it. Thanks!!!
Vassilii
-----Original Message-----
From: Brian F. G. Bidulock [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 08, 2001 5:53 PM
To: Khachaturov, Vassilii
Cc: 'Linux STREAMS Mailing List'
Subject: Re: [Linux-streams] Synchronization within my STREAMS module using
LiS on Linux?
Vasilii,
You can look at /usr/src/linux/Documentation/spinlocks.txt in your
Linux source tree if you are interested in a brief explanation of
how Linux kernel locks work.
I agree with Dave's recommendations (he's the man), but I have found
that it is necessary to use Linux kernel locks at the lowest driver
level on SMP machines (particularly in interrupt service routines).
Above the interrupt service routine, and within the STREAMS context,
I always use the LiS mechanisms for maximum portability.
Hope that helps.
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
[EMAIL PROTECTED] ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
