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
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.
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
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
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
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
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
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
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
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
10 matches
Mail list logo