Robert Love wrote:
> On Tue, 2002-07-09 at 14:00, William Lee Irwin III wrote:
>
>
>>This is an ugly aspect. But AFAICT the most that's needed to clean it
>>up is an explicit release before potentially sleeping.
>
>
> Yep that is all we need... remove the release_kernel_lock() and
> reacquire_kernel_lock() from schedule and do it explicitly everywhere it
> is needed.
>
> The problem is, it is needed in a _lot_ of places. Mostly instances
> where the lock is held across something that may implicitly sleep.
And _that_ is why I wrote the BKL debugging patch, to help find these
places at runtime. It may not be pretty, but it works. I'll post it
again if you're interested.
--
Dave Hansen
[email protected]
On Tue, 2002-07-09 at 07:19, Dave Hansen wrote:
> Robert Love wrote:
>
> > The problem is, it is needed in a _lot_ of places. Mostly instances
> > where the lock is held across something that may implicitly sleep.
>
> And _that_ is why I wrote the BKL debugging patch, to help find these
> places at runtime. It may not be pretty, but it works. I'll post it
> again if you're interested.
I saw the patch... the problem is we cannot say "oh I ran this code path
with the patch and did not see anything, it is safe". Can sleep != will
sleep, and thus we have code that 99% will not sleep but it may.
I suspect on my 1GB machine I rarely page fault on copy_*_user but that
does not mean it could not sleep.
If you find all the culprits and think you can safely remove the
release/reacquire routines from schedule, all the power to you.
Robert Love