linux-next: manual merge of the perfmon3 tree

linux-next: manual merge of the perfmon3 tree

[Stephen Rothwell]

Hi Stephane,

Today's linux-next merge of the perfmon3 tree got a conflict in
include/linux/sched.h between commit
f8d570a4745835f2238a33b537218a1bb03fc671 ("net: Fix recursive descent in
__scm_destroy()") from Linus' tree and commit
dab167960a632d29ef819adfa2d4c76a2ee3b26b ("perfmon: base code") from the
perfmon3 tree.

Just overlapping additions.  I fixed it up (see below) and you should fix
it in your tree by merging in Linus' tree and doing the same fixup in the
merge commit.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc include/linux/sched.h
index 755b570,16bf42d..0000000
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@@ -1304,8 -1349,9 +1304,11 @@@ struct task_struct 
  	 */
  	unsigned long timer_slack_ns;
  	unsigned long default_timer_slack_ns;
 +
 +	struct list_head	*scm_work_list;
+ #ifdef CONFIG_PERFMON_V20
+ 	struct pfm_context *pfm_context;
+ #endif
  };
  
  /*

linux-next: manual merge of the perfmon3 tree

[Stephen Rothwell]

Hi Stephane,

Today's linux-next merge of the perfmon3 tree got a conflict in
arch/x86/kernel/entry_64.S between commit
322648d1ba75280d62f114d47048beb0b35f5047 ("x86: include ENTRY/END in
entry handlers in entry_64.S") from the x86 tree and commit
3511a04973eaac18ee386f0db8c109e589019511 ("perfmon: x86-64 hooks") from
the perfmon3 tree.

A new way of doing things.  I fixed it up (see below) and can carry the
fixup as necessary.  I am not sure about this fix, confirmation would be
nice.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc arch/x86/kernel/entry_64.S
index fc0ad87,b6f061e..0000000
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@@ -929,190 -810,133 +929,195 @@@ ENTRY(\sym
  	INTR_FRAME
  	pushq $~(\num)
  	CFI_ADJUST_CFA_OFFSET 8
 -	interrupt \func
 +	interrupt \do_sym
  	jmp ret_from_intr
  	CFI_ENDPROC
 -	.endm
 -
 -ENTRY(thermal_interrupt)
 -	apicinterrupt THERMAL_APIC_VECTOR,smp_thermal_interrupt
 -END(thermal_interrupt)
 -
 -ENTRY(threshold_interrupt)
 -	apicinterrupt THRESHOLD_APIC_VECTOR,mce_threshold_interrupt
 -END(threshold_interrupt)
 -
 -#ifdef CONFIG_SMP	
 -ENTRY(reschedule_interrupt)
 -	apicinterrupt RESCHEDULE_VECTOR,smp_reschedule_interrupt
 -END(reschedule_interrupt)
 -
 -	.macro INVALIDATE_ENTRY num
 -ENTRY(invalidate_interrupt\num)
 -	apicinterrupt INVALIDATE_TLB_VECTOR_START+\num,smp_invalidate_interrupt	
 -END(invalidate_interrupt\num)
 -	.endm
 +END(\sym)
 +.endm
  
 -	INVALIDATE_ENTRY 0
 -	INVALIDATE_ENTRY 1
 -	INVALIDATE_ENTRY 2
 -	INVALIDATE_ENTRY 3
 -	INVALIDATE_ENTRY 4
 -	INVALIDATE_ENTRY 5
 -	INVALIDATE_ENTRY 6
 -	INVALIDATE_ENTRY 7
 -
 -ENTRY(call_function_interrupt)
 -	apicinterrupt CALL_FUNCTION_VECTOR,smp_call_function_interrupt
 -END(call_function_interrupt)
 -ENTRY(call_function_single_interrupt)
 -	apicinterrupt CALL_FUNCTION_SINGLE_VECTOR,smp_call_function_single_interrupt
 -END(call_function_single_interrupt)
 -ENTRY(irq_move_cleanup_interrupt)
 -	apicinterrupt IRQ_MOVE_CLEANUP_VECTOR,smp_irq_move_cleanup_interrupt
 -END(irq_move_cleanup_interrupt)
 +#ifdef CONFIG_SMP
 +apicinterrupt IRQ_MOVE_CLEANUP_VECTOR \
 +	irq_move_cleanup_interrupt smp_irq_move_cleanup_interrupt
  #endif
  
 -ENTRY(apic_timer_interrupt)
 -	apicinterrupt LOCAL_TIMER_VECTOR,smp_apic_timer_interrupt
 -END(apic_timer_interrupt)
 -
 -ENTRY(uv_bau_message_intr1)
 -	apicinterrupt 220,uv_bau_message_interrupt
 -END(uv_bau_message_intr1)
 +apicinterrupt 220 \
 +	uv_bau_message_intr1 uv_bau_message_interrupt
 +apicinterrupt LOCAL_TIMER_VECTOR \
 +	apic_timer_interrupt smp_apic_timer_interrupt
 +
 +#ifdef CONFIG_SMP
 +apicinterrupt INVALIDATE_TLB_VECTOR_START+0 \
 +	invalidate_interrupt0 smp_invalidate_interrupt
 +apicinterrupt INVALIDATE_TLB_VECTOR_START+1 \
 +	invalidate_interrupt1 smp_invalidate_interrupt
 +apicinterrupt INVALIDATE_TLB_VECTOR_START+2 \
 +	invalidate_interrupt2 smp_invalidate_interrupt
 +apicinterrupt INVALIDATE_TLB_VECTOR_START+3 \
 +	invalidate_interrupt3 smp_invalidate_interrupt
 +apicinterrupt INVALIDATE_TLB_VECTOR_START+4 \
 +	invalidate_interrupt4 smp_invalidate_interrupt
 +apicinterrupt INVALIDATE_TLB_VECTOR_START+5 \
 +	invalidate_interrupt5 smp_invalidate_interrupt
 +apicinterrupt INVALIDATE_TLB_VECTOR_START+6 \
 +	invalidate_interrupt6 smp_invalidate_interrupt
 +apicinterrupt INVALIDATE_TLB_VECTOR_START+7 \
 +	invalidate_interrupt7 smp_invalidate_interrupt
 +#endif
  
 -ENTRY(error_interrupt)
 -	apicinterrupt ERROR_APIC_VECTOR,smp_error_interrupt
 -END(error_interrupt)
 +apicinterrupt THRESHOLD_APIC_VECTOR \
 +	threshold_interrupt mce_threshold_interrupt
 +apicinterrupt THERMAL_APIC_VECTOR \
 +	thermal_interrupt smp_thermal_interrupt
 +
 +#ifdef CONFIG_SMP
 +apicinterrupt CALL_FUNCTION_SINGLE_VECTOR \
 +	call_function_single_interrupt smp_call_function_single_interrupt
 +apicinterrupt CALL_FUNCTION_VECTOR \
 +	call_function_interrupt smp_call_function_interrupt
 +apicinterrupt RESCHEDULE_VECTOR \
 +	reschedule_interrupt smp_reschedule_interrupt
 +#endif
  
 -ENTRY(spurious_interrupt)
 -	apicinterrupt SPURIOUS_APIC_VECTOR,smp_spurious_interrupt
 -END(spurious_interrupt)
 +apicinterrupt ERROR_APIC_VECTOR \
 +	error_interrupt smp_error_interrupt
 +apicinterrupt SPURIOUS_APIC_VECTOR \
 +	spurious_interrupt smp_spurious_interrupt
  
+ #ifdef CONFIG_PERFMON
 -ENTRY(pmu_interrupt)
 -	apicinterrupt LOCAL_PERFMON_VECTOR,smp_pmu_interrupt
 -END(pmu_interrupt)
++apicinterrupt LOCAL_PERFMON_VECTOR \
++	pmu_interrupt smp_pmu_interrupt
+ #endif
+ 
  /*
   * Exception entry points.
 - */ 		
 -	.macro zeroentry sym
 + */
 +.macro zeroentry sym do_sym
 +ENTRY(\sym)
  	INTR_FRAME
  	PARAVIRT_ADJUST_EXCEPTION_FRAME
 -	pushq $0	/* push error code/oldrax */ 
 +	pushq_cfi $-1		/* ORIG_RAX: no syscall to restart */
 +	subq $15*8,%rsp
 +	CFI_ADJUST_CFA_OFFSET 15*8
 +	call error_entry
 +	DEFAULT_FRAME 0
 +	movq %rsp,%rdi		/* pt_regs pointer */
 +	xorl %esi,%esi		/* no error code */
 +	call \do_sym
 +	jmp error_exit		/* %ebx: no swapgs flag */
 +	CFI_ENDPROC
 +END(\sym)
 +.endm
 +
 +.macro paranoidzeroentry sym do_sym
 +KPROBE_ENTRY(\sym)
 +	INTR_FRAME
 +	PARAVIRT_ADJUST_EXCEPTION_FRAME
 +	pushq $-1		/* ORIG_RAX: no syscall to restart */
  	CFI_ADJUST_CFA_OFFSET 8
 -	pushq %rax	/* push real oldrax to the rdi slot */ 
 +	subq $15*8, %rsp
 +	call save_paranoid
 +	TRACE_IRQS_OFF
 +	movq %rsp,%rdi		/* pt_regs pointer */
 +	xorl %esi,%esi		/* no error code */
 +	call \do_sym
 +	jmp paranoid_exit	/* %ebx: no swapgs flag */
 +	CFI_ENDPROC
 +KPROBE_END(\sym)
 +.endm
 +
 +.macro paranoidzeroentry_ist sym do_sym ist
 +KPROBE_ENTRY(\sym)
 + 	INTR_FRAME
 +	PARAVIRT_ADJUST_EXCEPTION_FRAME
 +	pushq $-1		/* ORIG_RAX: no syscall to restart */
  	CFI_ADJUST_CFA_OFFSET 8
 -	CFI_REL_OFFSET rax,0
 -	leaq  \sym(%rip),%rax
 -	jmp error_entry
 +	subq $15*8, %rsp
 +	call save_paranoid
 +	TRACE_IRQS_OFF
 +	movq %rsp,%rdi		/* pt_regs pointer */
 +	xorl %esi,%esi		/* no error code */
 +	movq %gs:pda_data_offset, %rbp
 +	subq $EXCEPTION_STKSZ, per_cpu__init_tss + TSS_ist + (\ist - 1) * 8(%rbp)
 +	call \do_sym
 +	addq $EXCEPTION_STKSZ, per_cpu__init_tss + TSS_ist + (\ist - 1) * 8(%rbp)
 +	jmp paranoid_exit	/* %ebx: no swapgs flag */
  	CFI_ENDPROC
 -	.endm	
 +KPROBE_END(\sym)
 +.endm
  
 -	.macro errorentry sym
 +.macro errorentry sym do_sym entry=0
 +.if \entry
 +KPROBE_ENTRY(\sym)
 +.else
 +ENTRY(\sym)
 +.endif
  	XCPT_FRAME
  	PARAVIRT_ADJUST_EXCEPTION_FRAME
 -	pushq %rax
 -	CFI_ADJUST_CFA_OFFSET 8
 -	CFI_REL_OFFSET rax,0
 -	leaq  \sym(%rip),%rax
 -	jmp error_entry
 +	subq $15*8,%rsp
 +	CFI_ADJUST_CFA_OFFSET 15*8
 +	call error_entry
 +	DEFAULT_FRAME 0
 +	movq %rsp,%rdi			/* pt_regs pointer */
 +	movq ORIG_RAX(%rsp),%rsi	/* get error code */
 +	movq $-1,ORIG_RAX(%rsp)		/* no syscall to restart */
 +	call \do_sym
 +	jmp error_exit			/* %ebx: no swapgs flag */
  	CFI_ENDPROC
 -	.endm
 +.if \entry
 +KPROBE_END(\sym)
 +.else
 +END(\sym)
 +.endif
 +.endm
  
  	/* error code is on the stack already */
 -	/* handle NMI like exceptions that can happen everywhere */
 -	.macro paranoidentry sym, ist=0, irqtrace=1
 -	SAVE_ALL
 -	cld
 -	movl $1,%ebx
 -	movl  $MSR_GS_BASE,%ecx
 -	rdmsr
 -	testl %edx,%edx
 -	js    1f
 -	SWAPGS
 -	xorl  %ebx,%ebx
 -1:
 -	.if \ist
 -	movq	%gs:pda_data_offset, %rbp
 -	.endif
 -	.if \irqtrace
 -	TRACE_IRQS_OFF
 -	.endif
 -	movq %rsp,%rdi
 -	movq ORIG_RAX(%rsp),%rsi
 -	movq $-1,ORIG_RAX(%rsp)
 -	.if \ist
 -	subq	$EXCEPTION_STKSZ, per_cpu__init_tss + TSS_ist + (\ist - 1) * 8(%rbp)
 -	.endif
 -	call \sym
 -	.if \ist
 -	addq	$EXCEPTION_STKSZ, per_cpu__init_tss + TSS_ist + (\ist - 1) * 8(%rbp)
 -	.endif
 -	DISABLE_INTERRUPTS(CLBR_NONE)
 -	.if \irqtrace
 +.macro paranoiderrorentry sym do_sym entry=1
 +.if \entry
 +KPROBE_ENTRY(\sym)
 +.else
 +ENTRY(\sym)
 +.endif
 +	XCPT_FRAME
 +	PARAVIRT_ADJUST_EXCEPTION_FRAME
 +	subq $15*8,%rsp
 +	CFI_ADJUST_CFA_OFFSET 15*8
 +	call save_paranoid
 +	DEFAULT_FRAME 0
  	TRACE_IRQS_OFF
 -	.endif
 -	.endm
 +	movq %rsp,%rdi			/* pt_regs pointer */
 +	movq ORIG_RAX(%rsp),%rsi	/* get error code */
 +	movq $-1,ORIG_RAX(%rsp)		/* no syscall to restart */
 +	call \do_sym
 +	jmp paranoid_exit		/* %ebx: no swapgs flag */
 +	CFI_ENDPROC
 +.if \entry
 +KPROBE_END(\sym)
 +.else
 +END(\sym)
 +.endif
 +.endm
 +
 +zeroentry divide_error do_divide_error
 +paranoidzeroentry_ist debug do_debug DEBUG_STACK
 +paranoidzeroentry_ist int3 do_int3 DEBUG_STACK
 +zeroentry overflow do_overflow
 +zeroentry bounds do_bounds
 +zeroentry invalid_op do_invalid_op
 +zeroentry device_not_available do_device_not_available
 +paranoiderrorentry double_fault do_double_fault 0
 +zeroentry coprocessor_segment_overrun do_coprocessor_segment_overrun
 +errorentry invalid_TSS do_invalid_TSS
 +errorentry segment_not_present do_segment_not_present
 +paranoiderrorentry stack_segment do_stack_segment
 +errorentry general_protection do_general_protection 1
 +errorentry page_fault do_page_fault 1
 +zeroentry spurious_interrupt_bug do_spurious_interrupt_bug
 +zeroentry coprocessor_error do_coprocessor_error
 +errorentry alignment_check do_alignment_check
 +#ifdef CONFIG_X86_MCE
 +paranoidzeroentry machine_check do_machine_check
 +#endif
 +zeroentry simd_coprocessor_error do_simd_coprocessor_error
  
  	/*
   	 * "Paranoid" exit path from exception stack.

linux-next: manual merge of the perfmon3 tree

[Stephen Rothwell]

Hi Stephane,

Today's linux-next merge of the perfmon3 tree got a conflict in
arch/x86/kernel/signal_32.c between commit
5c9b3a0c7b8be3cdef3d7418f0a49127e7cdc998 ("x86: signal: cosmetic
unification of including headers") from the x86 tree and commit
b8509b08e429bf36e4ac99dd03d24a3618428f71 ("perfmon: x86-32 hooks") from
the perfmon3 tree.

I fixed it up (see below) and can carry the fix.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc arch/x86/kernel/signal_32.c
index f7dd6c4,74da315..0000000
--- a/arch/x86/kernel/signal_32.c
+++ b/arch/x86/kernel/signal_32.c
@@@ -4,20 -4,24 +4,21 @@@
   *  1997-11-28  Modified for POSIX.1b signals by Richard Henderson
   *  2000-06-20  Pentium III FXSR, SSE support by Gareth Hughes
   */
 -#include <linux/list.h>
  
 -#include <linux/personality.h>
 -#include <linux/binfmts.h>
 -#include <linux/suspend.h>
 +#include <linux/sched.h>
 +#include <linux/mm.h>
 +#include <linux/smp.h>
  #include <linux/kernel.h>
 -#include <linux/ptrace.h>
  #include <linux/signal.h>
 -#include <linux/stddef.h>
 -#include <linux/unistd.h>
  #include <linux/errno.h>
 -#include <linux/sched.h>
  #include <linux/wait.h>
 +#include <linux/ptrace.h>
  #include <linux/tracehook.h>
 -#include <linux/elf.h>
 +#include <linux/unistd.h>
 +#include <linux/stddef.h>
 +#include <linux/personality.h>
 +#include <linux/uaccess.h>
