Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 21 10月, 2008 1 次提交
    • A
      [PATCH] beginning of methods conversion · d4430d62
      由 Al Viro 提交于 
      To keep the size of changesets sane we split the switch by drivers;
to keep the damn thing bisectable we do the following:
	1) rename the affected methods, add ones with correct
prototypes, make (few) callers handle both.  That's this changeset.
	2) for each driver convert to new methods.  *ALL* drivers
are converted in this series.
	3) kill the old (renamed) methods.

Note that it _is_ a flagday; all in-tree drivers are converted and by the
end of this series no trace of old methods remain.  The only reason why
we do that this way is to keep the damn thing bisectable and allow per-driver
debugging if anything goes wrong.

New methods:
	open(bdev, mode)
	release(disk, mode)
	ioctl(bdev, mode, cmd, arg)		/* Called without BKL */
	compat_ioctl(bdev, mode, cmd, arg)
	locked_ioctl(bdev, mode, cmd, arg)	/* Called with BKL, legacy */
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d4430d62
  3. 20 10月, 2008 2 次提交
    • W
      uml: fix a compile error · 966c8079
      由 WANG Cong 提交于 
      Fix

arch/um/sys-i386/signal.c: In function 'copy_sc_from_user':
arch/um/sys-i386/signal.c:182: warning: dereferencing 'void *' pointer
arch/um/sys-i386/signal.c:182: error: request for member '_fxsr_env' in something not a structure or union
Signed-off-by: NWANG Cong <wangcong@zeuux.org>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      966c8079
    • M
      container freezer: implement freezer cgroup subsystem · dc52ddc0
      由 Matt Helsley 提交于 
      This patch implements a new freezer subsystem in the control groups
framework.  It provides a way to stop and resume execution of all tasks in
a cgroup by writing in the cgroup filesystem.

The freezer subsystem in the container filesystem defines a file named
freezer.state.  Writing "FROZEN" to the state file will freeze all tasks
in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
the cgroup.  Reading will return the current state.

* Examples of usage :

   # mkdir /containers/freezer
   # mount -t cgroup -ofreezer freezer  /containers
   # mkdir /containers/0
   # echo $some_pid > /containers/0/tasks

to get status of the freezer subsystem :

   # cat /containers/0/freezer.state
   RUNNING

to freeze all tasks in the container :

   # echo FROZEN > /containers/0/freezer.state
   # cat /containers/0/freezer.state
   FREEZING
   # cat /containers/0/freezer.state
   FROZEN

to unfreeze all tasks in the container :

   # echo RUNNING > /containers/0/freezer.state
   # cat /containers/0/freezer.state
   RUNNING

This is the basic mechanism which should do the right thing for user space
task in a simple scenario.

It's important to note that freezing can be incomplete.  In that case we
return EBUSY.  This means that some tasks in the cgroup are busy doing
something that prevents us from completely freezing the cgroup at this
time.  After EBUSY, the cgroup will remain partially frozen -- reflected
by freezer.state reporting "FREEZING" when read.  The state will remain
"FREEZING" until one of these things happens:

	1) Userspace cancels the freezing operation by writing "RUNNING" to
		the freezer.state file
	2) Userspace retries the freezing operation by writing "FROZEN" to
		the freezer.state file (writing "FREEZING" is not legal
		and returns EIO)
	3) The tasks that blocked the cgroup from entering the "FROZEN"
		state disappear from the cgroup's set of tasks.

[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: export thaw_process]
Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
Signed-off-by: NMatt Helsley <matthltc@us.ibm.com>
Acked-by: NSerge E. Hallyn <serue@us.ibm.com>
Tested-by: NMatt Helsley <matthltc@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dc52ddc0
  5. 17 10月, 2008 1 次提交
  7. 14 10月, 2008 1 次提交
  9. 09 9月, 2008 1 次提交
    • M
      kernel/cpu.c: create a CPU_STARTING cpu_chain notifier · e545a614
      由 Manfred Spraul 提交于 
      Right now, there is no notifier that is called on a new cpu, before the new
cpu begins processing interrupts/softirqs.
Various kernel function would need that notification, e.g. kvm works around
by calling smp_call_function_single(), rcu polls cpu_online_map.

The patch adds a CPU_STARTING notification. It also adds a helper function
that sends the message to all cpu_chain handlers.

Tested on x86-64.
All other archs are untested. Especially on sparc, I'm not sure if I got
it right.
Signed-off-by: NManfred Spraul <manfred@colorfullife.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e545a614
  11. 07 9月, 2008 2 次提交
  13. 29 8月, 2008 1 次提交
    • T
      sound: make OSS sound core optional · d886e87c
      由 Tejun Heo 提交于 
      sound/sound_core.c implements soundcore.ko and contains two parts -
