On Wed, Apr 06 2016, Shaohua Li wrote: > On Tue, Apr 05, 2016 at 03:36:57PM +0200, Lars Ellenberg wrote: >> blk_check_plugged() will return a pointer >> to an object linked on current->plug->cb_list. >> >> That list may "at any time" be implicitly cleared by >> blk_flush_plug_list() >> flush_plug_callbacks() >> either as a result of blk_finish_plug(), >> or implicitly by schedule() [and maybe other implicit mechanisms?] >> >> If there is no protection against an implicit unplug >> between the call to blk_check_plug() and using its return value, >> that implicit unplug may have already happened, >> even before the plug is actually initialized or populated, >> and we may be using a pointer to already free()d data. > > This isn't correct. flush plug is never called in preemption, which is > designed > only called when the task is going to sleep. See sched_submit_work. Am I > missing anything?
Ahh yes, thanks.
Only two places call blk_schedule_flush_plug().
One is io_schedule_timeout() which must be called explicitly.
There other is, as you say, sched_submit_work(). It starts:
static inline void sched_submit_work(struct task_struct *tsk)
{
if (!tsk->state || tsk_is_pi_blocked(tsk))
return;
so if the task is runnable, then as
include/linux/sched.h:#define TASK_RUNNING 0
it will never call blk_schedule_flush_plug().
So I don't think you are missing anything, we were.
Lars: have your concerns been relieved or do you still have reason to
think there is a problem?
Thanks,
NeilBrown
signature.asc
Description: PGP signature
