linux-kernel - Re: [tip:sched/core] sched/completions/Documentation: Clean up the document some more

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:   Fri, 12 Oct 2018 00:06:31 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     peterz@...radead.org, hofrat@...dl.org,
        torvalds@...ux-foundation.org, john.garry@...wei.com,
        tglx@...utronix.de, linux-kernel@...r.kernel.org, hpa@...or.com
Cc:     linux-tip-commits@...r.kernel.org
Subject: Re: [tip:sched/core] sched/completions/Documentation: Clean up the
 document some more

hi Nicholas,

I was wondering about this paragraph:

> Using on-stack completions for code that calls any of the _timeout or
> _interruptible/_killable variants is not advisable as they will require
> additional synchronization to prevent the on-stack completion object in
> the timeout/signal cases from going out of scope. Consider using dynamically
> allocated completions when intending to use the _interruptible/_killable
> or _timeout variants of wait_for_completion().

What exact race related to _timeout()/_interruptible() waits and on-stack
completions were you trying to highlight here?

Is it the fact that if a signal is already pending for the current task,
that the _interruptible() variant might return prematurely, while any
kthread that has the completion pointer passed to it might still be using
it?

In that case the kthread should indeed be waited for.

How would a dynamically allocated completion object help in this case - or do
you mean a refcounted dynamic object?

A specific example might be useful here, instead of this rather vague,
generic description.

Thanks,

	Ingo