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: <CAHp75Vd3xAxmEEHHTXWvKYtieV+kUmP+L+tQGq30YDH9S2hc-w@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