[EMAIL PROTECTED] said:
> In message <[EMAIL PROTECTED]> you write:
> > [EMAIL PROTECTED] said:
> > > Good point. Spinlocks (with the exception of read-read locks, of
> > > course) and semaphores will deadlock on recursive use, while the BKL
> > > has this "process usage counter" recursion prote
In message <[EMAIL PROTECTED]> you write:
>
> [EMAIL PROTECTED] said:
> > Good point. Spinlocks (with the exception of read-read locks, of
> > course) and semaphores will deadlock on recursive use, while the BKL
> > has this "process usage counter" recursion protection.
>
> Obtaining a read loc
> > Sure, it's a pretty interaction. To be sure about the rule: any *_user
> > call can be treated as an implicit invocation of do_page_fault?
>
> As a first approximation, yes. The exception cases are certain callers
> that use kernel addresses and set_fs(KERNEL_DS) in order to "fake"
> argum
On Sat, 9 Jun 2001, Dawson Engler wrote:
> >
> > Good point. Spinlocks (with the exception of read-read locks, of course)
> > and semaphores will deadlock on recursive use, while the BKL has this
> > "process usage counter" recursion protection.
>
> Actually, it did show up all over the place -
> On Sat, 9 Jun 2001, Alexander Viro wrote:
> >
> > Another difference from spinlocks is that BKL is recursive. I'm
> > actually surprised that it didn't show up first.
>
> Good point. Spinlocks (with the exception of read-read locks, of course)
> and semaphores will deadlock on recursive use, w
On Sat, 9 Jun 2001, Linus Torvalds wrote:
> On Sat, 9 Jun 2001, Alexander Viro wrote:
> >
> > True, but... I can easily see the situation when ->foo() and ->bar()
> > both call a helper function which needs BKL for a small piece of code.
>
> I'd hope that we can fix the small helper functions
On Sat, 9 Jun 2001, Alexander Viro wrote:
>
> True, but... I can easily see the situation when ->foo() and ->bar()
> both call a helper function which needs BKL for a small piece of code.
I'd hope that we can fix the small helper functions to not need BKL -
there are already many circumstances
In article <[EMAIL PROTECTED]>,
David Woodhouse <[EMAIL PROTECTED]> wrote:
>
>Obtaining a read lock twice can deadlock too, can't it?
If it does (with spinlocks), then that's an implementation bug (which
might well be there). We depend on the read-lock being recursive in a
lot of places, notabl
On Sat, 9 Jun 2001, Linus Torvalds wrote:
> Anyway, in a 2.5.x timeframe we should probably make sure that we do not
> have the need for a recursive BKL any more. That shouldn't be that hard to
> fix, especially with help from CHECKER to verify that we didn't forget
> some case.
True, but... I
[EMAIL PROTECTED] said:
> Good point. Spinlocks (with the exception of read-read locks, of
> course) and semaphores will deadlock on recursive use, while the BKL
> has this "process usage counter" recursion protection.
Obtaining a read lock twice can deadlock too, can't it?
A
On Sat, 9 Jun 2001, Alexander Viro wrote:
>
> Another difference from spinlocks is that BKL is recursive. I'm
> actually surprised that it didn't show up first.
Good point. Spinlocks (with the exception of read-read locks, of course)
and semaphores will deadlock on recursive use, while the BKL
On 9 Jun 2001, Linus Torvalds wrote:
> The big kernel lock rules are that it's a "normal spinlock" in many
> regards, BUT you can block while holding it, and the BKL will magically
> be released during the blocking. This means, for example, that the BKL
> can never deadlock with a semaphore -
In article <[EMAIL PROTECTED]>,
Dawson Engler <[EMAIL PROTECTED]> wrote:
>
>we're starting to develop a checker that finds deadlocks by (1)
>computing all lock acquisition paths and (2) checking if two paths
>violate a partial order.
Looks good.
>The checker is pretty primitive. In particular
On Sat, 9 Jun 2001, Dawson Engler wrote:
> Hi All,
>
> we're starting to develop a checker that finds deadlocks by (1)
> computing all lock acquisition paths and (2) checking if two paths
> violate a partial order.
>
> E.g., for two threads T1 and T2:
> T1: foo acquires A --> calls bar
Hi All,
we're starting to develop a checker that finds deadlocks by (1)
computing all lock acquisition paths and (2) checking if two paths
violate a partial order.
E.g., for two threads T1 and T2:
T1: foo acquires A --> calls bar which tries to acquire B
T2: baz acquires B --> ca
15 matches
Mail list logo
