Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4719818pxj; Wed, 12 May 2021 11:39:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzu1CgaaR0tQXFTnsC7e2fD6bAXT3JlxwYCtSPaYjBhaXCP/2R31Ouu491qGnQ4KyVg7Lzh X-Received: by 2002:a17:906:4795:: with SMTP id cw21mr38543851ejc.304.1620844779893; Wed, 12 May 2021 11:39:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620844779; cv=none; d=google.com; s=arc-20160816; b=S39jUEj/muYPtDkW8KzWIg1ZfsYslxaClF9FJ4+nEaknkzXIPe6p0C2R4Ga2G2JMma tEnMq+xQW5NRNtSgEUbAzGHYWH1br2NrX1NWPcV+gBN8D50QSvmoUWIuz9nrlk/JqjyH Mds0kwi0FLEe8fJuk9YYfq2FI6wqCjrQ1FSbQm0lJaQMjyPUiikenI81nzrIHsSC+pYT 8h5MR1Lk8T3Tz9Hqp4FphOkn90V++2xqHVVaw6Ny+jzvNLj50vpDBN4ru8UU22MX0Pu/ 4hXJul8aNvROz646wecW9J4kGq4HKOfqmLYoSSJm1AU8+BkF+hTIxbNJ85EYtvTkq2Pv zqtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=tGT2hHf411Gq1VqL7jdmh+dH2dmwLyxKALkvj8a1m+U=; b=e8PEAm6IvGpVGOWgvpJEB4q8NLieAgEG+1VT7SQRkvli/s8XCzMDZIiW8TrLUR2thv b2wMxsmsNyVXznQPMC3f6kb6AH2hvUTsI2hqPCZKrjqzpNvjoko3wxj/ds18rLlBN3EM by3nznpdsxmUhRhFhF8fbruLcoQrp1vQNBVGPW4WptmiuQn04vfkrDFZgdGREnTIfHry FJPJ4ToZKYm7Qv0fNtqNXgjUgP6MArRWcHIcd4M6dDKN6QBNSEz+u7mT8gnqKr9rUEc3 xe0oIudDBoI2HMhiMV2m3B0YJ+CqrKiAcUxUDtUChusCyc0SPVPwb1OuPXtxjtP20o9r SPCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="QAI/Fin6"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x22si351718eds.436.2021.05.12.11.39.16; Wed, 12 May 2021 11:39:39 -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; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="QAI/Fin6"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354902AbhELS0g (ORCPT + 99 others); Wed, 12 May 2021 14:26:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:50690 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235902AbhELQcO (ORCPT ); Wed, 12 May 2021 12:32:14 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9916861107; Wed, 12 May 2021 15:58:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1620835113; bh=0vI9HVHUZLdAeqwj9RGj/+rSjzHBRRXnRRmJjFn913Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QAI/Fin6Qz2mImrnNHKQMw7bkehDShRMB8+72Pn/+Cp7YDIiMP0dJ1uTyK6T4c71i Xog2gbLia4tctAnldQD62sd+B8e3ABcu/PxSkFiDVvf8fKImqrmOq90tLVMs4GhlKi tlhpi6FnlsTn/2xDDVrpIOgxu1N6gtoVdJ2h7nCA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Christoph Hellwig , Rasmus Villemoes , Sasha Levin Subject: [PATCH 5.12 213/677] devtmpfs: fix placement of complete() call Date: Wed, 12 May 2021 16:44:19 +0200 Message-Id: <20210512144844.315836325@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210512144837.204217980@linuxfoundation.org> References: <20210512144837.204217980@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rasmus Villemoes [ Upstream commit 38f087de8947700d3b06d3d1594490e0f611c5d1 ] Calling complete() from within the __init function is wrong - theoretically, the init process could proceed all the way to freeing the init mem before the devtmpfsd thread gets to execute the return instruction in devtmpfs_setup(). In practice, it seems to be harmless as gcc inlines devtmpfs_setup() into devtmpfsd(). So the calls of the __init functions init_chdir() etc. actually happen from devtmpfs_setup(), but the __ref on that one silences modpost (it's all right, because those calls happen before the complete()). But it does make the __init annotation of the setup function moot, which we'll fix in a subsequent patch. Fixes: bcbacc4909f1 ("devtmpfs: refactor devtmpfsd()") Reviewed-by: Christoph Hellwig Signed-off-by: Rasmus Villemoes Link: https://lore.kernel.org/r/20210312103027.2701413-1-linux@rasmusvillemoes.dk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin --- drivers/base/devtmpfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c index 653c8c6ac7a7..aedeb2dc1a18 100644 --- a/drivers/base/devtmpfs.c +++ b/drivers/base/devtmpfs.c @@ -419,7 +419,6 @@ static int __init devtmpfs_setup(void *p) init_chroot("."); out: *(int *)p = err; - complete(&setup_done); return err; } @@ -432,6 +431,7 @@ static int __ref devtmpfsd(void *p) { int err = devtmpfs_setup(p); + complete(&setup_done); if (err) return err; devtmpfs_work_loop(); -- 2.30.2