linux-kernel - Re: Re: [PATCH V8] kdb: Fix the deadlock issue in KDB debugging.

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]

Date: Mon, 8 Apr 2024 13:29:59 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: LiuYe <liu.yeC@....com>
Cc: daniel.thompson@...aro.org, dianders@...omium.org, 
	gregkh@...uxfoundation.org, jason.wessel@...driver.com, jirislaby@...nel.org, 
	kgdb-bugreport@...ts.sourceforge.net, linux-kernel@...r.kernel.org, 
	linux-serial@...r.kernel.org
Subject: Re: Re: [PATCH V8] kdb: Fix the deadlock issue in KDB debugging.

On Mon, Apr 8, 2024 at 4:46 AM LiuYe <liu.yeC@....com> wrote:
> >Wed, Apr 03, 2024 at 02:11:09PM +0800, liu.yec@....com kirjoitti:

..

> >Ouch.
> >Please, read this
> >https://www.kernel.org/doc/html/latest/process/submitting-patches.html#backtraces-in-commit-messages
> >and modify the commit message accordingly.
>
> The example is the printout of the kernel lockup detection mechanism, which may be easier to understand.
> If organized according to the format provided in the previous link, should it be arranged as follows?

Do you think all lines are important from this?
Do you think you haven't dropped anything useful?

If "yes" is the answer to both Qs, then go with it (but at least I see
that first seems to me as "no", some lines are not important)


> Example:
> BUG: spinlock lockup suspected on CPU#0. owner_cpu: 1
> CPU1: Call Trace:
> __schedule
> schedule
> schedule_hrtimeout_range_clock
> mutex_unlock
> ep_scan_ready_list
> schedule_hrtimeout_range
> ep_poll
> wake_up_q
> SyS_epoll_wait
> entry_SYSCALL_64_fastpath
>
> CPU0: Call Trace:
> dump_stack
> spin_dump
> do_raw_spin_lock
> _raw_spin_lock
> try_to_wake_up
> wake_up_process
> insert_work
> __queue_work
> queue_work_on
> kgdboc_post_exp_handler
> kgdb_cpu_enter
> kgdb_handle_exception
> __kgdb_notify
> kgdb_notify
> notifier_call_chain
> notify_die
> do_int3
> int3

..

> >>  #include <linux/module.h>
> >>  #include <linux/platform_device.h>
> >>  #include <linux/serial_core.h>
> >> +#include <linux/irq_work.h>
> >
> >Please, keep it ordered (with visible context this should go at least before
> >module.h).
>
> I don't understand why this needs to be placed before module.h. Please explain further, thank you.

Alphabetical order helps long-term maintenance. Yes, I know that it is
not _fully_ sorted, but don't add more mess to it.

-- 
With Best Regards,
Andy Shevchenko