linux-kernel - Re: [PATCH 1/7] [RFC PATCH 1/7] osdump: Add one new os minidump module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6fe05804-da74-45cd-a6f1-df4644671d99@linaro.org>
Date: Sat, 23 Dec 2023 15:23:03 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: ruipeng qi <ruipengqi7@...il.com>
Cc: catalin.marinas@....com, will@...nel.org, bhe@...hat.com,
 vgoyal@...hat.com, dyoung@...hat.com, linux-kernel@...r.kernel.org,
 kexec@...ts.infradead.org, zalbassam@...gle.com, dianders@...omium.org,
 mark.rutland@....com, lecopzer.chen@...iatek.com, maz@...nel.org,
 arnd@...db.de, yury.norov@...il.com, brauner@...nel.org, mcgrof@...nel.org,
 maninder1.s@...sung.com, michael.christie@...cle.com,
 samitolvanen@...gle.com, linux-arm-kernel@...ts.infradead.org,
 qiruipeng@...iang.com
Subject: Re: [PATCH 1/7] [RFC PATCH 1/7] osdump: Add one new os minidump
 module

On 23/12/2023 15:12, ruipeng qi wrote:
> On Fri, Dec 22, 2023 at 12:25 AM Krzysztof Kozlowski <krzysztof.kozlowski
> @linaro.org> wrote:
>>> Osdump is a new crash dumping solution aiming at specific embedded
>>> devices within automotive or Industrial.
>>>  - limited memory.
>>>  - reboot as soon as possible when system fault.
>>
>> NAK, sorry, work with Qualcomm minidump series to incorporate all your
>> needs there.
> 
> Sorry, I didn't explain it properly. Will add more descriptions in the
> next version. Osdump is a totally different mindump, which aims at
> helping to solve kernel issues as easy as kdump/kexec/crash, but
> with little costs.
> 
> For something like Pstore, you can get where the issue occurs. You can
> figure out the problem if it is easy, but sometimes you can't. For example:
> 
> <4>[    5.311431]  task_blocks_on_rt_mutex+0x234/0x380
> <4>[    5.316166]  rt_spin_lock_slowlock_locked+0xcc/0x2b0
> <4>[    5.321257]  rt_spin_lock_slowlock+0x5c/0x90
> <4>[    5.325633]  rt_spin_lock+0x60/0x74
> <4>[    5.329207]  refill_stock+0x58/0x230
> 
> You can find where the issue occurs.
> static inline struct rt_mutex_waiter *rt_mutex_top_waiter(struct rt_mutex *lock)
>  {
>   struct rb_node *leftmost = rb_first_cached(&lock->waiters);
>   struct rt_mutex_waiter *w = NULL;
>   if (leftmost) {
>     w = rb_entry(leftmost, struct rt_mutex_waiter, tree_entry);
>     BUG_ON(w->lock != lock);
> 
> But you don't know why w->lock and lock are different, and who is wrong.
> 
> Qcom minidump can dump some logs like dmsg, some status like IRQ or
> Run queue. This can help to learn some information when the issue occurs,
> which will help to find out the root cause. But what it dumps are limited, it
> doesn't dump w and lock if they are not local data.

So add missing features to it. I don't think you got my comment and keep
arguing on the same thing repeated for upstream submissions many times.
We do not want multiple vendor solutions. Every vendor wants his work
and does not care about integrating or reusing other pieces.

> 
> For osdump, it dumps objects stored in slab, datas in bss, data segments,
> some data alloced with memblock, data stored in local stack, and so on.
> In a word, it dumps almost all of the key data in the kernel. Besides, you
> can use the crash tool to analyze the dump file.

I don't see a problem why minidump cannot do it.

> 
> In a word, I think this toal different minidump should have its own place in
> the kernel world. Looking forward to your suggestions!

No, work with minidump.

For any further submissions which do not merge this work into minidump,
please carry:

Nacked-by: Krzysztof Kozlowski <krzk@...nel.org>

Best regards,
Krzysztof