treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 244

Based on 1 normalized pattern(s):

this file is rleased under the gpl v2

extracted by the scancode license scanner the SPDX lice

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 244

Based on 1 normalized pattern(s):

this file is rleased under the gpl v2

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 1 file(s).

Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Reviewed-by: Alexios Zavras <[email protected]>
Reviewed-by: Enrico Weigelt <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

klist: implement klist_prev()

klist_prev() gets the previous element in the list. It is useful to traverse
through the list in reverse order, for example, to provide LIFO (last in first
out) variant

klist: implement klist_prev()

klist_prev() gets the previous element in the list. It is useful to traverse
through the list in reverse order, for example, to provide LIFO (last in first
out) variant of access.

Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Lee Jones <[email protected]>

show more ...

klist: use same naming scheme as hlist for klist_add_after()

The name was modified from hlist_add_after() to hlist_add_behind() when
adjusting the order of arguments to match the one with
klist_add_

klist: use same naming scheme as hlist for klist_add_after()

The name was modified from hlist_add_after() to hlist_add_behind() when
adjusting the order of arguments to match the one with
klist_add_after(). This is necessary to break old code when it would
use it the wrong way.

Make klist follow this naming scheme for consistency.

Signed-off-by: Ken Helias <[email protected]>
Cc: "Paul E. McKenney" <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Jeff Kirsher <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

Revert "driver core: check start node in klist_iter_init_node"

This reverts commit a15d49fd3094cff90e5410ca454a870e0a722fe1 as that
patch broke the build.

Cc: Hannes Reinecke <[email protected]>
Reporte

Revert "driver core: check start node in klist_iter_init_node"

This reverts commit a15d49fd3094cff90e5410ca454a870e0a722fe1 as that
patch broke the build.

Cc: Hannes Reinecke <[email protected]>
Reported-by: Stephen Rothwell <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: check start node in klist_iter_init_node

klist_iter_init_node() takes a node as a start argument.
However, this node might not be valid anymore.
This patch updates the klist_iter_init_n

driver core: check start node in klist_iter_init_node

klist_iter_init_node() takes a node as a start argument.
However, this node might not be valid anymore.
This patch updates the klist_iter_init_node() and
dependent functions to return an error if so.
All calling functions have been audited to check
for a return code here.

Signed-off-by: Hannes Reinecke <[email protected]>
Cc: Greg Kroah-Hartmann <[email protected]>
Cc: Kay Sievers <[email protected]>
Cc: Stable Kernel <[email protected]>
Cc: Linux Kernel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

klist: Fix object alignment on 64-bit.

Commit c0e69a5bbc6f ("klist.c: bit 0 in pointer can't be used as flag")
intended to make sure that all klist objects were at least pointer size
aligned, but us

klist: Fix object alignment on 64-bit.

Commit c0e69a5bbc6f ("klist.c: bit 0 in pointer can't be used as flag")
intended to make sure that all klist objects were at least pointer size
aligned, but used the constant "4" which only works on 32-bit.

Use "sizeof(void *)" which is correct in all cases.

Signed-off-by: David S. Miller <[email protected]>
Acked-by: Jesper Nilsson <[email protected]>
Cc: stable <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

klist.c: bit 0 in pointer can't be used as flag

