From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS
	autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 3EB0EC433ED
	for <linux-kernel@archiver.kernel.org>; Wed,  5 May 2021 15:12:00 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id F2EC761176
	for <linux-kernel@archiver.kernel.org>; Wed,  5 May 2021 15:11:59 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S233395AbhEEPMz (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Wed, 5 May 2021 11:12:55 -0400
Received: from mx2.suse.de ([195.135.220.15]:36406 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S233085AbhEEPMy (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 5 May 2021 11:12:54 -0400
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.221.27])
        by mx2.suse.de (Postfix) with ESMTP id 1C1DEB29F;
        Wed,  5 May 2021 15:11:57 +0000 (UTC)
MIME-Version: 1.0
Date:   Wed, 05 May 2021 08:11:56 -0700
From:   Davidlohr Bueso <dbueso@suse.de>
To:     Varad Gautam <varad.gautam@suse.com>
Cc:     linux-kernel@vger.kernel.org,
        Matthias von Faber <matthias.vonfaber@aox-tech.de>,
        Christian Brauner <christian.brauner@ubuntu.com>,
        Oleg Nesterov <oleg@redhat.com>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Manfred Spraul <manfred@colorfullife.com>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] ipc/mqueue: Avoid relying on a stack reference past its
 expiry
In-Reply-To: <fe1b29a0-af09-e270-de52-09bacac35d86@suse.com>
References: <20210504155534.17270-1-varad.gautam@suse.com>
 <4959eb8d8c14b00113370ae86dc7c9f5@suse.de>
 <fe1b29a0-af09-e270-de52-09bacac35d86@suse.com>
User-Agent: Roundcube Webmail
Message-ID: <6fbcb0fa502e7574f87213fc29877ed8@suse.de>
X-Sender: dbueso@suse.de
Organization: SUSE Labs
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2021-05-05 00:49, Varad Gautam wrote:
> The race here really is about the lifetime of __pipelined_op's `this`
> argument only
> being guaranteed for some duration of the call (ie, until someone sets
> ->state = STATE_READY). It is not about when wake_q addition happens,
> as long as it is
> being fed a valid task_struct.

Again, it's all about ensuring that the READY_STATE is set last, the 
blocked
task has no business returning in the first place, making both races 
(exit and
the one reported here) similar by ending up using bogus memory.

...

> I considered that initially, but given that the race isn't connected
> with wakeup, I
> preferred the current approach which makes this fact explicit by 
> showing what's
> valid/invalid during __pipelined_op.

I understand your point, but this is why I updated the ordering 
comments. Furthermore
there is no reason to decouple the task's refcount with the wake_q_add 
operation, it
just makes the code weird and harder to follow.

Thanks,
Davidlohr