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: <7c86c4470811260802x13df92b4wb40922f199691161@mail.gmail.com>
Date:	Wed, 26 Nov 2008 17:02:15 +0100
From:	"stephane eranian" <eranian@...glemail.com>
To:	"Thomas Gleixner" <tglx@...utronix.de>
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)

Thomas,

On Wed, Nov 26, 2008 at 4:50 PM, stephane eranian
<eranian@...glemail.com> wrote:
>>>   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 ?
>>
>
> Well, there are possibly PMU interrupts. If the monitored thread is
> active on the CPU
> by the time the tool dies, then it will keep on running with
> monitoring on, until it is
> context switched out or dies.
>
> With the approach currently implemented, the TIF bit will be set and
> as soon as the thread
> leaves the kernel for any reason,  it will execute the cleanup
> function which will stop
> monitoring and free the context.
>
To follow-up on that, worst case scenario is you get one more PMU interrupt.
The interrupt handler will notice the ZOMBIE state and will not reactivate
monitoring. The context will remain, but there will be no further cost to the
context switch because nothing will be saved or restored anymore.
--
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/