1. 18 Jun, 2008 11 commits
  2. 12 Jun, 2008 25 commits
    • Dave Airlie's avatar
    • Johannes Weiner's avatar
      drm: use drms ioctl cmd not what we get passed from userspace. · 41ee2ff4
      Johannes Weiner authored
      
      
      This enforces us to use the drm ioctl types so read/write works correctly and not believe
      what userspace tells us.
      
      It does this hopefully without breaking the drm api.
      
      Fixes bug from thread: BUG: unable to handle kernel NULL pointer dereference (drm_getunique)
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      41ee2ff4
    • Linus Torvalds's avatar
      Linux 2.6.26-rc6 · 5dd34572
      Linus Torvalds authored
      .. and a new name, courtesy of Alan.
      5dd34572
    • Linus Torvalds's avatar
      Merge branch 'x86-fixes-for-linus' of... · cbfa66b8
      Linus Torvalds authored
      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
    • Linus Torvalds's avatar
      Merge branch 'sched-fixes-for-linus' of... · 1b3cba8e
      Linus Torvalds authored
      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
    • Kevin Winchester's avatar
      x86: fix pointer type warning in arch/x86/mm/init_64.c:early_memtest · f8a45704
      Kevin Winchester authored
      
      
      Changed the call to find_e820_area_size to pass u64 instead of unsigned long.
      Signed-off-by: default avatarKevin Winchester <kjwinchester@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      f8a45704
    • Vegard Nossum's avatar
      x86, lockdep: fix "WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x128()" · 4461145e
      Vegard Nossum authored
      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: default avatarAlessandro Suardi <alessandro.suardi@gmail.com>
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4461145e
    • David Howells's avatar
      x86: fix an incompatible pointer type warning on 64-bit compilations · eb53e9f3
      David Howells authored
      
      
      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: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      eb53e9f3
    • Peter Zijlstra's avatar
      x86: fix lockdep warning during suspend-to-ram · e32e58a9
      Peter Zijlstra authored
      
      
      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: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e32e58a9
    • Manish Katiyar's avatar
      x86: fix unused variable 'loops' warning in arch/x86/boot/a20.c · 52aaa12f
      Manish Katiyar authored
      
      
      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: default avatarIngo Molnar <mingo@elte.hu>
      52aaa12f
    • Ingo Molnar's avatar
      Revert "x86: fix ioapic bug again" · 0b6a39f7
      Ingo Molnar authored
      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: default avatarNémeth Márton <nm127@freemail.hu>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      0b6a39f7
    • Joe Korty's avatar
      x86: fix asm warning in head_32.S · 86b2b70e
      Joe Korty authored
      
      
      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: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      86b2b70e
    • Henry Nestler's avatar
      x86: fix endless page faults in mount_block_root for Linux 2.6 · b29c701d
      Henry Nestler authored
      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: default avatarHenry Nestler <henry.nestler@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      b29c701d
    • Ingo Molnar's avatar
      geode: fix modular build · 3703f399
      Ingo Molnar authored
      -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: default avatarIngo Molnar <mingo@elte.hu>
      3703f399
    • Carl Henrik Lunde's avatar
      block: disable IRQs until data is written to relay channel · 14a73f54
      Carl Henrik Lunde authored
      
      
      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: default avatarCarl Henrik Lunde <chlunde@ping.uio.no>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      14a73f54
    • Linus Torvalds's avatar
      95dcf835
    • Paul Mundt's avatar
      nommu: Correct kobjsize() page validity checks. · 5a1603be
      Paul Mundt authored
      This implements a few changes on top of the recent kobjsize() refactoring
      introduced by commit 6cfd53fc.
      
      As Christoph points out:
      
      	virt_to_head_page cannot return NULL. virt_to_page also
      	does not return NULL. pfn_valid() needs to be used to
      	figure out if a page is valid.  Otherwise the page struct
      	reference that was returned may have PageReserved() set
      	to indicate that it is not a valid page.
      
      As discussed further in the thread, virt_addr_valid() is the preferable
      way to validate the object pointer in this case. In addition to fixing
      up the reserved page case, it also has the benefit of encapsulating the
      hack introduced by commit 4016a139
      
       on
      the impacted platforms, allowing us to get rid of the extra checking in
      kobjsize() for the platforms that don't perform this type of bizarre
      memory_end abuse (every nommu platform that isn't blackfin). If blackfin
      decides to get in line with every other platform and use PageReserved
      for the DMA pages in question, kobjsize() will also continue to work
      fine.
      
      It also turns out that compound_order() will give us back 0-order for
      non-head pages, so we can get rid of the PageCompound check and just
      use compound_order() directly. Clean that up while we're at it.
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Reviewed-by: default avatarChristoph Lameter <clameter@sgi.com>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5a1603be
    • Jeff Mahoney's avatar
      fsl-diu-db: compile fix · f969c567
      Jeff Mahoney authored
      
      
      This patch fixes a compile failure in 2.6.26-rc5-git5.
      
      The variable is expected to be called ofdev.
      Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f969c567
    • Linus Torvalds's avatar
      Merge branch 'core/iter-div' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip · dc10885d
      Linus Torvalds authored
      * 'core/iter-div' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        always_inline timespec_add_ns
        add an inlined version of iter_div_u64_rem
        common implementation of iterative div/mod
      dc10885d
    • Sam Ravnborg's avatar
      kbuild: ignore powerpc specific symbols in modpost · 4d7365d6
      Sam Ravnborg authored
      
      
      Kumar Gala <galak@kernel.crashing.org> wrote:
      We have a case in powerpc in which we want to link some library
      routines with all module objects.  The routines are intended for
      handling out-of-line function call register save/restore so having
      them as EXPORT_SYMBOL() is counter productive (we do also need to
      link the same "library" code into the kernel).
      
      Without this patch a powerpc build would error out and fail
      to build modules with the added register save/restore module.
      
      There were two obvious solutions:
      1) To link the .o file before the modpost stage
      2) To ignore the symbols in modpost
      
      Option 1) was ruled out because we do not have any separate
      linking stage for single file modules.
      
      This patch implements option 2 - and do so only for powerpc.
      
      The symbols we ignore are all undefined symbols named:
      _restgpr_*, _savegpr_*, _rest32gpr_*, _save32gpr_*
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: Kumar Gala <galak@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      4d7365d6
    • Lai Jiangshan's avatar
      sched: 64-bit: fix arithmetics overflow · 7a232e03
      Lai Jiangshan authored
      
      
      (overflow means weight >= 2^32 here, because inv_weigh = 2^32/weight)
      
      A weight of a cfs_rq is the sum of weights of which entities
      are queued on this cfs_rq, so it will overflow when there are
      too many entities.
      
      Although, overflow occurs very rarely, but it break fairness when
      it occurs. 64-bits systems have more memory than 32-bit systems
      and 64-bit systems can create more process usually, so overflow may
      occur more frequently.
      
      This patch guarantees fairness when overflow happens on 64-bit systems.
      Thanks to the optimization of compiler, it changes nothing on 32-bit.
      Signed-off-by: default avatarLai Jiangshan <laijs@cn.fujitsu.com>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7a232e03
    • Lai Jiangshan's avatar
      sched: fair group: fix overflow(was: fix divide by zero) · 2e084786
      Lai Jiangshan authored
      
      
      I found a bug which can be reproduced by this way:(linux-2.6.26-rc5, x86-64)
      (use 2^32, 2^33, ...., 2^63 as shares value)
      
      # mkdir /dev/cpuctl
      # mount -t cgroup -o cpu cpuctl /dev/cpuctl
      # cd /dev/cpuctl
      # mkdir sub
      # echo 0x8000000000000000 > sub/cpu.shares
      # echo $$ > sub/tasks
      oops here! divide by zero.
      
      This is because do_div() expects the 2th parameter to be 32 bits,
      but unsigned long is 64 bits in x86_64.
      
      Peter Zijstra pointed it out that the sane thing to do is limit the
      shares value to something smaller instead of using an even more
      expensive divide.
      
      Also, I found another bug about "the shares value is too large":
      
      pid1 and pid2 are set affinity to cpu#0
      pid1 is attached to cg1 and pid2 is attached to cg2
      
      if cg1/cpu.shares = 1024 cg2/cpu.shares = 2000000000
      then pid2 got 100% usage of cpu, and pid1 0%
      
      if cg1/cpu.shares = 1024 cg2/cpu.shares = 20000000000
      then pid2 got 0% usage of cpu, and pid1 100%
      
      And a weight of a cfs_rq is the sum of weights of which entities
      are queued on this cfs_rq, so the shares value should be limited
      to a smaller value.
      
      I think that (1UL << 18) is a good limited value:
      
      1) it's not too large, we can create a lot of group before overflow
      2) it's several times the weight value for nice=-19 (not too small)
      Signed-off-by: default avatarLai Jiangshan <laijs@cn.fujitsu.com>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      2e084786
    • Jeremy Fitzhardinge's avatar
      always_inline timespec_add_ns · 9412e286
      Jeremy Fitzhardinge authored
      
      
      timespec_add_ns is used from the x86-64 vdso, which cannot call out to
      other kernel code.  Make sure that timespec_add_ns is always inlined
      (and only uses always_inlined functions) to make sure there are no
      unexpected calls.
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9412e286
    • Jeremy Fitzhardinge's avatar
      add an inlined version of iter_div_u64_rem · d5e181f7
      Jeremy Fitzhardinge authored
      
      
      iter_div_u64_rem is used in the x86-64 vdso, which cannot call other
      kernel code.  For this case, provide the always_inlined version,
      __iter_div_u64_rem.
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d5e181f7
    • Jeremy Fitzhardinge's avatar
      common implementation of iterative div/mod · f595ec96
      Jeremy Fitzhardinge authored
      
      
      We have a few instances of the open-coded iterative div/mod loop, used
      when we don't expcet the dividend to be much bigger than the divisor.
      Unfortunately modern gcc's have the tendency to strength "reduce" this
      into a full mod operation, which isn't necessarily any faster, and
      even if it were, doesn't exist if gcc implements it in libgcc.
      
      The workaround is to put a dummy asm statement in the loop to prevent
      gcc from performing the transformation.
      
      This patch creates a single implementation of this loop, and uses it
      to replace the open-coded versions I know about.
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: john stultz <johnstul@us.ibm.com>
      Cc: Segher Boessenkool <segher@kernel.crashing.org>
      Cc: Christian Kujau <lists@nerdbynature.de>
      Cc: Robert Hancock <hancockr@shaw.ca>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      f595ec96
  3. 11 Jun, 2008 4 commits