[PATCH v7 03/10] drm/xe/devcoredump: Add ASCII85 dump helper function

Lucas De Marchi lucas.demarchi at intel.com
Fri Sep 6 03:04:26 UTC 2024


On Thu, Sep 05, 2024 at 07:01:33PM GMT, John Harrison wrote:
>On 9/5/2024 18:54, Lucas De Marchi wrote:
>>On Thu, Sep 05, 2024 at 01:50:58PM GMT, John.C.Harrison at Intel.com wrote:
>>>From: John Harrison <John.C.Harrison at Intel.com>
>>>
>>>There is a need to include the GuC log and other large binary objects
>>>in core dumps and via dmesg. So add a helper for dumping to a printer
>>>function via conversion to ASCII85 encoding.
>>
>>why are we not dumping the binary data directly to devcoredump?
>As per earlier comments, there is a WiFi driver or some such that does 
>exactly that. But all they are dumping is a binary blob.

In your v5 I see you mentioned
drivers/net/wireless/ath/ath10k/coredump.c, but that is a precedence for
including it as is from the device rather converting it to ASCII85 or
something else. It seems odd to do that type of conversion in kernel
space when it could be perfectly done in userspace.

$ git grep ascii85.h
drivers/gpu/drm/i915/i915_gpu_error.c:#include <linux/ascii85.h>
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:#include <linux/ascii85.h>
drivers/gpu/drm/msm/adreno/adreno_gpu.c:#include <linux/ascii85.h>
drivers/gpu/drm/xe/xe_lrc.c:#include <linux/ascii85.h>
drivers/gpu/drm/xe/xe_vm.c:#include <linux/ascii85.h>

>
>We want the devcoredump file to still be human readable. That won't be 
>the case if you stuff binary data in the middle of it. Most obvious 
>problem - the zeros in the data will terminate your text file at that 
>point. Potentially bigger problem for end users - random fake ANSI 
>codes will destroy your terminal window if you try to cat the file to 
>read it.

Users don't get a coredump and cat it to the terminal.
=(lk%A8`T7AKYH#FD,6++EqOABHUhsG%5H2ARoq#E$/V$Bl7Q+@<5pmBe<q;Bk;0mCj at .3DIal2FD5Q-+E_RBART+X@VfTuGA2/4Dfp.E at 3BN0DfB9.+E1b0F(KAV+:8

Lucas De Marchi


More information about the Intel-xe mailing list