[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZvbZWzW4I2CYNe3r@smile.fi.intel.com>
Date: Fri, 27 Sep 2024 19:12:11 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Keita Morisaki <keyz@...gle.com>
Cc: gregkh@...uxfoundation.org, rafael@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] devres: Fix page faults when tracing devres from
unloaded modules
On Fri, Sep 27, 2024 at 10:28:07PM +0800, Keita Morisaki wrote:
> The devres ftrace event logs the name of the devres node, which is often a
> function name (e.g., "devm_work_drop") stringified by macros like
> devm_add_action. Currently, ftrace stores this name as a string literal
> address, which can become invalid when the module containing the string is
> unloaded. This results in page faults when ftrace tries to access the name.
>
> This behavior is problematic because the devres ftrace event is designed to
> trace resource management throughout a device driver's lifecycle, including
> during module unload. The event should be available even after the module
> is unloaded to properly diagnose resource issues.
>
> Fix the issue by copying the devres node name into the ftrace ring buffer
> using __assign_str(), instead of storing just the address. This ensures
> that ftrace can always access the name, even if the module is unloaded.
>
> This change increases the memory usage for each of the ftrace entry by
> 12-16 bytes assuming the average devres node name is 20 bytes long,
> depending on the size of const char *.
>
> Note that this change does not affect anything unless all of following
> conditions are met.
> - CONFIG_DEBUG_DEVRES is enabled
> - ftrace tracing is enabled
> - The devres event is enabled in ftrace tracing
LGTM now,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
thanks!
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists