iio: adis_lib: Initialize trigger before requesting interrupt
The adis_probe_trigger() creates a new IIO trigger and requests an
interrupt associated with the trigger. The interrupt uses the generic
iio_trigger_generic_data_rdy_poll() function as its interrupt handler.
Currently the driver initializes some fields of the trigger structure after
the interrupt has been requested. But an interrupt can fire as soon as it
has been requested. This opens up a race condition.
iio_trigger_generic_data_rdy_poll() will access the trigger data structure
and dereference the ops field. If the ops field is not yet initialized this
will result in a NULL pointer deref.
It is not expected that the device generates an interrupt at this point, so
typically this issue did not surface unless e.g. due to a hardware
misconfiguration (wrong interrupt number, wrong polarity, etc.).
But some newer devices from the ADIS family start to generate periodic
interrupts in their power-on reset configuration and unfortunately the
interrupt can not be masked in the device. This makes the race condition
much more visible and the following crash has been observed occasionally
when booting a system using the ADIS16460.
Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = c0004000
[00000008] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257
Hardware name: Xilinx Zynq Platform
task: ef04f640 task.stack: ef050000
PC is at iio_trigger_notify_done+0x30/0x68
LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20
pc : [<c042d868>] lr : [<c042d924>] psr: 60000193
sp : ef051bb8 ip : 00000000 fp : ef106400
r10: c081d80a r9 : ef3bfa00 r8 : 00000087
r7 : ef051bec r6 : 00000000 r5 : ef3bfa00 r4 : ee92ab00
r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : ee97e400
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 18c5387d Table: 0000404a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xef050210)
[<c042d868>] (iio_trigger_notify_done) from [<c0065b10>] (__handle_irq_event_percpu+0x88/0x118)
[<c0065b10>] (__handle_irq_event_percpu) from [<c0065bbc>] (handle_irq_event_percpu+0x1c/0x58)
[<c0065bbc>] (handle_irq_event_percpu) from [<c0065c30>] (handle_irq_event+0x38/0x5c)
[<c0065c30>] (handle_irq_event) from [<c0068e28>] (handle_level_irq+0xa4/0x130)
[<c0068e28>] (handle_level_irq) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c021ab7c>] (zynq_gpio_irqhandler+0xb8/0x13c)
[<c021ab7c>] (zynq_gpio_irqhandler) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c0065370>] (__handle_domain_irq+0x5c/0xb4)
[<c0065370>] (__handle_domain_irq) from [<c000940c>] (gic_handle_irq+0x48/0x8c)
[<c000940c>] (gic_handle_irq) from [<c0013e8c>] (__irq_svc+0x6c/0xa8)
To fix this make sure that the trigger is fully initialized before
requesting the interrupt.
Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library") Reported-by: Robin Getz <Robin.Getz@analog.com> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Andreas Klinger [Thu, 1 Feb 2018 20:49:24 +0000 (21:49 +0100)]
iio: srf08: fix link error "devm_iio_triggered_buffer_setup" undefined
Functions for triggered buffer support are needed by this module.
If they are not defined accidentally by another driver, there's an error
thrown out while linking.
Add a select of IIO_BUFFER and IIO_TRIGGERED_BUFFER in the Kconfig file.
Signed-off-by: Andreas Klinger <ak@it-klinger.de> Fixes: a83195937151 ("iio: srf08: add triggered buffer support") Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
staging: iio: ad5933: switch buffer mode to software
Since commit 152a6a884ae1 ("staging:iio:accel:sca3000 move
to hybrid hard / soft buffer design.")
the buffer mechanism has changed and the
INDIO_BUFFER_HARDWARE flag has been unused.
Since commit 2d6ca60f3284 ("iio: Add a DMAengine framework
based buffer")
the INDIO_BUFFER_HARDWARE flag has been re-purposed for
DMA buffers.
This driver has lagged behind these changes, and
in order for buffers to work, the INDIO_BUFFER_SOFTWARE
needs to be used.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Fixes: 2d6ca60f3284 ("iio: Add a DMAengine framework based buffer") Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Error handling in stm32h7_adc_enable routine doesn't unwind enable
sequence correctly. ADEN can only be cleared by hardware (e.g. by
writing one to ADDIS).
It's also better to clear ADRDY just after it's been set by hardware.
Fixes: 95e339b6e85d ("iio: adc: stm32: add support for STM32H7") Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
staging: iio: adc: ad7192: fix external frequency setting
The external clock frequency was set only when selecting
the internal clock, which is fixed at 4.9152 Mhz.
This is incorrect, since it should be set when any of
the external clock or crystal settings is selected.
Added range validation for the external (crystal/clock)
frequency setting.
Valid values are between 2.4576 and 5.12 Mhz.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
staging: pi433: Cleanup codestyle, indent statements after case labels
This patch changes the indentation of the statements after case labels.
The linux coding guidelines do not explicitly mentiond this but pretty
much all existing code doesn't put any statements into the same line of
their belonging case labels. Therefore this adapts to the more usual style.
Please note that there is still a lot of > 80 character lines which will
cause checkpatch warnings. This patch does not intent to fix this
already existing issue.
Luis Gerhorst [Wed, 10 Jan 2018 17:30:35 +0000 (18:30 +0100)]
staging: fbtft: Fix indentation
This fixes the checkpatch message:
CHECK: Alignment should match open parenthesis
#1380: FILE: drivers/staging/fbtft/fbtft-core.c:1380:
+ dev_warn(dev,
+ "no default functions for regwidth=%d and buswidth=%d\n",
Signed-off-by: Luis Gerhorst <linux-kernel@luisgerhorst.de> Signed-off-by: Jonny Schaefer <schaefer.jonny@gmail.com> Acked-by: Alexander Wuerstlein <arw@cs.fau.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Tue, 9 Jan 2018 17:06:40 +0000 (17:06 +0000)]
ncpfs: remove redundant cast of struct ncp_inode_info
Casting a value returned by memory an allocation function is
not required and can be removed. Also add in a newline after before
the first statement. Code clean up as suggested by coccinelle.
Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The dma mask var was defined as dma_addr_t but should be
u64. This showed as a sparse warning when building for 32 bit.
Fix it by changing type to u64 and drop the cast.
NeilBrown [Tue, 9 Jan 2018 01:19:38 +0000 (12:19 +1100)]
staging: lustre: replace LIBCFS_CPT_ALLOC()
LIBCFS_APT_ALLOC() calls kvmalloc_node() with GFP_NOFS
which is not permitted.
Mostly, a kmalloc_node(GFP_NOFS) is appropriate, though occasionally
the allocation is large and GFP_KERNEL is acceptable, so
kvmalloc_node() can be used.
This patch introduces 4 alternatives to LIBCFS_CPT_ALLOC():
kmalloc_cpt()
kzalloc_cpt()
kvmalloc_cpt()
kvzalloc_cpt().
Each takes a size, gfp flags, and cpt number.
Almost every call to LIBCFS_CPT_ALLOC() passes lnet_cpt_table()
as the table. This patch embeds that choice in the k*alloc_cpt()
macros, and opencode kzalloc_node(..., cfs_cpt_spread_node(..))
in the one case that lnet_cpt_table() isn't used.
When LIBCFS_CPT_ALLOC() is replaced, the matching LIBCFS_FREE()
is also replaced, with with kfree() or kvfree() as appropriate.
NeilBrown [Tue, 9 Jan 2018 01:19:38 +0000 (12:19 +1100)]
staging: lustre: use kmalloc for allocating ksock_tx
The size of the data structure is primarily controlled
by the iovec size, which is limited to 256.
Entries in this vector are 12 bytes, so the whole
will always fit in a page.
So it is safe to use kmalloc (kvmalloc not needed).
So replace LIBCFS_ALLOC with kmalloc.
NeilBrown [Tue, 9 Jan 2018 01:19:38 +0000 (12:19 +1100)]
staging: lustre: lnet-route: use kmalloc for small allocation
This allocation is reasonably small.
As the function is called "*_locked", it might not be safe
to perform a GFP_KERNEL allocation, so be safe and
use GFP_NOFS.
NeilBrown [Tue, 9 Jan 2018 01:19:38 +0000 (12:19 +1100)]
staging: lustre: Convert more LIBCFS_ALLOC allocation to direct GFP_KERNEL
None of these need to be GFP_NOFS, so use GFP_KERNEL explicitly
with kmalloc(), kvmalloc(), or kvmalloc_array().
Change matching LIBCFS_FREE() to kfree() or kvfree()
NeilBrown [Tue, 9 Jan 2018 01:19:38 +0000 (12:19 +1100)]
staging: lustre: change some LIBCFS_ALLOC calls to k?alloc(GFP_KERNEL)
When an allocation happens from process context rather than
filesystem context, it is best to use GFP_KERNEL rather than
LIBCFS_ALLOC() which always uses GFP_NOFS.
This include initialization during, or prior to, mount,
and code run from separate worker threads.
So for some of these cases, switch to kmalloc, kvmalloc, or
kvmalloc_array() as appropriate.
In some cases we preserve __GFP_ZERO (via kzalloc/kvzalloc), but in
others it is clear that allocated memory is immediately initialized.
In each case, the matching LIBCFS_FREE() is converted to
kfree() or kvfree()
This is just a subset of locations that need changing.
As there are quite a lot, I've broken them up into several
ad-hoc sets to avoid review-fatigue.
NeilBrown [Tue, 9 Jan 2018 01:19:38 +0000 (12:19 +1100)]
staging: lustre: lnet: use kmalloc/kvmalloc in router_proc
The buffers allocated in router_proc are to temporarily
hold strings created for procfs files.
So they do not need to be zeroed and are safe to use
GFP_KERNEL.
So use kmalloc() directly except in two cases where it
isn't trivial to confirm that the size is always small.
In those cases, use kvmalloc().
NeilBrown [Tue, 9 Jan 2018 01:19:38 +0000 (12:19 +1100)]
staging: lustre: lnet: selftest: don't allocate small strings.
All of the "name" buffers here are at most LST_NAME_SIZE+1
bytes, so 33 bytes at most.
They are only used temporarily during the life of the function
that allocates them.
So it is much simpler to just allocate on the stack.
Worst case is lst_tet_add_ioct(), which allocates
3 for these which 99 bytes on the stack, instead of the 24 that would
have been allocated for 64-bit pointers.
NeilBrown [Tue, 9 Jan 2018 01:19:38 +0000 (12:19 +1100)]
staging: lustre: lnet: switch to cpumask_var_t
So that we can use the common cpumask allocation functions,
switch to cpumask_var_t.
We need to be careful not to free a cpumask_var_t until the
variable has been initialized, and it cannot be initialized
directly.
So we must be sure either that it is filled with zeros, or
that zalloc_cpumask_var() has been called on it.
Laura Abbott [Fri, 5 Jan 2018 19:14:09 +0000 (11:14 -0800)]
staging: android: ion: Switch from WARN to pr_warn
Syzbot reported a warning with Ion:
WARNING: CPU: 0 PID: 3502 at drivers/staging/android/ion/ion-ioctl.c:73 ion_ioctl+0x2db/0x380 drivers/staging/android/ion/ion-ioctl.c:73
Kernel panic - not syncing: panic_on_warn set ...
This is a warning that validation of the ioctl fields failed. This was
deliberately added as a warning to make it very obvious to developers that
something needed to be fixed. In reality, this is overkill and disturbs
fuzzing. Switch to pr_warn for a message instead.
This is a warning about attempting to allocate order > MAX_ORDER. This
is coming from a userspace Ion allocation request. Since userspace is
free to request however much memory it wants (and the kernel is free to
deny its allocation), silence the allocation attempt with __GFP_NOWARN
in case it fails.
Ioana Radulescu [Fri, 5 Jan 2018 11:04:32 +0000 (05:04 -0600)]
staging: fsl-dpaa2/eth: Use affine DPIO services
Use the newly added DPIO service API to map cpu-affine DPIO services
to channels.
The DPAA2 Ethernet driver already had mappings of frame queues and
channels to cpus, but had no control over the DPIOs used. We can
now ensure full affinity of hotpath hardware resources to cores,
which improves performance and almost eliminates some resource
contentions (e.g. enqueue/dequeue busy counters should be close to
zero from now on).
Making the pull channel operation core affine brings the most
significant benefits. This ensures the same DPIO service will be
used for all dequeue commands issued for a certain frame queue,
which is in line with the way hardware is optimized.
Additionally, we also use affine DPIOs for the frame enqueue and
buffer release operations in order to avoid resource contention.
dpaa2_io_service_register() and dpaa2_io_service_rearm()
functions receive an affine DPIO as argument mostly for uniformity,
but this doesn't change the previous functionality.
Ioana Radulescu [Fri, 5 Jan 2018 11:04:31 +0000 (05:04 -0600)]
staging: fsl-mc/dpio: Add dpaa2_io_service_select() API
All DPIO service API functions receive a dpaa2_io service pointer
as parameter (NULL meaning any service will do) which indicates
the hardware resource to be used to execute the specified command.
There isn't however any available API for obtaining such a service
reference that could be used further, effectively forcing the users
to always request a random service for DPIO operations.
(The DPIO driver holds internally an array mapping services to cpus,
and affine services can be indirectly requested by a couple of API
functions: dpaa2_io_service_register and dpaa2_io_service_rearm
use the cpu id provided by the user to select the corresponding
service)
This patch adds a function for selecting a DPIO service based on
the specified cpu id. If the user provides a "don't care" value
for the cpu, we revert to the default behavior and return the next
DPIO, taken in a round-robin fashion from a list of available
services.
Jia-Ju Bai [Sun, 24 Dec 2017 10:16:55 +0000 (18:16 +0800)]
staging: rtl8192u: Replace mdelay with msleep in rtl8192_usb_probe
rtl8192_usb_probe is not called in an interrupt handler
nor holding a spinlock.
The function mdelay in it can be replaced with msleep,
to avoid busy wait.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Kishore KP [Sun, 24 Dec 2017 14:03:54 +0000 (19:33 +0530)]
staging: vc04_services: Prefer WARN_ON_ONCE instead of if condition followed by BUG.
Coccinelle suggested to use BUG_ON instead of if condition followed by BUG
but BUG_ON should be used in situations where integrity of the system is no
longer guaranteed. In this case, as suggested by Stefan Wahren, vchiq isn't
critical.
Since it is not critical, BUG_ON should be avoided.
Replaced if condition followed by BUG with WARN_ON_ONCE.
This print the inode number of backing file and the name in
/proc/pid/fdinfo/fd.
These information helps users to know which processes are sharing the same
ashmem.
hash_init was mapping DMA memory that were then being unmap in
hash_digest/final/finup callbacks, which is against the Crypto API
usage rules (see discussion at
https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg30077.html)
Fix it by moving all buffer mapping/unmapping or each Crypto API op.
This also properly deals with hash_import() not knowing if
hash_init was called or not as it now no longer matters.
Move to allocating the buffers needed for requests as part of
the request structure instead of malloc'ing each one on it's
own, making for simpler (and more efficient) code.
The ccree hash code is using a double buffer to hold data
for processing but manages the buffers and their associated
data count in two separate fields and uses a predicate to
chose which to use.
Move to using a proper 2 members array for a much cleaner code.
stating: ccree: revert "staging: ccree: fix leak of import() after init()"
This reverts commit c5f39d07860c ("staging: ccree: fix leak of import()
after init()") and commit aece09024414 ("staging: ccree: Uninitialized
return in ssi_ahash_import()").
This is the wrong solution and ends up relying on uninitialized memory,
although it was not obvious to me at the time.
Crypto API tfm providers are required to provide a backlog
service, if so indicated, that queues up requests in the case
of the provider being busy and processing them later.
The ccree driver did not provide this facility. Add it now.
staging: ccree: break send_request and fix ret val
The send_request() function was handling both synchronous
and asynchronous invocations, but were not handling
the asynchronous case, which may be called in an atomic
context, properly as it was sleeping.
Start to fix the problem by breaking up the two use
cases to separate functions calling a common internal
service function and return error instead of sleeping
for the asynchronous case.
The next patch will complete the fix by implementing
proper backlog handling.
staging: ccree: pick alloc mem flags based on req flags
The ccree driver was allocating memory using GFP_KERNEL flag
always, ignoring the flags set in the crypto request. Fix it
by choosing gfp flags based on crypto request flags.
vboxvideo: Fix incorrect type in assignment sparse warning
Sparse emitted the following warning:
../drivers/staging/vboxvideo/vbox_fb.c:173:27: warning: incorrect type in assignment (different address spaces)
../drivers/staging/vboxvideo/vbox_fb.c:173:27: expected char [noderef] <asn:2>*screen_base
../drivers/staging/vboxvideo/vbox_fb.c:173:27: got void *virtual
The vbox_bo buffer object kernel mapping is handled by a call
to ttm_bo_kmap() prior to the assignment of bo->kmap.virtual to
info->screen_base of type char __iomem*.
Casting bo->kmap.virtual to char __iomem* in this assignment fixes
the warning.
vboxvideo: Fix address space of expression removal sparse warning
Sparse emitted the following warning:
../drivers/staging/vboxvideo/vbox_main.c:64:25: warning: cast removes address space of expression
vbox->vbva_buffers iomapping is handled by calling vbox_accel_init()
from vbox_hw_init().
__force attribute is used in assignment to vbva to fix the warning.
Signed-off-by: Alexander Kapshuk <alexander.kapshuk@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
lu_global_fini() explicitly uses knowledge about shrinker's
internals to make decision about calling of unregister_shrinker().
Now this check was integrated into unregister_shrinker(),
so it is safe to call it against unregistered shrinker.
NeilBrown [Mon, 18 Dec 2017 01:41:42 +0000 (12:41 +1100)]
staging: lustre: replace cfs_srand() calls with add_device_randomness().
The only places that cfs_srand is called, the random bits are
mixed with bits from get_random_bytes(). So it is equally effective
to add entropy to either pool.
So we can replace calls to cfs_srand() with calls that add the
entropy with add_device_randomness(). That function adds time-based
entropy, so we can discard the ktime_get_ts64 calls.
One location in lustre_handles.c only adds timebased
entropy. This cannot improve the entropy provided by get_random_bytes(),
so just discard that call.
NeilBrown [Mon, 18 Dec 2017 01:41:42 +0000 (12:41 +1100)]
staging: lustre: replace cfs_rand() with prandom_u32_max()
All occurrences of
cfs_rand() % X
are replaced with
prandom_u32_max(X)
cfs_rand() is a simple Linear Congruential PRNG. prandom_u32_max()
is at least as random, is seeded with more randomness, and uses
cpu-local state to avoid cross-cpu issues.
This is the first step is discarding the libcfs prng with
the standard linux prng.
projects / kernel.git / log