linux-toradex.git/lib/klist.c, branch v4.4.93

klist: fix starting point removed bug in klist iterators

2016-02-25T20:01:16+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

klist: implement klist_prev()

2015-07-28T07:50:42+00:00

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

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

2014-08-07T01:01:24+00:00

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 
Cc: "Paul E. McKenney" 
Cc: Christoph Hellwig 
Cc: Hugh Dickins 
Cc: Jeff Kirsher 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

klist: del waiter from klist_remove_waiters before wakeup waitting process

2013-05-21T17:16:39+00:00

There is a race between klist_remove and klist_release. klist_remove
uses a local var waiter saved on stack. When klist_release calls
wake_up_process(waiter->process) to wake up the waiter, waiter might run
immediately and reuse the stack. Then, klist_release calls
list_del(&waiter->list) to change previous
wait data and cause prior waiter thread corrupt.

The patch fixes it against kernel 3.9.

Signed-off-by: wang, biao 
Acked-by: Peter Zijlstra 
Signed-off-by: Greg Kroah-Hartman

lib: reduce the use of module.h wherever possible

2012-03-07T20:04:04+00:00

For files only using THIS_MODULE and/or EXPORT_SYMBOL, map
them onto including export.h -- or if the file isn't even
using those, then just delete the include.  Fix up any implicit
include dependencies that were being masked by module.h along
the way.

Signed-off-by: Paul Gortmaker

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