1. 14 Jul, 2008 7 commits
  2. 13 Jul, 2008 14 commits
    • Linus Torvalds's avatar
      Linux 2.6.26 · bce7f793
      Linus Torvalds authored
      bce7f793
    • Li Zefan's avatar
      devcgroup: fix permission check when adding entry to child cgroup · ec229e83
      Li Zefan authored
       # cat devices.list
       c 1:3 r
       # echo 'c 1:3 w' > sub/devices.allow
       # cat sub/devices.list
       c 1:3 w
      
      As illustrated, the parent group has no write permission to /dev/null, so
      it's child should not be allowed to add this write permission.
      Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Cc: Serge Hallyn <serue@us.ibm.com>
      Cc: Paul Menage <menage@google.com>
      Cc: Pavel Emelyanov <xemul@openvz.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ec229e83
    • Li Zefan's avatar
      devcgroup: always show positive major/minor num · 17d213f8
      Li Zefan authored
       # echo "b $((0x7fffffff)):$((0x80000000)) rwm" > devices.allow
       # cat devices.list
       b 214748364:-21474836 rwm
      
      though a major/minor number of 0x800000000 is meaningless, we
      should not cast it to a negative value.
      Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Cc: Serge Hallyn <serue@us.ibm.com>
      Cc: Paul Menage <menage@google.com>
      Cc: Pavel Emelyanov <xemul@openvz.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      17d213f8
    • Jiri Pirko's avatar
      Documentation/HOWTO: correct wrong kernel bugzilla FAQ URL · 0302c01b
      Jiri Pirko authored
      Signed-off-by: default avatarJiri Pirko <jpirko@redhat.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0302c01b
    • Linus Torvalds's avatar
      Merge branch 'sched-fixes-for-linus' of... · 3b5c6b83
      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:
        cpusets, hotplug, scheduler: fix scheduler domain breakage
      3b5c6b83
    • Mike Travis's avatar
      x86: change _node_to_cpumask_ptr to return const ptr · 11369f35
      Mike Travis authored
        * Strengthen the return type for the _node_to_cpumask_ptr to be
          a const pointer.  This adds compiler checking to insure that
          node_to_cpumask_map[] is not changed inadvertently.
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Acked-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      11369f35
    • Maciej W. Rozycki's avatar
      x86: I/O APIC: remove an IRQ2-mask hack · ce8b06b9
      Maciej W. Rozycki authored
      Now that IRQ2 is never made available to the I/O APIC, there is no need
      to special-case it and mask as a workaround for broken systems.  Actually,
      because of the former, mask_IO_APIC_irq(2) is a no-op already.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ce8b06b9
    • Dmitry Adamushko's avatar
      cpusets, hotplug, scheduler: fix scheduler domain breakage · 3e84050c
      Dmitry Adamushko authored
      Commit f18f982a ("sched: CPU hotplug events must not destroy scheduler
      domains created by the cpusets") introduced a hotplug-related problem as
      described below:
      
      Upon CPU_DOWN_PREPARE,
      
        update_sched_domains() -> detach_destroy_domains(&cpu_online_map)
      
      does the following:
      
      /*
       * Force a reinitialization of the sched domains hierarchy. The domains
       * and groups cannot be updated in place without racing with the balancing
       * code, so we temporarily attach all running cpus to the NULL domain
       * which will prevent rebalancing while the sched domains are recalculated.
       */
      
      The sched-domains should be rebuilt when a CPU_DOWN ops. has been
      completed, effectively either upon CPU_DEAD{_FROZEN} (upon success) or
      CPU_DOWN_FAILED{_FROZEN} (upon failure -- restore the things to their
      initial state). That's what update_sched_domains() also does but only
      for !CPUSETS case.
      
      With f18f982a, sched-domains' reinitialization is delegated to
      CPUSETS code:
      
      cpuset_handle_cpuhp() -> common_cpu_mem_hotplug_unplug() ->
      rebuild_sched_domains()
      
      Being called for CPU_UP_PREPARE and if its callback is called after
      update_sched_domains()), it just negates all the work done by
      update_sched_domains() -- i.e. a soon-to-be-offline cpu is included in
      the sched-domains and that makes it visible for the load-balancer
      while the CPU_DOWN ops. is in progress.
      
      __migrate_live_tasks() moves the tasks off a 'dead' cpu (it's already
      "offline" when this function is called).
      
      try_to_wake_up() is called for one of these tasks from another CPU ->
      the load-balancer (wake_idle()) picks up a "dead" CPU and places the
      task on it. Then e.g. BUG_ON(rq->nr_running) detects this a bit later
      -> oops.
      Signed-off-by: default avatarDmitry Adamushko <dmitry.adamushko@gmail.com>
      Tested-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Cc: Paul Menage <menage@google.com>
      Cc: Max Krasnyansky <maxk@qualcomm.com>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: miaox@cn.fujitsu.com
      Cc: rostedt@goodmis.org
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      3e84050c
    • Ingo Molnar's avatar
      Merge branch 'linus' into sched/devel · 54ef76f3
      Ingo Molnar authored
      54ef76f3
    • Yinghai Lu's avatar
      x86: fix numaq_tsc_disable calling · 3d88cca7
      Yinghai Lu authored
      got this on a test-system:
      
       calling  numaq_tsc_disable+0x0/0x39
       NUMAQ: disabling TSC
       initcall numaq_tsc_disable+0x0/0x39 returned 0 after 0 msecs
      
      that's because we should not be using arch_initcall to call numaq_tsc_disable.
      
      need to call it in setup_arch before time_init()/tsc_init()
      and call it in init_intel() to make the cpu feature bits right.
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      3d88cca7
    • Yinghai Lu's avatar
      x86, e820: remove end_user_pfn · 7b479bec
      Yinghai Lu authored
      end_user_pfn used to modify the meaning of the e820 maps.
      
      Now that all e820 operations are cleaned up, unified, tightened up,
      the e820 map always get updated to reality, we don't need to keep
      this secondary mechanism anymore.
      
      If you hit this commit in bisection it means something slipped through.
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7b479bec
    • Yinghai Lu's avatar
      x86: max_low_pfn_mapped fix, #3 · 9958e810
      Yinghai Lu authored
      optimization: try to merge the range with same page size in
      init_memory_mapping, to get the best possible linear mappings set up.
      
      thus when GBpages is not there, we could do 2M pages.
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9958e810
    • Yinghai Lu's avatar
      x86: max_low_pfn_mapped fix, #2 · 965194c1
      Yinghai Lu authored
      tighten the boundary checks around max_low_pfn_mapped - dont overmap
      nor undermap into holes.
      
      also print out tseg for AMD cpus, for diagnostic purposes.
      (this is an SMM area, and we split up any big mappings around that area)
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      965194c1
    • Yinghai Lu's avatar
      x86: max_low_pfn_mapped fix, #1 · 7ab073b6
      Yinghai Lu authored
      fix crash on Ingo's big box:
      
      calling  pci_iommu_init+0x0/0x17
      PCI-DMA: Disabling AGP.
      PCI-DMA: aperture base @ d0000000 size 65536 KB
      PCI-DMA: using GART IOMMU.
      PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
      BUG: unable to handle kernel paging request at ffff88000003be88
      IP: [<ffffffff8026d377>] __alloc_pages_internal+0xc3/0x3f2
      PGD 202063 PUD 206063 PMD 22fc00163 PTE 3b162
      Oops: 0000 [1] SMP
      
      and e820 is:
      
       BIOS-e820: 0000000000000000 - 000000000009ac00 (usable)
       BIOS-e820: 000000000009ac00 - 00000000000a0000 (reserved)
       BIOS-e820: 00000000000ca000 - 0000000000100000 (reserved)
       BIOS-e820: 0000000000100000 - 000000007ff70000 (usable)
       BIOS-e820: 000000007ff70000 - 000000007ff86000 (ACPI data)
       BIOS-e820: 000000007ff86000 - 0000000080000000 (ACPI NVS)
       BIOS-e820: 0000000080000000 - 00000000cfe00000 (usable)
       BIOS-e820: 00000000cfe00000 - 00000000d0000000 (reserved)
       BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
       BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
       BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
       BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
       BIOS-e820: 0000000100000000 - 0000000830000000 (usable)
      
      system has 32 GB RAM installed.
      
      max_low_pfn_mapped is 0xcfe00, and GART aperture is not mapped.
      
      So try to use init_memory_mapping to map that area, because the iommu
      thinks that area is ram ...
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7ab073b6
  3. 12 Jul, 2008 19 commits