linux-kernel - Re: [PATCH RFC] perf_counter: Don't swap contexts containing locked mutex

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: <18975.39916.877132.690506@cargo.ozlabs.ibm.com>
Date:	Fri, 29 May 2009 18:25:16 +1000
From:	Paul Mackerras <paulus@...ba.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] perf_counter: Don't swap contexts containing
 locked mutex

Peter Zijlstra writes:

> > -		&& ctx1->parent_gen == ctx2->parent_gen;
> > +		&& ctx1->parent_gen == ctx2->parent_gen
> > +		&& ctx1->parent_gen != ~0ull;
> >  }
> 
> There's a nasty surprise for people a few generations down the line. All
> of a sudden performance drops for a while for some unknown reason, and
> then its good again,.. how odd ;-)

If you can add a counter every microsecond (which I don't think any
current processor can do) it'll still be more than half a million
years before we get that far...

> But yeah, seems fine, given that the alternative is yet another
> variable.

Actually, having a 1-bit flag might be cleaner since we can then just
clear it, rather than having to put the old parent_gen back.

> <snip all the other WARN_ON_ONCEs>
> 
> How about:
> 
> #define ASSERT_CTX_STABLE(ctx) \
>   WARN_ON_ONCE((ctx)->parent_gen != ~0ull || ctx->parent_ctx)
> 
> which would deal with both a 'locked' context and uncloned one?

Yeah, all right.

> Could we maybe write this as:
> 
> static struct perf_counter_ctx *pin_ctx(struct perf_counter *counter, u64 *old_gen)

Yep, good idea.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/