linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Leo Yan <leo.yan@linaro.org>,
	linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [Regression] Missing device nodes for ETR, ETF and STM after CONFIG_UEVENT_HELPER=n
Date: Fri, 26 Jul 2019 12:19:25 +0200	[thread overview]
Message-ID: <20190726101925.GA22476@kroah.com> (raw)
In-Reply-To: <6d48f996-6297-dc69-250b-790be6d2670c@codeaurora.org>

On Fri, Jul 26, 2019 at 03:44:40PM +0530, Sai Prakash Ranjan wrote:
> On 7/26/2019 3:14 PM, Sai Prakash Ranjan wrote:
> > On 7/26/2019 2:11 PM, Greg Kroah-Hartman wrote:
> > > On Fri, Jul 26, 2019 at 01:50:27PM +0530, Sai Prakash Ranjan wrote:
> > > > On 7/26/2019 12:34 PM, Greg Kroah-Hartman wrote:
> > > > > On Fri, Jul 26, 2019 at 11:49:19AM +0530, Sai Prakash Ranjan wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > When trying to test my coresight patches, I found that etr,etf and stm
> > > > > > device nodes are missing from /dev.
> > > > > 
> > > > > I have no idea what those device nodes are.
> > > > > 
> > > > > > Bisection gives this as the bad commit.
> > > > > > 
> > > > > > 1be01d4a57142ded23bdb9e0c8d9369e693b26cc is the first bad commit
> > > > > > commit 1be01d4a57142ded23bdb9e0c8d9369e693b26cc
> > > > > > Author: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > > > Date:   Thu Mar 14 12:13:50 2019 +0100
> > > > > > 
> > > > > >       driver: base: Disable CONFIG_UEVENT_HELPER by default
> > > > > > 
> > > > > >       Since commit 7934779a69f1184f ("Driver-Core:
> > > > > > disable /sbin/hotplug by
> > > > > >       default"), the help text for the /sbin/hotplug fork-bomb says
> > > > > >       "This should not be used today [...] creates a
> > > > > > high system load, or
> > > > > >       [...] out-of-memory situations during bootup". 
> > > > > > The rationale for this
> > > > > >       was that no recent mainstream system used this
> > > > > > anymore (in 2010!).
> > > > > > 
> > > > > >       A few years later, the complete uevent helper
> > > > > > support was made optional
> > > > > >       in commit 86d56134f1b67d0c ("kobject: Make support
> > > > > > for uevent_helper
> > > > > >       optional.").  However, if was still left enabled
> > > > > > by default, to support
> > > > > >       ancient userland.
> > > > > > 
> > > > > >       Time passed by, and nothing should use this
> > > > > > anymore, so it can be
> > > > > >       disabled by default.
> > > > > > 
> > > > > >       Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > > >       Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > > 
> > > > > >    drivers/base/Kconfig | 1 -
> > > > > >    1 file changed, 1 deletion(-)
> > > > > > 
> > > > > > 
> > > > > > Any idea on this?
> > > > > 
> > > > > That means that who ever created those device nodes is relying on udev
> > > > > to do this, and is not doing the correct thing within the kernel and
> > > > > using devtmpfs.
> > > > > 
> > > > > Any pointers to where in the kernel those devices are trying to be
> > > > > created?
> > > > > 
> > > > 
> > > > Somewhere in drivers/hwtracing/coresight/* probably. I am not sure,
> > > > Mathieu/Suzuki would be able to point you to the exact code.
> > > > 
> > > > Also just to add on some more details, I am using *initramfs*
> > > 
> > > Are you using devtmpfs for your /dev/ mount?
> > > 
> > 
> > I am not mounting devtmpfs. However
> > 
> >   CONFIG_DEVTMPFS=y
> >   CONFIG_DEVTMPFS_MOUNT=y
> > 
> 
> Ok my initramfs is using mdev:
> 
> */sbin/mdev -s*
> 
> This somehow is not mounting etr, etf, stm devices when uevent-helper is
> disabled. Anyways as Suzuki mentioned, using devtmpfs does fix the issue.

Last I looked (many years ago) mdev requires uevent-helper in order for
it to work.  I recommend that if you rely on mdev to keep that option
enabled, or to just use devtmpfs and udev :)

thanks,

greg k-h

  reply	other threads:[~2019-07-26 10:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-26  6:19 [Regression] Missing device nodes for ETR, ETF and STM after CONFIG_UEVENT_HELPER=n Sai Prakash Ranjan
2019-07-26  6:26 ` Sai Prakash Ranjan
2019-07-26  7:04 ` Greg Kroah-Hartman
2019-07-26  8:20   ` Sai Prakash Ranjan
2019-07-26  8:41     ` Greg Kroah-Hartman
2019-07-26  9:28       ` Suzuki K Poulose
2019-07-26  9:58         ` Sai Prakash Ranjan
2019-07-26 10:02           ` Sai Prakash Ranjan
2019-07-26  9:44       ` Sai Prakash Ranjan
2019-07-26 10:14         ` Sai Prakash Ranjan
2019-07-26 10:19           ` Greg Kroah-Hartman [this message]
2019-07-26 10:24             ` Sai Prakash Ranjan
2019-07-26 11:33             ` Thomas Petazzoni
2019-07-26 11:43               ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190726101925.GA22476@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=geert+renesas@glider.be \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=saiprakash.ranjan@codeaurora.org \
    --cc=suzuki.poulose@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).