Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4592203pxj; Wed, 12 May 2021 08:51:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwYoXOf61WuzV/zg5f3H8SKHYAXSJMoEOoeqWGzeXZff//Z9JISnhIEy1Ho0PTHH7Q9Dp5o X-Received: by 2002:a05:6402:487:: with SMTP id k7mr13827142edv.315.1620834679837; Wed, 12 May 2021 08:51:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620834679; cv=none; d=google.com; s=arc-20160816; b=Ql+sS2nX4SdVJyjZbZvI6cyHdJosIC1diqhj7SnqmvavQaF0x8kwm/8/fK9D3zE+5D AxeDJ3Xrx2DhxKBOpF6ohhfe8K0dD1E0R7PbQEdHXeGk1LGW8jG7n/ftG+upSCp5kHkW fGUe4toUbhZgIlVAbPLdCtBRj/TS41hTrBdGJieh0RqPgdJEr1koqZWgKqDR64Tu571m UBokfRGT0wasa7r1vAZBqOvK5vAubnXHstZWmha+5mU47k7oEauaRlPzb6hQcQlibAFz XtdEec42OIrAFjr7y0LbQuKA9kBNGDFBzDK6HqNCaiOjyqqo/WfPe2za8LGOLPPwsghW vBXw== 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=M/L8+szmmBM1XBAEKry3uCf1xAVDGvOQqNzkL1mJVcY=; b=YBytwBPxWOVwKzGOHsDI9k+3kR2H2BZOBwYBs40GbzukDtbIvRoRxLqnMU79Ce4eXd EpiNWXC4dLOVvAp/snvEaidbRfScqR6XZe9fL/VmgvGQRnQttcV0oAZfxmzWBNv9jq4r 6sv39lU3DPvL0cwEHvTS2Dlfb6MH5DafSjQBjMKGsCmzFN4skHRU4aQi0L7VhcJH2Kku YSsuLIn4qho9ne7dMt0jj4y+a/9mZvIvmklxZW33dnHtYU+Mli66xwYI+SioHHa8UClD cqPusJSA4JlmqC4rj5kHgQhBLP5amTCHzJyNOc5E/2neSsvx02QyjAdUDYKx7t/Al3ok YL5A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=dQ9A+MkV; 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 n24si324597eju.330.2021.05.12.08.50.54; Wed, 12 May 2021 08:51:19 -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=dQ9A+MkV; 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 S237257AbhELPs7 (ORCPT + 99 others); Wed, 12 May 2021 11:48:59 -0400 Received: from mail.kernel.org ([198.145.29.99]:60804 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233684AbhELPWb (ORCPT ); Wed, 12 May 2021 11:22:31 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id EE326619AA; Wed, 12 May 2021 15:09:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1620832163; bh=sBEwm+uHlyVNF45BaxNuJHaixHJpYJV7yDlSlaGqhwU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dQ9A+MkVgiRO9R5+YMbQfjWk/dkz4LX5F78QN2qBL1z3dXAuFCPYcRQmmb95L1gcE gBkjiYRk5mPC5q/wqwV2LDXsoWClflRDe2rDq1uGKZa38I+Wa+VAfpoZkQPk7KhNak sktSY4U/3nN55ngZ/0qPNQq5r4LB4IYPWvo5aVZ0= 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.10 167/530] devtmpfs: fix placement of complete() call Date: Wed, 12 May 2021 16:44:37 +0200 Message-Id: <20210512144825.326123199@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210512144819.664462530@linuxfoundation.org> References: <20210512144819.664462530@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 eac184e6d657..a71d14117943 100644 --- a/drivers/base/devtmpfs.c +++ b/drivers/base/devtmpfs.c @@ -416,7 +416,6 @@ static int __init devtmpfs_setup(void *p) init_chroot("."); out: *(int *)p = err; - complete(&setup_done); return err; } @@ -429,6 +428,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