Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751873AbZG1IvJ (ORCPT ); Tue, 28 Jul 2009 04:51:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751229AbZG1IvI (ORCPT ); Tue, 28 Jul 2009 04:51:08 -0400 Received: from mail-bw0-f221.google.com ([209.85.218.221]:50988 "EHLO mail-bw0-f221.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750918AbZG1IvF (ORCPT ); Tue, 28 Jul 2009 04:51:05 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=ID6B0Pflo4Stm5TOSV++EDFJXYghGsdUSmYTwfI80mlW/diotsan1y8Wnvqc+n8Wfw yYu1Ij35WcmERE2sMpXIh+mD24pFqbNd5y1huU92i8jMkDC+FQGbZHym/EoPOcvt6mVd tCr9X3F7R/2+QnUtOxMcG3bMoHG9jONfjDqMs= MIME-Version: 1.0 Reply-To: eranian@gmail.com In-Reply-To: <7c86c4470907272213w2ee57080re50dd22a4d73a7e0@mail.gmail.com> References: <7c86c4470907270951i48886d56g90bc198f26bb0716@mail.gmail.com> <20090727212514.GA25386@basil.fritz.box> <7c86c4470907272213w2ee57080re50dd22a4d73a7e0@mail.gmail.com> Date: Tue, 28 Jul 2009 10:51:04 +0200 Message-ID: <7c86c4470907280151p13e275c0q27a51897351e8e0@mail.gmail.com> Subject: Re: perf_counters issue with self-sampling threads From: stephane eranian To: Andi Kleen Cc: perfmon2-devel , Maynard Johnson , Robert Richter , LKML , Thomas Gleixner , Paul Mackerras , Carl Love , Corey J Ashford , Andrew Morton , Peter Zijlstra , Philip Mucci , Dan Terpstra , Ingo Molnar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1858 Lines: 46 [Reposting the message because of stupid MIME-encoding error on my part] Andi, Looks like SIGPROF is calling _group_send_sig_info(), so I think it is subject to the same problem. I have built a perfmon example to test the problem, it is relatively easy to trigger by simply self-monitoring a thread which is using setitimer() and thus SIGALRM. You just have to increase the timer frequency. At some point, the SIGPROF signal will be delivered to the wrong thread. One thing I did not mention in my message is that one would think that forcing a specific signal via F_SETSIG could be a workaround if that signal is synchronous, e.g., SIGFPE. F_SETSIG looks like a Linux extension but it does not solve the problem. Linux determines the mode of delivery not on the signal number but on the code path, it seems. If you use F_ASYNC+F_SETOWN, then this is systematically considered asynchronous regardless of the signal used.If you come from traps.c, then the signal is delivered to the correct thread. All of this does not look unreasonable to me. I believe sampling, be it timer or PMU-based, may be a special case here. We want asynchronous + specific thread (only) when self- sampling. An alternative may be to choose the pending queue based on the signal type (synchronous, asynchronous). Then, we could use F_SETSIG to override SIGIO with a synchronous signal instead. But I am not a POSIX signal expert. On Jul 27, 2009 11:25 PM, "Andi Kleen" wrote: I wonder how SIGPROF gets around the same problem, or is it buggy too? -Andi -- ak@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/