public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* *_trylock return on success?
@ 2000-11-25 15:07 Roger Larsson
  2000-11-25 17:49 ` Rik van Riel
  0 siblings, 1 reply; 9+ messages in thread
From: Roger Larsson @ 2000-11-25 15:07 UTC (permalink / raw)
  To: Linux Kernel Mailing List, Nigel Gamble

Hi,

Background information:
 compiled and tested a test11 with the Montavista preemptive patch.
 After pressing Magic-SysRq-M all processes that tried to do IO hung in 'D'
 Last message "Buffer memory ..."
 Pressing Magic-SysRq-M again, all hung processes continued...

Checking the patch it looks like this

 	printk("Buffer memory:   %6dkB\n",
 			atomic_read(&buffermem_pages) << (PAGE_SHIFT-10));

-#ifdef CONFIG_SMP /* trylock does nothing on UP and so we could deadlock */
-	if (!spin_trylock(&lru_list_lock))
+#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)
+	if (!mutex_trylock(&lru_list_mtx))
 		return;
 	for(nlist = 0; nlist < NR_LIST; nlist++) {

Ok, so I run some more code now than before (UP system with PREEMPT).
mutex_trylock is defined as:

+#define mutex_trylock(x) down_trylock(x)

Noticed that if the spin_trylock returns 0 on success, I will get the 
behavior I see.
  Not printing buffer info first time.
  Holding the lock - stopping other fs processes.
  Failing the mutex_trylock next attempt, interprete as success
  - continuing and printing the buffer info.
  - finally release the mutex

I removed the not (!) and now it works as expected.

Questions:
  What are _trylocks supposed to return?
  Does spin_trylock and down_trylock behave differently?
  Why isn't the expected return value documented?
  
/RogerL

-- 
--
Home page:
  http://www.norran.net/nra02596/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: *_trylock return on success?
@ 2000-12-04 19:46 george anzinger
  0 siblings, 0 replies; 9+ messages in thread
From: george anzinger @ 2000-12-04 19:46 UTC (permalink / raw)
  To: linux-kernel@vger.redhat.com, Rik van Riel, Philipp Rumpf,
	Roger Larsson

So what is a coder to do.  We need to define the pi_mutex_trylock().  If
I understand this thread, it should return 0 on success.  Is this
correct?

George


On Saturday 25 November 2000 22:05, Roger Larsson wrote: 
> On Saturday 25 November 2000 20:22, Philipp Rumpf wrote: 
> > On Sat, Nov 25, 2000 at 08:03:49PM +0100, Roger Larsson wrote: 
> > > > _trylock functions return 0 for success. 
> > > 
> > > Not spin_trylock 
> > 
> > Argh, I missed the (recent ?) change to make x86 spinlocks use 1 to mean 
> > unlocked. You're correct, and obviously this should be fixed. 

Have looked more into this now... 
tasklet_trylock is also wrong (but there are only four of them) 
Is this 2.4 only, or where there spin locks earlier too? 

My suggestion now is a few steps: 
1) to release a kernel version that has corrected _trylocks; 
    spin2_trylock and tasklet2_trylock. 
    [with corresponding updates in as many places as possible: 
      s/!spin_trylock/spin2_trylock/g 
      s/spin_trylock/!spin2_trylock/g 
      . . .] 
    (ready for spin trylock, not done for tasklet yet..., attached, 
     hope it got included OK - not fully used to kmail) 

2) This will in house only drives or compilations that in some 
    strange way uses this calls... 

3a) (DANGEROUS) global rename spin2_trylock to spin_trylock 
     [no logic change this time - only name] 
3b) (dangerous) add compatibility interface 
     #define spin_trylock(L) (!spin2_trylock(L)) 
     Probably not necessary since it can not be linked against. 
     Binary modules will contain their own compatibility code :-) 
     Probably preferred by those who maintain drivers for several 
     releases; 2.2, 2.4, ... 
3c) do not do anything more... 

Alternative: 
1b) do nothing at all - suffer later 

/RogerL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2000-12-04 20:18 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-11-25 15:07 *_trylock return on success? Roger Larsson
2000-11-25 17:49 ` Rik van Riel
2000-11-25 18:30   ` Philipp Rumpf
2000-11-25 19:03     ` Roger Larsson
2000-11-25 19:22       ` Philipp Rumpf
2000-11-25 21:05         ` Roger Larsson
2000-11-28  1:07           ` Roger Larsson
2000-11-25 18:58   ` Roger Larsson
  -- strict thread matches above, loose matches on Subject: below --
2000-12-04 19:46 george anzinger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox