All of lore.kernel.org
 help / color / mirror / Atom feed
From: Schspa Shi <schspa@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, cocci@inria.fr, mcgrof@kernel.org,
	Julia Lawall <Julia.Lawall@inria.fr>,
	Nicolas Palix <nicolas.palix@imag.fr>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Valentin Schneider <vschneid@redhat.com>,
	buytenh@wantstofly.org, johannes.berg@intel.com,
	gregkh@linuxfoundation.org, tomba@kernel.org, airlied@gmail.com,
	daniel@ffwll.ch
Subject: Re: [cocci] [RFC PATCH] cocci: cpi: add complete api check script
Date: Tue, 28 Feb 2023 00:36:26 +0800	[thread overview]
Message-ID: <m2mt4z5adr.fsf@gmail.com> (raw)
In-Reply-To: <20230227105310.08d9a46e@gandalf.local.home>


Steven Rostedt <rostedt@goodmis.org> writes:

> On Mon, 27 Feb 2023 16:43:59 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
>
>> On Mon, Feb 27, 2023 at 10:28:08AM -0500, Steven Rostedt wrote:
>> 
>> > So what exact race are you trying to catch here?  
>> 
>> on-stack copmletion with a wait_for_completion that can return early
>> (eg. killable, interruptible, or timeout) can go out of scope (eg, free
>> the completion) with the other side calling complete() on some possibly
>> re-used piece of stack.
>> 
>> IOW, Use-after-Free.
>> 
>> Care must be taken to ensure the other side (whatever does complete())
>> is either terminated or otherwise stopped from calling complete() on an
>> out-of-scope variable.
>
> I got that. But as you were stating as well, when care is taken, the script
> appears to still report it. The example I gave has:
>
>         req = blk_mq_alloc_request(q, REQ_OP_DRV_OUT, 0);
> [..]
>         req->end_io_data = &wait;
> [..]
>         hba->tmf_rqs[req->tag] = req;
> [..]
>         err = wait_for_completion_io_timeout(&wait,
> [..]
>         spin_lock_irqsave(hba->host->host_lock, flags);
>         hba->tmf_rqs[req->tag] = NULL;
>         __clear_bit(task_tag, &hba->outstanding_tasks);
>         spin_unlock_irqrestore(hba->host->host_lock, flags);
>
>
> And where the complete is:
>
>         spin_lock_irqsave(hba->host->host_lock, flags);
>         pending = ufshcd_readl(hba, REG_UTP_TASK_REQ_DOOR_BELL);
>         issued = hba->outstanding_tasks & ~pending;
>         for_each_set_bit(tag, &issued, hba->nutmrs) {
>                 struct request *req = hba->tmf_rqs[tag];
>                 struct completion *c = req->end_io_data;
>  
>                 complete(c);
>                 ret = IRQ_HANDLED;
>         }
>         spin_unlock_irqrestore(hba->host->host_lock, flags);
>
> So the spinlock is making sure that the complete() only works on a
> completion if it is still there.
>
There is nothing wrong with your code.

This script will not check the hba->host->host_lock lock, and there is
another hba->outstanding_tasks bit mask to ensure that there is no UAF
here. But this script doesn't have a way to get these implicit
conditions.

> I guess I should have asked, how is this script differentiating between
> where there's a problem and where there isn't.
>
> If you remove the spinlocks, then there would most definitely be a race,
> and I'm not even sure if the supplied patch would improve this much.
>
> -- Steve


-- 
BRs
Schspa Shi

WARNING: multiple messages have this Message-ID (diff)
From: Schspa Shi <schspa@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, cocci@inria.fr, mcgrof@kernel.org,
	Julia Lawall <Julia.Lawall@inria.fr>,
	Nicolas Palix <nicolas.palix@imag.fr>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	AngeloGioacchino Del Regno 
	<angelogioacchino.delregno@collabora.com>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Valentin Schneider <vschneid@redhat.com>,
	buytenh@wantstofly.org, johannes.berg@intel.com,
	gregkh@linuxfoundation.org, tomba@kernel.org, airlied@gmail.com,
	daniel@ffwll.ch
Subject: Re: [RFC PATCH] cocci: cpi: add complete api check script
Date: Tue, 28 Feb 2023 00:36:26 +0800	[thread overview]
Message-ID: <m2mt4z5adr.fsf@gmail.com> (raw)
In-Reply-To: <20230227105310.08d9a46e@gandalf.local.home>


Steven Rostedt <rostedt@goodmis.org> writes:

> On Mon, 27 Feb 2023 16:43:59 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
>
>> On Mon, Feb 27, 2023 at 10:28:08AM -0500, Steven Rostedt wrote:
>> 
>> > So what exact race are you trying to catch here?  
>> 
>> on-stack copmletion with a wait_for_completion that can return early
>> (eg. killable, interruptible, or timeout) can go out of scope (eg, free
>> the completion) with the other side calling complete() on some possibly
>> re-used piece of stack.
>> 
>> IOW, Use-after-Free.
>> 
>> Care must be taken to ensure the other side (whatever does complete())
>> is either terminated or otherwise stopped from calling complete() on an
>> out-of-scope variable.
>
> I got that. But as you were stating as well, when care is taken, the script
> appears to still report it. The example I gave has:
>
>         req = blk_mq_alloc_request(q, REQ_OP_DRV_OUT, 0);
> [..]
>         req->end_io_data = &wait;
> [..]
>         hba->tmf_rqs[req->tag] = req;
> [..]
>         err = wait_for_completion_io_timeout(&wait,
> [..]
>         spin_lock_irqsave(hba->host->host_lock, flags);
>         hba->tmf_rqs[req->tag] = NULL;
>         __clear_bit(task_tag, &hba->outstanding_tasks);
>         spin_unlock_irqrestore(hba->host->host_lock, flags);
>
>
> And where the complete is:
>
>         spin_lock_irqsave(hba->host->host_lock, flags);
>         pending = ufshcd_readl(hba, REG_UTP_TASK_REQ_DOOR_BELL);
>         issued = hba->outstanding_tasks & ~pending;
>         for_each_set_bit(tag, &issued, hba->nutmrs) {
>                 struct request *req = hba->tmf_rqs[tag];
>                 struct completion *c = req->end_io_data;
>  
>                 complete(c);
>                 ret = IRQ_HANDLED;
>         }
>         spin_unlock_irqrestore(hba->host->host_lock, flags);
>
> So the spinlock is making sure that the complete() only works on a
> completion if it is still there.
>
There is nothing wrong with your code.

This script will not check the hba->host->host_lock lock, and there is
another hba->outstanding_tasks bit mask to ensure that there is no UAF
here. But this script doesn't have a way to get these implicit
conditions.

> I guess I should have asked, how is this script differentiating between
> where there's a problem and where there isn't.
>
> If you remove the spinlocks, then there would most definitely be a race,
> and I'm not even sure if the supplied patch would improve this much.
>
> -- Steve


-- 
BRs
Schspa Shi

  reply	other threads:[~2023-03-04 16:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-27  7:53 [cocci] [RFC PATCH] cocci: cpi: add complete api check script Schspa Shi
2023-02-27  7:53 ` Schspa Shi
2023-02-27 11:20 ` [cocci] " Peter Zijlstra
2023-02-27 11:20   ` Peter Zijlstra
2023-02-27 15:28   ` [cocci] " Steven Rostedt
2023-02-27 15:28     ` Steven Rostedt
2023-02-27 15:43     ` [cocci] " Peter Zijlstra
2023-02-27 15:43       ` Peter Zijlstra
2023-02-27 15:53       ` [cocci] " Steven Rostedt
2023-02-27 15:53         ` Steven Rostedt
2023-02-27 16:36         ` Schspa Shi [this message]
2023-02-27 16:36           ` Schspa Shi
2023-02-27 16:10   ` [cocci] " Schspa Shi
2023-02-27 16:10     ` Schspa Shi
2023-02-27 15:54 ` [cocci] [RFC PATCH] coccinelle: Add SmPL script for completion API check Markus Elfring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2mt4z5adr.fsf@gmail.com \
    --to=schspa@gmail.com \
    --cc=Julia.Lawall@inria.fr \
    --cc=airlied@gmail.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=buytenh@wantstofly.org \
    --cc=cocci@inria.fr \
    --cc=daniel@ffwll.ch \
    --cc=dietmar.eggemann@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=johannes.berg@intel.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mcgrof@kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=nicolas.palix@imag.fr \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tomba@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.