Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 19 11月, 2009 1 次提交
  3. 29 10月, 2009 1 次提交
  5. 27 10月, 2009 1 次提交
  7. 12 10月, 2009 1 次提交
  9. 06 10月, 2009 1 次提交
  11. 02 10月, 2009 1 次提交
  13. 24 9月, 2009 1 次提交
  15. 23 9月, 2009 1 次提交
  17. 22 9月, 2009 6 次提交
  19. 21 9月, 2009 1 次提交
  21. 20 9月, 2009 1 次提交
  23. 18 9月, 2009 2 次提交
    • S
      vsnprintf: remove duplicate comment of vsnprintf · 0efb4d20
      由 Steven Rostedt 提交于 
      Remove the duplicate comment of bstr_printf that is the same as the
vsnprintf.

Add the 's' option to the comment for the pointer function. This is
more of an internal function so the little duplication of the comment
here is OK.
Reported-by: NZhaolei <zhaolei@cn.fujitsu.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      0efb4d20
    • S
      vsprintf: add %ps that is the same as %pS but is like %pf · 91adcd2c
      由 Steven Rostedt 提交于 
      On PowerPC64 function pointers do not point directly at the functions,
but instead point to pointers to the functions. The output of %pF expects
to point to a pointer to the function, whereas %pS will show the function
itself.

mcount returns the direct pointer to the function and not the pointer to
the pointer. Thus %pS must be used to show this. The function tracer
requires printing of the functions without offsets and uses the %pf
instead.

 %pF produces run_local_timers+0x4/0x1f
 %pf produces just run_local_timers

For PowerPC64, we need to use the direct pointer, and we only have
%pS which will produce .run_local_timers+0x4/0x1f

