Hi,
When trying to test my coresight patches, I found that etr,etf and stm
device nodes are missing from /dev.
Bisection gives this as the bad commit.
1be01d4a57142ded23bdb9e0c8d9369e693b26cc is the first bad commit
commit 1be01d4a57142ded23bdb9e0c8d9369e693b26cc
Author: Geert Uytterhoeven <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
drivers/base/Kconfig | 1 -
1 file changed, 1 deletion(-)
Any idea on this?
-Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
On 7/26/2019 11:49 AM, 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.
>
> Bisection gives this as the bad commit.
>
> 1be01d4a57142ded23bdb9e0c8d9369e693b26cc is the first bad commit
> commit 1be01d4a57142ded23bdb9e0c8d9369e693b26cc
> Author: Geert Uytterhoeven <[email protected]>
> 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 <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> drivers/base/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
>
FYI, I am testing on linux-next.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
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 <[email protected]>
> 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 <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> 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?
thanks,
greg k-h
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 <[email protected]>
>> 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 <[email protected]>
>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>
>> 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*
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
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 <[email protected]>
> > > 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 <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > >
> > > 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?
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?
Do you have udev rules that create these nodes somehow?
thanks,
greg k-h
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 <[email protected]>
>>>> 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 <[email protected]>
>>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>>>
>>>> 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
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 <[email protected]>
>>>> 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 <[email protected]>
>>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>>>
>>>> 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
> If you enable this option, what does:
> ls -l /dev/etr
> ls -l /dev/etf
> ls -l /dev/stm
> result in?
>
/ # ls -l /dev/tmc_etr0
crw-rw---- 1 root 0 10, 57 Jan 1 00:00 /dev/tmc_etr0
/ #
/ # ls -l /dev/tmc_etf0
crw-rw---- 1 root 0 10, 58 Jan 1 00:00 /dev/tmc_etf0
/ #
/ # ls -l /dev/stm0
crw-rw---- 1 root 0 236, 0 Jan 1 00:00 /dev/stm0
> 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?
>
They are not symlinks.
These device node names represent coresight sinks(collect traces) like
ETR, ETF, ETB and coresight sources(generates traces) like STM.
ETR and ETF are misc device registered in drivers/hwtracing/coresight
/coresight-tmc.c. However STM is not a misc device.
> Do you have udev rules that create these nodes somehow?
>
No I do not have any udev rules.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Hi Suzuki,
On 7/26/2019 2:58 PM, Suzuki K Poulose wrote:
>
>
> 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 <[email protected]>
>>>>> 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 <[email protected]>
>>>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>>>>
>>>>> 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 ^^
>
Yes mounting /dev using devtmpfs does solve the issue. But is this
different behaviour OK?
-Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
On 7/26/2019 3:28 PM, Sai Prakash Ranjan wrote:
> Hi Suzuki,
>
> On 7/26/2019 2:58 PM, Suzuki K Poulose wrote:
>>
>>
>> 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 <[email protected]>
>>>>>> 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 <[email protected]>
>>>>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>>>>>
>>>>>> 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 ^^
>>
>
> Yes mounting /dev using devtmpfs does solve the issue. But is this
> different behaviour OK?
Sorry ignore the different behaviour thing. I misunderstood.
-Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
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 <[email protected]>
>>>>> 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 <[email protected]>
>>>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>>>>
>>>>> 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.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
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 <[email protected]>
> > > > > > 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 <[email protected]>
> > > > > > ????? Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > > > >
> > > > > > ?? 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
On 7/26/2019 3:49 PM, Greg Kroah-Hartman wrote:
> 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 <[email protected]>
>>>>>>> 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 <[email protected]>
>>>>>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>>>>>>
>>>>>>> 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 :)
>
Ok that explains, its not a hard requirement for me to use mdev. I just
happen to stumble upon this issue. Thanks for your time :)
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Hello,
On Fri, 26 Jul 2019 12:19:25 +0200
Greg Kroah-Hartman <[email protected]> wrote:
> > 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 :)
Since Busybox 1.31.0, mdev has gained a daemon mode. In this mode, mdev
runs in the background, and receives uevent through a netlink socket.
So there's been some changes in how Busybox mdev works in recent times.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On Fri, Jul 26, 2019 at 01:33:16PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Fri, 26 Jul 2019 12:19:25 +0200
> Greg Kroah-Hartman <[email protected]> wrote:
>
> > > 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 :)
>
> Since Busybox 1.31.0, mdev has gained a daemon mode. In this mode, mdev
> runs in the background, and receives uevent through a netlink socket.
> So there's been some changes in how Busybox mdev works in recent times.
Ideally mdev should switch to what udev did many many years ago and not
do any device node creations and just leave all of that up to devtmpfs.
Then it can just stick to any symlinks and any specific owner:group
permissions that might be wanted separate from the default ones the
kernel provides.
Makes things much simpler and should save a lot of userspace code,
making mdev even smaller.
thanks,
greg k-h