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: <20181011220631.GB128397@gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