+ #include <linux/perfmon_kern.h>
 -#include <linux/smp.h>
 -#include <linux/mm.h>
  
  #include <asm/processor.h>
  #include <asm/ucontext.h>

Re: linux-next: manual merge of the perfmon3 tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Stephane,
> 
> Today's linux-next merge of the perfmon3 tree got a conflict in 
> arch/x86/kernel/entry_64.S between commit 
> 322648d1ba75280d62f114d47048beb0b35f5047 ("x86: include ENTRY/END in 
> entry handlers in entry_64.S") from the x86 tree and commit 
> 3511a04973eaac18ee386f0db8c109e589019511 ("perfmon: x86-64 hooks") 
> from the perfmon3 tree.

very emphatic NAK on carrying such x86 changes in the perfmon tree, 
and putting that into linux-next!

Those perfmon changes should be submitted to the x86 tree. The code it 
touches is sensitive and the design questions matter a lot as well.

	Ingo

Re: linux-next: manual merge of the perfmon3 tree

[Alexander van Heukelum]

On Tue, Nov 25, 2008 at 09:03:19PM +1100, Stephen Rothwell wrote:
> Hi Stephane,
> 
> Today's linux-next merge of the perfmon3 tree got a conflict in
> arch/x86/kernel/entry_64.S between commit
> 322648d1ba75280d62f114d47048beb0b35f5047 ("x86: include ENTRY/END in
> entry handlers in entry_64.S") from the x86 tree and commit
> 3511a04973eaac18ee386f0db8c109e589019511 ("perfmon: x86-64 hooks") from
> the perfmon3 tree.
> 
> A new way of doing things.  I fixed it up (see below) and can carry the
> fixup as necessary.  I am not sure about this fix, confirmation would be
> nice.

Yes, this is a good fixup.

Thanks,
	Alexander

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> 
> diff --cc arch/x86/kernel/entry_64.S
> index fc0ad87,b6f061e..0000000
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
[...removed uninteresting part...]
>  +apicinterrupt ERROR_APIC_VECTOR \
>  +	error_interrupt smp_error_interrupt
>  +apicinterrupt SPURIOUS_APIC_VECTOR \
>  +	spurious_interrupt smp_spurious_interrupt
>   
> + #ifdef CONFIG_PERFMON
>  -ENTRY(pmu_interrupt)
>  -	apicinterrupt LOCAL_PERFMON_VECTOR,smp_pmu_interrupt
>  -END(pmu_interrupt)
> ++apicinterrupt LOCAL_PERFMON_VECTOR \
> ++	pmu_interrupt smp_pmu_interrupt
> + #endif
> + 
>   /*
>    * Exception entry points.
>  - */ 		
>  -	.macro zeroentry sym
>  + */
>  +.macro zeroentry sym do_sym
>  +ENTRY(\sym)
> [...]

Re: linux-next: manual merge of the perfmon3 tree

[stephane eranian]

Hi,


I looked at the modifications to entry_32.S and entry_64.S generated
by perfmon in 2.6.28-rc6
and they are quite minimal:

--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -513,7 +513,7 @@ ENDPROC(system_call)
        ALIGN
        RING0_PTREGS_FRAME              # can't unwind into user space anyway
 work_pending:
-       testb $_TIF_NEED_RESCHED, %cl
+       testw $(_TIF_NEED_RESCHED|_TIF_PERFMON_WORK), %cx
        jz work_notifysig
 work_resched:
        call schedule
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index b86f332..b6f061e 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -869,7 +869,13 @@ END(error_interrupt)
 ENTRY(spurious_interrupt)
        apicinterrupt SPURIOUS_APIC_VECTOR,smp_spurious_interrupt
 END(spurious_interrupt)
-
+
+#ifdef CONFIG_PERFMON
+ENTRY(pmu_interrupt)
+       apicinterrupt LOCAL_PERFMON_VECTOR,smp_pmu_interrupt
+END(pmu_interrupt)
+#endif
+
 /*
  * Exception entry points.
  */


Looking at Stephen's tree, looks like there were some new macros introduced to
declare the lowest level interrupt handler for entry_64. There is not much I can
do in advance to avoid this kind of problems. The handler is part of perfmon not
some generic x86 modification. Same thing for entry_32.S.

So I am not sure I understand your point about submitting the changes to the x86
tree first.




On Tue, Nov 25, 2008 at 11:22 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi Stephane,
>>
>> Today's linux-next merge of the perfmon3 tree got a conflict in
>> arch/x86/kernel/entry_64.S between commit
>> 322648d1ba75280d62f114d47048beb0b35f5047 ("x86: include ENTRY/END in
>> entry handlers in entry_64.S") from the x86 tree and commit
>> 3511a04973eaac18ee386f0db8c109e589019511 ("perfmon: x86-64 hooks")
>> from the perfmon3 tree.
>
> very emphatic NAK on carrying such x86 changes in the perfmon tree,
> and putting that into linux-next!
>
> Those perfmon changes should be submitted to the x86 tree. The code it
> touches is sensitive and the design questions matter a lot as well.
>
>        Ingo
>

Re: linux-next: manual merge of the perfmon3 tree

[stephane eranian]

Stephen,

I compiled your 2008-11-25 linux-next patch relative to 2.6.28-rc6 and
perfmon appeared to be working fine with your changes.
Thanks.


On Tue, Nov 25, 2008 at 11:03 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Stephane,
>
> Today's linux-next merge of the perfmon3 tree got a conflict in
> arch/x86/kernel/entry_64.S between commit
> 322648d1ba75280d62f114d47048beb0b35f5047 ("x86: include ENTRY/END in
> entry handlers in entry_64.S") from the x86 tree and commit
> 3511a04973eaac18ee386f0db8c109e589019511 ("perfmon: x86-64 hooks") from
> the perfmon3 tree.
>
> A new way of doing things.  I fixed it up (see below) and can carry the
> fixup as necessary.  I am not sure about this fix, confirmation would be
> nice.
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
> diff --cc arch/x86/kernel/entry_64.S
> index fc0ad87,b6f061e..0000000
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@@ -929,190 -810,133 +929,195 @@@ ENTRY(\sym
>        INTR_FRAME
>        pushq $~(\num)
>        CFI_ADJUST_CFA_OFFSET 8
>  -      interrupt \func
>  +      interrupt \do_sym
>        jmp ret_from_intr
>        CFI_ENDPROC
>  -      .endm
>  -
>  -ENTRY(thermal_interrupt)
>  -      apicinterrupt THERMAL_APIC_VECTOR,smp_thermal_interrupt
>  -END(thermal_interrupt)
>  -
>  -ENTRY(threshold_interrupt)
>  -      apicinterrupt THRESHOLD_APIC_VECTOR,mce_threshold_interrupt
>  -END(threshold_interrupt)
>  -
>  -#ifdef CONFIG_SMP
>  -ENTRY(reschedule_interrupt)
>  -      apicinterrupt RESCHEDULE_VECTOR,smp_reschedule_interrupt
>  -END(reschedule_interrupt)
>  -
>  -      .macro INVALIDATE_ENTRY num
>  -ENTRY(invalidate_interrupt\num)
>  -      apicinterrupt INVALIDATE_TLB_VECTOR_START+\num,smp_invalidate_interrupt
>  -END(invalidate_interrupt\num)
>  -      .endm
>  +END(\sym)
>  +.endm
>
>  -      INVALIDATE_ENTRY 0
>  -      INVALIDATE_ENTRY 1
>  -      INVALIDATE_ENTRY 2
>  -      INVALIDATE_ENTRY 3
>  -      INVALIDATE_ENTRY 4
>  -      INVALIDATE_ENTRY 5
>  -      INVALIDATE_ENTRY 6
>  -      INVALIDATE_ENTRY 7
>  -
>  -ENTRY(call_function_interrupt)
>  -      apicinterrupt CALL_FUNCTION_VECTOR,smp_call_function_interrupt
>  -END(call_function_interrupt)
>  -ENTRY(call_function_single_interrupt)
>  -      apicinterrupt CALL_FUNCTION_SINGLE_VECTOR,smp_call_function_single_interrupt
>  -END(call_function_single_interrupt)
>  -ENTRY(irq_move_cleanup_interrupt)
>  -      apicinterrupt IRQ_MOVE_CLEANUP_VECTOR,smp_irq_move_cleanup_interrupt
>  -END(irq_move_cleanup_interrupt)
>  +#ifdef CONFIG_SMP
>  +apicinterrupt IRQ_MOVE_CLEANUP_VECTOR \
>  +      irq_move_cleanup_interrupt smp_irq_move_cleanup_interrupt
>  #endif
>
>  -ENTRY(apic_timer_interrupt)
>  -      apicinterrupt LOCAL_TIMER_VECTOR,smp_apic_timer_interrupt
>  -END(apic_timer_interrupt)
>  -
>  -ENTRY(uv_bau_message_intr1)
>  -      apicinterrupt 220,uv_bau_message_interrupt
>  -END(uv_bau_message_intr1)
>  +apicinterrupt 220 \
>  +      uv_bau_message_intr1 uv_bau_message_interrupt
>  +apicinterrupt LOCAL_TIMER_VECTOR \
>  +      apic_timer_interrupt smp_apic_timer_interrupt
>  +
>  +#ifdef CONFIG_SMP
>  +apicinterrupt INVALIDATE_TLB_VECTOR_START+0 \
>  +      invalidate_interrupt0 smp_invalidate_interrupt
>  +apicinterrupt INVALIDATE_TLB_VECTOR_START+1 \
>  +      invalidate_interrupt1 smp_invalidate_interrupt
>  +apicinterrupt INVALIDATE_TLB_VECTOR_START+2 \
>  +      invalidate_interrupt2 smp_invalidate_interrupt
>  +apicinterrupt INVALIDATE_TLB_VECTOR_START+3 \
>  +      invalidate_interrupt3 smp_invalidate_interrupt
>  +apicinterrupt INVALIDATE_TLB_VECTOR_START+4 \
>  +      invalidate_interrupt4 smp_invalidate_interrupt
>  +apicinterrupt INVALIDATE_TLB_VECTOR_START+5 \
>  +      invalidate_interrupt5 smp_invalidate_interrupt
>  +apicinterrupt INVALIDATE_TLB_VECTOR_START+6 \
>  +      invalidate_interrupt6 smp_invalidate_interrupt
>  +apicinterrupt INVALIDATE_TLB_VECTOR_START+7 \
>  +      invalidate_interrupt7 smp_invalidate_interrupt
>  +#endif
>
>  -ENTRY(error_interrupt)
>  -      apicinterrupt ERROR_APIC_VECTOR,smp_error_interrupt
>  -END(error_interrupt)
>  +apicinterrupt THRESHOLD_APIC_VECTOR \
>  +      threshold_interrupt mce_threshold_interrupt
>  +apicinterrupt THERMAL_APIC_VECTOR \
>  +      thermal_interrupt smp_thermal_interrupt
>  +
>  +#ifdef CONFIG_SMP
>  +apicinterrupt CALL_FUNCTION_SINGLE_VECTOR \
>  +      call_function_single_interrupt smp_call_function_single_interrupt
>  +apicinterrupt CALL_FUNCTION_VECTOR \
>  +      call_function_interrupt smp_call_function_interrupt
>  +apicinterrupt RESCHEDULE_VECTOR \
>  +      reschedule_interrupt smp_reschedule_interrupt
>  +#endif
>
>  -ENTRY(spurious_interrupt)
>  -      apicinterrupt SPURIOUS_APIC_VECTOR,smp_spurious_interrupt
>  -END(spurious_interrupt)
>  +apicinterrupt ERROR_APIC_VECTOR \
>  +      error_interrupt smp_error_interrupt
>  +apicinterrupt SPURIOUS_APIC_VECTOR \
>  +      spurious_interrupt smp_spurious_interrupt
>
> + #ifdef CONFIG_PERFMON
>  -ENTRY(pmu_interrupt)
>  -      apicinterrupt LOCAL_PERFMON_VECTOR,smp_pmu_interrupt
>  -END(pmu_interrupt)
> ++apicinterrupt LOCAL_PERFMON_VECTOR \
> ++      pmu_interrupt smp_pmu_interrupt
> + #endif
> +
>  /*
>   * Exception entry points.
>  - */
>  -      .macro zeroentry sym
>  + */
>  +.macro zeroentry sym do_sym
>  +ENTRY(\sym)
>        INTR_FRAME
>        PARAVIRT_ADJUST_EXCEPTION_FRAME
>  -      pushq $0        /* push error code/oldrax */
>  +      pushq_cfi $-1           /* ORIG_RAX: no syscall to restart */
>  +      subq $15*8,%rsp
>  +      CFI_ADJUST_CFA_OFFSET 15*8
>  +      call error_entry
>  +      DEFAULT_FRAME 0
>  +      movq %rsp,%rdi          /* pt_regs pointer */
>  +      xorl %esi,%esi          /* no error code */
>  +      call \do_sym
>  +      jmp error_exit          /* %ebx: no swapgs flag */
>  +      CFI_ENDPROC
>  +END(\sym)
>  +.endm
>  +
>  +.macro paranoidzeroentry sym do_sym
>  +KPROBE_ENTRY(\sym)
>  +      INTR_FRAME
>  +      PARAVIRT_ADJUST_EXCEPTION_FRAME
>  +      pushq $-1               /* ORIG_RAX: no syscall to restart */
>        CFI_ADJUST_CFA_OFFSET 8
>  -      pushq %rax      /* push real oldrax to the rdi slot */
>  +      subq $15*8, %rsp
>  +      call save_paranoid
>  +      TRACE_IRQS_OFF
>  +      movq %rsp,%rdi          /* pt_regs pointer */
>  +      xorl %esi,%esi          /* no error code */
>  +      call \do_sym
>  +      jmp paranoid_exit       /* %ebx: no swapgs flag */
>  +      CFI_ENDPROC
>  +KPROBE_END(\sym)
>  +.endm
>  +
>  +.macro paranoidzeroentry_ist sym do_sym ist
>  +KPROBE_ENTRY(\sym)
>  +      INTR_FRAME
>  +      PARAVIRT_ADJUST_EXCEPTION_FRAME
>  +      pushq $-1               /* ORIG_RAX: no syscall to restart */
>        CFI_ADJUST_CFA_OFFSET 8
>  -      CFI_REL_OFFSET rax,0
>  -      leaq  \sym(%rip),%rax
>  -      jmp error_entry
>  +      subq $15*8, %rsp
>  +      call save_paranoid
>  +      TRACE_IRQS_OFF
>  +      movq %rsp,%rdi          /* pt_regs pointer */
>  +      xorl %esi,%esi          /* no error code */
>  +      movq %gs:pda_data_offset, %rbp
>  +      subq $EXCEPTION_STKSZ, per_cpu__init_tss + TSS_ist + (\ist - 1) * 8(%rbp)
>  +      call \do_sym
>  +      addq $EXCEPTION_STKSZ, per_cpu__init_tss + TSS_ist + (\ist - 1) * 8(%rbp)
>  +      jmp paranoid_exit       /* %ebx: no swapgs flag */
>        CFI_ENDPROC
>  -      .endm
>  +KPROBE_END(\sym)
>  +.endm
>
>  -      .macro errorentry sym
>  +.macro errorentry sym do_sym entry=0
>  +.if \entry
>  +KPROBE_ENTRY(\sym)
>  +.else
>  +ENTRY(\sym)
>  +.endif
>        XCPT_FRAME
>        PARAVIRT_ADJUST_EXCEPTION_FRAME
>  -      pushq %rax
>  -      CFI_ADJUST_CFA_OFFSET 8
>  -      CFI_REL_OFFSET rax,0
>  -      leaq  \sym(%rip),%rax
>  -      jmp error_entry
>  +      subq $15*8,%rsp
>  +      CFI_ADJUST_CFA_OFFSET 15*8
>  +      call error_entry
>  +      DEFAULT_FRAME 0
>  +      movq %rsp,%rdi                  /* pt_regs pointer */
>  +      movq ORIG_RAX(%rsp),%rsi        /* get error code */
>  +      movq $-1,ORIG_RAX(%rsp)         /* no syscall to restart */
>  +      call \do_sym
>  +      jmp error_exit                  /* %ebx: no swapgs flag */
>        CFI_ENDPROC
>  -      .endm
>  +.if \entry
>  +KPROBE_END(\sym)
>  +.else
>  +END(\sym)
>  +.endif
>  +.endm
>
>        /* error code is on the stack already */
>  -      /* handle NMI like exceptions that can happen everywhere */
>  -      .macro paranoidentry sym, ist=0, irqtrace=1
>  -      SAVE_ALL
>  -      cld
>  -      movl $1,%ebx
>  -      movl  $MSR_GS_BASE,%ecx
>  -      rdmsr
>  -      testl %edx,%edx
>  -      js    1f
>  -      SWAPGS
>  -      xorl  %ebx,%ebx
>  -1:
>  -      .if \ist
>  -      movq    %gs:pda_data_offset, %rbp
>  -      .endif
>  -      .if \irqtrace
>  -      TRACE_IRQS_OFF
>  -      .endif
>  -      movq %rsp,%rdi
>  -      movq ORIG_RAX(%rsp),%rsi
>  -      movq $-1,ORIG_RAX(%rsp)
>  -      .if \ist
>  -      subq    $EXCEPTION_STKSZ, per_cpu__init_tss + TSS_ist + (\ist - 1) * 8(%rbp)
>  -      .endif
>  -      call \sym
>  -      .if \ist
>  -      addq    $EXCEPTION_STKSZ, per_cpu__init_tss + TSS_ist + (\ist - 1) * 8(%rbp)
>  -      .endif
>  -      DISABLE_INTERRUPTS(CLBR_NONE)
>  -      .if \irqtrace
>  +.macro paranoiderrorentry sym do_sym entry=1
>  +.if \entry
>  +KPROBE_ENTRY(\sym)
>  +.else
>  +ENTRY(\sym)
>  +.endif
>  +      XCPT_FRAME
>  +      PARAVIRT_ADJUST_EXCEPTION_FRAME
>  +      subq $15*8,%rsp
>  +      CFI_ADJUST_CFA_OFFSET 15*8
>  +      call save_paranoid
>  +      DEFAULT_FRAME 0
>        TRACE_IRQS_OFF
>  -      .endif
>  -      .endm
>  +      movq %rsp,%rdi                  /* pt_regs pointer */
>  +      movq ORIG_RAX(%rsp),%rsi        /* get error code */
>  +      movq $-1,ORIG_RAX(%rsp)         /* no syscall to restart */
>  +      call \do_sym
>  +      jmp paranoid_exit               /* %ebx: no swapgs flag */
>  +      CFI_ENDPROC
>  +.if \entry
>  +KPROBE_END(\sym)
>  +.else
>  +END(\sym)
>  +.endif
>  +.endm
>  +
>  +zeroentry divide_error do_divide_error
>  +paranoidzeroentry_ist debug do_debug DEBUG_STACK
>  +paranoidzeroentry_ist int3 do_int3 DEBUG_STACK
>  +zeroentry overflow do_overflow
>  +zeroentry bounds do_bounds
>  +zeroentry invalid_op do_invalid_op
>  +zeroentry device_not_available do_device_not_available
>  +paranoiderrorentry double_fault do_double_fault 0
>  +zeroentry coprocessor_segment_overrun do_coprocessor_segment_overrun
>  +errorentry invalid_TSS do_invalid_TSS
>  +errorentry segment_not_present do_segment_not_present
>  +paranoiderrorentry stack_segment do_stack_segment
>  +errorentry general_protection do_general_protection 1
>  +errorentry page_fault do_page_fault 1
>  +zeroentry spurious_interrupt_bug do_spurious_interrupt_bug
>  +zeroentry coprocessor_error do_coprocessor_error
>  +errorentry alignment_check do_alignment_check
>  +#ifdef CONFIG_X86_MCE
>  +paranoidzeroentry machine_check do_machine_check
>  +#endif
>  +zeroentry simd_coprocessor_error do_simd_coprocessor_error
>
>        /*
>         * "Paranoid" exit path from exception stack.
>

Re: linux-next: manual merge of the perfmon3 tree

[Ingo Molnar]

* stephane eranian <eranian@googlemail.com> wrote:

> So I am not sure I understand your point about submitting the 
> changes to the x86 tree first.

You are modifying x86 architecture files to enable a kernel feature on 
x86. Such feature enablement, if it's pushed into linux-next, must go 
via the arch maintainers.

The x86 impact of the perfmon3 tree is substantial:

 arch/x86/Kconfig                               |    2 +
 arch/x86/Makefile                              |    3 +
 arch/x86/ia32/ia32entry.S                      |    5 +
 arch/x86/include/asm/Kbuild                    |    1 +
 arch/x86/include/asm/irq_vectors.h             |    5 +
 arch/x86/include/asm/mach-default/entry_arch.h |    4 +
 arch/x86/include/asm/perfmon.h                 |   34 ++
 arch/x86/include/asm/perfmon_kern.h            |  438 +++++++++++++++++
 arch/x86/include/asm/thread_info.h             |    8 +-
 arch/x86/include/asm/unistd_32.h               |    5 +
 arch/x86/include/asm/unistd_64.h               |   11 +-
 arch/x86/kernel/entry_32.S                     |    2 +-
 arch/x86/kernel/entry_64.S                     |    8 +-
 arch/x86/kernel/irqinit_64.c                   |    5 +
 arch/x86/kernel/process_32.c                   |   10 +
 arch/x86/kernel/process_64.c                   |   10 +
 arch/x86/kernel/signal_32.c                    |    5 +
 arch/x86/kernel/signal_64.c                    |    5 +
 arch/x86/kernel/syscall_table_32.S             |    5 +
 arch/x86/oprofile/nmi_int.c                    |   10 +-
 arch/x86/perfmon/Kconfig                       |   33 ++
 arch/x86/perfmon/Makefile                      |    7 +
 arch/x86/perfmon/perfmon.c                     |  619 +++++++++++++++++++++++
 arch/x86/perfmon/perfmon_amd64.c               |  483 ++++++++++++++++++
 arch/x86/perfmon/perfmon_intel_arch.c          |  628 ++++++++++++++++++++++++
 25 files changed, 2340 insertions(+), 6 deletions(-)

linux-next is not a development kernel - it is an integration tree 
simulating the next version of the upstream kernel and hence all trees 
that are in it must be synced up (and in this case, go via) their 
respective maintainers.

Thanks,

	Ingo

Re: linux-next: manual merge of the perfmon3 tree

[stephane eranian]

Ingo,


On Tue, Nov 25, 2008 at 4:33 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * stephane eranian <eranian@googlemail.com> wrote:
>
>> So I am not sure I understand your point about submitting the
>> changes to the x86 tree first.
>
> You are modifying x86 architecture files to enable a kernel feature on
> x86. Such feature enablement, if it's pushed into linux-next, must go
> via the arch maintainers.
>
> The x86 impact of the perfmon3 tree is substantial:
>
[snip]
>  25 files changed, 2340 insertions(+), 6 deletions(-)
>
> linux-next is not a development kernel - it is an integration tree
> simulating the next version of the upstream kernel and hence all trees
> that are in it must be synced up (and in this case, go via) their
> respective maintainers.
>
Perfmon3 as it exists in linux-next has two components: generic + x86
I can send x86@kernel.org the x86 specific patches to integrate them into
the x86 tree even though they would not be operational without the generic part.
But then, where do I send the generic code?

> Thanks,
>
>        Ingo
>

Re: linux-next: manual merge of the perfmon3 tree

[Ingo Molnar]

* stephane eranian <eranian@googlemail.com> wrote:

> Ingo,
> 
> 
> On Tue, Nov 25, 2008 at 4:33 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * stephane eranian <eranian@googlemail.com> wrote:
> >
> >> So I am not sure I understand your point about submitting the
> >> changes to the x86 tree first.
> >
> > You are modifying x86 architecture files to enable a kernel feature on
> > x86. Such feature enablement, if it's pushed into linux-next, must go
> > via the arch maintainers.
> >
> > The x86 impact of the perfmon3 tree is substantial:
> >
> [snip]
> >  25 files changed, 2340 insertions(+), 6 deletions(-)
> >
> > linux-next is not a development kernel - it is an integration tree
> > simulating the next version of the upstream kernel and hence all trees
> > that are in it must be synced up (and in this case, go via) their
> > respective maintainers.
> >
>
> Perfmon3 as it exists in linux-next has two components: generic + 
> x86 I can send x86@kernel.org the x86 specific patches to integrate 
> them into the x86 tree even though they would not be operational 
> without the generic part. But then, where do I send the generic 
> code?

There are a number of ways to do that - and we'll sure be able to work 
that out - but first please submit the full patchset (x86 and generic 
bits as well) to lkml with the x86 maintainers Cc:-ed.

In any case, until that happens and until there's agreement with the 
x86 maintainers (there's none at the moment) the perfmon3 tree (or at 
least its x86 bits) needs to be removed from linux-next. I already see 
a number of problems with the patchset that we'll have to work out via 
an iterative review process.

	Ingo

Re: linux-next: manual merge of the perfmon3 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]

Hi Ingo,

On Tue, 25 Nov 2008 17:51:18 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> There are a number of ways to do that - and we'll sure be able to work 
> that out - but first please submit the full patchset (x86 and generic 
> bits as well) to lkml with the x86 maintainers Cc:-ed.

Let see ... the permfmon patches have been submitted to LKML several
times over the past couple of years.  In their latest incarnation they
were posted to LKML on October 18 (lkml is, of course, also the mailing
list for x86 patches noted in MAINTAINERS - maybe you should submit a
patch noting that x86 code has to be submitted on x86@kernel.org as
well).  There has been ample time for the x86 maintainers to comment and
notice that their code is being modified.  I have seen no attempt at
review from them.

Also this code has been in linux-next since next-20081106 (i.e. November
6) and the only problem reports have been from the ia64 people.

> In any case, until that happens and until there's agreement with the 
> x86 maintainers (there's none at the moment) the perfmon3 tree (or at 
> least its x86 bits) needs to be removed from linux-next. I already see 
> a number of problems with the patchset that we'll have to work out via 
> an iterative review process.

That process has been happening except it seems that the x86 maintainers
haven't bothered to participate.  If, as you say, all the x86 parts have
to go via the x86 tree, then be aware that this woukd probably delay x86
perfmon integration until 2.6.30 or later (*cough* ftrace *cough*).  As
Andrew pointed out in another thread you seem to have missed, the
integration of perfmon (or something like it) is way over due.  The way
he suggested to go forward was to get it into linux-next and aim for
2.6.29 integration.

Several other architectures want this code in the kernel, so if they have
to wait for the x86 maintainers to decide what they want, then the only
way forward may be to separate the generic parts of the code and get that
integrated along with one of the other architectures.

/me dons flame-proof suite :-)
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the perfmon3 tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > In any case, until that happens and until there's agreement with 
> > the x86 maintainers (there's none at the moment) the perfmon3 tree 
> > (or at least its x86 bits) needs to be removed from linux-next. I 
> > already see a number of problems with the patchset that we'll have 
> > to work out via an iterative review process.
> 
> That process has been happening except it seems that the x86 
> maintainers haven't bothered to participate. [...]

uhm, that's plain not true. There are three x86 maintainers and we 
take pride in replying to all x86 patch submission within a day 
typically, so i reject your suggestion.

We know and knew about the existence of the perfmon patches, but they 
were always in the vague RFC category and never directly submitted or 
Cc:-ed to us.

The authors of those patches never even bothered to Cc: the x86 arch 
maintainers, and never asked for those patches to be Ack-ed, accepted 
or reviewed. If that is not so, please show me the lkml link that 
contradicts my claim.

And how did we notice that this was going on? Not because we were 
told, but due to a bad perfmon commit modifying x86 code that suddenly 
showed up in linux-next ...

> [...] If, as you say, all the x86 parts have to go via the x86 tree, 
> then be aware that this woukd probably delay x86 perfmon integration 
> until 2.6.30 or later [...]

Why should that be so?

All i'm asking for you is to follow the upstream kernel integration 
process. All i'm asking you is when a new tree matches such a wide 
pattern of x86 modifications:

       25 files changed, 2340 insertions(+), 6 deletions(-)

_to at least Cc: the maintainers and ask their opinion_

this isnt just a file here and there. It goes straight into the guts 
of the architecture.

All i'm asking for is to not use linux-next as a backdoor to get 
_unreviewed_ and _clearly bad_ patches behind the back of architecture 
maintainers who specifically asked to be involved.

> [...] (*cough* ftrace *cough*). [...]

I'm not sure what you want to imply by that. ftrace was delayed for 
several kernel releases before it went upstream and the initial port 
went upstream with the full knowledge (and participation) of the 
architecture maintainers. (x86, incidentally)

> [...] As Andrew pointed out in another thread you seem to have 
> missed, the integration of perfmon (or something like it) is way 
> over due.  The way he suggested to go forward was to get it into 
> linux-next and aim for 2.6.29 integration.
>
> Several other architectures want this code in the kernel, so if they 
> have to wait for the x86 maintainers to decide what they want, then 
> the only way forward may be to separate the generic parts of the 
> code and get that integrated along with one of the other 
> architectures.

There's a proper process for merging brand new features, and it starts 
with asking the opinion of the maintainers. This isnt just a random 
stale subsystem no-one is interested in. This is a highly active piece 
of code maintained by three maintainers. This subsystem saw more than 
5800 commits in the last year alone.

Stephen, this is kernel maintenance 101, and you must follow it.

	Ingo

RE: linux-next: manual merge of the perfmon3 tree

[H. Peter Anvin]

I guess it really comes down to: is -next a merge window preview tree, or is it another -mm tree just based on a different toolset/workflow?

    -hpa

-- 
Sent from my mobile phone (pardon any lack of formatting)


-----Original Message-----
From: Ingo Molnar <mingo@elte.hu>
Sent: Tuesday, November 25, 2008 19:33
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: eranian@gmail.com; linux-next@vger.kernel.org; Alexander van Heukelum <heukelum@mailshack.com>; the arch/x86 maintainers <x86@kernel.org>; H. Peter Anvin <hpa@zytor.com>; Thomas Gleixner <tglx@linutronix.de>; Peter Zijlstra <a.p.zijlstra@chello.nl>; Andrew Morton <akpm@linux-foundation.org>
Subject: Re: linux-next: manual merge of the perfmon3 tree


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > In any case, until that happens and until there's agreement with 
> > the x86 maintainers (there's none at the moment) the perfmon3 tree 
> > (or at least its x86 bits) needs to be removed from linux-next. I 
> > already see a number of problems with the patchset that we'll have 
> > to work out via an iterative review process.
> 
> That process has been happening except it seems that the x86 
> maintainers haven't bothered to participate. [...]

uhm, that's plain not true. There are three x86 maintainers and we 
take pride in replying to all x86 patch submission within a day 
typically, so i reject your suggestion.

We know and knew about the existence of the perfmon patches, but they 
were always in the vague RFC category and never directly submitted or 
Cc:-ed to us.

The authors of those patches never even bothered to Cc: the x86 arch 
maintainers, and never asked for those patches to be Ack-ed, accepted 
or reviewed. If that is not so, please show me the lkml link that 
contradicts my claim.

And how did we notice that this was going on? Not because we were 
told, but due to a bad perfmon commit modifying x86 code that suddenly 
showed up in linux-next ...

> [...] If, as you say, all the x86 parts have to go via the x86 tree, 
> then be aware that this woukd probably delay x86 perfmon integration 
> until 2.6.30 or later [...]

Why should that be so?

All i'm asking for you is to follow the upstream kernel integration 
process. All i'm asking you is when a new tree matches such a wide 
pattern of x86 modifications:

       25 files changed, 2340 insertions(+), 6 deletions(-)

_to at least Cc: the maintainers and ask their opinion_

this isnt just a file here and there. It goes straight into the guts 
of the architecture.

All i'm asking for is to not use linux-next as a backdoor to get 
_unreviewed_ and _clearly bad_ patches behind the back of architecture 
maintainers who specifically asked to be involved.

> [...] (*cough* ftrace *cough*). [...]

I'm not sure what you want to imply by that. ftrace was delayed for 
several kernel releases before it went upstream and the initial port 
went upstream with the full knowledge (and participation) of the 
architecture maintainers. (x86, incidentally)

> [...] As Andrew pointed out in another thread you seem to have 
> missed, the integration of perfmon (or something like it) is way 
> over due.  The way he suggested to go forward was to get it into 
> linux-next and aim for 2.6.29 integration.
>
> Several other architectures want this code in the kernel, so if they 
> have to wait for the x86 maintainers to decide what they want, then 
> the only way forward may be to separate the generic parts of the 
> code and get that integrated along with one of the other 
> architectures.

There's a proper process for merging brand new features, and it starts 
with asking the opinion of the maintainers. This isnt just a random 
stale subsystem no-one is interested in. This is a highly active piece 
of code maintained by three maintainers. This subsystem saw more than 
5800 commits in the last year alone.

Stephen, this is kernel maintenance 101, and you must follow it.

	Ingo

Re: linux-next: manual merge of the perfmon3 tree

[Paul Mackerras]

Ingo Molnar writes:

> We know and knew about the existence of the perfmon patches, but they 
> were always in the vague RFC category and never directly submitted or 
> Cc:-ed to us.

So at least now we have your attention. :)

The best thing now might be for Stephane to do a patch set with the
perfmon3 core + powerpc bits.  I'd be happy to take that through my
tree, and I really want to see perfmon3 get upstream.  X86 can follow
whenever you can get some time to take a look at it.

Paul.

Re: linux-next: manual merge of the perfmon3 tree

[Ingo Molnar]

* Paul Mackerras <paulus@samba.org> wrote:

> Ingo Molnar writes:
> 
> > We know and knew about the existence of the perfmon patches, but they 
> > were always in the vague RFC category and never directly submitted or 
> > Cc:-ed to us.
> 
> So at least now we have your attention. :)
> 
> The best thing now might be for Stephane to do a patch set with the 
> perfmon3 core + powerpc bits.  I'd be happy to take that through my 
> tree, and I really want to see perfmon3 get upstream.  X86 can 
> follow whenever you can get some time to take a look at it.

Sounds sensible. x86 doesnt always have to be the guinea pig for new 
kernel features :)

	Ingo

Re: linux-next: manual merge of the perfmon3 tree

[stephane eranian]

Ingo,

On Wed, Nov 26, 2008 at 4:33 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> > In any case, until that happens and until there's agreement with
>> > the x86 maintainers (there's none at the moment) the perfmon3 tree
>> > (or at least its x86 bits) needs to be removed from linux-next. I
>> > already see a number of problems with the patchset that we'll have
>> > to work out via an iterative review process.
>>
>> That process has been happening except it seems that the x86
>> maintainers haven't bothered to participate. [...]
>
> uhm, that's plain not true. There are three x86 maintainers and we
> take pride in replying to all x86 patch submission within a day
> typically, so i reject your suggestion.
>
> We know and knew about the existence of the perfmon patches, but they
> were always in the vague RFC category and never directly submitted or
> Cc:-ed to us.
>
As Stephen pointed out, the full patchset was posted on LKML in October
I never saw any comments from you or any other x86 maintainers. I always
assumed you were ALL on LKML anyway.

The perfmon patchset has been posted on LKML numerous times. I have
listened to all comments and made tons of changes both internally and to
the syscall APIs. I would not call this patchset a 'vague RFC'.


> The authors of those patches never even bothered to Cc: the x86 arch
> maintainers, and never asked for those patches to be Ack-ed, accepted
> or reviewed. If that is not so, please show me the lkml link that
> contradicts my claim.
>
You were cc'ed but apparently there is a problem with the script I am using
to post this patchset as it seems it was sent only to LKML and the cc-list
got dropped.

>
> All i'm asking for is to not use linux-next as a backdoor to get
> _unreviewed_ and _clearly bad_ patches behind the back of architecture
> maintainers who specifically asked to be involved.
>
I would appreciate if you could explain and point me to the x86 code which
you think is bad. I am always happy to take constructive comments to
improve the code.

I have reposted the full patchset yesterday on LKML but unfortunately my
script dropped the cc-list. I will repost today making sure x86@kernel.org
is cc'ed. I am sorry about that, it never was intentional. I will be waiting for
your feedback on the x86 code.

Re: linux-next: manual merge of the perfmon3 tree

[Ingo Molnar]

* stephane eranian <eranian@googlemail.com> wrote:

> > We know and knew about the existence of the perfmon patches, but 
> > they were always in the vague RFC category and never directly 
> > submitted or Cc:-ed to us.
>
> As Stephen pointed out, the full patchset was posted on LKML in 
> October I never saw any comments from you or any other x86 
> maintainers. I always assumed you were ALL on LKML anyway.

There's nothing to be "pointed out" about that - i was well aware of 
the regular perfmon spam on lkml ;-)

What was done in stealth was its sudden "will go upstream in 1-2 
months" status change, and its showing up in linux-next. There was 
ample opportunity to Cc: the maintainers for all of those steps - when 
you sent the tree setup request to Stephen, etc.

Really, in such cases you are expected to ping the respective 
maintainers about what they think about it and whether there's any 
objections. If they only notice it via conflicts of problem patches in 
linux-next they'll (rightfully) go into grumpy mode. _Especially_ if 
then the linux-next integrator also plays stupid about basic kernel 
workflow questions ;-)

> I have reposted the full patchset yesterday on LKML but 
> unfortunately my script dropped the cc-list. I will repost today 
> making sure x86@kernel.org is cc'ed. I am sorry about that, it never 
> was intentional. I will be waiting for your feedback on the x86 
> code.

ok, thanks. That's all that is needed normally.

	Ingo

Re: linux-next: manual merge of the perfmon3 tree

[Andrew Morton]

On Wed, 26 Nov 2008 09:46:04 +0100 Ingo Molnar <mingo@elte.hu> wrote:

> _Especially_ if 
> then the linux-next integrator also plays stupid about basic kernel 
> workflow questions ;-)

He didn't.  I suggested to Stephane and Stephen that we get this stuff
into linux-next for a shot at 2.6.29 and that the collective 'we' make
an extra effort to get perfmon over the hump and merged up.

You missed that email, missed the presence of perfmon in linux-next
and repeatedly chose to not review the perfmon patch series when it went
past.

So here we all are.

Re: linux-next: manual merge of the perfmon3 tree

[Peter Zijlstra]

On Wed, 2008-11-26 at 01:00 -0800, Andrew Morton wrote:
> On Wed, 26 Nov 2008 09:46:04 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> 
> > _Especially_ if 
> > then the linux-next integrator also plays stupid about basic kernel 
> > workflow questions ;-)
> 
> He didn't.  I suggested to Stephane and Stephen that we get this stuff
> into linux-next for a shot at 2.6.29 and that the collective 'we' make
> an extra effort to get perfmon over the hump and merged up.
> 
> You missed that email, missed the presence of perfmon in linux-next
> and repeatedly chose to not review the perfmon patch series when it went
> past.
> 
> So here we all are.

It just seems to me that CC-ing the intended 'we' at that point would
have saved a lot of grief.

Stuffing 2.3k lines of code in without the maintainers ACK is not
something we do each day, and I can understand them getting miffed about
that. I think every maintainer would consider such an action plain rude.

Re: linux-next: manual merge of the perfmon3 tree

[Ingo Molnar]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> On Wed, 26 Nov 2008 09:46:04 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> 
> > _Especially_ if 
> > then the linux-next integrator also plays stupid about basic kernel 
> > workflow questions ;-)
> 
> He didn't.  I suggested to Stephane and Stephen that we get this 
> stuff into linux-next for a shot at 2.6.29 and that the collective 
> 'we' make an extra effort to get perfmon over the hump and merged 
> up.

Did you think of Cc:-ing the affected maintainers, as a basic 
courtesy, and to make sure it's aligned up with their next merge 
window plans? Inform them to warn them about upcoming conflicts and 
other possible trouble you are causing in the code they are 
maintaining.

I'm sure you must have noticed the x86 impact from that patchset:

 arch/x86/Kconfig                               |    2 +
 arch/x86/Makefile                              |    3 +
 arch/x86/ia32/ia32entry.S                      |    5 +
 arch/x86/include/asm/Kbuild                    |    1 +
 arch/x86/include/asm/irq_vectors.h             |    5 +
 arch/x86/include/asm/mach-default/entry_arch.h |    4 +
 arch/x86/include/asm/perfmon.h                 |   34 ++
 arch/x86/include/asm/perfmon_kern.h            |  438 +++++++++++++++++
 arch/x86/include/asm/thread_info.h             |    8 +-
 arch/x86/include/asm/unistd_32.h               |    5 +
 arch/x86/include/asm/unistd_64.h               |   11 +-
 arch/x86/kernel/entry_32.S                     |    2 +-
 arch/x86/kernel/entry_64.S                     |    8 +-
 arch/x86/kernel/irqinit_64.c                   |    5 +
 arch/x86/kernel/process_32.c                   |   10 +
 arch/x86/kernel/process_64.c                   |   10 +
 arch/x86/kernel/signal_32.c                    |    5 +
 arch/x86/kernel/signal_64.c                    |    5 +
 arch/x86/kernel/syscall_table_32.S             |    5 +
 arch/x86/oprofile/nmi_int.c                    |   10 +-
 arch/x86/perfmon/Kconfig                       |   33 ++
 arch/x86/perfmon/Makefile                      |    7 +
 arch/x86/perfmon/perfmon.c                     |  619 +++++++++++++++++++++++
 arch/x86/perfmon/perfmon_amd64.c               |  483 ++++++++++++++++++
 arch/x86/perfmon/perfmon_intel_arch.c          |  628 ++++++++++++++++++++++++
 25 files changed, 2340 insertions(+), 6 deletions(-)

There's a ton of RFC patches on lkml that affect x86, it's a naturally 
popular arch for various kernel features. Right now there's 4-5 RFC 
features on lkml that have an x86 impact. Should we NAK all of them as 
a precaution, just to be on the safe side against surprises?

> You missed that email, [...]

to put it into perspective, this is the single mail about this topic 
that you are referring to:

  http://lkml.org/lkml/2008/10/22/381

you wrote (well into the mail):

  | What it needs is a sustained effort to get it over the hump.  
  | How's about getting it into linux-next asap and then we all agree 
  | to do the re-re-re-review and runtime testing for a 2.6.29 merge?

That was deep inside an existing discussion, and posed as a question.

The rest is probably private mails between you and sfr, right? No Cc: 
to the affected x86 maintainers and without any syncing with the merge 
schedule of the affected maintainers. How do you expect us to have 
magically deducted what you've done after that point privately?

And what would it have costed you to actually ... ask our opinion? To 
make sure everyone is on the same page? Instead of doing this all 
privately and behind our backs in essence?

> [...] missed the presence of perfmon in linux-next and repeatedly 
> chose to not review the perfmon patch series when it went past.

So every patch that touches lkml and has not specifically been NAK-ed 
by maintainers can show up in linux-next tomorrow, overlapping 
existing and well-maintained subsystem trees? That's a rather new 
concept to me that goes straight again all current maintenance 
practices and i think it is an absurd notion. It does not and it 
cannot work like that.

Sometimes we maintainers volunteer and review an pick up larger 
patches from lkml without being asked to. (we dont actually _have_ to, 
but we try to - the influx of patches and the plans for the cycle 
_ALWAYS_ has to be synced up with affected maintainers)

Sometimes, especially if a difficult merge is upcoming, we wait for 
them to be actively submitted to us and prioritize features based on 
review and testing feedback. Especially if it's the 10th version of a 
rather complex patchset that seemed to be getting nowhere.

Also, i asked this from you before and have not gotten an answer to it 
yet: how am i supposed to follow what goes into linux-next, in an 
efficient manner?

linux-next is a huge tree with 4000+ ever changing commits, and it is 
not at all transparent in the Git space: a ton of commits get rebased 
on a daily basis (all the quilt queues). There's no history of for 
example the 'linux-next/master/Trees' file either that would show and 
explain when and why trees were added to (or removed from) linux-next.

So linux-next has no proper reviewable history - unless you expect us 
to standardize on doing nothing but parsing linux-next changelogs all 
day.

_You_ certainly know what goes into linux-next, simply because you are 
the one who gets Cc:-ed to everything that goes into it. So you are in 
a fundamentally assymetric position. But how can you then expect 
symmetric awareness from us?

On the other hand i can and i do monitor what goes into Linus's tree, 
because it's a proper append-only Git tree. I can see all the merge 
decisions and activities in a very straightforward manner. The same is 
not possible with linux-next.

	Ingo