All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: markus.t.metzger@intel.com
Cc: tglx@linutronix.de, hpa@zytor.com, markus.t.metzger@gmail.com,
	roland@redhat.com, eranian@googlemail.com, oleg@redhat.com,
	juan.villacis@intel.com, ak@linux.jf.intel.com,
	linux-kernel@vger.kernel.org
Subject: Re: [patch 13/18] x86, ds: add leakage warning
Date: Thu, 2 Apr 2009 21:27:55 +0200	[thread overview]
Message-ID: <20090402192755.GD2455@elte.hu> (raw)
In-Reply-To: <20090402145726.223198000@intel.com>


* markus.t.metzger@intel.com <markus.t.metzger@intel.com> wrote:

> +static inline void ds_warn_leak(struct task_struct *tsk)
> +{
> +	WARN(tsk->thread.ds_ctx, "leaking DS context\n");
> +}

> +	ds_warn_leak(tsk);

since we normally expect X86_DS enabled i'd suggest this 
simplification: always have thread.ds_ctx around so the WARN_ON can 
go there unconditionally. (it wont trigger in the !DS case)

>  struct task_struct;
>  struct mm_struct;
> +struct ds_context;

why is this needed in processor.h?

ds.h should be split into ds_types.h and ds_api.h, with the pure 
data type definitions in ds_types.h. processor.h (which needs to 
know about the DS context type) then includes ds_types.h - which
is a lightweight header.

Actual DS using facilities also disable ds_api.h.

This keeps data types nicely separated from methods and inlines.

	Ingo

  reply	other threads:[~2009-04-02 19:28 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-02 14:54 [patch 00/18] x86, bts, ptrace, hw-branch-tracer: fixes and cleanups markus.t.metzger
2009-04-02 14:54 ` [patch 01/18] x86, bts: fix race when bts tracer is removed markus.t.metzger
2009-04-02 18:45   ` Ingo Molnar
2009-04-03  6:19     ` Metzger, Markus T
2009-04-03  7:17       ` Metzger, Markus T
2009-04-03 11:30         ` Ingo Molnar
2009-04-03 11:29       ` Ingo Molnar
2009-04-02 14:54 ` [patch 02/18] sched: add task_is_running() fucntion to sched.h markus.t.metzger
2009-04-02 14:54 ` [patch 03/18] x86, ptrace, bts: defer branch trace stopping markus.t.metzger
2009-04-02 18:40   ` Ingo Molnar
2009-04-02 14:54 ` [patch 04/18] x86, bts: wait until traced task has been scheduled out markus.t.metzger
2009-04-02 19:17   ` Ingo Molnar
2009-04-03  6:22     ` Metzger, Markus T
2009-04-03 11:32       ` Ingo Molnar
2009-04-03 11:36         ` Metzger, Markus T
2009-04-02 14:55 ` [patch 05/18] x86, bts: fix race between per-task and per-cpu branch tracing markus.t.metzger
2009-04-02 14:55 ` [patch 06/18] x86, debugctlmsr: add _on_cpu variants to debugctlmsr functions markus.t.metzger
2009-04-02 14:55 ` [patch 07/18] x86, bts, hw-branch-tracer: add _noirq variants to the debug store interface markus.t.metzger
2009-04-02 14:55 ` [patch 08/18] x86, hw-branch-tracer: allocate selftest iterator on heap markus.t.metzger
2009-04-02 14:55 ` [patch 09/18] x86, ds: fix compiler warning markus.t.metzger
2009-04-02 14:55 ` [patch 10/18] x86, ds: fix bounds check in ds selftest markus.t.metzger
2009-04-02 14:55 ` [patch 11/18] x86, ds: selftest each cpu markus.t.metzger
2009-04-02 14:55 ` [patch 12/18] x86, ds: add task tracing selftest markus.t.metzger
2009-04-02 14:55 ` [patch 13/18] x86, ds: add leakage warning markus.t.metzger
2009-04-02 19:27   ` Ingo Molnar [this message]
2009-04-03  6:42     ` Metzger, Markus T
2009-04-02 14:55 ` [patch 14/18] x86, ds: use single debug store cpu configuration markus.t.metzger
2009-04-02 19:29   ` Ingo Molnar
2009-04-03  6:46     ` Metzger, Markus T
2009-04-02 14:55 ` [patch 15/18] x86, ptrace: remove duplicate functionality markus.t.metzger
2009-04-02 14:55 ` [patch 16/18] x86, ds: dont use TIF_DEBUGCTLMSR markus.t.metzger
2009-04-02 14:55 ` [patch 17/18] x86, ds: fix bad ds_reset_pebs() markus.t.metzger
2009-04-02 14:55 ` [patch 18/18] x86, ds: support Core i7 markus.t.metzger
2009-04-02 19:22 ` [patch 00/18] x86, bts, ptrace, hw-branch-tracer: fixes and cleanups Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090402192755.GD2455@elte.hu \
    --to=mingo@elte.hu \
    --cc=ak@linux.jf.intel.com \
    --cc=eranian@googlemail.com \
    --cc=hpa@zytor.com \
    --cc=juan.villacis@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.t.metzger@gmail.com \
    --cc=markus.t.metzger@intel.com \
    --cc=oleg@redhat.com \
    --cc=roland@redhat.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.