Skip to content

cloud-kernel
cloud-kernel

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

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel

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

切换分支/标签
  1. 10 7月, 2013 3 次提交
  3. 05 7月, 2013 7 次提交
  5. 04 7月, 2013 3 次提交
  7. 28 6月, 2013 1 次提交
    • G
      lib: Move fonts from drivers/video/console/ to lib/fonts/ · ee89bd6b
      由 Geert Uytterhoeven 提交于 
      Several drivers need font support independent of CONFIG_VT, cfr. commit
9cbce8d7e1dae0744ca4f68d62aa7de18196b6f4, "console/font: Refactor font
support code selection logic").
Hence move the fonts and their support logic from drivers/video/console/ to
its own library directory lib/fonts/.
This also allows to limit processing of drivers/video/console/Makefile to
CONFIG_VT=y again.

[Kevin Hilman <khilman@linaro.org>: Update arch/arm/boot/compressed/Makefile]
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      ee89bd6b
  9. 26 6月, 2013 6 次提交
  11. 19 6月, 2013 1 次提交
    • A
      X.509: do not emit any informational output · a857c6e7
      由 Arnd Bergmann 提交于 
      When building a kernel using 'make -s', I expect to see an empty output,
except for build warnings and errors. The build_OID_registry code
always prints one line when run, which is not helpful to most people
building the kernels, and which makes it harder to automatically
check for build warnings.

Let's just remove the one line output.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: David Howells <dhowells@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
      a857c6e7
  13. 18 6月, 2013 1 次提交
  15. 17 6月, 2013 1 次提交
    • T
      percpu-refcount: use RCU-sched insted of normal RCU · a4244454
      由 Tejun Heo 提交于 
      percpu-refcount was incorrectly using preempt_disable/enable() for RCU
critical sections against call_rcu().  6a24474d ("percpu-refcount:
consistently use plain (non-sched) RCU") fixed it by converting the
preepmtion operations with rcu_read_[un]lock() citing that there isn't
any advantage in using sched-RCU over using the usual one; however,
rcu_read_[un]lock() for the preemptible RCU implementation -
CONFIG_TREE_PREEMPT_RCU, chosen when CONFIG_PREEMPT - are slightly
more expensive than preempt_disable/enable().

In a contrived microbench which repeats the followings,

 - percpu_ref_get()
 - copy 32 bytes of data into percpu buffer
 - percpu_put_get()
 - copy 32 bytes of data into percpu buffer

rcu_read_[un]lock() used in percpu_ref_get/put() makes it go slower by
about 15% when compared to using sched-RCU.

As the RCU critical sections are extremely short, using sched-RCU
shouldn't have any latency implications.  Convert to RCU-sched.
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NKent Overstreet <koverstreet@google.com>
Acked-by: N"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Rusty Russell <rusty@rustcorp.com.au>
      a4244454
  17. 14 6月, 2013 3 次提交
    • T
      percpu-refcount: implement percpu_tryget() along with percpu_ref_kill_and_confirm() · dbece3a0
      由 Tejun Heo 提交于 
      Implement percpu_tryget() which stops giving out references once the
percpu_ref is visible as killed.  Because the refcnt is per-cpu,
different CPUs will start to see a refcnt as killed at different
points in time and tryget() may continue to succeed on subset of cpus
for a while after percpu_ref_kill() returns.

For use cases where it's necessary to know when all CPUs start to see
the refcnt as dead, percpu_ref_kill_and_confirm() is added.  The new
function takes an extra argument @confirm_kill which is invoked when
the refcnt is guaranteed to be viewed as killed on all CPUs.

While this isn't the prettiest interface, it doesn't force synchronous
wait and is much safer than requiring the caller to do its own
call_rcu().

v2: Patch description rephrased to emphasize that tryget() may
    continue to succeed on some CPUs after kill() returns as suggested
    by Kent.

v3: Function comment in percpu_ref_kill_and_confirm() updated warning
    people to not depend on the implied RCU grace period from the
    confirm callback as it's an implementation detail.
Signed-off-by: NTejun Heo <tj@kernel.org>
Slightly-Grumpily-Acked-by: NKent Overstreet <koverstreet@google.com>
      dbece3a0
    • T
      percpu-refcount: implement percpu_ref_cancel_init() · bc497bd3
      由 Tejun Heo 提交于 
      Normally, percpu_ref_init() initializes and percpu_ref_kill()
initiates destruction which completes asynchronously.  The
asynchronous destruction can be problematic in init failure path where
the caller wants to destroy half-constructed object - distinguishing
half-constructed objects from the usual release method can be painful
for complex objects.

This patch implements percpu_ref_cancel_init() which synchronously
destroys the percpu_ref without invoking release.  To avoid
unintentional misuses, the function requires the ref to have finished
percpu_ref_init() but never used and triggers WARN otherwise.

v2: Explain the weird name and usage restriction in the function
    comment.
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NKent Overstreet <koverstreet@google.com>
      bc497bd3
    • T
      percpu-refcount: add __must_check to percpu_ref_init() and don't use... · acac7883
      由 Tejun Heo 提交于 
      percpu-refcount: add __must_check to percpu_ref_init() and don't use ACCESS_ONCE() in percpu_ref_kill_rcu()

Two small changes.

* Unlike most init functions, percpu_ref_init() allocates memory and
  may fail.  Let's mark it with __must_check in case the caller
  forgets.

* percpu_ref_kill_rcu() is unnecessarily using ACCESS_ONCE() to
  dereference @ref->pcpu_count, which can be misleading.  The pointer
  is guaranteed to be valid and visible and can't change underneath
  the function.  Drop ACCESS_ONCE().
Signed-off-by: NTejun Heo <tj@kernel.org>
      acac7883
  19. 13 6月, 2013 2 次提交
  21. 08 6月, 2013 1 次提交
  23. 06 6月, 2013 1 次提交
  25. 05 6月, 2013 1 次提交
  27. 04 6月, 2013 3 次提交
  29. 29 5月, 2013 1 次提交
  31. 25 5月, 2013 1 次提交
    • H
      MPILIB: disable usage of floating point registers on parisc · 70ef5578
      由 Helge Deller 提交于 
      The umul_ppmm() macro for parisc uses the xmpyu assembler statement
which does calculation via a floating point register.

But usage of floating point registers inside the Linux kernel are not
allowed and gcc will stop compilation due to the -mdisable-fpregs
compiler option.

Fix this by disabling the umul_ppmm() and udiv_qrnnd() macros. The
mpilib will then use the generic built-in implementations instead.
Signed-off-by: NHelge Deller <deller@gmx.de>
      70ef5578
  33. 24 5月, 2013 1 次提交
  35. 22 5月, 2013 1 次提交
  37. 20 5月, 2013 2 次提交