"Andrew E. Mileski" <aem@netcom.ca> writes:
> > The last time I was working with the loop encryption I managed to
> > really screw up my system.
>
> Thanks to a hint from Andries Brouwer, I think I've squashed this bug :-)
> Before I announce victory, I need to get a question answered:
>
> What's the difference between BH_Locked and BH_Protected?
BH_Locked prevents anybody from accessing the buffer (if they call
wait_on_buffer, that is). BH_Protected just prevents reuse of the
buffer, and IMHO is a broken feature --- if you want to pin a buffer
against reuse, the correct way should really be to increment b_count
around the critical code.
> Using BH_Protected seems to work for the loop driver - buffers for the
> requests it creates cannot be freed until the loop driver is finished
> with them [or so I'm led to believe by the ramdisk driver].
If that's all you want, then use b_count instead. It has the
advantage that two concurrent processes trying to pin the buffer in
memory won't conflict with each other.
> While I'm here, two more questions:
> Does calling schedule() set "current" to the next run-able process
> if "current" is already run-able? If no, then how do you do this?
schedule() doesn't always force a new process to run --- it decides
based on the current credits available to each runnable process. If
you want to force the current process out of scheduling, then you
should either suspend it by setting its state to TASK_INTERRUPTIBLE or
TASK_UNINTERRUPTIBLE, or by setting its scheduling credits to zero by
doing
current->counter = 0;
schedule()
However, that's a bad idea if it's going to happen a lot, since you'll
end up screwing up the credits for the scheduling of any user code
which runs after the syscall, too.
Cheers,
Stephen.