search for: stackdepot

...h the non-premap handling). Rather than make yet another copy of these mechanisms, I propose refactoring them into sanitizer_common versions. Like HWASAN, the initial version of the heap profiler will be supported for linux only, but other OSes can be added as needed similar to ASAN. StackTrace and StackDepot The sanitizer already contains support for obtaining and representing a stack trace in a StackTrace object, and storing it in the StackDepot which “efficiently stores huge amounts of stack traces”. This is in the sanitizer_common subdirectory and the support is shared by ASAN and ThreadSanitizer....

...dling). Rather than make yet another copy of these > mechanisms, I propose refactoring them into sanitizer_common versions. Like > HWASAN, the initial version of the heap profiler will be supported for > linux only, but other OSes can be added as needed similar to ASAN. > StackTrace and StackDepot > > The sanitizer already contains support for obtaining and representing a > stack trace in a StackTrace object, and storing it in the StackDepot which > “efficiently stores huge amounts of stack traces”. This is in the > sanitizer_common subdirectory and the support is shared by AS...

...make yet another copy of these mechanisms, I propose refactoring > them into sanitizer_common versions. Like HWASAN, the initial version > of the heap profiler will be supported for linux only, but other OSes > can be added as needed similar to ASAN. > > > StackTrace and StackDepot > > The sanitizer already contains support for obtaining and representing > a stack trace in a StackTrace object, and storing it in the StackDepot > which “efficiently stores huge amounts of stack traces”. This is in > the sanitizer_common subdirectory and the support is shared by...

...t; > >> I'll increase the limit to 2^19 for our build, and I'll report the results >> here. > > I ended up increasing the limit to 2^20, because the max allocation for large objects is around 100G on those hosts. With that done, i hit an issue where adding stacks to the StackDepot became a visible bottleneck after a few hours. To solve that, i've set `malloc_context_size=0`, because we're not tracking leaks, and in our experience getting the call site of the ASAN report carries enough information to diagnose the issue. With these two changes, the build is behaving as...

...yet >> another copy of these mechanisms, I propose refactoring them into >> sanitizer_common versions. Like HWASAN, the initial version of the heap >> profiler will be supported for linux only, but other OSes can be added as >> needed similar to ASAN. >> StackTrace and StackDepot >> >> The sanitizer already contains support for obtaining and representing a >> stack trace in a StackTrace object, and storing it in the StackDepot which >> “efficiently stores huge amounts of stack traces”. This is in the >> sanitizer_common subdirectory and the sup...

On Wed, Jan 24, 2018 at 12:10 PM, Frederik Deweerdt < frederik.deweerdt at gmail.com> wrote: > On Wed, Jan 24, 2018 at 11:30 AM, Kostya Serebryany <kcc at google.com> > wrote: > > +Aleksey, who has been dealing with the allocator recently. > > > > If you have a "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) > > check failure, it means that

...c2a6e2c 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -93,6 +93,20 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_DEBUG_DP_MST_TOPOLOGY_REFS + bool "Enable refcount backtrace history in the DP MST helpers" + select STACKDEPOT + depends on DRM_KMS_HELPER + depends on DEBUG_KERNEL + depends on EXPERT + help + Enables debug tracing for topology refs in DRM's DP MST helpers. A + history of each topology reference/dereference will be printed to the + kernel log once...

...10743d4 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -93,6 +93,20 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_DEBUG_DP_MST_TOPOLOGY_REFS + bool "Enable refcount backtrace history in the DP MST helpers" + select STACKDEPOT + depends on DRM_KMS_HELPER + depends on DEBUG_KERNEL + depends on EXPERT + help + Enables debug tracing for topology refs in DRM's DP MST helpers. A + history of each topology reference/dereference will be printed to the + kernel log once...

...095359 +0200 +++ b/drivers/gpu/drm/Kconfig 2019-04-12 11:42:30.066095359 +0200 @@ -37,7 +37,6 @@ config DRM_DP_AUX_CHARDEV config DRM_DEBUG_MM bool "Insert extra checks and debug info into the DRM range managers" - default n depends on DRM=y depends on STACKTRACE_SUPPORT select STACKDEPOT @@ -56,7 +55,6 @@ config DRM_DEBUG_SELFTEST select PRIME_NUMBERS select DRM_LIB_RANDOM select DRM_KMS_HELPER - default n help This option provides kernel modules that can be used to run various selftests on parts of the DRM api. This option is not @@ -113,7 +111,6 @@ config DRM_FBDE...

On Wed, Jan 24, 2018 at 11:30 AM, Kostya Serebryany <kcc at google.com> wrote: > +Aleksey, who has been dealing with the allocator recently. > > If you have a "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) > check failure, it means that you've allocated (and did not deallocate) 2^18 > large heap regions, each *at least* (2^17+1) bytes. > This means, that

...ig 2019-04-12 11:42:30.066095359 +0200 > @@ -37,7 +37,6 @@ config DRM_DP_AUX_CHARDEV > > config DRM_DEBUG_MM > bool "Insert extra checks and debug info into the DRM range managers" > - default n > depends on DRM=y > depends on STACKTRACE_SUPPORT > select STACKDEPOT > @@ -56,7 +55,6 @@ config DRM_DEBUG_SELFTEST > select PRIME_NUMBERS > select DRM_LIB_RANDOM > select DRM_KMS_HELPER > - default n > help > This option provides kernel modules that can be used to run > various selftests on parts of the DRM api. This option is...

...say "N". + If in doubt, say "N". config DRM_I915_DEBUG - bool "Enable additional driver debugging" - depends on DRM_I915 - select DEBUG_FS - select PREEMPT_COUNT - select REFCOUNT_FULL - select I2C_CHARDEV - select STACKDEPOT - select DRM_DP_AUX_CHARDEV - select X86_MSR # used by igt/pm_rpm - select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks) - select DRM_DEBUG_MM if DRM=y + bool "Enable additional driver debugging" + depends on DRM_I915 + select DEBUG_FS + select PREE...

...say "N". + If in doubt, say "N". config DRM_I915_DEBUG - bool "Enable additional driver debugging" - depends on DRM_I915 - select DEBUG_FS - select PREEMPT_COUNT - select REFCOUNT_FULL - select I2C_CHARDEV - select STACKDEPOT - select DRM_DP_AUX_CHARDEV - select X86_MSR # used by igt/pm_rpm - select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks) - select DRM_DEBUG_MM if DRM=y + bool "Enable additional driver debugging" + depends on DRM_I915 + select DEBUG_FS + select PREE...

This is the large series for adding MST suspend/resume reprobing that I've been working on for quite a while now. In addition, I: - Refactored and cleaned up any code I ended up digging through in the process of understanding how some parts of these helpers worked. - Added some debugging tools along the way that I ended up needing to figure out some issues in my own code Note that

This is the final portion of the large series for adding MST suspend/resume reprobing that I've been working on for quite a while now. In addition, I: * Refactored and cleaned up any code I ended up digging through in the process of understanding how some parts of these helpers worked. * Added some debugging tools along the way that I ended up needing to figure out some issues in my own