Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp780818pxy; Wed, 5 May 2021 13:49:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzsnio2KKI0C/WkMiDPWlXrqIsnrAflTKiFu6FmWkvkKz2jrdFr0thxlAU1OpeQS0v/CDHT X-Received: by 2002:a17:902:d508:b029:ee:d95b:c39d with SMTP id b8-20020a170902d508b02900eed95bc39dmr658373plg.42.1620247771173; Wed, 05 May 2021 13:49:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620247771; cv=none; d=google.com; s=arc-20160816; b=a0RxtyLUtvTlejJwL32bGc+mkaFS1ZB1QeRiHleD8zQnYtFRS60S1KUKMJt9huNEB3 Pl+5Kd54E4tE9gsqZFOTPOUhVE5EihdoHvgx82t071I6n/PqI+CdraQSPXD3eOW7TH/i mk1aNsLeCbx2bLcTZ7CBUB1tE4XHv00lxAqk2CJ1Jd6bZAPMmsTUv/CijBbpnfLjG7HZ EBOTzvPBQpo73CDKHFNUkY9NGS2/PG/5LbTOEL5j52Sq4VMnMX9rNz415NGyPBF2hFFv IJRgD8XdEOLkwMeAaXl2coXtCLTT1qL5HaY2jqtwpvB/CmsU39g961bEtzveNc/WeGIJ /dUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:organization :message-id:user-agent:references:in-reply-to:subject:cc:to:from :date:mime-version; bh=imrlV6Z/cO6PFn31hQFwFzPcitm32XGd4xgd/XI0mM4=; b=E4gR9uKInLMp88x3hohjZdzMdOHWMLmUczuvNuR+cG0IzW9zYTzfwyu8c4lbn3bRKM P1xrQPaYZL/KSUr9KV0ZJCADQ0xcrL0U+2RFvjl+hmPbo+/0+w7fEb6mYkJAJRRsLVBs +8z0EmfcKy5IjitNEq/8cEUZarDWYWWuvwCr0ifc3BFkVR+GvG2LGYNxEOmFPdgooIll tOYCv+fGP6owXMeUA2/YDSuCGpuQe40cdFOLfmGIvLWS8m//VuwhNiaHsS0fW9uEC4NX uDj9RgStLkp9qy3JcTz+3oKJvoJ34r6UBakAyIXor9+/n5wW3Ic/9QuwQC0KLWn0pdf6 K4/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r7si390357pgv.466.2021.05.05.13.49.17; Wed, 05 May 2021 13:49:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233373AbhEEPMy (ORCPT + 99 others); Wed, 5 May 2021 11:12:54 -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 ); 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 To: Varad Gautam Cc: linux-kernel@vger.kernel.org, Matthias von Faber , Christian Brauner , Oleg Nesterov , "Eric W. Biederman" , Manfred Spraul , Andrew Morton Subject: Re: [PATCH] ipc/mqueue: Avoid relying on a stack reference past its expiry In-Reply-To: References: <20210504155534.17270-1-varad.gautam@suse.com> <4959eb8d8c14b00113370ae86dc7c9f5@suse.de> 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: 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