Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1031623pxb; Thu, 4 Mar 2021 01:09:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJz3ISFd7pZhW9Uyy/1WIG4XYh6nYDV9Ule8xyylU5K3xxywn8cwPFGxl48Wm29fABImw327 X-Received: by 2002:a17:906:39a:: with SMTP id b26mr3235384eja.158.1614848955038; Thu, 04 Mar 2021 01:09:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614848955; cv=none; d=google.com; s=arc-20160816; b=CGwqOvJ3J1iGbKPgfBfHd+Q6doZxB50JgEcjW246G27CLDr4nHwJTAPqu4AzTAUQMD DptqZuYWbpqCu/OyYtxMdBJwuTzQQWN0hZyuHvMd6FpjMUCHl65D7bEu1ufCX4x6XVkP wzMAZAH9gxchZDCgVRhTi1gi8haF6rvRb0oLYlgoL1c/7UeBrOfFEcHb2vvCXjoqPpcS +dcdfjcuOfxeAzAPLa293Bge0RTLuxHAOTmq6FXXOnMKzCgwWSERzM6YPkXq/HLaS0Tk 9ZmW7j+ETr7QRL+PLC1e8DVh4P2qotpAf01+dY+OWyrUEHocbcJg1/Lgq9awezichtXY 8/rw== 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=tizoAoxj1MkSbHFp7V2+QcWvWzsNKthubw4LeYpfuqI=; b=FgQ9cfxw9ZbAwWD4wAQBtrl+iXeGibPgUC2SeZFsJMlOdqqnSPm41fWKL+Rgi8f8dK w80EaCikRvk7fWTOU32Q4un2d3bTvWo2oBMiIIdSpdKA2NP8VU5S+ZSFz83HAVGuBYB1 5pGqhgfCC7wlpdUQzOXwVgblN8CUiRAA/etBtHNdGIb1svMEaXr8737cpBjlIPzHNrsV i5pWC92HTJpIrK5qJgU69XCTrqUEGG9Bhx9raJII2hc4NbdpOpnptAFKN8PJZGBuzdh6 eqjuJdiEkemHk8rSG/LlwJu0b2thwe43wJJGNc0U5P5b0hIqT2qMd6IpuHcC5WpVT2xs tU3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=jxIUAfJ3; 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 dc18si370404ejb.636.2021.03.04.01.08.51; Thu, 04 Mar 2021 01:09:15 -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=jxIUAfJ3; 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 S1350470AbhCCN5j (ORCPT + 99 others); Wed, 3 Mar 2021 08:57:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1582449AbhCCKWJ (ORCPT ); Wed, 3 Mar 2021 05:22:09 -0500 Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CC95C08ED84 for ; Wed, 3 Mar 2021 02:18:18 -0800 (PST) Received: by mail-oi1-x22e.google.com with SMTP id l64so25354397oig.9 for ; Wed, 03 Mar 2021 02:18:18 -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=tizoAoxj1MkSbHFp7V2+QcWvWzsNKthubw4LeYpfuqI=; b=jxIUAfJ3U4ZH+UI3+YAb5ouL3zRfORY+g1i2znUqOgAQFlcRT6fkHhFuyPimU0bSgd 5fY7NR+Tpxpa4XPzHRklpoOFqdHh/9qbI89Ym39gbhw6CMUTsKGDGC8jsQ4oensYFBub aGP5hHiXsGeRG+4ZLvbrGn5pwknc+1BuWtbJEEcbfYIK4yzzdx+WCn0jnJIKb2+uL5WK +iNOKwxcPc2hS94atEabN1H+4VWjFcxvZvo8gYZgay6Wmu28G2YfC1JI5+S7qCC7Qfn6 SKZ2FZ3dX9HRdBmH/yuxrEH8l63ReiOwVoVtQqeRHThkH2wJJBcVR3f9t095Zed86tsy ztuw== 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=tizoAoxj1MkSbHFp7V2+QcWvWzsNKthubw4LeYpfuqI=; b=FOPSjZMi9gZq833dtjNOxRZWdBIPfQzyM2+yypguVSRXV34/6vsn3OIUFvuw+pgIwW WbvnFvDFvhIfMXJkIm2IjldZ2kAUbKGNBOyKmo0T2RJeXG5me3hCEl8tJt0XuZbGRIGI VxQbTvmY3C9AY8ZmGuqsXLyZ+OfLxHsD6h6FUSmoIkDQekqat/cCvUZDrjeWJEn5JGAf teUOO0fDinZ+ty29Gr2+Ka1diQshQDpU7yDl1oxhsL0NISvseno8NkRLr0muFjnm+ipc AzgpvwW0gLh8rIKtS1GkGLOEP3Y16+j6chBfAwVwZ8Ojr/bIuhTxToWZr2CbakhDtef9 2DoQ== X-Gm-Message-State: AOAM533sh72dX0SgOj0aZAYl/e07Ep+VS8Rqre1V7N8ul5UQgkej+jIO vQJyv1SlWoVLE/RO9zobvRJKHJG5t/w8L35OshqsRw== X-Received: by 2002:aca:d515:: with SMTP id m21mr6810808oig.172.1614766697628; Wed, 03 Mar 2021 02:18:17 -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:18:06 +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 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). > Reviewed-by: Greg Kroah-Hartman Thanks! Would it be possible to get this into 5.12? -- Marco