[PATCH 1/1] add support for Power7 to perfmon2 kernel code

Hello,

This patch adds support for Power7 to the perfmon2 kernel code.  The changes are 
quite simple, happily, since Power7's PMU is programmed very similarly to the 
Power5 PMU.

Signed-off-by: Corey Ashford <cjashfor <at> us.ibm.com>

Thanks for your consideration,

- Corey

Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjashfor <at> us.ibm.com

diff --git a/arch/powerpc/perfmon/Kconfig b/arch/powerpc/perfmon/Kconfig
index 3f4bbf2..6c0128f 100644
--- a/arch/powerpc/perfmon/Kconfig
+++ b/arch/powerpc/perfmon/Kconfig
 <at>  <at>  -47,6 +47,14  <at>  <at>  config PERFMON_POWER6
 	Enables support for the Power 6 hardware performance counters
 	If unsure, say M.

+config PERFMON_POWER7

[PATCH 1/1] fix error in omission of Power7 support in libpfm

Hello,

In testing the perfmon2 and perf_counters substrates for PAPI, I discovered an 
error in the Power7 implementation for libpfm.  There was an omission from one 
of the case statements.  The attached patch fixes that.

Thanks for your consideration,

- Corey

Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjashfor <at> us.ibm.com

Index: pfmlib_gen_powerpc.c
===================================================================
RCS file: /cvsroot/perfmon2/libpfm/lib/pfmlib_gen_powerpc.c,v
retrieving revision 1.13
diff -u -p -r1.13 pfmlib_gen_powerpc.c
--- pfmlib_gen_powerpc.c	14 Jul 2009 17:39:49 -0000	1.13
+++ pfmlib_gen_powerpc.c	31 Jul 2009 23:50:50 -0000
 <at>  <at>  -292,6 +292,12  <at>  <at>  static int pfm_gen_powerpc_get_event_cod
 			return PFMLIB_SUCCESS;
                 } else
 			return PFMLIB_ERR_INVAL;

[PATCH 0/2] send_sigio/do_send_sig_info (Was: [RFC][PATCH] fcntl: F_[SG]ETOWN_TID)

Preparation for Peter's changes, but imho makes sense anyway.

Oleg.

[PATCH 1/2] signals: introduce do_send_sig_info() helper

Introduce do_send_sig_info() and convert group_send_sig_info(),
send_sig_info(), do_send_specific() to use this helper.

Hopefully it will have more users soon, it allows to specify
specific/group behaviour via "bool group" argument.

Shaves 80 bytes from .text.

Signed-off-by: Oleg Nesterov <oleg <at> redhat.com>
---

 include/linux/signal.h |    2 +
 kernel/signal.c        |   56 +++++++++++++++++++++++--------------------------
 2 files changed, 29 insertions(+), 29 deletions(-)

--- WAIT/include/linux/signal.h~1_HELPER	2009-06-11 14:16:46.000000000 +0200
+++ WAIT/include/linux/signal.h	2009-08-01 02:26:41.000000000 +0200
 <at>  <at>  -233,6 +233,8  <at>  <at>  static inline int valid_signal(unsigned 
 }

 extern int next_signal(struct sigpending *pending, sigset_t *mask);
