From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: gregkh@linuxfoundation.org, saiprakash.ranjan@codeaurora.org
Cc: geert+renesas@glider.be, mathieu.poirier@linaro.org,
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 10:28:41 +0100 [thread overview]
Message-ID: <f72f2fa1-7b1b-d7de-c9b4-cd574400d8e5@arm.com> (raw)
In-Reply-To: <20190726084127.GA28470@kroah.com>
On 07/26/2019 09:41 AM, 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 think that should solve the issue ^^
>
> If you enable this option, what does:
> ls -l /dev/etr
> ls -l /dev/etf
> ls -l /dev/stm
> result in?
>
> What are these device nodes for? Are they symlinks? Real devices that
> show up in /sys/dev/char/ as a real value? Or something else?
Greg, those are registered as miscellaneous devices to export the trace
collected (for etfs and etrs) in sysfs mode and for user-space access to
allow STM tracing. So they are real devices.
Suzuki
next prev parent reply other threads:[~2019-07-26 9:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-26 6:19 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 [this message]
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
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=f72f2fa1-7b1b-d7de-c9b4-cd574400d8e5@arm.com \
--to=suzuki.poulose@arm.com \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--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 \
/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
Powered by JetHome