1. 13 6月, 2008 16 次提交
    • K
      parisc: export copy_user_page_asm · db51d92b
      Kyle McMartin 提交于
      Needed by fuse (via copy_highpage).
      Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
      db51d92b
    • K
      parisc: move head.S to head.text section · 1138a72c
      Kyle McMartin 提交于
      And explicitly list it in vmlinux.lds...
      Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
      1138a72c
    • K
      Revert "parisc: fix trivial section name warnings" · dfcf753b
      Kyle McMartin 提交于
      This reverts commit bd3bb8c1.
      Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
      dfcf753b
    • L
      Linux 2.6.26-rc6 · 5dd34572
      Linus Torvalds 提交于
      .. and a new name, courtesy of Alan.
      5dd34572
    • L
      Merge branch 'x86-fixes-for-linus' of... · cbfa66b8
      Linus Torvalds 提交于
      Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        x86: fix pointer type warning in arch/x86/mm/init_64.c:early_memtest
        x86, lockdep: fix "WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x128()"
        x86: fix an incompatible pointer type warning on 64-bit compilations
        x86: fix lockdep warning during suspend-to-ram
        x86: fix unused variable 'loops' warning in arch/x86/boot/a20.c
        Revert "x86: fix ioapic bug again"
        x86: fix asm warning in head_32.S
        x86: fix endless page faults in mount_block_root for Linux 2.6
        geode: fix modular build
      cbfa66b8
    • L
      Merge branch 'sched-fixes-for-linus' of... · 1b3cba8e
      Linus Torvalds 提交于
      Merge branch 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        sched: 64-bit: fix arithmetics overflow
        sched: fair group: fix overflow(was: fix divide by zero)
        sched: fix TASK_WAKEKILL vs SIGKILL race
      1b3cba8e
    • K
      x86: fix pointer type warning in arch/x86/mm/init_64.c:early_memtest · f8a45704
      Kevin Winchester 提交于
      Changed the call to find_e820_area_size to pass u64 instead of unsigned long.
      Signed-off-by: NKevin Winchester <kjwinchester@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f8a45704
    • V
      x86, lockdep: fix "WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x128()" · 4461145e
      Vegard Nossum 提交于
      Alessandro Suardi reported:
      > Recently upgraded my FC6 desktop to Fedora 9; with the
      >  latest nautilus RPM updates my VNC session went nuts
      >  with nautilus pegging the CPU for everything that breathed.
      >
      > I now reverted to an earlier nautilus package, but during
      >  the peak CPU period my kernel spat this:
      >
      > [314185.623294] ------------[ cut here ]------------
      > [314185.623414] WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x128()
      > [314185.623514] Modules linked in: iptable_filter ip_tables x_tables
      > sunrpc ipv6 fuse snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart
      > snd_rawmidi via686a hwmon parport_pc sg parport uhci_hcd ehci_hcd
      > [314185.623924] Pid: 12314, comm: nautilus Not tainted 2.6.26-rc5-git2 #4
      > [314185.624021]  [<c0115b95>] warn_on_slowpath+0x41/0x7b
      > [314185.624021]  [<c010de70>] ? do_page_fault+0x2c1/0x5fd
      > [314185.624021]  [<c0128396>] ? up_read+0x16/0x28
      > [314185.624021]  [<c010de70>] ? do_page_fault+0x2c1/0x5fd
      > [314185.624021]  [<c012fa33>] ? __lock_acquire+0xbb4/0xbc3
      > [314185.624021]  [<c012d0a0>] check_flags+0x4c/0x128
      > [314185.624021]  [<c012fa73>] lock_acquire+0x31/0x7d
      > [314185.624021]  [<c0128cf6>] __atomic_notifier_call_chain+0x30/0x80
      > [314185.624021]  [<c0128cc6>] ? __atomic_notifier_call_chain+0x0/0x80
      > [314185.624021]  [<c0128d52>] atomic_notifier_call_chain+0xc/0xe
      > [314185.624021]  [<c0128d81>] notify_die+0x2d/0x2f
      > [314185.624021]  [<c01043b0>] do_int3+0x1f/0x4d
      > [314185.624021]  [<c02f2d3b>] int3+0x27/0x2c
      > [314185.624021]  =======================
      > [314185.624021] ---[ end trace 1923f65a2d7bb246 ]---
      > [314185.624021] possible reason: unannotated irqs-off.
      > [314185.624021] irq event stamp: 488879
      > [314185.624021] hardirqs last  enabled at (488879): [<c0102d67>]
      > restore_nocheck+0x12/0x15
      > [314185.624021] hardirqs last disabled at (488878): [<c0102dca>]
      > work_resched+0x19/0x30
      > [314185.624021] softirqs last  enabled at (488876): [<c011a1ba>]
      > __do_softirq+0xa6/0xac
      > [314185.624021] softirqs last disabled at (488865): [<c010476e>]
      > do_softirq+0x57/0xa6
      >
      > I didn't seem to find it with some googling, so here it is.
      >
      > I was incidentally ltracing that process to try and find out
      >  what was gulping down that much CPU (sorry, no idea
      >  whether ltrace and the WARNING happened at the same
      >  time or which came first) and:
      
      Yeah, this is extremely likely to be the source of the warning.
      
      The warning should be harmless, however.
      
      > Box is my trusty noname K7-800, 512MB RAM; if there's
      >  anything else useful I might be able to provide, just ask.
      
      It would be interesting to see where the int3 comes from.  Too bad,
      lockdep doesn't provide the register dump. The stacktrace also doesn't
      go further than the int3(), I wonder if this int3 came from userspace?
      The ltrace readme says "software breakpoints, like gdb", so I guess
      this is the case. Yep, seems like it.
      
      This looks relevant:
      
      | commit fb1dac90
      | Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
      | Date:   Wed Jan 16 09:51:59 2008 +0100
      |
      |     lockdep: more hardirq annotations for notify_die()
      
      I'm attaching a similarly-looking patch for this case (DO_VM86_ERROR),
      though I suspect it might be missing for the other cases
      (DO_ERROR/DO_ERROR_INFO) as well.
      Reported-by: NAlessandro Suardi <alessandro.suardi@gmail.com>
      Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4461145e
    • D
      x86: fix an incompatible pointer type warning on 64-bit compilations · eb53e9f3
      David Howells 提交于
      Fix an incompatible pointer type warning on x86_64 compilations.
      early_memtest() is passing a u64* to find_e820_area_size() which is expecting
      an unsigned long.  Change t_start and t_size to unsigned long as those are
      also 64-bit types on x88_64.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      eb53e9f3
    • P
      x86: fix lockdep warning during suspend-to-ram · e32e58a9
      Peter Zijlstra 提交于
      Andrew Morton wrote:
      
      > I've been seeing the below for a long time during suspend-to-ram on the Vaio.
      >
      >
      > PM: Syncing filesystems ... done.
      > PM: Preparing system for mem sleep
      > Freezing user space processes ... <4>------------[ cut here ]------------
      > WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x127()
      > Modules linked in: i915 drm ipw2200 sonypi ipv6 autofs4 hidp l2cap bluetooth sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables acpi_cpufreq nvram ohci1394 ieee1394 ehci_hcd uhci_hcd sg joydev snd_hda_intel snd_seq_dummy sr_mod snd_seq_oss cdrom snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ieee80211 pcspkr ieee80211_crypt snd_pcm i2c_i801 snd_timer i2c_core ide_pci_generic piix snd soundcore snd_page_alloc button ext3 jbd ide_disk ide_core [last unloaded: ipw2200]
      > Pid: 3250, comm: zsh Not tainted 2.6.26-rc5 #1
      >  [<c011c5f5>] warn_on_slowpath+0x41/0x6d
      >  [<c01080e6>] ? native_sched_clock+0x82/0x96
      >  [<c013789c>] ? mark_held_locks+0x41/0x5c
      >  [<c0315688>] ? _spin_unlock_irqrestore+0x36/0x58
      >  [<c0137a29>] ? trace_hardirqs_on+0xe6/0x10d
      >  [<c0138637>] ? __lock_acquire+0xae3/0xb2b
      >  [<c0313413>] ? schedule+0x39b/0x3b4
      >  [<c0135596>] check_flags+0x4c/0x127
      >  [<c01386b9>] lock_acquire+0x3a/0x86
      >  [<c0315075>] _spin_lock+0x26/0x53
      >  [<c0140660>] ? refrigerator+0x13/0xc3
      >  [<c0140660>] refrigerator+0x13/0xc3
      >  [<c012684a>] get_signal_to_deliver+0x3c/0x31e
      >  [<c0102fe7>] do_notify_resume+0x91/0x6ee
      >  [<c01359fd>] ? lock_release_holdtime+0x50/0x56
      >  [<c0315688>] ? _spin_unlock_irqrestore+0x36/0x58
      >  [<c0235d24>] ? read_chan+0x0/0x58c
      >  [<c0137a29>] ? trace_hardirqs_on+0xe6/0x10d
      >  [<c0315694>] ? _spin_unlock_irqrestore+0x42/0x58
      >  [<c0230afa>] ? tty_ldisc_deref+0x5c/0x63
      >  [<c0233104>] ? tty_read+0x66/0x98
      >  [<c014b3f0>] ? audit_syscall_exit+0x2aa/0x2c5
      >  [<c0109430>] ? do_syscall_trace+0x6b/0x16f
      >  [<c0103a9c>] work_notifysig+0x13/0x1b
      >  =======================
      > ---[ end trace 25b49fe59a25afa5 ]---
      > possible reason: unannotated irqs-off.
      > irq event stamp: 58919
      > hardirqs last  enabled at (58919): [<c0103afd>] syscall_exit_work+0x11/0x26
      
      Joy - I so love entry.S
      
      Best I can make of it:
      
      syscall_exit_work
        resume_userspace
          DISABLE_INTERRUPTS
          (no TRACE_IRQS_OFF)
            work_pending
              work_notifysig
                do_notify_resume()
                  do_signal()
                    get_signal_to_deliver()
                      try_to_freeze()
                        refrigerator()
                          task_lock() -> check_flags() -> BANG
      
      The normal path is:
      
      syscall_exit_work
        resume_userspace
          DISABLE_INTERRUPTS
          restore_all
            TRACE_IRQS_IRET
            iret
      
      No idea why that would not warn..
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e32e58a9
    • M
      x86: fix unused variable 'loops' warning in arch/x86/boot/a20.c · 52aaa12f
      Manish Katiyar 提交于
      Following patch fixes the below warning message :
      arch/x86/boot/a20.c:118: warning: unused variable 'loops'
      
      Signed-off-by : Manish Katiyar <mkatiyar@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      52aaa12f
    • I
      Revert "x86: fix ioapic bug again" · 0b6a39f7
      Ingo Molnar 提交于
      This reverts commit 6e908947.
      
      Németh Márton reported:
      
      | there is a problem in 2.6.26-rc3 which was not there in case of
      | 2.6.25: the CPU wakes up ~90,000 times per sec instead of ~60 per sec.
      |
      | I also "git bisected" the problem, the result is:
      |
      | 6e908947 is first bad commit
      | commit 6e908947
      | Author: Ingo Molnar <mingo@elte.hu>
      | Date:   Fri Mar 21 14:32:36 2008 +0100
      |
      |     x86: fix ioapic bug again
      
      the original problem is fixed by Maciej W. Rozycki in the tip/x86/apic
      branch (confirmed by Márton), but those changes are too intrusive for
      v2.6.26 so we'll go for the less intrusive (repeated) revert now.
      Reported-and-bisected-by: NNémeth Márton <nm127@freemail.hu>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0b6a39f7
    • J
      x86: fix asm warning in head_32.S · 86b2b70e
      Joe Korty 提交于
      On Mon, May 19, 2008 at 04:10:02PM -0700, Linus Torvalds wrote:
      > It also causes these warnings on 32-bit PAE:
      >
      > 	  AS      arch/x86/kernel/head_32.o
      > 	arch/x86/kernel/head_32.S: Assembler messages:
      > 	arch/x86/kernel/head_32.S:225: Warning: left operand is a bignum; integer 0 assumed
      > 	arch/x86/kernel/head_32.S:609: Warning: left operand is a bignum; integer 0 assumed
      >
      > and I do not see why (the end result seems to be identical).
      
      Fix head_32.S gcc bignum warnings when CONFIG_PAE=y.
      
          arch/x86/kernel/head_32.S: Assembler messages:
          arch/x86/kernel/head_32.S:225: Warning: left operand is a bignum; integer 0 assumed
          arch/x86/kernel/head_32.S:609: Warning: left operand is a bignum; integer 0 assumed
      
      The assembler was stumbling over the 64-bit constant 0x100000000 in the
      KPMDS #define.
      
      Testing: a cmp(1) on head_32.o before and after shows the binary is unchanged.
      
      Signed-off-by: Joe Korty <joe.korty@ccur.com
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Theodore Tso <tytso@mit.edu>
      Cc: Gabriel C <nix.or.die@googlemail.com>
      Cc: Keith Packard <keithp@keithp.com>
      Cc: "Pallipadi Venkatesh" <venkatesh.pallipadi@intel.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: "Siddha Suresh B" <suresh.b.siddha@intel.com>
      Cc: bugme-daemon@bugzilla.kernel.org
      Cc: airlied@linux.ie
      Cc: "Barnes Jesse" <jesse.barnes@intel.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      86b2b70e
    • H
      x86: fix endless page faults in mount_block_root for Linux 2.6 · b29c701d
      Henry Nestler 提交于
      Page faults in kernel address space between PAGE_OFFSET up to
      VMALLOC_START should not try to map as vmalloc.
      
      Fix rarely endless page faults inside mount_block_root for root
      filesystem at boot time.
      
      All 32bit kernels up to 2.6.25 can fail into this hole.
      I can not present this under native linux kernel. I see, that the 64bit
      has fixed the problem. I copied the same lines into 32bit part.
      
      Recorded debugs are from coLinux kernel 2.6.22.18 (virtualisation):
      http://www.henrynestler.com/colinux/testing/pfn-check-0.7.3/20080410-antinx/bug16-recursive-page-fault-endless.txt
      The physicaly memory was trimmed down to 192MB to better catch the bug.
      More memory gets the bug more rarely.
      
      Details, how every x86 32bit system can fail:
      
      Start from "mount_block_root",
      http://lxr.linux.no/linux/init/do_mounts.c#L297
      There the variable "fs_names" got one memory page with 4096 bytes.
      Variable "p" walks through the existing file system types. The first
      string is no problem.
      But, with the second loop in mount_block_root the offset of "p" is not
      at beginning of page, the offset is for example +9, if "reiserfs" is the
      first in list.
      Than calls do_mount_root, and lands in sys_mount.
      Remember: Variable "type_page" contains now "fs_type+9" and not contains
      a full page.
      The sys_mount copies 4096 bytes with function "exact_copy_from_user()":
      http://lxr.linux.no/linux/fs/namespace.c#L1540
      
      Mostly exist pages after the buffer "fs_names+4096+9" and the page fault
      handler was not called. No problem.
      
      In the case, if the page after "fs_names+4096" is not mapped, the page
      fault handler was called from http://lxr.linux.no/linux/fs/namespace.c#L1320
      
      The do_page_fault gots an address 0xc03b4000.
      It's kernel address, address >= TASK_SIZE, but not from vmalloc! It's
      from "__getname()" alias "kmem_cache_alloc".
      The "error_code" is 0. "vmalloc_fault" will be call:
      http://lxr.linux.no/linux/arch/i386/mm/fault.c#L332
      
      "vmalloc_fault" tryed to find the physical page for a non existing
      virtual memory area. The macro "pte_present" in vmalloc_fault()
      got a next page fault for 0xc0000ed0 at:
      http://lxr.linux.no/linux/arch/i386/mm/fault.c#L282
      
      No PTE exist for such virtual address. The page fault handler was trying
      to sync the physical page for the PTE lockup.
      
      This called vmalloc_fault() again for address 0xc000000, and that also
      was not existing. The endless began...
      
      In normal case the cpu would still loop with disabled interrrupts. Under
      coLinux this was catched by a stack overflow inside printk debugs.
      Signed-off-by: NHenry Nestler <henry.nestler@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      b29c701d
    • I
      geode: fix modular build · 3703f399
      Ingo Molnar 提交于
      -tip testing found this build bug:
      
       MODPOST 331 modules
       ERROR: "geode_mfgpt_toggle_event" [drivers/watchdog/geodewdt.ko] undefined!
       ERROR: "geode_mfgpt_alloc_timer" [drivers/watchdog/geodewdt.ko] undefined!
       make[1]: *** [__modpost] Error 1
       make: *** [modules] Error 2
      
      with this config:
      
        http://redhat.com/~mingo/misc/config-Wed_Jun__4_18_01_59_CEST_2008.bad
      
      export those symbols.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3703f399
    • C
      block: disable IRQs until data is written to relay channel · 14a73f54
      Carl Henrik Lunde 提交于
      As we may run relay_reserve from interrupt context we must always disable
      IRQs.  This is because a call to relay_reserve may expose previously written
      data to use space.
      
      Updated new message code and an old but related comment.
      Signed-off-by: NCarl Henrik Lunde <chlunde@ping.uio.no>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      14a73f54
  2. 12 6月, 2008 24 次提交