All of lore.kernel.org
 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

WARNING: multiple messages have this Message-ID (diff)
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>,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Leo Yan <leo.yan@linaro.org>,
	linux-arm-kernel@lists.infradead.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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

Thread overview: 28+ 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:19 ` Sai Prakash Ranjan
2019-07-26  6:26 ` Sai Prakash Ranjan
2019-07-26  6:26   ` Sai Prakash Ranjan
2019-07-26  7:04 ` Greg Kroah-Hartman
2019-07-26  7:04   ` Greg Kroah-Hartman
2019-07-26  8:20   ` Sai Prakash Ranjan
2019-07-26  8:20     ` Sai Prakash Ranjan
2019-07-26  8:41     ` Greg Kroah-Hartman
2019-07-26  8:41       ` Greg Kroah-Hartman
2019-07-26  9:28       ` Suzuki K Poulose
2019-07-26  9:28         ` Suzuki K Poulose
2019-07-26  9:58         ` Sai Prakash Ranjan
2019-07-26  9:58           ` Sai Prakash Ranjan
2019-07-26 10:02           ` Sai Prakash Ranjan
2019-07-26 10:02             ` Sai Prakash Ranjan
2019-07-26  9:44       ` Sai Prakash Ranjan
2019-07-26  9:44         ` Sai Prakash Ranjan
2019-07-26 10:14         ` 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:19             ` Greg Kroah-Hartman
2019-07-26 10:24             ` Sai Prakash Ranjan
2019-07-26 10:24               ` Sai Prakash Ranjan
2019-07-26 11:33             ` Thomas Petazzoni
2019-07-26 11:33               ` Thomas Petazzoni
2019-07-26 11:43               ` Greg Kroah-Hartman
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.