Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1372162

Re: [PATCH] [RFC] fix potential access after free: return value of blk_check_plugged() must be used schedule() safe

From NeilBrown <neilb@suse.de>
Newsgroups linux.kernel
Subject Re: [PATCH] [RFC] fix potential access after free: return value of blk_check_plugged() must be used schedule() safe
Date 2016-04-06 05:20 +0200
Message-ID <rkMaB-60f-3@gated-at.bofh.it> (permalink)
References <rkzn4-4jC-27@gated-at.bofh.it> <rkJZ8-3Wx-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] [RFC] fix potential access after free: return value of  blk_check_plugged() must be used schedule() safe Lars Ellenberg <lars.ellenberg@linbit.com> - 2016-04-05 15:40 +0200
  Re: [PATCH] [RFC] fix potential access after free: return value of blk_check_plugged() must be used schedule() safe NeilBrown <neilb@suse.de> - 2016-04-06 01:00 +0200
  Re: [PATCH] [RFC] fix potential access after free: return value of  blk_check_plugged() must be used schedule() safe Chris Mason <clm@fb.com> - 2016-04-06 02:40 +0200
  Re: [PATCH] [RFC] fix potential access after free: return value of  blk_check_plugged() must be used schedule() safe Shaohua Li <shli@kernel.org> - 2016-04-06 03:00 +0200
    Re: [PATCH] [RFC] fix potential access after free: return value of blk_check_plugged() must be used schedule() safe NeilBrown <neilb@suse.de> - 2016-04-06 05:20 +0200
      Re: [PATCH] [RFC] fix potential access after free: return value of  blk_check_plugged() must be used schedule() safe Lars Ellenberg <lars.ellenberg@linbit.com> - 2016-04-06 14:10 +0200

csiph-web