The commit 6d1368e8f9 ("scsi: qedf: fixup locking in
qedf_restart_rport()") introduced the lock. Though the lock protects
only the fc_rport_create() call. Thus, we can move the mutex unlock up
before the if statement and drop the else body.
Link: https://lore.kernel.org/r/20200403092717.19779-1-dwagner@suse.de
Cc: Hannes Reinecke <hare@suse.com>
Cc: Saurav Kashyap <skashyap@marvell.com>
Signed-off-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reporting hides KCSAN runtime functions in the stack trace, with
filtering done based on function names. Currently this included all
functions (or modules) that would match "kcsan_". Make the filter aware
of KCSAN tests, which contain "kcsan_test", and are no longer skipped in
the report.
This is in preparation for adding a KCSAN test module.
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Pass string length as returned by scnprintf() to strnstr(), since
strnstr() searches exactly len bytes in haystack, even if it contains a
NUL-terminator before haystack+len.
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Thus far, accesses marked with data_race() would still require the
racing access to be marked in some way (be it with READ_ONCE(),
WRITE_ONCE(), or data_race() itself), as otherwise KCSAN would still
report a data race. This requirement, however, seems to be unintuitive,
and some valid use-cases demand *not* marking other accesses, as it
might hide more serious bugs (e.g. diagnostic reads).
Therefore, this commit changes data_race() to no longer require marking
racing accesses (although it's still recommended if possible).
The alternative would have been introducing another variant of
data_race(), however, since usage of data_race() already needs to be
carefully reasoned about, distinguishing between these cases likely adds
more complexity in the wrong place.
Link: https://lkml.kernel.org/r/20200331131002.GA30975@willie-the-truck
Cc: Paul E. McKenney <paulmck@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Qian Cai <cai@lca.pw>
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Both affect access checks, and should therefore be in kcsan-checks.h.
This is in preparation to use these in compiler.h.
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Introduce ASSERT_EXCLUSIVE_*_SCOPED(), which provide an intuitive
interface to use the scoped-access feature, without having to explicitly
mark the start and end of the desired scope. Basing duration of the
checks on scope avoids accidental misuse and resulting false positives,
which may be hard to debug. See added comments for usage.
The macros are implemented using __attribute__((__cleanup__(func))),
which is supported by all compilers that currently support KCSAN.
Suggested-by: Boqun Feng <boqun.feng@gmail.com>
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Add explicitly invoked KCSAN check functions to objtool's uaccess
whitelist. This is needed in order to permit calling into
kcsan_check_scoped_accesses() from the fast-path, which in turn calls
__kcsan_check_access(). __kcsan_check_access() is the generic variant
of the already whitelisted specializations __tsan_{read,write}N.
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
This adds support for scoped accesses, where the memory range is checked
for the duration of the scope. The feature is implemented by inserting
the relevant access information into a list of scoped accesses for
the current execution context, which are then checked (until removed)
on every call (through instrumentation) into the KCSAN runtime.
An alternative, more complex, implementation could set up a watchpoint for
the scoped access, and keep the watchpoint set up. This, however, would
require first exposing a handle to the watchpoint, as well as dealing
with cases such as accesses by the same thread while the watchpoint is
still set up (and several more cases). It is also doubtful if this would
provide any benefit, since the majority of delay where the watchpoint
is set up is likely due to the injected delays by KCSAN. Therefore,
the implementation in this patch is simpler and avoids hurting KCSAN's
main use-case (normal data race detection); it also implicitly increases
scoped-access race-detection-ability due to increased probability of
setting up watchpoints by repeatedly calling __kcsan_check_access()
throughout the scope of the access.
The implementation required adding an additional conditional branch to
the fast-path. However, the microbenchmark showed a *speedup* of ~5%
on the fast-path. This appears to be due to subtly improved codegen by
GCC from moving get_ctx() and associated load of preempt_count earlier.
Suggested-by: Boqun Feng <boqun.feng@gmail.com>
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
To avoid deadlock in case watchers can be interrupted, we need to ensure
that producers of the struct other_info can never be blocked by an
unrelated consumer. (Likely to occur with KCSAN_INTERRUPT_WATCHER.)
There are several cases that can lead to this scenario, for example:
1. A watchpoint A was set up by task T1, but interrupted by
interrupt I1. Some other thread (task or interrupt) finds
watchpoint A consumes it, and sets other_info. Then I1 also
finds some unrelated watchpoint B, consumes it, but is blocked
because other_info is in use. T1 cannot consume other_info
because I1 never returns -> deadlock.
2. A watchpoint A was set up by task T1, but interrupted by
interrupt I1, which also sets up a watchpoint B. Some other
thread finds watchpoint A, and consumes it and sets up
other_info with its information. Similarly some other thread
finds watchpoint B and consumes it, but is then blocked because
other_info is in use. When I1 continues it sees its watchpoint
was consumed, and that it must wait for other_info, which
currently contains information to be consumed by T1. However, T1
cannot unblock other_info because I1 never returns -> deadlock.
To avoid this, we need to ensure that producers of struct other_info
always have a usable other_info entry. This is obviously not the case
with only a single instance of struct other_info, as concurrent
producers must wait for the entry to be released by some consumer (which
may be locked up as illustrated above).
While it would be nice if producers could simply call kmalloc() and
append their instance of struct other_info to a list, we are very
limited in this code path: since KCSAN can instrument the allocators
themselves, calling kmalloc() could lead to deadlock or corrupted
allocator state.
Since producers of the struct other_info will always succeed at
try_consume_watchpoint(), preceding the call into kcsan_report(), we
know that the particular watchpoint slot cannot simply be reused or
consumed by another potential other_info producer. If we move removal of
a watchpoint after reporting (by the consumer of struct other_info), we
can see a consumed watchpoint as a held lock on elements of other_info,
if we create a one-to-one mapping of a watchpoint to an other_info
element.
Therefore, the simplest solution is to create an array of struct
other_info that is as large as the watchpoints array in core.c, and pass
the watchpoint index to kcsan_report() for producers and consumers, and
change watchpoints to be removed after reporting is done.
With a default config on a 64-bit system, the array other_infos consumes
~37KiB. For most systems today this is not a problem. On smaller memory
constrained systems, the config value CONFIG_KCSAN_NUM_WATCHPOINTS can
be reduced appropriately.
Overall, this change is a simplification of the prepare_report() code,
and makes some of the checks (such as checking if at least one access is
a write) redundant.
Tested:
$ tools/testing/selftests/rcutorture/bin/kvm.sh \
--cpus 12 --duration 10 --kconfig "CONFIG_DEBUG_INFO=y \
CONFIG_KCSAN=y CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC=n \
CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=n \
CONFIG_KCSAN_REPORT_ONCE_IN_MS=100000 CONFIG_KCSAN_VERBOSE=y \
CONFIG_KCSAN_INTERRUPT_WATCHER=y CONFIG_PROVE_LOCKING=y" \
--configs TREE03
=> No longer hangs and runs to completion as expected.
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Improve readability by introducing access_info and other_info structs,
and in preparation of the following commit in this series replaces the
single instance of other_info with an array of size 1.
No functional change intended.
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
In the pm860x_battery_probe(), when get irq failed, the function
platform_get_irq() logs an dev_err message, so remove redundant
message here.
Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The Meegopad T02 is a PC in stick format and doesn't have a battery,
it is reported with a random and constant battery charge but as
discharging to userspace.
Add it to the blacklist to avoid the bogus battery status reporting.
Signed-off-by: Rafael Gandolfi <rafirafi.at@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
vc4's firmware bus DMA limitations") as it turned out to be faulty
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEErOkkGDHCg2EbPcGjlfZmHno8x/4FAl5+ZSAACgkQlfZmHno8
x/7fWQf/SODT8sooJto4VFAbsDjXjNPmkqXBvFxYcPVN67ET2pSFdiGpGV4/Zt0+
/f1/niWVvOXL8j4MicEjhQeRwRCznzBHb07PW33ynf6i7u+b3eGr/gbfFckbpSsV
FhN5/5rcH7ebnsekGRG3c0386IGtRZW3xE4Dk2wLcRv3qhgs98y+U8s5vGlaxXG6
KAim6SUlh+FZak58CcVovBUe30HpX9vxuuHUk8mzhhrDEbZqDY2VW4VkhcagnAc8
y6X0mriyv6EoJdDzPQtlq94c/siNKIEbrJ/E5ozUU3ZNAs4nu2KIoru0lhXgaNl9
rMnHqEKCCF1/8gXeN1+t2DHXBfVvkA==
=/iN4
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAl6U7aoACgkQh9CWnEQH
BwQcxA//d+oVlxMvuIJ0mN8vrorEUSLJYee1+yxEU5SrDFWey4Bs0JeSwT6DbMf8
bs9AY9hsmmeBW0LDgm6L0aY7FZFV7G2BhnMT3lqfuQ9vGpRYLQEARU4XUtmwq/YA
FEc4eBKPNGgs8+IVQQjLlbx/UuwJG0ocA/CPDJc8TwSMOE0mga6D++Ovd4WLTc9s
7XDTWa3hcbX5YRkHhM0quu+X2v4ed/fDZbM6UBDaqditL+ziKWnFAMrw0WZDDcfm
Go/j4lIjOiQE0MsZUzWsWfFXx8YSr15D5X8zGT5h4EslIQVvzEm6K69+1Bg8BfPF
EAEVxguekifzjVYkTV5TW6aNIH7DjhwGJeov3fqz4fAD+whW3CC+OL/JPQZh4U2L
fm5dGNRrV80HjkGV+pJiBl4uMg8Ezhjpc/b2stsElvCxwVbQLVhsCVvKOVj5g5ip
JELyYJ7N4KkEzlXTQnihAvF+VLBbhGDn0BCI/IZLjsUt2s3QoOIb5rcon+Ouu9/P
CnVNEHe2Pdaq8j2Lom76sbNAtjIDWGwTKeFDRZWk75s/m11Raq6J4r/c9oX0bR5v
GmSftZQ7VgAbbp9ynrgw0+7inroA6iLPnsIJccNiHABxZ4I083UFUlXBYYvWq5hH
eEU2gny6Bp52S0oF7U3UTxQXuGz4bAfiNTTLbG6cGGBwm778TxM=
=gRon
-----END PGP SIGNATURE-----
Merge tag 'tags/bcm2835-dt-fixes-2020-03-27' into devicetree/fixes
This patch is to be squashed into 55c7c06210 ("ARM: dts: bcm283x: Fix
vc4's firmware bus DMA limitations") as it turned out to be faulty
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
- Second patch adds a fixed regulator that controls the SD power and
hooks it up with emmc2.
- Third patch rolls back to the firmware based power driver as the MMIO
version is unstable.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEErOkkGDHCg2EbPcGjlfZmHno8x/4FAl5+ZkYACgkQlfZmHno8
x/51Iwf/XKTwPJsNu3qaPeLZP6r3sMUSpIkb09+uF48ecYT2kKltMSWy4AMRILx1
GuPVyfhH9EOL7kf2pui+DotWfZ6V0w8QXmw+h5jmvrSL7HmNj7t+AUvlX765h/9/
tb+6/3Yum+GJwrG7mSmBCXvV4S5ReCdifmNse1WujgX5AfLZ/8SSdLl7/vwl5UTn
xkhGyGjGNwiabqwVZGAbhnv12IBsWPm7KAjpkPZRp6Yuyf9uawgnoNlIh4HDmH78
PBsXVoBlqlfBdroIVjjiUtcrqQIXxm4vcAwlCTXVKYC0boZib226a7D+bjrbVtRY
ou521MEikPI+tnydzQErBq7Ktj0SiA==
=q1oY
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAl6U7XMACgkQh9CWnEQH
BwTZFRAAj6RJzy61lcjwEALvCGZqTs/n17Ecpnd7BD+nfv8Ug2umEYrvDalvVOAg
uTPKGM2feA/eWks+bFSgF8auPnHdO+XBm8FmDJAMr8/fN6mP5Fm8pcBqS59U9lOb
ASRzIBjOK06SFkFzMas0AVtLMaRo/DwsASqx8Bc6UHxI9ZMKIaBRHChdaDTiH3md
5JinxSmOkPaAX+wB0rcpVIL/T3pSf5I6DrXCkhU0dsER2NxRiYdvnAdyE12i4emn
FCVplHyUCyzicU/qtwMBNqBfpTVOZ5PT9WAotMN329Csy0D95QKTUPuri0F3qOXW
UeuE9UPex1ZOF3kNhLlFmlZRBaPaQsih2EEQOdKenZWffj5RXLVjGjmAYoHj6rew
7BoEpEiPCAZWPAOyEWg9OqvOd5z7Dj7Xr1ukfGuf1UZ01ZsmTvrUyNIELRPFpRg9
6Z+X2iH/pU9VwvBhloT/8lWKdRF0TAE8PJR5NnXFn2SFKZ+Fue2ubaJ0dMjAeAqK
/mQFod5+QbKcZkG65L2GY6+C1rj3ZVxEx+dUZxtfTQqPDsTPRjl08YjvFgmzT6LD
VhzVnw+dzUPo0BM0MrjxwjryRkdQW1iMijvXzRa7qsYbRW4dZc/kig57Xft6L0zQ
hi9dvfPgJYbEnwn24WYkbksbPt1jTCAwekNm1V5ks9o/mOSogSA=
=Aotf
-----END PGP SIGNATURE-----
Merge tag 'tags/bcm2835-dt-next-2020-03-27' into devicetree/next
- First patch updates RPi4's expgpio's GPIO labels, adding the SD power rail.
- Second patch adds a fixed regulator that controls the SD power and
hooks it up with emmc2.
- Third patch rolls back to the firmware based power driver as the MMIO
version is unstable.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead to data loss when the
buffer size used is smaller than the available data.
This change fixes this issue and allows user space to read all OA data
even when using a buffer size smaller than the available data using
multiple non-blocking reads rather than staying blocked in poll till
the next timer interrupt.
v2: Fix ret value for blocking reads (Umesh)
v3: Mistake during patch send (Ashutosh)
v4: Remove -EAGAIN from comment (Umesh)
v5: Improve condition for clearing pollin and return (Lionel)
v6: Improve blocking read loop and other cleanups (Lionel)
v7: Added Cc stable
Testcase: igt/perf/polling-small-buf
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200403010120.3067-1-ashutosh.dixit@intel.com
(cherry-picked from commit 6352219c39)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Fix the following gcc warning:
drivers/power/supply/max14656_charger_detector.c:142:6: warning:
variable ‘ret’ set but not used [-Wunused-but-set-variable]
int ret = 0;
^~~
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The commit c31427d0d2 ("ALSA: hda: No preallocation on x86
platforms") changed CONFIG_SND_HDA_PREALLOC_SIZE setup and its default
to zero for x86, as the preallocation should work almost all cases.
However, this expectation was too naive; some applications try to
allocate as the max buffer size as possible, and it leads to the
memory exhaustion. More badly, the commit changed the kconfig no
longer adjustable for x86, so you can't fix it statically (although it
can be still adjusted via procfs).
So, practically seen, it's more recommended to set a reasonable limit
for x86, too. This patch follows to that experience, and changes the
default to 2048 and allow the kconfig adjustable again.
Fixes: c31427d0d2 ("ALSA: hda: No preallocation on x86 platforms")
Cc: <stable@vger.kernel.org>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207223
Link: https://lore.kernel.org/r/20200413201919.24241-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Merging 5.7 fixes branch as of April 13, containing two fixes to branch
destined for chrome-platform-5.8.
538b8471fe platform/chrome: cros_ec_sensorhub: Add missing '\n' in log messages
5b69c23799 platform/chrome: cros_ec_sensorhub: Off by one in cros_sensorhub_send_sample()
Signed-off-by: Benson Leung <bleung@chromium.org>
We need to drop the inode spinlock while calling nfs4_select_rw_stateid(),
since nfs4_copy_delegation_stateid() could take the delegation lock.
Note that it is safe to do this, since all other calls to
pnfs_update_layout() for that inode will find themselves blocked by
the lock we hold on NFS_LAYOUT_FIRST_LAYOUTGET.
Fixes: fc51b1cf39 ("NFS: Beware when dereferencing the delegation cred")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Don't gate uart1_eb which provides console clock, gating that clock would
make serial stop working if serial driver didn't enable that explicitly.
Fixes: 0e4b8a2349 ("clk: sprd: add clocks support for SC9863A")
Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
Link: https://lkml.kernel.org/r/20200408020234.31764-1-zhang.lyra@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The newly added function is only built into the kernel if mmp2
is enabled, causing a link error otherwise.
arm-linux-gnueabi-ld: drivers/clk/mmp/clk.o: in function `mmp_register_pll_clks':
clk.c:(.text+0x6dc): undefined reference to `mmp_clk_register_pll'
Move it to a different file to get it to link.
Fixes: 5d34d0b32d ("clk: mmp2: Add support for PLL clock sources")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lkml.kernel.org/r/20200408160518.2798571-1-arnd@arndb.de
Reported-by: Guenter Roeck <linux@roeck-us.net>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The __clk_hw_register_fixed_rate_with_accuracy() function (with two '_')
does not exist, and apparently never did:
drivers/clk/clk-asm9260.c: In function 'asm9260_acc_init':
drivers/clk/clk-asm9260.c:279:7: error: implicit declaration of function '__clk_hw_register_fixed_rate_with_accuracy'; did you mean 'clk_hw_register_fixed_rate_with_accuracy'? [-Werror=implicit-function-declaration]
279 | hw = __clk_hw_register_fixed_rate_with_accuracy(NULL, NULL, pll_clk,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| clk_hw_register_fixed_rate_with_accuracy
drivers/clk/clk-asm9260.c:279:5: error: assignment to 'struct clk_hw *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
279 | hw = __clk_hw_register_fixed_rate_with_accuracy(NULL, NULL, pll_clk,
| ^
From what I can tell, __clk_hw_register_fixed_rate() is the correct
API here, so use that instead.
Fixes: 728e309674 ("clk: asm9260: Use parent accuracy in fixed rate clk")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lkml.kernel.org/r/20200408155402.2138446-1-arnd@arndb.de
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Original cgroup v2 eBPF code for filtering device access made it
possible to compile with CONFIG_CGROUP_DEVICE=n and still use the eBPF
filtering. Change
commit 4b7d4d453f ("device_cgroup: Export devcgroup_check_permission")
reverted this, making it required to set it to y.
Since the device filtering (and all the docs) for cgroup v2 is no longer
a "device controller" like it was in v1, someone might compile their
kernel with CONFIG_CGROUP_DEVICE=n. Then (for linux 5.5+) the eBPF
filter will not be invoked, and all processes will be allowed access
to all devices, no matter what the eBPF filter says.
Signed-off-by: Odin Ugedal <odin@ugedal.com>
Acked-by: Roman Gushchin <guro@fb.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
The cleanup in commit 630f289b71 ("asm-generic: make more
kernel-space headers mandatory") did not take into account the recently
added line for hardirq.h in commit acc45648b9 ("m68k: Switch to
asm-generic/hardirq.h"), leading to the following message during the
build:
scripts/Makefile.asm-generic:25: redundant generic-y found in arch/m68k/include/asm/Kbuild: hardirq.h
Fix this by dropping the now redundant line.
Fixes: 630f289b71 ("asm-generic: make more kernel-space headers mandatory")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In case command ring buffer becomes inconsistent, tcmu sets device flag
TCMU_DEV_BIT_BROKEN. If the bit is set, tcmu rejects new commands from LIO
core with TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE, and no longer processes
completions from the ring. The reset_ring attribute can be used to
completely clean up the command ring, so after reset_ring the ring no
longer is inconsistent.
Therefore reset_ring also should reset bit TCMU_DEV_BIT_BROKEN to allow
normal processing.
Link: https://lore.kernel.org/r/20200409101026.17872-1-bstroesser@ts.fujitsu.com
Acked-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Creation of the response to READ FULL STATUS fails for FC based
reservations. Reason is the too high loop limit (< 24) in
fc_get_pr_transport_id(). The string representation of FC WWPN is 23 chars
long only ("11:22:33:44:55:66:77:88"). So when i is 23, the loop body is
executed a last time for the ending '\0' of the string and thus hex2bin()
reports an error.
Link: https://lore.kernel.org/r/20200408132610.14623-3-bstroesser@ts.fujitsu.com
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This patch fixes a minor flaw that could be triggered by a PR OUT RESERVE
on iSCSI, if TRANSPORT IDs with and without ISID are used in the same
command. In case an ISCSI Transport ID has no ISID, port_nexus_ptr was not
used to write NULL, so value from previous call might persist. I don't
know if that ever could happen, but with the change the code is cleaner, I
think.
Link: https://lore.kernel.org/r/20200408132610.14623-2-bstroesser@ts.fujitsu.com
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add njavali@marvell.com as new maintainer.
Also add Marvell Upstream email alias to the maintainers list.
Link: https://lore.kernel.org/r/20200403084018.30766-3-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/scsi/qla2xxx/qla_dbg.c:2542:7: warning: The scope of the variable 'pbuf'
can be reduced. [variableScope]
drivers/scsi/qla2xxx/qla_init.c:3615:6: warning: Variable 'rc' is assigned a
value that is never used. [unreadVariable]
drivers/scsi/qla2xxx/qla_isr.c:81:11-29: WARNING: dma_alloc_coherent use in
rsp_els already zeroes out memory, so memset is not needed
drivers/scsi/qla2xxx/qla_mbx.c:4889:15-33: WARNING: dma_alloc_coherent use in
els_cmd_map already zeroes out memory, so memset is not needed
[mkp: added newline after variable declaration]
Link: https://lore.kernel.org/r/20200403084018.30766-2-njavali@marvell.com
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The new async dirops callback routines can pass ERR_PTR values to
ceph_mdsc_free_path, which could cause an oops. Make ceph_mdsc_free_path
ignore ERR_PTR values. Also, ensure that the pr_warn messages look sane
even if ceph_mdsc_build_path fails.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
If SATA_HOST is n, build fails:
drivers/scsi/hisi_sas/hisi_sas_main.o: In function
`hisi_sas_fill_ata_reset_cmd': hisi_sas_main.c:(.text+0x2500): undefined
reference to `ata_tf_to_fis'
Select SATA_HOST to fix this.
Link: https://lore.kernel.org/r/20200402085812.32948-1-yuehaibing@huawei.com
Fixes: bd322af15c ("ata: make SATA_PMP option selectable only if any SATA host driver is enabled")
Reported-by: Hulk Robot <hulkci@huawei.com>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: John Garry <john.garry@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
If the request has been marked as canceled, don't try and issue it.
Instead just fill a canceled event and finish the request.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Remove "params.h" include, which has been dropped in GCC 10.
Remove is_a_helper() macro, which is now defined in gimple.h, as seen
when running './scripts/gcc-plugin.sh g++ g++ gcc':
In file included from <stdin>:1:
./gcc-plugins/gcc-common.h:852:13: error: redefinition of ‘static bool is_a_helper<T>::test(U*) [with U = const gimple; T = const ggoto*]’
852 | inline bool is_a_helper<const ggoto *>::test(const_gimple gs)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./gcc-plugins/gcc-common.h:125,
from <stdin>:1:
/usr/lib/gcc/x86_64-redhat-linux/10/plugin/include/gimple.h:1037:1: note: ‘static bool is_a_helper<T>::test(U*) [with U = const gimple; T = const ggoto*]’ previously declared here
1037 | is_a_helper <const ggoto *>::test (const gimple *gs)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
Add -Wno-format-diag to scripts/gcc-plugins/Makefile to avoid
meaningless warnings from error() formats used by plugins:
scripts/gcc-plugins/structleak_plugin.c: In function ‘int plugin_init(plugin_name_args*, plugin_gcc_version*)’:
scripts/gcc-plugins/structleak_plugin.c:253:12: warning: unquoted sequence of 2 consecutive punctuation characters ‘'-’ in format [-Wformat-diag]
253 | error(G_("unknown option '-fplugin-arg-%s-%s'"), plugin_name, argv[i].key);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Frédéric Pierret (fepitre) <frederic.pierret@qubes-os.org>
Link: https://lore.kernel.org/r/20200407113259.270172-1-frederic.pierret@qubes-os.org
[kees: include -Wno-format-diag for plugin builds]
Signed-off-by: Kees Cook <keescook@chromium.org>
With GCC version >= 8, the cgraph_create_edge() macro argument using
"frequency" goes unused. Instead of assigning a temporary variable for
the argument, pass the compute_call_stmt_bb_frequency() call directly
as the macro argument so that it will just not be called when it is
not wanted by the macros.
Silences the warning:
scripts/gcc-plugins/stackleak_plugin.c:54:6: warning: variable ‘frequency’ set but not used [-Wunused-but-set-variable]
Now builds cleanly with gcc-7 and gcc-9. Both boot and pass
STACKLEAK_ERASING LKDTM test.
Signed-off-by: Kees Cook <keescook@chromium.org>
Elm is Acer Chromebook R13. Hana is Lenovo Chromebook. Both uses mt8173
SoC.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200210063523.133333-5-hsinyi@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Fixing several unit name warnings:
Warning (unit_address_vs_reg): /oscillator@0: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /oscillator@1: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /oscillator@2: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/trips/trip-point@0: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/trips/trip-point@1: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/trips/cpu_crit@0: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/cooling-maps/map@0: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/cooling-maps/map@1: node has a unit name, but no reg property
Warning (unit_address_vs_reg): /reserved-memory/vpu_dma_mem_region: node has a reg or ranges property, but no unit name
Warning (simple_bus_reg): /soc/pinctrl@10005000: simple-bus unit address format error, expected "1000b000"
Warning (simple_bus_reg): /soc/interrupt-controller@10220000: simple-bus unit address format error, expected "10221000"
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Link: https://lore.kernel.org/r/20200210063523.133333-4-hsinyi@chromium.org
[mb: drop fixes for '_' in property name]
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
We added this for just the regular poll requests in commit a6ba632d2c
("io_uring: retry poll if we got woken with non-matching mask"), we
should do the same for the poll handler used pollable async requests.
Move the re-wait check and arm into a helper, and call it from
io_async_task_func() as well.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Add serial as uart aliases in mt8173.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200210063523.133333-3-hsinyi@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Elm is Acer Chromebook R13. Hana is Lenovo Chromebook. Both uses mt8173
SoC.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200210063523.133333-2-hsinyi@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Split a cluster level cpuidle state into two, so mt8183 variant
boards can adjust parameters for each cluster, and reduce cluster0's
default target residency to 1000us as power measurements showed that
its minimum residency is slightly less than cluster1's 1300us.
Signed-off-by: Ikjoon Jang <ikjn@chromium.org>
Link: https://lore.kernel.org/r/20200225080752.200952-1-ikjn@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
In order to use GCE function, we need add some informations
into display node (mboxes, mediatek,gce-client-reg, mediatek,gce-events).
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Vram lost counter is wrongly increased by two during baco reset.
V2: assumed vram lost for mode1 reset on all ASICs
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The HD-audio controller does system-suspend and resume operations by
directly calling its helpers __azx_runtime_suspend() and
__azx_runtime_resume(). However, in general, we don't have to resume
always the device fully at the system resume; typically, if a device
has been runtime-suspended, we can leave it to runtime resume.
Usually for achieving this, the driver would call
pm_runtime_force_suspend() and pm_runtime_force_resume() pairs in the
system suspend and resume ops. Unfortunately, this doesn't work for
the resume path in our case. For handling the jack detection at the
system resume, a child codec device may need the (literally) forcibly
resume even if it's been runtime-suspended, and for that, the
controller device must be also resumed even if it's been suspended.
This patch is an attempt to improve the situation. It replaces the
direct __azx_runtime_suspend()/_resume() calls with with
pm_runtime_force_suspend() and pm_runtime_force_resume() with a slight
trick as we've done for the codec side. More exactly:
- azx_has_pm_runtime() check is dropped from azx_runtime_suspend() and
azx_runtime_resume(), so that it can be properly executed from the
system-suspend/resume path
- The WAKEEN handling depends on the card's power state now; it's set
and cleared only for the runtime-suspend
- azx_resume() checks whether any codec may need the forcible resume
beforehand. If the forcible resume is required, it does temporary
PM refcount up/down for actually triggering the runtime resume.
- A new helper function, hda_codec_need_resume(), is introduced for
checking whether the codec needs a forcible runtime-resume, and the
existing code is rewritten with that.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043
Link: https://lore.kernel.org/r/20200413082034.25166-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently, when the HD-audio controller driver doesn't detect any
codecs, it tries to abort the probe. But this abort happens at the
delayed probe, i.e. the primary probe call already returned success,
hence the driver is never unbound until user does so explicitly.
As a result, it may leave the HD-audio device in the running state
without the runtime PM. More badly, if the device is a HD-audio bus
that is tied with a GPU, GPU cannot reach to the full power down and
consumes unnecessarily much power.
This patch changes the logic after no-codec situation; it continues
probing without the further codec initialization but keep the
controller driver running normally.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043
Tested-by: Roy Spliet <nouveau@spliet.org>
Link: https://lore.kernel.org/r/20200413082034.25166-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