sound_class which is shared by both ALSA and OSS and device
redirection support for OSS.  It's always compiled when any sound
support is enabled although it's necessary only when OSS (the actual
one or emulation) is enabled.  This is slightly wasteful and as device
redirection always registers character device region for major 14, it
prevents alternative implementation.

This patch introduces a new config SOUND_OSS_CORE which is selected
iff OSS support is actually necessary and build the OSS core part
conditionally.

If OSS is disabled, soundcore merely contains sound_class but leaving
it that way seems to be the simplest approach as otherwise sound_class
should be in ALSA core file if OSS is disabled but should be in
soundcore if OSS is enabled.  Also, there's also the user confusion
factor.
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NJaroslav Kysela <perex@perex.cz>
      d886e87c
  15. 15 8月, 2008 1 次提交
  17. 31 7月, 2008 1 次提交
  19. 27 7月, 2008 1 次提交
  21. 25 7月, 2008 3 次提交
  23. 24 7月, 2008 1 次提交
    • J
      UML - Fix boot crash · 7c1fed03
      由 Jeff Dike 提交于 
      My copying of linux/init.h didn't go far enough.  The definition of
__used singled out gcc minor version 3, but didn't care what the major
version was.  This broke when unit-at-a-time was added and gcc started
throwing out initcalls.

This results in an early boot crash when ptrace tries to initialize a
process with an empty, uninitialized register set.
Signed-off-by: NJeff Dike <jdike@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7c1fed03
  25. 19 7月, 2008 1 次提交
    • T
      nohz: prevent tick stop outside of the idle loop · b8f8c3cf
      由 Thomas Gleixner 提交于 
      Jack Ren and Eric Miao tracked down the following long standing
problem in the NOHZ code:

	scheduler switch to idle task
	enable interrupts

Window starts here

	----> interrupt happens (does not set NEED_RESCHED)
	      	irq_exit() stops the tick

	----> interrupt happens (does set NEED_RESCHED)

	return from schedule()
	
	cpu_idle(): preempt_disable();

Window ends here

The interrupts can happen at any point inside the race window. The
first interrupt stops the tick, the second one causes the scheduler to
rerun and switch away from idle again and we end up with the tick
disabled.

The fact that it needs two interrupts where the first one does not set
NEED_RESCHED and the second one does made the bug obscure and extremly
hard to reproduce and analyse. Kudos to Jack and Eric.

Solution: Limit the NOHZ functionality to the idle loop to make sure
that we can not run into such a situation ever again.

cpu_idle()
{
	preempt_disable();

	while(1) {
		 tick_nohz_stop_sched_tick(1); <- tell NOHZ code that we
		 			          are in the idle loop

		 while (!need_resched())
		       halt();

		 tick_nohz_restart_sched_tick(); <- disables NOHZ mode
		 preempt_enable_no_resched();
		 schedule();
		 preempt_disable();
	}
}

In hindsight we should have done this forever, but ... 

/me grabs a large brown paperbag.

Debugged-by: Jack Ren <jack.ren@marvell.com>, 
Debugged-by: Neric miao <eric.y.miao@gmail.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      b8f8c3cf
  27. 08 7月, 2008 1 次提交
    • J
      [UML] fix gcc ICEs and unresolved externs · 4f81c535
      由 Jeff Dike 提交于 
      There are various constraints on the use of unit-at-a-time:
 - i386 uses no-unit-at-a-time for pre-4.0 (not 4.3)
 - x86_64 uses unit-at-a-time always

Uli reported a crash on x86_64 with gcc 4.1.2 with unit-at-a-time,
resulting in commit c0a18111

Ingo reported a gcc internal error with gcc 4.3 with no-unit-at-a-timem,
resulting in 22eecde2

Benny Halevy is seeing extern inlines not resolved with gcc 4.3 with
no-unit-at-a-time

This patch reintroduces unit-at-a-time for gcc >= 4.0, bringing back the
possibility of Uli's crash.  If that happens, we'll debug it.

I started seeing both the internal compiler errors and unresolved
inlines on Fedora 9.  This patch fixes both problems, without so far
reintroducing the crash reported by Uli.
Signed-off-by: NJeff Dike <jdike@linux.intel.com>
Cc: Benny Halevy <bhalevy@panasas.com>
Cc: Adrian Bunk <bunk@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Ulrich Drepper <drepper@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4f81c535
  29. 03 7月, 2008 3 次提交
  31. 26 6月, 2008 1 次提交
  33. 13 6月, 2008 2 次提交
  35. 07 6月, 2008 6 次提交
  37. 22 5月, 2008 5 次提交
  39. 17 5月, 2008 1 次提交
  41. 13 5月, 2008 4 次提交