Skip to content

L
linux

Linux-御风守护者 / linux
与 Fork 源项目一致

从无法访问的项目Fork

通知 1
Star 0
Fork 0
L
linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 26 1月, 2011 9 次提交
  3. 25 1月, 2011 24 次提交
  5. 24 1月, 2011 7 次提交
    • Y
      sched: Fix poor interactivity on UP systems due to group scheduler nice tune bug · 3ff6dcac
      由 Yong Zhang 提交于 
      Michael Witten and Christian Kujau reported that the autogroup
scheduling feature hurts interactivity on their UP systems.

It turns out that this is an older bug in the group scheduling code,
and the wider appeal provided by the autogroup feature exposed it
more prominently.

When on UP with FAIR_GROUP_SCHED enabled, tune shares
only affect tg->shares, but is not reflected in
tg->se->load. The reason is that update_cfs_shares()
does nothing on UP.

So introduce update_cfs_shares() for UP && FAIR_GROUP_SCHED.

This issue was found when enable autogroup scheduling was enabled,
but it is an older bug that also exists on cgroup.cpu on UP.
Reported-and-Tested-by: NMichael Witten <mfwitten@gmail.com>
Reported-and-Tested-by: NChristian Kujau <christian@nerdbynature.de>
Signed-off-by: NYong Zhang <yong.zhang0@gmail.com>
Acked-by: NPekka Enberg <penberg@kernel.org>
Acked-by: NMike Galbraith <efault@gmx.de>
Acked-by: NPeter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
LKML-Reference: <20110124073352.GA24186@windriver.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3ff6dcac
    • L
      Merge branch 'BUG_ON' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus · d315777b
      由 Linus Torvalds 提交于 
      * 'BUG_ON' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus:
  Remove MAYBE_BUILD_BUG_ON
  BUILD_BUG_ON: make it handle more cases
      d315777b
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus · 5a05a6d7
      由 Linus Torvalds 提交于 
      * git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus:
  module: fix missing semicolons in MODULE macro usage
  param: add null statement to compiled-in module params
  module: fix linker error for MODULE_VERSION when !MODULE and CONFIG_SYSFS=n
  module: show version information for built-in modules in sysfs
      5a05a6d7
    • L
      Merge branch 'for-linus' of... · d20761a7
      由 Linus Torvalds 提交于 
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6:
  selinux: return -ENOMEM when memory allocation fails
  tpm: fix panic caused by "tpm: Autodetect itpm devices"
  TPM: Long default timeout fix
  trusted keys: Fix a memory leak in trusted_update().
  keys: add trusted and encrypted maintainers
  encrypted-keys: rename encrypted_defined files to encrypted
  trusted-keys: rename trusted_defined files to trusted
      d20761a7
    • R
      Make CIFS mount work in a container. · f1d0c998
      由 Rob Landley 提交于 
      Teach cifs about network namespaces, so mounting uses adresses/routing
visible from the container rather than from init context.

A container is a chroot on steroids that changes more than just the root
filesystem the new processes see.  One thing containers can isolate is
"network namespaces", meaning each container can have its own set of
ethernet interfaces, each with its own own IP address and routing to the
outside world.  And if you open a socket in _userspace_ from processes
within such a container, this works fine.

But sockets opened from within the kernel still use a single global
networking context in a lot of places, meaning the new socket's address
and routing are correct for PID 1 on the host, but are _not_ what
userspace processes in the container get to use.

So when you mount a network filesystem from within in a container, the
mount code in the CIFS driver uses the host's networking context and not
the container's networking context, so it gets the wrong address, uses
the wrong routing, and may even try to go out an interface that the
container can't even access...  Bad stuff.

This patch copies the mount process's network context into the CIFS
structure that stores the rest of the server information for that mount
point, and changes the socket open code to use the saved network context
instead of the global network context.  I.E. "when you attempt to use
these addresses, do so relative to THIS set of network interfaces and
routing rules, not the old global context from back before we supported
containers".

The big long HOWTO sets up a test environment on the assumption you've
never used ocntainers before.  It basically says:

1) configure and build a new kernel that has container support
2) build a new root filesystem that includes the userspace container
control package (LXC)
3) package/run them under KVM (so you don't have to mess up your host
system in order to play with containers).
4) set up some containers under the KVM system
5) set up contradictory routing in the KVM system and the container so
that the host and the container see different things for the same address
6) try to mount a CIFS share from both contexts so you can both force it
to work and force it to fail.

For a long drawn out test reproduction sequence, see:

  http://landley.livejournal.com/47024.html
  http://landley.livejournal.com/47205.html
  http://landley.livejournal.com/47476.htmlSigned-off-by: NRob Landley <rlandley@parallels.com>
Reviewed-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NSteve French <sfrench@us.ibm.com>
      f1d0c998
    • R
      Remove MAYBE_BUILD_BUG_ON · 1765e3a4
      由 Rusty Russell 提交于 
      Now BUILD_BUG_ON() can handle optimizable constants, we don't need
MAYBE_BUILD_BUG_ON any more.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      1765e3a4
    • R
      BUILD_BUG_ON: make it handle more cases · 7ef88ad5
      由 Rusty Russell 提交于 
      BUILD_BUG_ON used to use the optimizer to do code elimination or fail
at link time; it was changed to first the size of a negative array (a
nicer compile time error), then (in
8c87df45) to a bitfield.

This forced us to change some non-constant cases to MAYBE_BUILD_BUG_ON();
as Jan points out in that commit, it didn't work as intended anyway.

bitfields: needs a literal constant at parse time, and can't be put under
	"if (__builtin_constant_p(x))" for example.
negative array: can handle anything, but if the compiler can't tell it's
	a constant, silently has no effect.
link time: breaks link if the compiler can't determine the value, but the
	linker output is not usually as informative as a compiler error.

If we use the negative-array-size method *and* the link time trick,
we get the ability to use BUILD_BUG_ON() under __builtin_constant_p()
branches, and maximal ability for the compiler to detect errors at
build time.

We also document it thoroughly.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: Jan Beulich <JBeulich@novell.com>
Acked-by: NHollis Blanchard <hollisb@us.ibm.com>
      7ef88ad5