+extern int do_send_sig_info(int sig, struct siginfo *info,
+				struct task_struct *p, bool group);
 extern int group_send_sig_info(int sig, struct siginfo *info, struct task_struct *p);
 extern int __group_send_sig_info(int, struct siginfo *, struct task_struct *);
 extern long do_rt_tgsigqueueinfo(pid_t tgid, pid_t pid, int sig,
--- WAIT/kernel/signal.c~1_HELPER	2009-07-01 20:22:44.000000000 +0200
+++ WAIT/kernel/signal.c	2009-08-01 02:21:27.000000000 +0200
 <at>  <at>  -971,6 +971,20  <at>  <at>  specific_send_sig_info(int sig, struct s
 	return send_signal(sig, info, t, 0);

[PATCH 2/2] signals: send_sigio: use do_send_sig_info() to avoid check_kill_permission()

group_send_sig_info()->check_kill_permission() assumes that current
is the sender and uses current_cred().

This is not true in send_sigio_to_task() case. From the security pov
the sender is not current, but the task which did fcntl(F_SETOWN),
that is why we have sigio_perm() which uses the right creds to check.

Fortunately, send_sigio() always sends either SEND_SIG_PRIV or
SI_FROMKERNEL() signal, so check_kill_permission() does nothing. But
still it would be tidier to avoid this bogus security check and save
a couple of cycles.

Signed-off-by: Oleg Nesterov <oleg <at> redhat.com>
---

 fs/fcntl.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- WAIT/fs/fcntl.c~2_SIGIO	2009-06-17 14:11:26.000000000 +0200
+++ WAIT/fs/fcntl.c	2009-08-01 02:40:41.000000000 +0200
 <at>  <at>  -462,11 +462,11  <at>  <at>  static void send_sigio_to_task(struct ta
 			else
 				si.si_band = band_table[reason - POLL_IN];
 			si.si_fd    = fd;
-			if (!group_send_sig_info(signum, &si, p))
+			if (!do_send_sig_info(signum, &si, p, true))
 				break;
 		/* fall-through: fall back on the old plain SIGIO signal */
 		case 0:
-			group_send_sig_info(SIGIO, SEND_SIG_PRIV, p);

Re: [PATCH 1/1] fix error in omission of Power7 support in libpfm

Corey,

Patch applied.
Thanks.

On Sat, Aug 1, 2009 at 2:18 AM, Corey
Ashford<cjashfor <at> linux.vnet.ibm.com> wrote:
>
> Hello,
>
> In testing the perfmon2 and perf_counters substrates for PAPI, I discovered
> an error in the Power7 implementation for libpfm.  There was an omission
> from one of the case statements.  The attached patch fixes that.
>
> Thanks for your consideration,
>
> - Corey
>
> Corey Ashford
> Software Engineer
> IBM Linux Technology Center, Linux Toolchain
> Beaverton, OR
> 503-578-3507
> cjashfor <at> us.ibm.com
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 

Re: [RFC][PATCH] fcntl: F_[SG]ETOWN_TID

Andrew,

On Fri, Jul 31, 2009 at 11:11 PM, Andrew
Morton<akpm <at> linux-foundation.org> wrote:
> On Fri, 31 Jul 2009 10:35:20 +0200
> Peter Zijlstra <a.p.zijlstra <at> chello.nl> wrote:
>
>> In order to direct the SIGIO signal to a particular thread of a
>> multi-threaded application we cannot, like suggested by the manpage, put
>> a TID into the regular fcntl(F_SETOWN) call. It will still be send to
>> the whole process of which that thread is part.
>>
>> Since people do want to properly direct SIGIO we introduce F_SETOWN_TID,
>> which functions similarly to F_SETOWN, except positive arguments are
>> interpreted as TIDs and negative arguments are interpreted as PIDs.
>>
>> This extension is fully bug compatible with the old F_GETOWN
>> implementation in that F_GETOWN_TID will be troubled by the negative
>> return value for PIDs similarly to F_GETOWN's trouble with process
>> groups.
>
> I'd be interested in seeing a bit more explanation about the "people do
> want to properly direct SIGIO" thing - use cases, how the current code
> causes them problems, etc.  As it stands, it's a bit of a mystery-patch.
>
I have explained that  in my initial post on LKML. Here is a link to it:
http://lkml.org/lkml/2009/7/27/242

Basically, in the context of self-monitoring threads (which is very common),
you want the sample notification to be asynchronous and yet delivered to

Re: I.1 - System calls - ioctl

On Thu, 2009-07-30 at 19:20 +0200, Arnd Bergmann wrote:
> On Thursday 30 July 2009, stephane eranian wrote:
> > But that won't always work in the case of a 32-bit monitoring tool
> > running on top of
> > a 64-bit OS. Imagine the target id is indeed 64-bit, e.g., inode
> > number (as suggested
> > by Peter). It's not because you are a 32-bit tool than you cannot name
> > a monitoring
> > resource in a 64-bit OS.
> 
> Right, there are obviously things that you cannot address with 
> a 'long', but there are potentially other things that you could
> that you cannot address with an 'int', e.g. an opaque user
> token (representing a user pointer) that you can get back in
> the sample data.
> 
> In the worst case, you could still redefine the argument as a
> transparent union to a long and pointer in the future if you
> use a 'long' now. AFAICT, there are no advantages of using
> an 'int' instead of a 'long', but there are disadvantages of
> using a 'long long'.

OK, so time is running out on this thing. Ingo, Paulus what would you
prefer?

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Re: [RFC][PATCH] fcntl: F_[SG]ETOWN_TID

On Fri, 2009-07-31 at 14:11 -0700, Andrew Morton wrote:
> 
> 
> > arch/parisc/include/asm/fcntl.h |    2 +
> > fs/fcntl.c                      |   64 +++++++++++++++++++++++++++++++++-----
> > include/asm-generic/fcntl.h     |    4 ++
> > include/linux/fs.h              |   11 +++++-
> > net/socket.c                    |    2 +-
> 
> OK.
> 
> 
> 
> Alpha has private definitions of F_SETSIG and F_GETSIG which are
> identical to the generic ones.  That's somewhat logical, given that
> alpha's F_SETOWN/F_GETOWN _differ_ from the asm-generic ones.
> 
> Alpha appears to have made the decision to spell out _all_ the F_*
> flags, given that some of them are different.  That has some merit, I
> guess.
> 
> But your patch broke that.

Right, all I did was validate that I didn't overlap with any of the
existing fcntl numbers. I can explicitly add them to alpha if that makes
people happy..

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 

[PATCH 3/2] fcntl: F_[SG]ETOWN_TID

In order to direct the SIGIO signal to a particular thread of a
multi-threaded application we cannot, like suggested by the manpage, put
a TID into the regular fcntl(F_SETOWN) call. It will still be send to
the whole process of which that thread is part.

Since people do want to properly direct SIGIO we introduce F_SETOWN_TID,
which functions similarly to F_SETOWN, except positive arguments are
interpreted as TIDs and negative arguments are interpreted as PIDs.

The need to direct SIGIO comes from self-monitoring profiling such as 
with perf-counters. Perf-counters uses SIGIO to notify that new sample
data is available. If the signal is delivered to the same task that
generated the new sample it can augment that data by inspecting the
task's user-space state right after it returns from the kernel. This 
is esp. convenient for interpreted or virtual machine driven environments.

This extension is fully bug compatible with the old F_GETOWN
implementation in that F_GETOWN_TID will be troubled by the negative
return value for PIDs similarly to F_GETOWN's trouble with process
groups.

Signed-off-by: Peter Zijlstra <a.p.zijlstra <at> chello.nl>
Tested-by: stephane eranian <eranian <at> googlemail.com>
---
 arch/alpha/include/asm/fcntl.h  |    2 +
 arch/parisc/include/asm/fcntl.h |    2 +
 fs/fcntl.c                      |   62 ++++++++++++++++++++++++++++++++++------
 include/asm-generic/fcntl.h     |    4 ++
 include/linux/fs.h              |   11 +++++--