The commit a1ed5b0cffe4b16a93a6a3390e8cee0fbef94f86
(klist: don't iterate over deleted entries) introduces use of the
low bit in a pointer to indicate

klist.c: bit 0 in pointer can't be used as flag

The commit a1ed5b0cffe4b16a93a6a3390e8cee0fbef94f86
(klist: don't iterate over deleted entries) introduces use of the
low bit in a pointer to indicate if the knode is dead or not,
assuming that this bit is always free.

This is not true for all architectures, CRIS for example may align data
on byte borders.

The result is a bunch of warnings on bootup, devices not being
added correctly etc, reported by Hinko Kocevar <[email protected]>:

------------[ cut here ]------------
WARNING: at lib/klist.c:62 ()
Modules linked in:

Stack from c1fe1cf0:
c01cc7f4 c1fe1d11 c000eb4e c000e4de 00000000 00000000 c1f4f78f c1f50c2d
c01d008c c1fdd1a0 c1fdd1a0 c1fe1d38 c0192954 c1fe0000 00000000 c1fe1dc0
00000002 7fffffff c1fe1da8 c0192d50 c1fe1dc0 00000002 7fffffff c1ff9fcc
Call Trace: [<c000eb4e>] [<c000e4de>] [<c0192954>] [<c0192d50>] [<c001d49e>] [<c000b688>] [<c0192a3c>]
[<c000b63e>] [<c000b63e>] [<c001a542>] [<c00b55b0>] [<c00411c0>] [<c00b559c>] [<c01918e6>] [<c0191988>]
[<c01919d0>] [<c00cd9c8>] [<c00cdd6a>] [<c0034178>] [<c000409a>] [<c0015576>] [<c0029130>] [<c0029078>]
[<c0029170>] [<c0012336>] [<c00b4076>] [<c00b4770>] [<c006d6e4>] [<c006d974>] [<c006dca0>] [<c0028d6c>]
[<c0028e12>] [<c0006424>] <4>---[ end trace 4eaa2a86a8e2da22 ]---
------------[ cut here ]------------
Repeat ad nauseam.

Wed, Jan 14, 2009 at 12:11:32AM +0100, Bastien ROUCARIES wrote:
> Perhaps using a pointerhackalign trick on this structure where
> #define pointerhackalign(x) __attribute__ ((aligned (x)))
> and declare
> struct klist_node {
> ...
> } pointerhackalign(2);
>
> Because __attribute__ ((aligned (x))) could only increase alignment
> it will safe to do that and serve as documentation purpose :)

That works, but we need to do it not for the struct klist_node,
but for the struct we insert into the void * in klist_node,
which is struct klist.

Reported-by: Hinko Kocevar <[email protected]
Cc: Bastien ROUCARIES <[email protected]>
Signed-off-by: Jesper Nilsson <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: Remove completion from struct klist_node

Removing the completion from klist_node reduces its size from 64 bytes
to 28 on x86-64. To maintain the semantics of klist_remove(), we add
a s

driver core: Remove completion from struct klist_node

Removing the completion from klist_node reduces its size from 64 bytes
to 28 on x86-64. To maintain the semantics of klist_remove(), we add
a single list of klist nodes which are pending deletion and scan them.

Signed-off-by: Matthew Wilcox <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

klist: don't iterate over deleted entries

A klist entry is kept on the list till all its current iterations are
finished; however, a new iteration after deletion also iterates over
deleted entries a

klist: don't iterate over deleted entries

A klist entry is kept on the list till all its current iterations are
finished; however, a new iteration after deletion also iterates over
deleted entries as long as their reference count stays above zero.
This causes problems for cases where there are users which iterate
over the list while synchronized against list manipulations and
natuarally expect already deleted entries to not show up during
iteration.

This patch implements dead flag which gets set on deletion so that
iteration can skip already deleted entries. The dead flag piggy backs
on the lowest bit of knode->n_klist and only visible to klist
implementation proper.

While at it, drop klist_iter->i_head as it's redundant and doesn't
offer anything in semantics or performance wise as klist_iter->i_klist
is dereferenced on every iteration anyway.

Signed-off-by: Tejun Heo <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Alan Stern <[email protected]>
Cc: Jens Axboe <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>

show more ...

klist: fix coding style errors in klist.h and klist.c

Finally clean up the odd spacing in these files.

Signed-off-by: Greg Kroah-Hartman <[email protected]>

klist: implement klist_add_{after|before}()

Add klist_add_after() and klist_add_before() which puts a new node
after and before an existing node, respectively. This is useful for
callers which need

klist: implement klist_add_{after|before}()

Add klist_add_after() and klist_add_before() which puts a new node
after and before an existing node, respectively. This is useful for
callers which need to keep klist ordered. Note that synchronizing
between simultaneous additions for ordering is the caller's
responsibility.

Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

klist: implement KLIST_INIT() and DEFINE_KLIST()

klist is missing static initializers and definition helper. Add them.

Signed-off-by: Tejun Heo <[email protected]>
Cc: Peter Zijlstra <peterz@infrad

klist: implement KLIST_INIT() and DEFINE_KLIST()

klist is missing static initializers and definition helper. Add them.

Signed-off-by: Tejun Heo <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

[PATCH] fix klist semantics for lists which have elements removed on traversal

The problem is that klists claim to provide semantics for safe traversal of
lists which are being modified. The failur

[PATCH] fix klist semantics for lists which have elements removed on traversal

The problem is that klists claim to provide semantics for safe traversal of
lists which are being modified. The failure case is when traversal of a
list causes element removal (a fairly common case). The issue is that
although the list node is refcounted, if it is embedded in an object (which
is universally the case), then the object will be freed regardless of the
klist refcount leading to slab corruption because the klist iterator refers
to the prior element to get the next.

The solution is to make the klist take and release references to the
embedding object meaning that the embedding object won't be released until
the list relinquishes the reference to it.

(akpm: fast-track this because it's needed for the 2.6.13 scsi merge)

Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

[PATCH] klist: fix klist to have the same klist_add semantics as list_head

at the moment, the list_head semantics are

list_add(node, head)

whereas current klist semantics are

klist_add(head, node

[PATCH] klist: fix klist to have the same klist_add semantics as list_head

at the moment, the list_head semantics are

list_add(node, head)

whereas current klist semantics are

klist_add(head, node)

This is bound to cause confusion, and since klist is the newcomer, it
should follow the list_head semantics.

I also added missing include guards to klist.h

Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

[PATCH] add klist_node_attached() to determine if a node is on a list or not.

Signed-off-by: Patrick Mochel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

diff -Nru

[PATCH] add klist_node_attached() to determine if a node is on a list or not.

Signed-off-by: Patrick Mochel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

diff -Nru a/include/linux/klist.h b/include/linux/klist.h

show more ...

[PATCH] Add initial implementation of klist helpers.

This klist interface provides a couple of structures that wrap around
struct list_head to provide explicit list "head" (struct klist) and
list "n

[PATCH] Add initial implementation of klist helpers.

This klist interface provides a couple of structures that wrap around
struct list_head to provide explicit list "head" (struct klist) and
list "node" (struct klist_node) objects. For struct klist, a spinlock
is included that protects access to the actual list itself. struct
klist_node provides a pointer to the klist that owns it and a kref
reference count that indicates the number of current users of that node
in the list.

The entire point is to provide an interface for iterating over a list
that is safe and allows for modification of the list during the
iteration (e.g. insertion and removal), including modification of the
current node on the list.

It works using a 3rd object type - struct klist_iter - that is declared
and initialized before an iteration. klist_next() is used to acquire the
next element in the list. It returns NULL if there are no more items.
This klist interface provides a couple of structures that wrap around
struct list_head to provide explicit list "head" (struct klist) and
list "node" (struct klist_node) objects. For struct klist, a spinlock
is included that protects access to the actual list itself. struct
klist_node provides a pointer to the klist that owns it and a kref
reference count that indicates the number of current users of that node
in the list.

The entire point is to provide an interface for iterating over a list
that is safe and allows for modification of the list during the
iteration (e.g. insertion and removal), including modification of the
current node on the list.

It works using a 3rd object type - struct klist_iter - that is declared
and initialized before an iteration. klist_next() is used to acquire the
next element in the list. It returns NULL if there are no more items.
Internally, that routine takes the klist's lock, decrements the reference
count of the previous klist_node and increments the count of the next
klist_node. It then drops the lock and returns.

There are primitives for adding and removing nodes to/from a klist.
When deleting, klist_del() will simply decrement the reference count.
Only when the count goes to 0 is the node removed from the list.
klist_remove() will try to delete the node from the list and block
until it is actually removed. This is useful for objects (like devices)
that have been removed from the system and must be freed (but must wait
until all accessors have finished).

Internally, that routine takes the klist's lock, decrements the reference
count of the previous klist_node and increments the count of the next
klist_node. It then drops the lock and returns.

There are primitives for adding and removing nodes to/from a klist.
When deleting, klist_del() will simply decrement the reference count.
Only when the count goes to 0 is the node removed from the list.
klist_remove() will try to delete the node from the list and block
until it is actually removed. This is useful for objects (like devices)
that have been removed from the system and must be freed (but must wait
until all accessors have finished).

Signed-off-by: Patrick Mochel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

diff -Nru a/include/linux/klist.h b/include/linux/klist.h

show more ...