Received-SPF: pass (google.com: domain of linux-kernel+bounces-10443-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20231221130930.32634-1-ruipengqi7@gmail.com> <e9aa311f-6f13-410e-bb35-20320275668c@linaro.org>
In-Reply-To: <e9aa311f-6f13-410e-bb35-20320275668c@linaro.org>
From: ruipeng qi <ruipengqi7@gmail.com>
Date: Sat, 23 Dec 2023 22:12:57 +0800
Message-ID: <CADHLONGLZaZT4Ot56AnxOf=ROrTWvge5=NUx5uqKqJhpJibfOQ@mail.gmail.com>
Subject: Re: [PATCH 1/7] [RFC PATCH 1/7] osdump: Add one new os minidump module
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: catalin.marinas@arm.com, will@kernel.org, bhe@redhat.com, 
	vgoyal@redhat.com, dyoung@redhat.com, linux-kernel@vger.kernel.org, 
	kexec@lists.infradead.org, zalbassam@google.com, dianders@chromium.org, 
	mark.rutland@arm.com, lecopzer.chen@mediatek.com, maz@kernel.org, 
	arnd@arndb.de, yury.norov@gmail.com, brauner@kernel.org, mcgrof@kernel.org, 
	maninder1.s@samsung.com, michael.christie@oracle.com, samitolvanen@google.com, 
	linux-arm-kernel@lists.infradead.org, qiruipeng@lixiang.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 22, 2023 at 12:25=E2=80=AFAM Krzysztof Kozlowski <krzysztof.koz=
lowski
@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 =3D rb_first_cached(&lock->waiters);
  struct rt_mutex_waiter *w =3D NULL;
  if (leftmost) {
    w =3D rb_entry(leftmost, struct rt_mutex_waiter, tree_entry);
    BUG_ON(w->lock !=3D 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.

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.

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

Best Regards
Ruipeng