Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 29 5月, 2005 21 次提交
  3. 28 5月, 2005 14 次提交
  5. 27 5月, 2005 5 次提交
    • A
      [PATCH] Note on ACPI build fix · 8aadff7d
      由 Alexander Nyberg 提交于 
      Even after the previous fix you can still set CONFIG_ACPI_BOOT
indirectly even without CONFIG_ACPI by choosing CONFIG_PCI and
CONFIG_PCI_MMCONFIG.

That doesn't build very well either.

This makes PCI_MMCONFIG depend on ACPI, fixing that hole.

[ I guess in theory Kconfig could follow the whole chain of dependencies
  for things that get selected, but that sounds insanely complicated, so
  we'll just fix up these things by hand.  --Linus ]
Signed-off-by: NAlexander Nyberg <alexn@telia.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8aadff7d
    • L
      [PATCH] ACPI build fix · 3e11c3ce
      由 Len Brown 提交于 
      Fix 2.6.12 CONFIG_ACPI=n build regression.
CONFIG_ACPI_BOOT shall be set only if CONFIG_ACPI.
Signed-off-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3e11c3ce
    • A
      [PATCH] Fixup VIA IRQ quirk · 9920e914
      由 Alexander Nyberg 提交于 
      quirk_via_irqpic can't be __devinit for swsuspend
Signed-off-by: NAlexander Nyberg <alexn@telia.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9920e914
    • L
      [PATCH] VIA IRQ quirk · 25be5e6c
      由 Len Brown 提交于 
      Delete quirk_via_bridge(), restore quirk_via_irqpic() -- but now
improved to be invoked upon device ENABLE, and now only for VIA devices
-- not all devices behind VIA bridges.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      25be5e6c
    • P
      [PATCH] cpuset exit NULL dereference fix · 2efe86b8
      由 Paul Jackson 提交于 
      There is a race in the kernel cpuset code, between the code
to handle notify_on_release, and the code to remove a cpuset.
The notify_on_release code can end up trying to access a
cpuset that has been removed.  In the most common case, this
causes a NULL pointer dereference from the routine cpuset_path.
However all manner of bad things are possible, in theory at least.

The existing code decrements the cpuset use count, and if the
count goes to zero, processes the notify_on_release request,
if appropriate.  However, once the count goes to zero, unless we
are holding the global cpuset_sem semaphore, there is nothing to
stop another task from immediately removing the cpuset entirely,
and recycling its memory.

The obvious fix would be to always hold the cpuset_sem
semaphore while decrementing the use count and dealing with
notify_on_release.  However we don't want to force a global
semaphore into the mainline task exit path, as that might create
a scaling problem.

The actual fix is almost as easy - since this is only an issue
for cpusets using notify_on_release, which the top level big
cpusets don't normally need to use, only take the cpuset_sem
for cpusets using notify_on_release.

This code has been run for hours without a hiccup, while running
a cpuset create/destroy stress test that could crash the existing
kernel in seconds.  This patch applies to the current -linus
git kernel.
Signed-off-by: NPaul Jackson <pj@sgi.com>
Acked-by: NSimon Derr <simon.derr@bull.net>
Acked-by: NDinakar Guniguntala <dino@in.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2efe86b8