Date:   Mon, 27 Feb 2023 10:53:10 -0500
From:   Steven Rostedt <rostedt@goodmis.org>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Schspa Shi <schspa@gmail.com>, 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
Message-ID: <20230227105310.08d9a46e@gandalf.local.home>
In-Reply-To: <Y/zPv+L2iqOkD2Oa@hirez.programming.kicks-ass.net>
References: <20230227075346.69658-1-schspa@gmail.com>
        <Y/yR/LypvJQXRhAr@hirez.programming.kicks-ass.net>
        <20230227102808.2cea9705@gandalf.local.home>
        <Y/zPv+L2iqOkD2Oa@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.

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