On 4/19/22 06:16, Jason A. Donenfeld wrote:
In the event that random_get_entropy() can't access a cycle counter or
similar, falling back to returning 0 is really not the best we can do.
Instead, at least calling random_get_entropy_fallback() would be
preferable, because that always needs to re
ping?
___
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
Oleg Nesterov writes:
> On 04/29, Eric W. Biederman wrote:
>>
>> Stop playing with tsk->__state to remove TASK_WAKEKILL while a ptrace
>> command is executing.
>
> Eric, I'll read this patch and the rest of this series tomorrow.
> Somehow I failed to force myself to read yet another version after
On 02/05/2022 12:38, Florian Fainelli wrote:
> [...]
>
> Acked-by: Florian Fainelli
>
> Not sure if the Fixes tag is warranted however as this is a clean up,
> and not really fixing a bug.
Perfect, thanks Florian. I'll add your ACK and remove the fixes tag in V2.
Cheers,
Guilherme
On 02/05/2022 12:38, Florian Fainelli wrote:
> [...]
> Acked-by: Florian Fainelli
>
> Likewise, I am not sure if the Fixes tag is necessary here.
Perfect Florian, thanks! I'll add your Acked-by tag and remove the
fixes for V2 =)
Cheers,
Guilherme
On 04/29, Eric W. Biederman wrote:
>
> static void ptrace_unfreeze_traced(struct task_struct *task)
> {
> - if (READ_ONCE(task->__state) != __TASK_TRACED)
> - return;
> -
> - WARN_ON(!task->ptrace || task->parent != current);
> + unsigned long flags;
>
> /*
> -
On 04/29, Eric W. Biederman wrote:
>
> Stop playing with tsk->__state to remove TASK_WAKEKILL while a ptrace
> command is executing.
Eric, I'll read this patch and the rest of this series tomorrow.
Somehow I failed to force myself to read yet another version after
weekend ;)
plus I don't really u
On 4/27/2022 3:49 PM, Guilherme G. Piccoli wrote:
The panic notifier of this driver is very simple code-wise, just a memory
write to a special position with some numeric code. But this is not clear
from the semantic point-of-view, and there is no public documentation
about that either.
After
On 4/27/2022 3:49 PM, Guilherme G. Piccoli wrote:
This patch improves the panic/die notifiers in this driver by
making use of a passed "id" instead of comparing pointer
address; also, it removes an useless prototype declaration
and unnecessary header inclusion.
This is part of a panic notifie
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 PTRACE_KILL
and what should it actu
On 2022-04-29 16:46:59 [-0500], Eric W. Biederman wrote:
>
> The states TASK_STOPPED and TASK_TRACE are special in they can not
> handle spurious wake-ups. This plus actively depending upon and
> changing the value of tsk->__state causes problems for PREEMPT_RT and
> Peter's freezer rewrite.
PRE
On 2022-04-29 16:48:37 [-0500], Eric W. Biederman wrote:
Needs
From: Peter Zijlstra (Intel)
at the top.
> Currently ptrace_stop() / do_signal_stop() rely on the special states
> TASK_TRACED and TASK_STOPPED resp. to keep unique state. That is, this
> state exists only in task->__state and nowh
On 2022-04-29 16:48:35 [-0500], Eric W. Biederman wrote:
> In ptrace_stop a ptrace_unlink or SIGKILL can occur either after
> siglock is dropped or after tasklist_lock is dropped. At either point
> the result can be that ptrace will continue and not stop at schedule.
>
> This means that there are
On 2022-04-29 16:48:32 [-0500], Eric W. Biederman wrote:
> Stop playing with tsk->__state to remove TASK_WAKEKILL while a ptrace
> command is executing.
>
> Instead TASK_WAKEKILL from the definition of TASK_TRACED, and
> implemention a new jobctl flag TASK_PTRACE_FROZEN. This new This new
Instea
On 2022-04-29 16:48:27 [-0500], Eric W. Biederman wrote:
> The function send_signal_locked does more than __group_send_sig_info so
> replace it.
This might be easier to understand:
__group_send_sig_info() is just a wrapper around send_signal_locked()
with a special pid_type.
Replace
On 2022-04-29 16:48:26 [-0500], Eric W. Biederman wrote:
> Rename send_signal send_signal_locked and make to make
s@to make@@
> it usable outside of signal.c.
>
> Signed-off-by: "Eric W. Biederman"
Sebastian
___
linux-um mailing list
linux-um@lists.
On Mon, 2 May 2022, Geert Uytterhoeven wrote:
JFYI, when comparing v5.18-rc5[1] to v5.18-rc4[3], the summaries are:
- build errors: +6/-21
6 error regressions:
+ /kisskb/src/arch/sh/kernel/machvec.c: error: array subscript 'struct
sh_machine_vector[0]' is partly outside array bounds of 'lon
17 matches
Mail list logo
