* Re: linux-next: ftrace tree build warnings
From: Ingo Molnar @ 2008-11-25 8:00 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, H. Peter Anvin, linux-next, Steven Rostedt,
Alan Cox
In-Reply-To: <20081125133828.8f9b49df.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next build (x86_64 allmodconfig) produced lots of these
> warnings:
>
> include/linux/tty.h:330: warning: '______f' is static but declared in inline function 'tty_kref_get' which is not static
>
> Caused by commit 2bcd521a684cc94befbe2ce7d5b613c841b0d304 ("trace:
> profile all if conditionals"). Something needs to be done about
> this ... maybe tty_kref_get needs to be "static inline" instead of
> "extern inline"?
i've queued up the fix below, and pushed out a new ftrace-next tree.
Thanks,
Ingo
------------------>
From 14bfc987e395797dfe03e915e8b4c7fc9e5078e4 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Tue, 25 Nov 2008 08:58:11 +0100
Subject: [PATCH] tracing, tty: fix warnings caused by branch tracing and tty_kref_get()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Stephen Rothwell reported tht this warning started triggering in
linux-next:
In file included from init/main.c:27:
include/linux/tty.h: In function ‘tty_kref_get’:
include/linux/tty.h:330: warning: ‘______f’ is static but declared in inline function ‘tty_kref_get’ which is not static
Which gcc emits for 'extern inline' functions that nevertheless define
static variables. Change it to 'static inline', which is the norm
in the kernel anyway.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
include/linux/tty.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 3b8121d..eaec37c 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -325,7 +325,7 @@ extern struct class *tty_class;
* go away
*/
-extern inline struct tty_struct *tty_kref_get(struct tty_struct *tty)
+static inline struct tty_struct *tty_kref_get(struct tty_struct *tty)
{
if (tty)
kref_get(&tty->kref);
^ permalink raw reply related
* Re: linux-next: ftrace tree build failure
From: Ingo Molnar @ 2008-11-25 8:04 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, H. Peter Anvin, linux-next, Steven Rostedt,
Luis R. Rodriguez, John W. Linville, David S. Miller
In-Reply-To: <20081125184335.330cf28e.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Ingo,
>
> On Tue, 25 Nov 2008 08:28:01 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > this fix is wrong - the intention of that line was to add a proper
> > WARN(), not a WARN_ON(). Your change loses the message that WARN()
> > prints.
> >
> > i posted a tested fix for this two days ago:
> >
> > http://marc.info/?l=linux-kernel&m=122745649425646&w=2
> >
> > see it also below.
>
> Yeah, Steve told me. However, it might have been useful to tell the
> wireless maintainer, the network maintainer and the original author
> (and probably netdev - which I also left off).
yep, i too forgot to add full Cc:s (it was in the context of a tracing
discussion) - but lkml was Cc:-ed so it wasnt actually lost.
Ingo
^ permalink raw reply
* linux-next: manual merge of the security-testing tree
From: Stephen Rothwell @ 2008-11-25 8:11 UTC (permalink / raw)
To: James Morris; +Cc: linux-next, David Howells, J. Bruce Fields
Hi James,
Today's linux-next merge of the security-testing tree got a conflict in
fs/nfsd/nfs4recover.c between commit
e4625eb826de4f6774ee602c442ba23b686bdcc7 ("nfsd: use of unitialized list
head on error exit in nfs4recover.c") from the nfsd tree and commit
d84f4f992cbd76e8f39c488cf0c5d123843923b1 ("CRED: Inaugurate COW
credentials") from the security-testing tree.
Just a context change. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc fs/nfsd/nfs4recover.c
index cf94563,9371ea1..0000000
--- a/fs/nfsd/nfs4recover.c
+++ b/fs/nfsd/nfs4recover.c
@@@ -224,10 -230,12 +230,13 @@@ nfsd4_list_rec_dir(struct dentry *dir,
if (!rec_dir_init)
return 0;
- nfs4_save_user(&uid, &gid);
+ status = nfs4_save_creds(&original_cred);
+ if (status < 0)
+ return status;
+ INIT_LIST_HEAD(dentries);
- filp = dentry_open(dget(dir), mntget(rec_dir.mnt), O_RDONLY);
+ filp = dentry_open(dget(dir), mntget(rec_dir.mnt), O_RDONLY,
+ current_cred());
status = PTR_ERR(filp);
if (IS_ERR(filp))
goto out;
^ permalink raw reply
* Re: linux-next: ftrace tree build warnings
From: Stephen Rothwell @ 2008-11-25 8:17 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, H. Peter Anvin, linux-next, Steven Rostedt,
Alan Cox
In-Reply-To: <20081125080035.GA27513@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 278 bytes --]
Hi Ingo,
On Tue, 25 Nov 2008 09:00:35 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> i've queued up the fix below, and pushed out a new ftrace-next tree.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: kbuild tree build failure
From: Sam Ravnborg @ 2008-11-25 8:42 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next
In-Reply-To: <20081125154705.09683583.sfr@canb.auug.org.au>
On Tue, Nov 25, 2008 at 03:47:05PM +1100, Stephen Rothwell wrote:
> Hi Sam,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> WARNING: modpost: Found 11 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> .tmp_kallsyms1.S:1:23: error: asm/types.h: No such file or directory
>
> I have dropped the kbuild tree for today.
Fixed.
Sam
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Stephen Rothwell @ 2008-11-25 8:42 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Stephen Hemminger, David Miller, linux-next
In-Reply-To: <20081124221232.GA945@uranus.ravnborg.org>
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]
Hi Sam,
On Mon, 24 Nov 2008 23:12:32 +0100 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Anyway - I can see that only "cris m68k parisc s390 sparc sparc64 um" lacks
Actually parisc gets it through drivers/parisc/Kconfig.
> the include of drivers/scsi/pcmcia/Kconfig.
> So I will try to add it to drivers/Kconfig in my tree and see it -next
> blows up. I will wait until next -next as I want to see my current
> pending patches there in a clean run first.
I started to do this but then decided that ordering of the includes may
need some thought.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: next-20081119: general protection fault: get_next_timer_interrupt()
From: Jens Axboe @ 2008-11-25 8:51 UTC (permalink / raw)
To: malahal
Cc: Stephen Rothwell, Thomas Gleixner, Mike Anderson, James Bottomley,
Alexander Beregalov, LKML, linux-next, Ingo Molnar, linux-scsi,
David Miller
In-Reply-To: <20081125020852.GA27280@us.ibm.com>
On Mon, Nov 24 2008, malahal@us.ibm.com wrote:
> Stephen Rothwell [sfr@canb.auug.org.au] wrote:
> > > The block timer code calls del_timer(), should it call del_timer_sync()?
> > > It is possible although unlikely that you are hitting del_timer_sync vs
> > > del_timer problem in the block timeout code. Can only be seen on SMP
> > > systems though!
> >
> > Is this still a problem in next-20081121? In that tree, the block commit
> > "block: leave the request timeout timer running even on an empty list"
> > was changed to add this:
> >
> > diff --git a/block/blk-core.c b/block/blk-core.c
> > index 04267d6..44f547c 100644
> > --- a/block/blk-core.c
> > +++ b/block/blk-core.c
> > @@ -391,6 +391,7 @@ EXPORT_SYMBOL(blk_stop_queue);
> > void blk_sync_queue(struct request_queue *q)
> > {
> > del_timer_sync(&q->unplug_timer);
> > + del_timer_sync(&q->timeout);
> > kblockd_flush_work(&q->unplug_work);
> > }
> > EXPORT_SYMBOL(blk_sync_queue);
>
> I was looking at the Linux tree. Clearly same problem doesn't exist with
> the above commit! I wonder why kblockd_flush_work() is called after the
> del_timer_sync(). It makes sense to cancel the work and then shutdown
> the timer(s). I doubt if you are running into this problem though.
If the kernel tested doesn't include the above fix, it'll surely go
boom. Can someone verify that this is the case?
--
Jens Axboe
^ permalink raw reply
* Re: linux-next: kbuild tree build failure
From: Stephen Rothwell @ 2008-11-25 8:58 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next
In-Reply-To: <20081125084226.GA31444@uranus.ravnborg.org>
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]
Hi Sam,
On Tue, 25 Nov 2008 09:42:26 +0100 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> On Tue, Nov 25, 2008 at 03:47:05PM +1100, Stephen Rothwell wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> >
> > WARNING: modpost: Found 11 section mismatch(es).
> > To see full details build your kernel with:
> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> > .tmp_kallsyms1.S:1:23: error: asm/types.h: No such file or directory
> >
> > I have dropped the kbuild tree for today.
>
> Fixed.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Sam Ravnborg @ 2008-11-25 9:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Stephen Hemminger, David Miller, linux-next
In-Reply-To: <20081125194257.84089d9b.sfr@canb.auug.org.au>
On Tue, Nov 25, 2008 at 07:42:57PM +1100, Stephen Rothwell wrote:
> Hi Sam,
>
> On Mon, 24 Nov 2008 23:12:32 +0100 Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > Anyway - I can see that only "cris m68k parisc s390 sparc sparc64 um" lacks
>
> Actually parisc gets it through drivers/parisc/Kconfig.
>
> > the include of drivers/scsi/pcmcia/Kconfig.
> > So I will try to add it to drivers/Kconfig in my tree and see it -next
> > blows up. I will wait until next -next as I want to see my current
> > pending patches there in a clean run first.
>
> I started to do this but then decided that ordering of the includes may
> need some thought.
x86 at least put it in the "Bus" menu where I also think it belongs.
So it is not a simple move to drivers/Kconfig as I orginally thought
and I think we should let it be as it is for now.
Sam
^ permalink raw reply
* linux-next: manual merge of the cputime tree
From: Stephen Rothwell @ 2008-11-25 9:21 UTC (permalink / raw)
To: Martin Schwidefsky; +Cc: linux-next, Oleg Nesterov, Ingo Molnar
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
Hi Martin,
Today's linux-next merge of the cputime tree got a conflict in
kernel/sched.c between commit 74fcd524e808975dd546dac847119f1995a7c622
("account_steal_time: kill the unneeded account_group_system_time()")
from the tip-core tree and commit
b7f4776b7f575ed8f288c44b64befd241fd44458 ("[PATCH] idle cputime
accounting") from the cputime tree.
The latter removes the call to account_group_system_time() as a side
effect of further changes. So the fixup is to just take the latter
change. I can carry the merge fix.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: manual merge of the perfmon3 tree
From: Stephen Rothwell @ 2008-11-25 10:03 UTC (permalink / raw)
To: stephane eranian; +Cc: linux-next, Alexander van Heukelum, Ingo Molnar
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.
^ permalink raw reply
* linux-next: manual merge of the perfmon3 tree
From: Stephen Rothwell @ 2008-11-25 10:03 UTC (permalink / raw)
To: stephane eranian; +Cc: linux-next, Hiroshi Shimamoto, Ingo Molnar
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>
^ permalink raw reply
* Re: linux-next: manual merge of the cputime tree
From: Peter Zijlstra @ 2008-11-25 10:06 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martin Schwidefsky, linux-next, Oleg Nesterov, Ingo Molnar
In-Reply-To: <20081125202105.2e80cf92.sfr@canb.auug.org.au>
On Tue, 2008-11-25 at 20:21 +1100, Stephen Rothwell wrote:
> Hi Martin,
>
> Today's linux-next merge of the cputime tree got a conflict in
> kernel/sched.c between commit 74fcd524e808975dd546dac847119f1995a7c622
> ("account_steal_time: kill the unneeded account_group_system_time()")
> from the tip-core tree and commit
> b7f4776b7f575ed8f288c44b64befd241fd44458 ("[PATCH] idle cputime
> accounting") from the cputime tree.
>
> The latter removes the call to account_group_system_time() as a side
> effect of further changes. So the fixup is to just take the latter
> change. I can carry the merge fix.
Martin,
Why does s390 do its own cpu accounting?
^ permalink raw reply
* Re: linux-next: manual merge of the cputime tree
From: Martin Schwidefsky @ 2008-11-25 10:15 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Stephen Rothwell, linux-next, Oleg Nesterov, Ingo Molnar
In-Reply-To: <1227607612.4259.1428.camel@twins>
On Tue, 2008-11-25 at 11:06 +0100, Peter Zijlstra wrote:
> On Tue, 2008-11-25 at 20:21 +1100, Stephen Rothwell wrote:
> > Hi Martin,
> >
> > Today's linux-next merge of the cputime tree got a conflict in
> > kernel/sched.c between commit 74fcd524e808975dd546dac847119f1995a7c622
> > ("account_steal_time: kill the unneeded account_group_system_time()")
> > from the tip-core tree and commit
> > b7f4776b7f575ed8f288c44b64befd241fd44458 ("[PATCH] idle cputime
> > accounting") from the cputime tree.
> >
> > The latter removes the call to account_group_system_time() as a side
> > effect of further changes. So the fixup is to just take the latter
> > change. I can carry the merge fix.
>
> Why does s390 do its own cpu accounting?
Is that a trick question? I invented the cputime accounting specifically
for s390 because it is a virtual architecture and the standard cpu
accounting numbers are just useless.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: linux-next: manual merge of the perfmon3 tree
From: Ingo Molnar @ 2008-11-25 10:22 UTC (permalink / raw)
To: Stephen Rothwell
Cc: stephane eranian, linux-next, Alexander van Heukelum,
the arch/x86 maintainers, H. Peter Anvin, Thomas Gleixner,
Peter Zijlstra, Andrew Morton
In-Reply-To: <20081125210319.35b2d189.sfr@canb.auug.org.au>
* 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
^ permalink raw reply
* Re: linux-next: ftrace tree build warnings
From: Alan Cox @ 2008-11-25 10:25 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
Steven Rostedt, Alan Cox
In-Reply-To: <20081125133828.8f9b49df.sfr@canb.auug.org.au>
On Tue, 25 Nov 2008 13:38:28 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next build (x86_64 allmodconfig) produced lots of these
> warnings:
>
> include/linux/tty.h:330: warning: '______f' is static but declared in inline function 'tty_kref_get' which is not static
>
> Caused by commit 2bcd521a684cc94befbe2ce7d5b613c841b0d304 ("trace:
> profile all if conditionals"). Something needs to be done about
> this ... maybe tty_kref_get needs to be "static inline" instead of
> "extern inline"?
If someone from the ftrace crew can sort the problem out and send me a
diff for the ttydev tree that shouldn't be a problem, but really it looks
like a problem with ftrace as that can't be the only case this happens
surely ?
^ permalink raw reply
* Re: linux-next: manual merge of the cputime tree
From: Peter Zijlstra @ 2008-11-25 10:28 UTC (permalink / raw)
To: schwidefsky; +Cc: Stephen Rothwell, linux-next, Oleg Nesterov, Ingo Molnar
In-Reply-To: <1227608128.30264.2.camel@localhost>
On Tue, 2008-11-25 at 11:15 +0100, Martin Schwidefsky wrote:
> On Tue, 2008-11-25 at 11:06 +0100, Peter Zijlstra wrote:
> > On Tue, 2008-11-25 at 20:21 +1100, Stephen Rothwell wrote:
> > > Hi Martin,
> > >
> > > Today's linux-next merge of the cputime tree got a conflict in
> > > kernel/sched.c between commit 74fcd524e808975dd546dac847119f1995a7c622
> > > ("account_steal_time: kill the unneeded account_group_system_time()")
> > > from the tip-core tree and commit
> > > b7f4776b7f575ed8f288c44b64befd241fd44458 ("[PATCH] idle cputime
> > > accounting") from the cputime tree.
> > >
> > > The latter removes the call to account_group_system_time() as a side
> > > effect of further changes. So the fixup is to just take the latter
> > > change. I can carry the merge fix.
> >
> > Why does s390 do its own cpu accounting?
>
> Is that a trick question? I invented the cputime accounting specifically
> for s390 because it is a virtual architecture and the standard cpu
> accounting numbers are just useless.
Nah, just general ignorance brought on by the mondays on a tuesday ;-)
Right, makes sense, is it shared with all other virt* folks out there?
^ permalink raw reply
* linux-next: ocsf2 tree build warnings
From: Stephen Rothwell @ 2008-11-25 10:31 UTC (permalink / raw)
To: Mark Fasheh; +Cc: linux-next, Jan Kara
[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]
Hi Mark,
Today's linux-next build (powerpc allyesconfig) produced these warnings:
fs/ocfs2/quota_local.c: In function 'olq_set_dquot':
fs/ocfs2/quota_local.c:844: warning: format '%lld' expects type 'long long int', but argument 7 has type '__le64'
fs/ocfs2/quota_local.c:844: warning: format '%lld' expects type 'long long int', but argument 8 has type '__le64'
fs/ocfs2/quota_local.c:844: warning: format '%lld' expects type 'long long int', but argument 7 has type '__le64'
fs/ocfs2/quota_local.c:844: warning: format '%lld' expects type 'long long int', but argument 8 has type '__le64'
fs/ocfs2/quota_local.c:844: warning: format '%lld' expects type 'long long int', but argument 7 has type '__le64'
fs/ocfs2/quota_local.c:844: warning: format '%lld' expects type 'long long int', but argument 8 has type '__le64'
fs/ocfs2/quota_global.c: In function '__ocfs2_sync_dquot':
fs/ocfs2/quota_global.c:457: warning: format '%lld' expects type 'long long int', but argument 8 has type 's64'
fs/ocfs2/quota_global.c:457: warning: format '%lld' expects type 'long long int', but argument 10 has type 's64'
fs/ocfs2/quota_global.c:457: warning: format '%lld' expects type 'long long int', but argument 8 has type 's64'
fs/ocfs2/quota_global.c:457: warning: format '%lld' expects type 'long long int', but argument 10 has type 's64'
fs/ocfs2/quota_global.c:457: warning: format '%lld' expects type 'long long int', but argument 8 has type 's64'
fs/ocfs2/quota_global.c:457: warning: format '%lld' expects type 'long long int', but argument 10 has type 's64'
These are because s64 is "long" on some architectures. Our usual
solution is to cast them to "long long" when printing them. Also, you
shouldn't directly print an __le64 (you need to convert it to the host
type first for it to make much sense.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the cputime tree
From: Paul Mackerras @ 2008-11-25 10:32 UTC (permalink / raw)
To: Peter Zijlstra
Cc: schwidefsky, Stephen Rothwell, linux-next, Oleg Nesterov,
Ingo Molnar
In-Reply-To: <1227608880.4259.1451.camel@twins>
Peter Zijlstra writes:
> Right, makes sense, is it shared with all other virt* folks out there?
PowerPC uses it too.
Paul.
^ permalink raw reply
* linux-next: Tree for November 25
From: Stephen Rothwell @ 2008-11-25 10:37 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 7615 bytes --]
Hi all,
Changes since 20081124:
Undropped trees:
net
userns
Dropped trees (temporarily):
ftrace (build problems)
v4l-dvb (build problem)
kbuild (build problem)
rr (build problem)
ttydev (build problem)
semaphore-removal (due to unfixed conflicts against Linus' tree)
cpu_alloc (build problem)
The 4xx tree gained a conflict against the powerpc-merge tree.
The ftrace tree lost a conflict, but gained 2 build problems (and lots of
warnings) and was dropped.
The v4l-dvb tree gained a build problem and was dropped.
The kbuild tree gained a build problem and was dropped.
The kvm tree gained a conflict against the x86 tree.
The ocfs2 tree gained a header check problem.
The rr tree gained 2 build problems and was dropped.
The firmware tree gained a conflict against the net tree.
The kmemcheck tree lost a conflict.
The security-testing tree gained a conflict against the nfsd tree.
The cputime tree gained a conflict against the tip-core tree.
The perfmon3 tree gained 2 conflicts against the x86 tree.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig,
44x_defconfig and allyesconfig and i386, sparc and sparc64 defconfig.
Below is a summary of the state of the merge.
We are up to 126 trees (counting Linus' and 15 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-2.6.26
Merging dwmw2/master
Merging arm/devel
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
CONFLICT (content): Merge conflict in arch/powerpc/configs/ppc44x_defconfig
Merging galak/next
Merging pxa/for-next
Merging s390/features
CONFLICT (content): Merge conflict in drivers/char/Makefile
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
Merging xtensa/master
Merging quilt/driver-core
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
Merging ftrace/auto-ftrace-next
CONFLICT (content): Merge conflict in scripts/recordmcount.pl
$ git reset --hard HEAD^
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging pci/linux-next
Merging quilt/device-mapper
Merging hid/mm
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
$ git reset --hard HEAD^
Merging jfs/next
Merging kbuild/master
$ git reset --hard HEAD^
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
CONFLICT (content): Merge conflict in arch/x86/kernel/reboot.c
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
Applying ocfs2: temporary includes fix
Merging ext4/next
Merging async_tx/next
Merging udf/for_next
Merging net/master
Applying net: async_tx merge fix
Merging mtd/master
Merging wireless/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
Merging cpufreq/next
Merging v9fs/for-next
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/x86/kernel/io_apic.c
CONFLICT (content): Merge conflict in arch/x86/kernel/setup.c
CONFLICT (content): Merge conflict in kernel/irq/manage.c
CONFLICT (content): Merge conflict in kernel/irq/proc.c
$ git reset --hard HEAD^
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging semaphore/semaphore
Merging bkl-removal/bkl-removal
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in drivers/net/tg3.c
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in mm/slab.c
CONFLICT (content): Merge conflict in mm/slub.c
Merging generic-ipi/auto-generic-ipi-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
CONFLICT (content): Merge conflict in fs/nfsd/nfs4recover.c
CONFLICT (content): Merge conflict in fs/ocfs2/namei.c
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_cred.h
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_globals.h
CONFLICT (content): Merge conflict in fs/xfs/xfs_vnodeops.h
Merging lblnet/master
Merging agp/agp-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
Merging iommu/auto-iommu-next
Merging uwb/for-upstream
Merging watchdog/master
Merging proc/proc
CONFLICT (content): Merge conflict in fs/proc/base.c
CONFLICT (content): Merge conflict in kernel/exit.c
Merging bdev/master
Merging dwmw2-iommu/master
Merging userns/next
Merging cputime/cputime
CONFLICT (content): Merge conflict in kernel/sched.c
Merging perfmon3/master
CONFLICT (content): Merge conflict in arch/x86/kernel/entry_64.S
CONFLICT (content): Merge conflict in arch/x86/kernel/signal_32.c
Merging osd/linux-next
Merging fatfs/master
Merging quilt/staging
Merging scsi-post-merge/master
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the cputime tree
From: Martin Schwidefsky @ 2008-11-25 11:00 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Stephen Rothwell, linux-next, Oleg Nesterov, Ingo Molnar
In-Reply-To: <1227608880.4259.1451.camel@twins>
On Tue, 2008-11-25 at 11:28 +0100, Peter Zijlstra wrote:
> On Tue, 2008-11-25 at 11:15 +0100, Martin Schwidefsky wrote:
> > On Tue, 2008-11-25 at 11:06 +0100, Peter Zijlstra wrote:
> > > Why does s390 do its own cpu accounting?
> >
> > Is that a trick question? I invented the cputime accounting specifically
> > for s390 because it is a virtual architecture and the standard cpu
> > accounting numbers are just useless.
>
> Nah, just general ignorance brought on by the mondays on a tuesday ;-)
Ah, I usually have this on mondays ..
> Right, makes sense, is it shared with all other virt* folks out there?
Yes, the other virtual architectures have started to use the interface
as well.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: linux-next: manual merge of the security-testing tree
From: David Howells @ 2008-11-25 11:04 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: dhowells, James Morris, linux-next, J. Bruce Fields
In-Reply-To: <20081125191137.d5474c9e.sfr@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next merge of the security-testing tree got a conflict in
> fs/nfsd/nfs4recover.c between commit
> e4625eb826de4f6774ee602c442ba23b686bdcc7 ("nfsd: use of unitialized list
> head on error exit in nfs4recover.c") from the nfsd tree and commit
> d84f4f992cbd76e8f39c488cf0c5d123843923b1 ("CRED: Inaugurate COW
> credentials") from the security-testing tree.
>
> Just a context change. I fixed it up (see below) and can carry the fix as
> necessary.
That looks okay.
^ permalink raw reply
* Re: linux-next: manual merge of the perfmon3 tree
From: Alexander van Heukelum @ 2008-11-25 10:39 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: stephane eranian, linux-next, Ingo Molnar
In-Reply-To: <20081125210319.35b2d189.sfr@canb.auug.org.au>
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)
> [...]
^ permalink raw reply
* Re: linux-next: rr tree build failure
From: Rusty Russell @ 2008-11-25 11:47 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Mike Travis, Christian Borntraeger
In-Reply-To: <20081125174554.dbd84cde.sfr@canb.auug.org.au>
On Tuesday 25 November 2008 17:15:54 Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> arch/powerpc/sysdev/mpic.c:809: error: conflicting types for
> 'mpic_set_affinity' arch/powerpc/sysdev/mpic.h:39: error: previous
> declaration of 'mpic_set_affinity' was here
Thanks, fixed. Grepping found some more sparc ones, too.
> The declaration in the header file was missed.
>
> Also, the x86_64 allmodconfig build failed like this:
>
> ERROR: "hvc_resize" [drivers/char/virtio_console.ko] undefined!
>
> hvc_resize is currently not exported to modules.
>
> I have dropped the rr tree again.
OK, I've dropped Christian's patch for the moment until he fixes this. I'm
travelling to Sydney for the day so I won't get a chance to fix this if it
breaks tomorrow :(
Rusty.
^ permalink raw reply
* [PATCH] tracing, tty: fix warnings caused by branch tracing and tty_kref_get()
From: Ingo Molnar @ 2008-11-25 12:19 UTC (permalink / raw)
To: Alan Cox
Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, linux-next,
Steven Rostedt, Alan Cox
In-Reply-To: <20081125102515.54282c0d@lxorguk.ukuu.org.uk>
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Tue, 25 Nov 2008 13:38:28 +1100
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi all,
> >
> > Today's linux-next build (x86_64 allmodconfig) produced lots of these
> > warnings:
> >
> > include/linux/tty.h:330: warning: '______f' is static but declared in inline function 'tty_kref_get' which is not static
> >
> > Caused by commit 2bcd521a684cc94befbe2ce7d5b613c841b0d304 ("trace:
> > profile all if conditionals"). Something needs to be done about
> > this ... maybe tty_kref_get needs to be "static inline" instead of
> > "extern inline"?
>
> If someone from the ftrace crew can sort the problem out and send me
> a diff for the ttydev tree that shouldn't be a problem, but really
> it looks like a problem with ftrace as that can't be the only case
> this happens surely ?
i've done quite wide build testing of it and tty.h seems to be the
only affected file triggering a warning due to this. ('extern inline'
has been eliminated from most of the kernel in recent cycles)
Ingo
---------------->
From 14bfc987e395797dfe03e915e8b4c7fc9e5078e4 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Tue, 25 Nov 2008 08:58:11 +0100
Subject: [PATCH] tracing, tty: fix warnings caused by branch tracing and tty_kref_get()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Stephen Rothwell reported tht this warning started triggering in
linux-next:
In file included from init/main.c:27:
include/linux/tty.h: In function ‘tty_kref_get’:
include/linux/tty.h:330: warning: ‘______f’ is static but declared in inline function ‘tty_kref_get’ which is not static
Which gcc emits for 'extern inline' functions that nevertheless define
static variables. Change it to 'static inline', which is the norm
in the kernel anyway.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
include/linux/tty.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 3b8121d..eaec37c 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -325,7 +325,7 @@ extern struct class *tty_class;
* go away
*/
-extern inline struct tty_struct *tty_kref_get(struct tty_struct *tty)
+static inline struct tty_struct *tty_kref_get(struct tty_struct *tty)
{
if (tty)
kref_get(&tty->kref);
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox