linux-stable.git/lib/klist.c, branch v3.2.99

klist: fix starting point removed bug in klist iterators

2016-02-27T14:28:47+00:00

commit 00cd29b799e3449f0c68b1cc77cd4a5f95b42d17 upstream.

The starting node for a klist iteration is often passed in from
somewhere way above the klist infrastructure, meaning there's no
guarantee the node is still on the list.  We've seen this in SCSI where
we use bus_find_device() to iterate through a list of devices.  In the
face of heavy hotplug activity, the last device returned by
bus_find_device() can be removed before the next call.  This leads to

Dec  3 13:22:02 localhost kernel: WARNING: CPU: 2 PID: 28073 at include/linux/kref.h:47 klist_iter_init_node+0x3d/0x50()
Dec  3 13:22:02 localhost kernel: Modules linked in: scsi_debug x86_pkg_temp_thermal kvm_intel kvm irqbypass crc32c_intel joydev iTCO_wdt dcdbas ipmi_devintf acpi_power_meter iTCO_vendor_support ipmi_si imsghandler pcspkr wmi acpi_cpufreq tpm_tis tpm shpchp lpc_ich mfd_core nfsd nfs_acl lockd grace sunrpc tg3 ptp pps_core
Dec  3 13:22:02 localhost kernel: CPU: 2 PID: 28073 Comm: cat Not tainted 4.4.0-rc1+ #2
Dec  3 13:22:02 localhost kernel: Hardware name: Dell Inc. PowerEdge R320/08VT7V, BIOS 2.0.22 11/19/2013
Dec  3 13:22:02 localhost kernel: ffffffff81a20e77 ffff880613acfd18 ffffffff81321eef 0000000000000000
Dec  3 13:22:02 localhost kernel: ffff880613acfd50 ffffffff8107ca52 ffff88061176b198 0000000000000000
Dec  3 13:22:02 localhost kernel: ffffffff814542b0 ffff880610cfb100 ffff88061176b198 ffff880613acfd60
Dec  3 13:22:02 localhost kernel: Call Trace:
Dec  3 13:22:02 localhost kernel: [] dump_stack+0x44/0x55
Dec  3 13:22:02 localhost kernel: [] warn_slowpath_common+0x82/0xc0
Dec  3 13:22:02 localhost kernel: [] ? proc_scsi_show+0x20/0x20
Dec  3 13:22:02 localhost kernel: [] warn_slowpath_null+0x1a/0x20
Dec  3 13:22:02 localhost kernel: [] klist_iter_init_node+0x3d/0x50
Dec  3 13:22:02 localhost kernel: [] bus_find_device+0x51/0xb0
Dec  3 13:22:02 localhost kernel: [] scsi_seq_next+0x2d/0x40
[...]

And an eventual crash. It can actually occur in any hotplug system
which has a device finder and a starting device.

We can fix this globally by making sure the starting node for
klist_iter_init_node() is actually a member of the list before using it
(and by starting from the beginning if it isn't).

Reported-by: Ewan D. Milne 
Tested-by: Ewan D. Milne 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

driver core: Remove completion from struct klist_node

2009-01-06T18:44:30+00:00

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 
Signed-off-by: Greg Kroah-Hartman

klist: don't iterate over deleted entries

2008-10-09T06:56:04+00:00

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 
Cc: Greg Kroah-Hartman 
Cc: Alan Stern 
Cc: Jens Axboe 
Signed-off-by: Jens Axboe

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

2008-04-30T23:52:58+00:00

Finally clean up the odd spacing in these files.

Signed-off-by: Greg Kroah-Hartman

klist: implement klist_add_{after|before}()

2008-04-30T23:52:47+00:00

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 
Signed-off-by: Greg Kroah-Hartman

Driver core: Don't call put methods while holding a spinlock

2006-09-26T04:08:40+00:00

The klist utility routines currently call _put methods while holding a
spinlock.  This is of course illegal; a put routine could try to
unregister a device and hence need to sleep.

No problems have arisen until now because in many cases klist removals
were done synchronously, so the _put methods were never actually used.
In other cases we may simply have been lucky.

This patch (as784) reworks the klist routines so that _put methods are
called only _after_ the klist's spinlock has been released.

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

[PATCH] klist: Fix broken kref counting in find functions

2006-01-05T00:18:08+00:00

The klist reference counting in the find functions that use
klist_iter_init_node is broken.  If the function (for example
driver_find_device) is called with a NULL start object then everything is
fine, the first call to next_device()/klist_next increases the ref-count of
the first node on the list and does nothing for the start object which is
NULL.

If they are called with a valid start object then klist_next will decrement
the ref-count for the start object but nobody has incremented it.  Logical
place to fix this would be klist_iter_init_node because the function puts a
reference of the object into the klist_iter struct.

Signed-off-by: Martin Schwidefsky 
Signed-off-by: Frank Pavlic 
Cc: Patrick Mochel 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

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

2005-09-08T01:26:54+00:00

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 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

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

2005-09-05T23:03:13+00:00

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 
Signed-off-by: Greg Kroah-Hartman

[PATCH] Don't reference NULL klist pointer in klist_remove().

2005-06-20T22:15:19+00:00

Signed-off-by: Patrick Mochel 
Signed-off-by: Greg Kroah-Hartman 

diff -Nru a/lib/klist.c b/lib/klist.c