Re: [PATCH v2 07/12] ptrace: Don't change __state

2022-05-03 Thread Oleg Nesterov
On 05/02, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > >> #define TASK_KILLABLE (TASK_WAKEKILL | > >> TASK_UNINTERRUPTIBLE) > >> #define TASK_STOPPED (TASK_WAKEKILL | __TASK_STOPPED) > >> -#define TASK_TRACED (TASK_WAKEKIL

Re: fix and cleanup discard_alignment handling

2022-05-03 Thread Jens Axboe
On Mon, 18 Apr 2022 06:53:03 +0200, Christoph Hellwig wrote: > the somewhat confusing name of the discard_alignment queue limit, that > really is an offset for the discard granularity mislead a lot of driver > authors to set it to an incorrect value. This series tries to fix up > all these cases.

Re: [PATCH 19/30] panic: Add the panic hypervisor notifier list

2022-05-03 Thread Guilherme G. Piccoli
On 03/05/2022 14:44, Michael Kelley (LINUX) wrote: > [...] >> >> Hi Michael, thanks for your feedback! I agree that your idea could work, >> but...there is one downside: imagine the kmsg_dump() approach is not set >> in some Hyper-V guest, then we would rely in the regular notification >> mechanism

Re: [PATCH 24/30] panic: Refactor the panic path

2022-05-03 Thread Guilherme G. Piccoli
On 03/05/2022 14:31, Michael Kelley (LINUX) wrote: > [...] > > To me, it's a weak correlation between having a kmsg dumper, and > wanting or not wanting the info level output to come before kdump. > Hyper-V is one of only a few places that register a kmsg dumper, so most > Linux instances outside

Re: [PATCH 04/30] firmware: google: Convert regular spinlock into trylock on panic path

2022-05-03 Thread Evan Green
On Wed, Apr 27, 2022 at 3:51 PM Guilherme G. Piccoli wrote: > > Currently the gsmi driver registers a panic notifier as well as > reboot and die notifiers. The callbacks registered are called in > atomic and very limited context - for instance, panic disables > preemption, local IRQs and all other

Re: [PATCH 16/30] drivers/hv/vmbus, video/hyperv_fb: Untangle and refactor Hyper-V panic notifiers

2022-05-03 Thread Guilherme G. Piccoli
On 03/05/2022 15:13, Michael Kelley (LINUX) wrote: > [...] >> (a) We could forget about this change, and always do the clean-up here, >> not relying in machine_crash_shutdown(). >> Pro: really simple, behaves the same as it is doing currently. >> Con: less elegant/concise, doesn't allow arm64 custo

Re: [PATCH 04/30] firmware: google: Convert regular spinlock into trylock on panic path

2022-05-03 Thread Guilherme G. Piccoli
On 03/05/2022 15:03, Evan Green wrote: > [...] > gsmi_shutdown_reason() is a common function called in other scenarios > as well, like reboot and thermal trip, where it may still make sense > to wait to acquire a spinlock. Maybe we should add a parameter to > gsmi_shutdown_reason() so that you can

Re: [PATCH v2 06/12] ptrace: Reimplement PTRACE_KILL by always sending SIGKILL

2022-05-03 Thread Eric W. Biederman
Oleg Nesterov writes: > On 04/29, Eric W. Biederman wrote: >> >> Call send_sig_info in PTRACE_KILL instead of ptrace_resume. Calling >> ptrace_resume is not safe to call if the task has not been stopped >> with ptrace_freeze_traced. > > Oh, I was never, never able to understand why do we have PT

Re: [PATCH v2 07/12] ptrace: Don't change __state

2022-05-03 Thread Eric W. Biederman
Oleg Nesterov writes: > On 05/02, Eric W. Biederman wrote: >> >> Oleg Nesterov writes: >> >> >> #define TASK_KILLABLE(TASK_WAKEKILL | >> >> TASK_UNINTERRUPTIBLE) >> >> #define TASK_STOPPED (TASK_WAKEKILL | __TASK_STOPPED) >> >> -#define TASK_TRACED

Re: [PATCH 04/30] firmware: google: Convert regular spinlock into trylock on panic path

2022-05-03 Thread Evan Green
Hi Guilherme, On Tue, May 3, 2022 at 12:12 PM Guilherme G. Piccoli wrote: > > On 03/05/2022 15:03, Evan Green wrote: > > [...] > > gsmi_shutdown_reason() is a common function called in other scenarios > > as well, like reboot and thermal trip, where it may still make sense > > to wait to acquire