This patch creates a %ps that matches the %pf as %pS matches %pF.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Zhao Lei <zhaolei@cn.fujitsu.com>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      91adcd2c
  25. 16 9月, 2009 1 次提交
  27. 02 9月, 2009 1 次提交
    • D
      CRED: Add some configurable debugging [try #6] · e0e81739
      由 David Howells 提交于 
      Add a config option (CONFIG_DEBUG_CREDENTIALS) to turn on some debug checking
for credential management.  The additional code keeps track of the number of
pointers from task_structs to any given cred struct, and checks to see that
this number never exceeds the usage count of the cred struct (which includes
all references, not just those from task_structs).

Furthermore, if SELinux is enabled, the code also checks that the security
pointer in the cred struct is never seen to be invalid.

This attempts to catch the bug whereby inode_has_perm() faults in an nfsd
kernel thread on seeing cred->security be a NULL pointer (it appears that the
credential struct has been previously released):

	http://www.kerneloops.org/oops.php?number=252883Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NJames Morris <jmorris@namei.org>
      e0e81739
  29. 29 8月, 2009 1 次提交
  31. 28 8月, 2009 1 次提交
  33. 27 8月, 2009 3 次提交
  35. 23 8月, 2009 2 次提交
    • P
      rcu: Remove CONFIG_PREEMPT_RCU · 6b3ef48a
      由 Paul E. McKenney 提交于 
      Now that CONFIG_TREE_PREEMPT_RCU is in place, there is no
further need for CONFIG_PREEMPT_RCU.  Remove it, along with
whatever subtle bugs it may (or may not) contain.
Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: laijs@cn.fujitsu.com
Cc: dipankar@in.ibm.com
Cc: akpm@linux-foundation.org
Cc: mathieu.desnoyers@polymtl.ca
Cc: josht@linux.vnet.ibm.com
Cc: dvhltc@us.ibm.com
Cc: niv@us.ibm.com
Cc: peterz@infradead.org
Cc: rostedt@goodmis.org
LKML-Reference: <125097461396-git-send-email->
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6b3ef48a
    • P
      rcu: Merge preemptable-RCU functionality into hierarchical RCU · f41d911f
      由 Paul E. McKenney 提交于 
      Create a kernel/rcutree_plugin.h file that contains definitions
for preemptable RCU (or, under the #else branch of the #ifdef,
empty definitions for the classic non-preemptable semantics).
These definitions fit into plugins defined in kernel/rcutree.c
for this purpose.

This variant of preemptable RCU uses a new algorithm whose
read-side expense is roughly that of classic hierarchical RCU
under CONFIG_PREEMPT. This new algorithm's update-side expense
is similar to that of classic hierarchical RCU, and, in absence
of read-side preemption or blocking, is exactly that of classic
hierarchical RCU.  Perhaps more important, this new algorithm
has a much simpler implementation, saving well over 1,000 lines
of code compared to mainline's implementation of preemptable
RCU, which will hopefully be retired in favor of this new
algorithm.

The simplifications are obtained by maintaining per-task
nesting state for running tasks, and using a simple
lock-protected algorithm to handle accounting when tasks block
within RCU read-side critical sections, making use of lessons
learned while creating numerous user-level RCU implementations
over the past 18 months.
Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: laijs@cn.fujitsu.com
Cc: dipankar@in.ibm.com
Cc: akpm@linux-foundation.org
Cc: mathieu.desnoyers@polymtl.ca
Cc: josht@linux.vnet.ibm.com
Cc: dvhltc@us.ibm.com
Cc: niv@us.ibm.com
Cc: peterz@infradead.org
Cc: rostedt@goodmis.org
LKML-Reference: <12509746134003-git-send-email->
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f41d911f
  37. 22 8月, 2009 1 次提交
    • L
      Make bitmask 'and' operators return a result code · f4b0373b
      由 Linus Torvalds 提交于 
      When 'and'ing two bitmasks (where 'andnot' is a variation on it), some
cases want to know whether the result is the empty set or not.  In
particular, the TLB IPI sending code wants to do cpumask operations and
determine if there are any CPU's left in the final set.

So this just makes the bitmask (and cpumask) functions return a boolean
for whether the result has any bits set.

Cc: stable@kernel.org (2.6.30, needed by TLB shootdown fix)
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f4b0373b
  39. 21 8月, 2009 2 次提交
    • C
      lib/swiotlb.c: Fix strange panic message selection logic when swiotlb fills up · c7084b35
      由 Casey Dahlin 提交于 
      swiotlb_full() in lib/swiotlb.c throws one of two panic messages
based on whether the direction of transfer is from the device
or to the device. The logic around this is somewhat weird in
the case of bidirectional transfers. It appears to want to
throw both in succession, but since its a panic only the first
makes it.

This patch adds a third, separate error for DMA_BIDIRECTIONAL
to make things a bit clearer.
Signed-off-by: NCasey Dahlin <cdahlin@redhat.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Becky Bruce <beckyb@kernel.crashing.org>
[ further fixed the error message ]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
LKML-Reference: <200908202327.n7KNRuqK001504@imap1.linux-foundation.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c7084b35
    • K
      dma-debug: Fix check_unmap null pointer dereference · ec9c96ef
      由 Kyle McMartin 提交于 
      While it's debatable whether or not a NULL device argument to
the DMA API functions is valid... since it certainly isn't
valid on devices with an IOMMU... dma-debug really shouldn't be
dereferencing null pointers either.

Guard against that in err_printk and the driver_filter
functions. A Fedora rawhide user was seeing this in one of the
dvb drivers resulting in an oops on boot.

[ A patch has been sent for testing to the driver, but I feel
  the dma debugging support should be fixed as well. (There's
  still a pile of legacy garbage in the kernel passing null
  pointers to dma_{alloc,free}_*. :( ]
Signed-off-by: NKyle McMartin <kyle@redhat.com>
Cc: mchehab@infradead.org
Cc: Joerg Roedel <joerg.roedel@amd.com>
LKML-Reference: <20090820011708.GP25206@bombadil.infradead.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ec9c96ef
  41. 20 8月, 2009 1 次提交
  43. 08 8月, 2009 3 次提交
  45. 05 8月, 2009 1 次提交
  47. 31 7月, 2009 1 次提交
  49. 30 7月, 2009 2 次提交
    • D
      lib: flexible array implementation · 534acc05
      由 Dave Hansen 提交于 
      Once a structure goes over PAGE_SIZE*2, we see occasional allocation
failures.  Some people have chosen to switch over to things like vmalloc()
that will let them keep array-like access to such a large structures.
But, vmalloc() has plenty of downsides.

Here's an alternative.  I think it's what Andrew was suggesting here:

	http://lkml.org/lkml/2009/7/2/518

I call it a flexible array.  It does all of its work in PAGE_SIZE bits, so
never does an order>0 allocation.  The base level has
PAGE_SIZE-2*sizeof(int) bytes of storage for pointers to the second level.
 So, with a 32-bit arch, you get about 4MB (4183112 bytes) of total
storage when the objects pack nicely into a page.  It is half that on
64-bit because the pointers are twice the size.  There's a table detailing
this in the code.

There are kerneldocs for the functions, but here's an
overview:

flex_array_alloc() - dynamically allocate a base structure
flex_array_free() - free the array and all of the
		    second-level pages
flex_array_free_parts() - free the second-level pages, but
			  not the base (for static bases)
flex_array_put() - copy into the array at the given index
flex_array_get() - copy out of the array at the given index
flex_array_prealloc() - preallocate the second-level pages
			between the given indexes to
			guarantee no allocs will occur at
			put() time.

We could also potentially just pass the "element_size" into each of the
API functions instead of storing it internally.  That would get us one
more base pointer on 32-bit.

I've been testing this by running it in userspace.  The header and patch
that I've been using are here, as well as the little script I'm using to
generate the size table which goes in the kerneldocs.

	http://sr71.net/~dave/linux/flexarray/

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: NDave Hansen <dave@linux.vnet.ibm.com>
Reviewed-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      534acc05
    • R
      lib: export generic atomic64_t functions · 3fc7b4b2
      由 Roland Dreier 提交于 
      The generic atomic64_t implementation in lib/ did not export the functions
it defined, which means that modules that use atomic64_t would not link on
platforms (such as 32-bit powerpc).  For example, trying to build a kernel
with CONFIG_NET_RDS on such a platform would fail with:

    ERROR: "atomic64_read" [net/rds/rds.ko] undefined!
    ERROR: "atomic64_set" [net/rds/rds.ko] undefined!

Fix this by exporting the atomic64_t functions to modules.  (I export the
entire API even if it's not all currently used by in-tree modules to avoid
having to continue fixing this in dribs and drabs)
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
Acked-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3fc7b4b2
  51. 29 7月, 2009 1 次提交
  53. 28 7月, 2009 1 次提交