Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1047095pxb; Thu, 4 Mar 2021 01:39:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJz2lMd47tdQFLJX2uuGXHCY0br96xtjZCeV25rzs34TOfxNhRzQOCCv6MUTaLAzDFfLCvJP X-Received: by 2002:a17:906:3916:: with SMTP id f22mr3287071eje.328.1614850788419; Thu, 04 Mar 2021 01:39:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614850788; cv=none; d=google.com; s=arc-20160816; b=U/b+QlbhaCY4VhuyHZuJdgs+rShCM53itc3u34GEh3P72cwA7CPYSkp6gjXeZd7+qH /rcbeDzeEAR39RNJTh4LwUcORMHOmhmoTNV3Rs6E9dlxPy0ifrRnVySOtLgDNTaNbukZ xiyfNXLvJE6F9FngAhoSbX/kAEpwdaFyQvBptmmOGF/N9ldytiqMAMh9YsEGNzKlLJym 1W3PwxTSQimCQgnFUiq6jnZAsEMpwozN7aW+w1uI0ItjPnmVdWiWzCtHUWuPOP5RCvW3 QEM4SWv0Q7R+/GtbLgEU6kBAf/d1L7Eu0x3l65pbaBysj4r2Q3rj7vehVlmKOOkMX10z Rq5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=94FU4aImSyveb72Fh42pjQwrSbJ+f3XzeivB4wSoR78=; b=SIeHIdqkOLUeGu5u4kEIcUySfIrBMTAm4P1RtjuQM4eIT4Jcmd2dsXREdaAfpAB3BY JfrB2Vj8WFoWIrEkUlr6/FqGIUB+2A/GTsLoEpY6EowxDHJ5BAKp76UveIm/6zJ9FWLq dIGjGq5tGA67f98jfkNb9k9x4CntCj6bG1gR1nCmZ7mkDZugVdcrT/i2AdUgJkk74HpO vYU4cuwievV9/+7Brg9DR8rdgNt+TuZ/CVR2wff1kH/2IhrSHHl1pTtr89aC+T+UCzod xwsmbsK8I5/Xyr4N42S601Qeq4bown7X7nYfvXuPg+wgo3D+XY09Z3s+RLPYyqFNUebX wjHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=TPsmqF4D; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g22si16101836edw.133.2021.03.04.01.39.25; Thu, 04 Mar 2021 01:39:48 -0800 (PST) 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=@google.com header.s=20161025 header.b=TPsmqF4D; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1447648AbhCCPQE (ORCPT + 99 others); Wed, 3 Mar 2021 10:16:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39178 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240097AbhCCK2I (ORCPT ); Wed, 3 Mar 2021 05:28:08 -0500 Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90B48C061788 for ; Wed, 3 Mar 2021 02:27:28 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id q203so2368861oih.5 for ; Wed, 03 Mar 2021 02:27:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=94FU4aImSyveb72Fh42pjQwrSbJ+f3XzeivB4wSoR78=; b=TPsmqF4DiwneZsBqICYdPOa29BGt70SR8yCZLys0WXRd8rFZIw1GUvfX7iMCLGVxQB C5MxaiTdM2gnMZNd72rNUuRZReFaYDvCJjfAct7n3kaMDZiPbvkoIcgD51I7edBYM3uZ G50f5hmZYM9BO0FHhjNfGoty7zvsPgda8dQcV/T0vY3cDDJEgTR12X+zUTJvY6dy6IUS k35maJzmrft8jBKaRug9SJYxosur19yPY8DQpYLY3c4AqAmhEMOKX/mxPqj7+H0EQV7i 6FQgEmBjjdmvMIMRpbNJV+phC4qgeQ4OJ2usuyXDHwugttb/emwZ5rh53RsQyOm+P2TY 84fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=94FU4aImSyveb72Fh42pjQwrSbJ+f3XzeivB4wSoR78=; b=Te2qu2GCooafewt8M351qm2ERO/qr8JmdI8LSu1jzbDHGpNwiC8hxd39lIIUP5fi87 D4acfJrv09siabLhjiB0aKrIAAPDojBdf40uuVP/DGwhMC5Eh6d9TTaKOpj9glW4FS5B De5RJfc2Z8rzEy3Dleh1x57osYLcXY+jBhyToydmvyookLVT5Cbfdo0oeuolNrXGjsQQ 5he8bIjQ3XX8aJK3Fsc8l2IHKSDikIgfcJb6aZf0iHhmKih1vZbFQTI6yFp6y3ku7O0R mloSCs6THRpOXKzBMpsnprrZzDlr4p7e7X/9KXjufqrE3Bsl8tDeUg1w5dMY7A484gfO dPFg== X-Gm-Message-State: AOAM530tgZ4YivWlBmbYyiZRCJXA3UpgX0XlV7A+Yr3wSiwSv5B7bcpi aWonJBbSWrHmcz4J+2Pi6KfUTeIPjA7ohbhM+pB3Dw== X-Received: by 2002:aca:5fd4:: with SMTP id t203mr6668726oib.121.1614767247769; Wed, 03 Mar 2021 02:27:27 -0800 (PST) MIME-Version: 1.0 References: <20210303093845.2743309-1-elver@google.com> In-Reply-To: From: Marco Elver Date: Wed, 3 Mar 2021 11:27:16 +0100 Message-ID: Subject: Re: [PATCH] kcsan, debugfs: Move debugfs file creation out of early init To: Greg KH Cc: rafael@kernel.org, "Paul E. McKenney" , Dmitry Vyukov , Alexander Potapenko , Andrey Konovalov , kasan-dev , LKML , stable Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 3 Mar 2021 at 11:24, Greg KH wrote: > On Wed, Mar 03, 2021 at 11:18:06AM +0100, Marco Elver wrote: > > On Wed, 3 Mar 2021 at 10:57, Greg KH wrote: > > > > > > On Wed, Mar 03, 2021 at 10:38:45AM +0100, Marco Elver wrote: > > > > Commit 56348560d495 ("debugfs: do not attempt to create a new file > > > > before the filesystem is initalized") forbids creating new debugfs files > > > > until debugfs is fully initialized. This breaks KCSAN's debugfs file > > > > creation, which happened at the end of __init(). > > > > > > How did it "break" it? The files shouldn't have actually been created, > > > right? > > > > Right, with 56348560d495 the debugfs file isn't created anymore, which > > is the problem. Before 56348560d495 the file exists (syzbot wants the > > file to exist.) > > > > > > There is no reason to create the debugfs file during early > > > > initialization. Therefore, move it into a late_initcall() callback. > > > > > > > > Cc: Greg Kroah-Hartman > > > > Cc: "Rafael J. Wysocki" > > > > Cc: stable > > > > Fixes: 56348560d495 ("debugfs: do not attempt to create a new file before the filesystem is initalized") > > > > Signed-off-by: Marco Elver > > > > --- > > > > I've marked this for 'stable', since 56348560d495 is also intended for > > > > stable, and would subsequently break KCSAN in all stable kernels where > > > > KCSAN is available (since 5.8). > > > > > > No objection from me, just odd that this actually fixes anything :) > > > > 56348560d495 causes the file to just not be created if we try to > > create at the end of __init(). Having it created as late as > > late_initcall() gets us the file back. > > > > When you say "fixes anything", should the file be created even though > > it's at the end of __init()? Perhaps I misunderstood what 56348560d495 > > changes, but I verified it to be the problem by reverting (upon which > > the file exists as expected). > > All my change did is explicitly not allow you to create a file if > debugfs had not been initialized. If you tried to do that before, you > should have gotten an error from the vfs layer that the file was not > created, as otherwise how would it have succeeded? > > I just moved the check up higher in the "stack" to the debugfs code, and > not relied on the vfs layer to do a lot of work only to reject things > later on. > > So there "should" not have been any functional change with this patch. > If there was, then something is really odd as how can the vfs layer > create a file for a filesystem _before_ that filesystem has been > registered with the vfs layer? Ah, I see. I do confirm that the file has been created until 56348560d495, without any errors. Thanks, -- Marco