linux-kernel - Re: [patch 06/24] perfmon: generic x86 definitions (x86)

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: <alpine.LFD.2.00.0811261628290.3325@localhost.localdomain>
Date:	Wed, 26 Nov 2008 16:44:05 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	eranian@...il.com
cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	mingo@...e.hu, x86@...nel.org, andi@...stfloor.org,
	sfr@...b.auug.org.au
Subject: Re: [patch 06/24] perfmon: generic x86 definitions (x86)

Stephane,

On Wed, 26 Nov 2008, stephane eranian wrote:
> The goal of the TIF flag is to force the thread to go do some extra work on
> kernel exit. There are two situations where this is necessary, there is one
> in the current patchset, the other is related to sampling (not yet provided).
> 
> With per-thread monitoring, a tool is monitoring another thread, possibly in
> another process. The monitored process and the tool may not be parent
> of each other.
> 
> What happens if the tool dies BEFORE it can cleanly close the
> monitoring session?
> 
> There are 2 scenarios:
>   1- the monitored process also had the perfmon file descriptor open,
> e.g., inherited
>      on fork/exec. In that case the monitored thread will keep on
> running to completion
>      with an attached perfmon context.

So no TIF work for this case, right ?
 
>   2- the monitoring had the last reference to the file descriptor. In
> that case, we have a
>      perfmon context attached to a thread but no mean to get to it
> from userland. This is
>      the case where we declare the context as ZOMBIE.
> 
>      I think Andi confused it with the meaning of ZOMBIE for the
> process. In this situation,
>      we want to cleanup the context and make sure monitoring is stopped.
>
>      That has to be done by the monitored thread. The issue is that
> the thread may notice
>      the context is ZOMBIE during context switch in. At this level, we
> run with interrupts
>      disabled, and it is not possible to free certain resources. So
> instead, we set the TIF
>      flag, and let the thread clean things up at a much higher level
> in the kernel execution
>      somewhere where we know we can safely call certain kernel APIs, e.g, kfree.

There is no harm, when the context is kept around, right ?
 
> Another possible solution (which is not implemented):
>      - just let the context attached and run the thread to completion.
> If another tool wants to
>        attach to the same thread, it will detect there is already a
> context attached, and that it is
>        marked ZOMBIE, so it will clean it up. This is a lazy cleanup approach.

Looks like ctx is a couple of hundred bytes, so just keep it around
until thread exit time or until the other tool does the cleanup
possibly by recycling the context.

Thanks,

	tglx

--
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/