Date: Mon, 19 May 2003 19:54:41 -0400
From: Pete Zaitcev <zaitcev@redhat.com>
Message-Id: <200305192354.h4JNsfQ09659@devserv.devel.redhat.com>
To: linux-kernel@vger.kernel.org
Subject: Re: recursive spinlocks. Shoot.
In-Reply-To: <mailman.1053352200.24653.linux-kernel2news@redhat.com>
References: <200305191337.h4JDbf311387@oboe.it.uc3m.es> <mailman.1053352200.24653.linux-kernel2news@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1353
Lines: 38

>> Let's quote the example from rubini & corbet of the sbull block device
>> driver. The request function ends like so:
> 
> defective locking in a driver is no excuse to pamper over it with
> recusrive shite.

Arjan is a little too harsh here, but on the principle I happen
to agree, because I worked with systems which allow recursive locks.
They very often cover up for programmer's lack of basic understanding.
Worse, sometimes even experienced programmers can do poorly.
I ran into the latter cathegory of code when fixing so-called
"presto" in Solaris (now replaced by Encore-originated code).

Normal spinlocks are not without problems, in particular people
tend to write:

   void urb_rm_priv_locked(struct urb *) {
     ......
   }
   void urb_rm_priv(struct urb *u) {
     spin_lock_irqsave();
     urb_rm_prin_locked(u);
     spin_unlock_irqrestore();
   }

Which eats a stack frame. We make this tradeoff on purpose,
as a lesser evil.

BTW, I do not see Linus and his leutenants rebuking the onslaught
of recursive ingenuity in this thread. Ignoring the hogwash,
or waiting and watching?

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