On Fri, Aug 07, 2020 at 02:07:59PM -0400, Mathieu Desnoyers wrote:
> One thing I find weird about Peter's patch is that it adds a
> MEMBERRIER_CMD_PRIVATE_EXPEDITED_RSEQ without a corresponding
> MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ. Considering that
> the SYNC_CORE variant already has
- On Aug 7, 2020, at 1:48 PM, Peter Oskolkov p...@posk.io wrote:
> On Thu, Aug 6, 2020 at 10:37 AM Mathieu Desnoyers
> wrote:
>>
[...]
>> Also, should this belong to the membarrier or the rseq system call ? It just
>> looks like the membarrier happens to implement very similar things for
>>
On Thu, Aug 6, 2020 at 10:37 AM Mathieu Desnoyers
wrote:
>
> >>
> >> This is an unpriv IPI the world. That's a big no-no.
> >
> > removed in v2.
>
> I don't think the feature must be removed, but its implementation needs
> adjustment.
>
> How about we simply piggy-back on the membarrier schemes
- On Aug 6, 2020, at 1:07 PM, Peter Oskolkov p...@posk.io wrote:
> On Thu, Aug 6, 2020 at 6:48 AM wrote:
>>
>> On Wed, Aug 05, 2020 at 05:08:58PM -0700, Peter Oskolkov wrote:
>>
>> Thanks for the Cc!
>
> Always a pleasure!
>
> (Sorry, included only membarrier maintainers in v1; in v2
On Wed, Aug 05, 2020 at 05:08:58PM -0700, Peter Oskolkov wrote:
Thanks for the Cc!
> + * @MEMBARRIER_CMD_PRIVATE_RESTART_RSEQ_ON_CPU:
> + * If a thread belonging to the current process
> + * is currently in an RSEQ critical section on the
> + *
On Thu, Aug 6, 2020 at 6:48 AM wrote:
>
> On Wed, Aug 05, 2020 at 05:08:58PM -0700, Peter Oskolkov wrote:
>
> Thanks for the Cc!
Always a pleasure!
(Sorry, included only membarrier maintainers in v1; in v2 included
both membarrier and rseq maintainers).
>
> > + *
This patchset is based on Google-internal RSEQ
work done by Paul Turner and Andrew Hunter.
When working with per-CPU RSEQ-based memory allocations,
it is sometimes important to make sure that a global
memory location is no longer accessed from RSEQ critical
sections. For example, there can be two
7 matches
Mail list logo
