Running the Clang static analyzer on IORT code detected the following
error:
Logic error: Branch condition evaluates to a garbage value
in
iort_get_platform_device_domain()
If the named component associated with a given device has no IORT
mappings, iort_get_platform_device_domain() exits its MSI mapping loop
with msi_parent pointer containing garbage, which can lead to erroneous
code path execution.
Initialize the msi_parent pointer, fixing the bug.
Fixes: d4f54a1866 ("ACPI: platform: setup MSI domain for ACPI based
platform device")
Reported-by: Patrick Bellasi <patrick.bellasi@arm.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJcAKgKAAoJEAx081l5xIa+0PgP/A+2bvrs6EgLQHAmdyJtuAzp
/qeip9RtQG15rmgkzYucRgeTqmIwDHduCJDp7TcJ94Lial2FzBH5o8gRfqcOatgg
Ury7/MwAOEg4omYxpuRP1qlZkK0wkEZiDT5aWYlYRFZI1+qsL28vdYyA1KflBNLS
ZbGGB1DOIjtT1NGG4/cMGTd8iGM8cQIDzeKra6ZlTdDA3fARLBrf4bQCuphu7Eqv
z2n0ZSEmGlvOWEAE4GR3nG3Uu32F6wCKdwWRG+/GLhRRFb8GdXZ3uriZXswdMNwt
I1pIgHGHcpAGqD6IyHKtoBPlBs1Xs+VL1QwqHkN5hGniF32szBpCKOAPIxhLfJ7w
S6clk/kauzdlzOI/t31LjKLME9a/mn95wxzridNTv2SmksEmNoNhvsEeXEoMjs2m
s4CcJTyt5tbRqwXlWQg5DWkBAyNqNI1EkoDJRmefN+rW33m6x79r0RFcv57E8Sbs
VyaLelyNyOcPm8Tqanko5o9RTQ56sZTNR4aOXVVrxSOBa7iJnK+h/kMeCn8TJDsT
i8ftCzpco5uycxDgunw+lPoj9rnzuB7i2MgbEb2rOz3Mj8TH/WQnb1YWlUWPejuG
ClAVjwWJAEy26MdGpMy0XUVtvgJK0h5hvnSA9yXAZjkJzA8LtbV82Nexu2MsEt02
DiTPOpSgtSyxC4CLZ2G3
=2Pvh
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2018-11-30' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"This weeks instalment of fixes. Looks fairly like business as usual
and everything seems to rolling along. There was one MST fix applied
and reverted in the misc tree, but otherwise nothing too strange in
here.
core:
- incorrect master setting on error fix
i915:
- only GVT fixes this week:
* one MOCS register load
* rpm lock fix
* use after free
rcar-du:
- regression fix for group start
amdgpu:
- DP MST fix
- GPUVM fix for huge pages
- RLC fix for vega20
ast:
- fix EDID reading stability
- ioreg free fix
meson:
- sleep in irq fix
- vblank fixes
- array boundary fix"
* tag 'drm-fixes-2018-11-30' of git://anongit.freedesktop.org/drm/drm:
drm/ast: fixed reading monitor EDID not stable issue
drm/ast: Fix incorrect free on ioregs
Revert "drm/dp_mst: Skip validating ports during destruction, just ref"
drm/amdgpu: Add delay after enable RLC ucode
drm/amdgpu: Avoid endless loop in GPUVM fragment processing
drm/amdgpu: Cast to uint64_t before left shift
drm/meson: add support for 1080p25 mode
drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut()
drm/meson: Enable fast_io in meson_dw_hdmi_regmap_config
drm/meson: Fixes for drm_crtc_vblank_on/off support
drm: set is_master to 0 upon drm_new_set_master() failure
drm/dp_mst: Skip validating ports during destruction, just ref
drm: rcar-du: Fix DU3 start/stop on M3-N
drm/amd/dm: Understand why attaching path/tile properties are needed
drm/amd/dm: Don't forget to attach MST encoders
drm/i915/gvt: Avoid use-after-free iterating the gtt list
drm/i915/gvt: ensure gpu is powered before do i915_gem_gtt_insert
drm/i915/gvt: not to touch undefined MOCS registers
Pull NVMe fixes from Christoph:
"Various fixlets all over."
* 'nvme-4.20' of git://git.infradead.org/nvme:
nvme-rdma: fix double freeing of async event data
nvme: flush namespace scanning work just before removing namespaces
nvme: warn when finding multi-port subsystems without multipathing enabled
nvme-pci: fix surprise removal
nvme-fc: initialize nvme_req(rq)->ctrl after calling __nvme_fc_init_request()
nvme: Free ctrl device name on init failure
The stackleak_erase() function is called on the trampoline stack at the
end of syscall. This stack is not big enough for ftrace and kprobes
operations, e.g. it can be exhausted if we use kprobe_events for
stackleak_erase().
So let's disable function tracing and kprobes of stackleak_erase().
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 10e9ae9fab ("gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack")
Signed-off-by: Alexander Popov <alex.popov@linux.com>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
A set of small driver and core code fixes:
- Small series fixing longtime user triggerable bugs in the
ODP processing inside mlx5 and core code
- Various small driver malfunctions and crashes (use after, free, error
unwind, implementation bugs)
- A misfunction of the RDMA GID cache that can be triggered by the
administrator
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEfB7FMLh+8QxL+6i3OG33FX4gmxoFAlwAbPgACgkQOG33FX4g
mxpMCg/8DMvxyz5byYhLbreKuMCeG8+L5PuvR8myeeA5ycbPUo+HYCFe7fkqpHUH
tlgLWm0PoMnGh1s8pjD2OvFU2xHAl9tydk1tU8XLBpEjC3XvrD5ZTvd/i2rHdvDy
hKDGRouU6QnDiNwTR5HrSlqH5OVVZ0K0Oyl3YjAbGItL4xJEEPbiRCWA+SN8tuBl
mkFEkGr+MKZIDEieatf9KT2cLQbhVbtjG58rTxA1jOVL1ZM+PT0FZ/J7JsQAD2FO
MVkw2NQrgu/bLiqr2d679rShWRetctap9iYiGna2ftVghCHqXajN477Dv0w01pQu
5k9JaSPA2j7rGaFql4fyyuHBMqHF+pqwC/p1ExgUpbOTShcibUCIfJbIHhjLVTCl
sszZculTfCiYnJBiBkSp1G1L784Z6QPnDRacxeHRuV2yUd5MhrW2KCTwk0ZkPV9F
PKwKCNC90TeD3STUAk0GXouzuZYvqjxDdwiE5ohYgCCR5CNRBS/fdmmRK/PnRb1Y
ekTYHStoBFT1tkAG5NqAcfKm3qs/tdxlcdo+3sS9n5XWNwyUwUP2buKKnaXu9ACf
yD3+vDaBCEcGhQXaw6lUm8sTF2P5eD67lMvJiteLJr9dsnk7bUd6+d1sXB3TjJss
bX5FQx2CwNMnRQ7hKrBqZa3dhCA578Hq0AgmH+1jw/7mD5Ay6Hw=
=QrHg
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
Pull rdma fixes from Jason Gunthorpe:
"This is a bit later than usual for our first -rc but I'm not seeing
anything worry-some in the RDMA tree right now. Quiet so far this -rc
cycle, only a few internal driver related bugs and a small series
fixing ODP bugs found by more advanced testing.
A set of small driver and core code fixes:
- Small series fixing longtime user triggerable bugs in the ODP
processing inside mlx5 and core code
- Various small driver malfunctions and crashes (use after, free,
error unwind, implementation bugs)
- A misfunction of the RDMA GID cache that can be triggered by the
administrator"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
RDMA/mlx5: Initialize return variable in case pagefault was skipped
IB/mlx5: Fix page fault handling for MW
IB/umem: Set correct address to the invalidation function
IB/mlx5: Skip non-ODP MR when handling a page fault
RDMA/hns: Bugfix pbl configuration for rereg mr
iser: set sector for ambiguous mr status errors
RDMA/rdmavt: Fix rvt_create_ah function signature
IB/mlx5: Avoid load failure due to unknown link width
IB/mlx5: Fix XRC QP support after introducing extended atomic
RDMA/bnxt_re: Avoid accessing the device structure after it is freed
RDMA/bnxt_re: Fix system hang when registration with L2 driver fails
RDMA/core: Add GIDs while changing MAC addr only for registered ndev
RDMA/mlx5: Fix fence type for IB_WR_LOCAL_INV WR
net/mlx5: Fix XRC SRQ umem valid bits
Some error paths in configuration of admin queue free data buffer
associated with async request SQE without resetting the data buffer
pointer to NULL, This buffer is also freed up again if the controller
is shutdown or reset.
Signed-off-by: Prabhath Sajeepa <psajeepa@purestorage.com>
Reviewed-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
nvme_stop_ctrl can be called also for reset flow and there is no need to
flush the scan_work as namespaces are not being removed. This can cause
deadlock in rdma, fc and loop drivers since nvme_stop_ctrl barriers
before controller teardown (and specifically I/O cancellation of the
scan_work itself) takes place, but the scan_work will be blocked anyways
so there is no need to flush it.
Instead, move scan_work flush to nvme_remove_namespaces() where it really
needs to flush.
Reported-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Keith Busch <keith.busch@intel.com>
Reviewed by: James Smart <jsmart2021@gmail.com>
Tested-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Without CONFIG_NVME_MULTIPATH enabled a multi-port subsystem might
show up as invididual devices and cause problems, warn about it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Variable 'cache' is being assigned but is never used hence it is
redundant and can be removed.
Cleans up clang warning:
warning: variable 'cache' set but not used [-Wunused-but-set-variable]
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David Howells <dhowells@redhat.com>
get_seconds() returns an unsigned long can overflow on some architectures
and is deprecated because of that. In cachefs, we cast that number to
a a 32-bit integer, which will overflow in year 2106 on all architectures.
As confirmed by David Howells, the overflow probably isn't harmful
in the end, since the timestamps are only used to make the file names
unique, but they don't strictly have to be in monotonically increasing
order since the files only exist in order to be deleted as quickly
as possible.
Moving to ktime_get_real_seconds() avoids the deprecated interface.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David Howells <dhowells@redhat.com>
Clang warns when one enumerated type is implicitly converted to another.
fs/cachefiles/namei.c:247:50: warning: implicit conversion from
enumeration type 'enum cachefiles_obj_ref_trace' to different
enumeration type 'enum fscache_obj_ref_trace' [-Wenum-conversion]
cache->cache.ops->put_object(&xobject->fscache,
cachefiles_obj_put_wait_retry);
Silence this warning by explicitly casting to fscache_obj_ref_trace,
which is also done in put_object.
Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
It was observed that a process blocked indefintely in
__fscache_read_or_alloc_page(), waiting for FSCACHE_COOKIE_LOOKING_UP
to be cleared via fscache_wait_for_deferred_lookup().
At this time, ->backing_objects was empty, which would normaly prevent
__fscache_read_or_alloc_page() from getting to the point of waiting.
This implies that ->backing_objects was cleared *after*
__fscache_read_or_alloc_page was was entered.
When an object is "killed" and then "dropped",
FSCACHE_COOKIE_LOOKING_UP is cleared in fscache_lookup_failure(), then
KILL_OBJECT and DROP_OBJECT are "called" and only in DROP_OBJECT is
->backing_objects cleared. This leaves a window where
something else can set FSCACHE_COOKIE_LOOKING_UP and
__fscache_read_or_alloc_page() can start waiting, before
->backing_objects is cleared
There is some uncertainty in this analysis, but it seems to be fit the
observations. Adding the wake in this patch will be handled correctly
by __fscache_read_or_alloc_page(), as it checks if ->backing_objects
is empty again, after waiting.
Customer which reported the hang, also report that the hang cannot be
reproduced with this fix.
The backtrace for the blocked process looked like:
PID: 29360 TASK: ffff881ff2ac0f80 CPU: 3 COMMAND: "zsh"
#0 [ffff881ff43efbf8] schedule at ffffffff815e56f1
#1 [ffff881ff43efc58] bit_wait at ffffffff815e64ed
#2 [ffff881ff43efc68] __wait_on_bit at ffffffff815e61b8
#3 [ffff881ff43efca0] out_of_line_wait_on_bit at ffffffff815e625e
#4 [ffff881ff43efd08] fscache_wait_for_deferred_lookup at ffffffffa04f2e8f [fscache]
#5 [ffff881ff43efd18] __fscache_read_or_alloc_page at ffffffffa04f2ffe [fscache]
#6 [ffff881ff43efd58] __nfs_readpage_from_fscache at ffffffffa0679668 [nfs]
#7 [ffff881ff43efd78] nfs_readpage at ffffffffa067092b [nfs]
#8 [ffff881ff43efda0] generic_file_read_iter at ffffffff81187a73
#9 [ffff881ff43efe50] nfs_file_read at ffffffffa066544b [nfs]
#10 [ffff881ff43efe70] __vfs_read at ffffffff811fc756
#11 [ffff881ff43efee8] vfs_read at ffffffff811fccfa
#12 [ffff881ff43eff18] sys_read at ffffffff811fda62
#13 [ffff881ff43eff50] entry_SYSCALL_64_fastpath at ffffffff815e986e
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: David Howells <dhowells@redhat.com>
commit e259221763 ("fs: simplify the
generic_write_sync prototype") reworked callers of generic_write_sync(),
and ended up dropping the error return for the directio path. Prior to
that commit, in dio_complete(), an error would be bubbled up the stack,
but after that commit, errors passed on to dio_complete were eaten up.
This was reported on the list earlier, and a fix was proposed in
https://lore.kernel.org/lkml/20160921141539.GA17898@infradead.org/, but
never followed up with. We recently hit this bug in our testing where
fencing io errors, which were previously erroring out with EIO, were
being returned as success operations after this commit.
The fix proposed on the list earlier was a little short -- it would have
still called generic_write_sync() in case `ret` already contained an
error. This fix ensures generic_write_sync() is only called when there's
no pending error in the write. Additionally, transferred is replaced
with ret to bring this code in line with other callers.
Fixes: e259221763 ("fs: simplify the generic_write_sync prototype")
Reported-by: Ravi Nankani <rnankani@amazon.com>
Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
CC: Torsten Mehlan <tomeh@amazon.de>
CC: Uwe Dannowski <uwed@amazon.de>
CC: Amit Shah <aams@amazon.de>
CC: David Woodhouse <dwmw@amazon.co.uk>
CC: stable@vger.kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The bio referencing has a trick that doesn't do any actual atomic
inc/dec on the reference count until we have to elevator to > 1. For the
async IO O_DIRECT case, we can't use the simple DIO variants, so we use
__blkdev_direct_IO(). It always grabs an extra reference to the bio
after allocation, which means we then enter the slower path of actually
having to do atomic_inc/dec on the count.
We don't need to do that for the async case, unless we end up going
multi-bio, in which case we're already doing huge amounts of IO. For the
smaller IO case (< BIO_MAX_PAGES), we can do without the extra ref.
Based on an earlier patch (and commit log) from Jens Axboe.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The tracefs file set_graph_function is used to only function graph functions
that are listed in that file (or all functions if the file is empty). The
way this is implemented is that the function graph tracer looks at every
function, and if the current depth is zero and the function matches
something in the file then it will trace that function. When other functions
are called, the depth will be greater than zero (because the original
function will be at depth zero), and all functions will be traced where the
depth is greater than zero.
The issue is that when a function is first entered, and the handler that
checks this logic is called, the depth is set to zero. If an interrupt comes
in and a function in the interrupt handler is traced, its depth will be
greater than zero and it will automatically be traced, even if the original
function was not. But because the logic only looks at depth it may trace
interrupts when it should not be.
The recent design change of the function graph tracer to fix other bugs
caused the depth to be zero while the function graph callback handler is
being called for a longer time, widening the race of this happening. This
bug was actually there for a longer time, but because the race window was so
small it seldom happened. The Fixes tag below is for the commit that widen
the race window, because that commit belongs to a series that will also help
fix the original bug.
Cc: stable@kernel.org
Fixes: 39eb456dac ("function_graph: Use new curr_ret_depth to manage depth instead of curr_ret_stack")
Reported-by: Joe Lawrence <joe.lawrence@redhat.com>
Tested-by: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
After enabling KVM event tracing, almost all of trace_kvm_exit()'s
printk shows
"kvm_exit: IRQ: ..."
even if the actual exception_type is NOT IRQ. More specifically,
trace_kvm_exit() is defined in virt/kvm/arm/trace.h by TRACE_EVENT.
This slight problem may have existed after commit e6753f23d9
("tracepoint: Make rcuidle tracepoint callers use SRCU"). There are
two variables in trace_kvm_exit() and __DO_TRACE() which have the
same name, *idx*. Thus the actual value of *idx* will be overwritten
when tracing. Fix it by adding a simple prefix.
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: Wang Haibin <wanghaibin.wang@huawei.com>
Cc: linux-trace-devel@vger.kernel.org
Cc: stable@vger.kernel.org
Fixes: e6753f23d9 ("tracepoint: Make rcuidle tracepoint callers use SRCU")
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Use d_instantiate() rather than d_add() and don't d_drop() in
afs_vnode_new_inode(). The dentry shouldn't be removed as it's not
changing its name.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
kAFS can be given certain network errors (EADDRNOTAVAIL, EHOSTDOWN and
ERFKILL) that it doesn't handle in its server/address rotation algorithms.
They cause the probing and rotation to abort immediately rather than
rotating.
Fix this by:
(1) Abstracting out the error prioritisation from the VL and FS rotation
algorithms into a common function and expand usage into the server
probing code.
When multiple errors are available, this code selects the one we'd
prefer to return.
(2) Add handling for EADDRNOTAVAIL, EHOSTDOWN and ERFKILL.
Fixes: 0fafdc9f88 ("afs: Fix file locking")
Fixes: 0338747d8454 ("afs: Probe multiple fileservers simultaneously")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
When afs_validate() is called to validate a vnode (inode), there are two
unhandled cases in the fastpath at the top of the function:
(1) If the vnode is promised (AFS_VNODE_CB_PROMISED is set), the break
counters match and the data has expired, then there's an implicit case
in which the vnode needs revalidating.
This has no consequences since the default "valid = false" set at the
top of the function happens to do the right thing.
(2) If the vnode is not promised and it hasn't been deleted
(AFS_VNODE_DELETED is not set) then there's a default case we're not
handling in which the vnode is invalid. If the vnode is invalid, we
need to bring cb_s_break and cb_v_break up to date before we refetch
the status.
As a consequence, once the server loses track of the client
(ie. sufficient time has passed since we last sent it an operation),
it will send us a CB.InitCallBackState* operation when we next try to
talk to it. This calls afs_init_callback_state() which increments
afs_server::cb_s_break, but this then doesn't propagate to the
afs_vnode record.
The result being that every afs_validate() call thereafter sends a
status fetch operation to the server.
Clarify and fix this by:
(A) Setting valid in all the branches rather than initialising it at the
top so that the compiler catches where we've missed.
(B) Restructuring the logic in the 'promised' branch so that we set valid
to false if the callback is due to expire (or has expired) and so that
the final case is that the vnode is still valid.
(C) Adding an else-statement that ups cb_s_break and cb_v_break if the
promised and deleted cases don't match.
Fixes: c435ee3455 ("afs: Overhaul the callback handling")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Fix a recent regression in ACPICA releted to the Generic Serial Bus
protocol handling and causing it to read or write too little or too
much data in some cases, so incorrect data may be written to hardware
as a result (Hans de Goede).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJcAE+KAAoJEILEb/54YlRxoDQP/RIGQDpBQa9AZ4Z0+t2Ehze7
4WRXAIDJBbV8wz2VOJz1UFIdNvyBIldUZFs2MAdDpMywhuPorTx4SiHsrhQBwUao
khwMEGvCwzSuAo1aUC/IF7asUB/JWwVp7RusHvExyIMEH4Ie9ZmFfCD9CffMj3ol
0dq3EJxpCTWEeZkD7cSFRjfmcEXjsx1OKFY65thg5cJaaiNb9UFNMuOQyEVIDuwS
Mr/NBvj6VsGEe1rNViJlI2N24NVx9mrkqpOol3SRL3N3g022iQlE9WqaA1NOkiWo
gTaSifY8QHUCFsoZjTyO0rOxr0emQKIS2A0mRBCNBANdRgq98VkwVjStJCndSrKM
TXJwiZuw0xDphqBUFoTqycE2wTI2RSKvs/WEGYHI0KsPm5MCjxeiDZYgieSx60P5
j2V2YtOuB4n0q0gjtrEeCJDqtzXsbEBU6YBB1WuV9e5kdk6hePssLGg++bHn3yKX
j9cKJFnM1FuS83Mgg+QMOUj9Dh2KBTFMsym3I7YQhkGsl3IzLFHtRDrSpdA6tyxQ
b/q74xw3HbKqbZg/LZDecE+uYdo2abn9elEIu4wRFllFL0x6YiqXOaKEjSPB6l3s
rm613/0gMSaAGPDFsSIISAMuqjbNbvvJXU45MXfo6XSZRhwP55lmGyxKYm+FhDRv
fxz2nZMaaeHgdfLYmgsp
=F3ad
-----END PGP SIGNATURE-----
Merge tag 'acpi-4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fix from Rafael Wysocki:
"Fix a recent regression in ACPICA releted to the Generic Serial Bus
protocol handling and causing it to read or write too little or too
much data in some cases, so incorrect data may be written to hardware
as a result (Hans de Goede)"
* tag 'acpi-4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPICA: Fix handling of buffer-size in acpi_ex_write_data_to_field()
- Fix the handling of the "operating-points-v2" property to
avoid failures if multiple phandles are present in it which
is legitimate (Viresh Kumar).
- Drop the unnecessary static initialization of the .owner field in
the ti_opp_supply_driver structure (YueHaibing).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJcAE74AAoJEILEb/54YlRxE68P/3VlBcgCQv9u6kHhDi3qMEEI
VcYtzE17ruUDIfV9IvifeOOYNT0/38nFN947f6QRFOxepsRhStDGAl7VHqfdNF63
17MWlWD8ko+UUtatOCeHfDbVx+8ssXcAMV5VNu3+2PEb3qNh0C/uILlnQdxqWG2H
YGo1RHrTMC3Hpavt9HPX6j6Q7wXVz397JdakqjPjp4K8cZzZemzTYzLST/KZrYFy
th+DhIT7SbtB5WRziyVGalb+aMcLyq/CLOviwVn5NJdsoFHPnPQpYxMVdj3gcpTe
4XHU225/T7KmDUT4arqhSNBB21b0admrQzmJjVrVHy4swK4xbJKkCE64daApBOlK
rtpGy9/J5trm0H74OTt691yIT8TRwUrY8BwwHUpFbZD/k1wUQqSG35S88JPtpqmF
W4Hc1dH4ktkW4foYX+9wZwHPEyTEFowx9u1otRZhBXLlCxGQwi1SPm8FyTifnERp
KDReKDvA52+bNWwN2TuV3AWjv1oCfX2d5kn28ioVDIU8XRO5bKE67InD8HjIidUH
cQEZ6Vcu9NAKvFia1h0ZeDr39gVvTSJnF7xU1GPI1D9APNvXkGh/Q5Fa9fr9MO8x
k+KwxbOo6e3vt8qWIDGCjq8sFtPFCST5nMdl00VMo5t/9FBzClH03D4L0vYv6jjN
5z8sYv/o1Ac5O6Ypw20Y
=vxO4
-----END PGP SIGNATURE-----
Merge tag 'pm-4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"These fix two issues in the operating performance points (OPP)
framework.
Specifics:
- Fix the handling of the "operating-points-v2" property to avoid
failures if multiple phandles are present in it which is legitimate
(Viresh Kumar).
- Drop the unnecessary static initialization of the .owner field in
the ti_opp_supply_driver structure (YueHaibing)"
* tag 'pm-4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
OPP: Fix parsing of multiple phandles in "operating-points-v2" property
opp: ti-opp-supply: Fix platform_no_drv_owner.cocci warnings
Pagefaults occurred in non-ODP MR are completely valid events, so
initialize return variable to 0.
Fixes: 4d5422a309 ("IB/mlx5: Skip non-ODP MR when handling a page fault")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
The actual number of bytes stored in a PRZ is smaller than the
bytes requested by platform data, since there is a header on each
PRZ. Additionally, if ECC is enabled, there are trailing bytes used
as well. Normally this mismatch doesn't matter since PRZs are circular
buffers and the leading "overflow" bytes are just thrown away. However, in
the case of a compressed record, this rather badly corrupts the results.
This corruption was visible with "ramoops.mem_size=204800 ramoops.ecc=1".
Any stored crashes would not be uncompressable (producing a pstorefs
"dmesg-*.enc.z" file), and triggering errors at boot:
[ 2.790759] pstore: crypto_comp_decompress failed, ret = -22!
Backporting this depends on commit 70ad35db33 ("pstore: Convert console
write to use ->write_buf")
Reported-by: Joel Fernandes <joel@joelfernandes.org>
Fixes: b0aad7a99c ("pstore: Add compression support to pstore")
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
If we aren't forced to do round robin tag allocation, just use the
allocation hint to find the index for the tag word, don't use it for the
offset inside the word. This avoids a potential extra round trip in the
bit looping, and since we're fetching this cacheline, we may as well
check the whole word from the start.
Reviewed-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
-----BEGIN PGP SIGNATURE-----
iQJIBAABCAAyFiEES0KozwfymdVUl37v6iDy2pc3iXMFAlwAFUUUHHBhdWxAcGF1
bC1tb29yZS5jb20ACgkQ6iDy2pc3iXM7ThAAw1j+HSBNM4util2Ji5JZKjjThdVe
ZS1Jji30H51lVl3PNOfIUd9Ep3jLVbQOQ40jFQ2B8LEjjITKQykHtp4p6raYAxbb
yEJGeVikD+UZ0izHMj05uZRBNY5F09s6y1WGMz8EZ6NdSSQezW0CpBCvKN4FpyKQ
LgHmW7oRccSBgs5IcW8bCX/aM1p+HsI8N508T8MbO3qDt4/0OU/6OM+NAE19WvYp
HVrq/BfRgDoQSoz3XxW5bCa7r3GFtxYYtTUjVnqBiRcEk+u67JJ5iJMwiUos1kV3
94iAedGB1cXL0+qgyyb7eaoemSWL2A8FqTwEOL0VoIvaGzW4HJmioIzYgOGd4ni6
BzXHIfdDff3DDWZ+g/T0da6znDLJ+R6u9xETAXcQ+g15FZ0F1ZY+3lJGlQvYfIVY
RGHlWB93NU/Y2vebeqaGDuQOTu8XXJfBBjlHNUi3NQbRZ0ITBduTGpwpyKA6Uuiz
cqrNt7DECTPJzOAJNeZZ7Flhfto1KQvLnPacWzjv9S8Cj1cJn2uS97QPkEqYQVYe
b5D2PprAXpP6hPq3+Roxe+tBL1G+9XjStNrL0xPLgbiQvGCcsoD0R1dEZAesyfLO
ZQGBP+0O/lFyQwn8T3A9QKZRgZFcfVMyOGbQRCUs98XkH0gvbLyfBNzN72aEy0+I
ADbhCoY7pfs1ZZs=
=SyQy
-----END PGP SIGNATURE-----
Merge tag 'selinux-pr-20181129' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux
Pull SELinux fix from Paul Moore:
"One more SELinux fix for v4.20: add some missing netlink message to
SELinux permission mappings. The netlink messages were added in v4.19,
but unfortunately we didn't catch it then because the mechanism to
catch these things was bypassed.
In addition to adding the mappings, we're adding some comments to the
code to hopefully prevent bypasses in the future"
* tag 'selinux-pr-20181129' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux:
selinux: add support for RTM_NEWCHAIN, RTM_DELCHAIN, and RTM_GETCHAIN
- Add two missing kfree calls on error paths in the vfio-ccw code
- Make sure that all data structures of a mediated vfio-ccw device are
initialized before registering it
- Fix a sparse warning in vfio-ccw
- A followup patch for the pgtable_bytes accounting, the page table
downgrade for compat processes missed a mm_dec_nr_pmds()
- Reject sampling requests in the PMU init function of the CPU
measurement counter facility
- With the vfio AP driver an AP queue needs to be reset on every device
probe as the alternative driver could have modified the device state
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAABCAAGBQJb/9clAAoJEDjwexyKj9rgDFIIAMifOGVivY5Dq+PbS2YfVJAS
QVMN6PZEyOZaLHk9rTxIFTAwaZ6i4i0vw01UOiE91VJkDz49wHenDiwaNELtVQrs
57FkzbEuAhjKJ6DaWIr7bWgeaBFUlC+Z4mNxXFaNI2olzNncHhDJME7lPI/XoBvu
zPlWBvliiNiaHAzLBDLw+zx1wyxyYjV+B8ZZ9HtH0xzHm3EOiRWpVsr2TbwePEmd
yC6fTYoDUSJHZF9eoVZaJ0p1wSa8d6NfTE7a5TZOIv7yZQHWo0/tyN0wzyoWb0Oo
7volx9/4BjbP7fBIkBN6LMPDNH8itTmrx6wdhekf+tElBj1iOOi27l8rcyTby00=
=AgxV
-----END PGP SIGNATURE-----
Merge tag 's390-4.20-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 updates from Martin Schwidefsky:
- Add two missing kfree calls on error paths in the vfio-ccw code
- Make sure that all data structures of a mediated vfio-ccw device are
initialized before registering it
- Fix a sparse warning in vfio-ccw
- A followup patch for the pgtable_bytes accounting, the page table
downgrade for compat processes missed a mm_dec_nr_pmds()
- Reject sampling requests in the PMU init function of the CPU
measurement counter facility
- With the vfio AP driver an AP queue needs to be reset on every device
probe as the alternative driver could have modified the device state
* tag 's390-4.20-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/mm: correct pgtable_bytes on page table downgrade
s390/zcrypt: reinit ap queue state machine during device probe
s390/cpum_cf: Reject request for sampling in event initialization
s390/cio: Fix cleanup when unsupported IDA format is used
s390/cio: Fix cleanup of pfn_array alloc failure
vfio: ccw: Register mediated device once all structures are initialized
s390/cio: make vfio_ccw_io_region static
As a usual pattern, we've got relatively large updates at rc5.
- A fix for races in ALSA control user elements
- ASoC DAPM regression due to component refactoring
- A fix in error handling of ASoC iteration macro
- ASoC Intel SST Skylake kconfig fix; a new Kconfig will appear as a
consequence, but in the end it's a good cleanup
- HD-audio and USB-audio quirks as always
- Assort of ASoC driver fixes (pcm186x, Intel cht, rockchip, pcm3060,
rsnd, omap, wm_adsp, qcom, sunxi, stm32)
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAlv+yaEOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE8rJRAAs3PHBkPy5xVd8bTFiWNPiMrts3GWjTMiQbPf
oQcgfXjJFyAnsdIQlCGwF9dLCVCRQDGUqe1Uf01CCP/0yzY2aXjzNa8SF8Mxt2PZ
F5AZs8BgQyMKNqHCvyFEUwrPTwhNj3APk19oBdB+lfU7alFf/JNkuBP3cnYASGeJ
CybHJzRtPr8r12a46olttU7CqGC6twoNG84It6C+gfIvmG4Wqh0nHVVubLXpwCJG
mDt/fgsCwXDfUD41mNZ2KjIufWWI1SHcHWSCP9xV8W9vcugH1AvD/DkvBp4JpGuG
92emTcOVJNV3Xg5fOeL3wMmk8YiDtxezdQs0ZWKSDLINo8Q9jvfCHvFGW3fJI85y
Fwwm8c2s/MYUEfyUyqbdNekFmQ9t4Gt+tjRKMjZhmj1N40CuyFQOC2kx4oF8J15Z
7U8/eOQ6paUV+E2Tbrui5qsdt3IzV3YAAJwbVPXjqJQ26uxKwgNzd0oO1mGKUX5N
f5h2EMb3mwCPwsxZR8Bi5NmSpCyUXNKDrUogauPjV1IX8x3vC5TpwrI9IWupUNQu
oUOsJxc8Mp4qeufspfdaB3m/8nQJ66sxfLTMuagT7Iy007DfLP2V8xyjAbNtxwq4
yg2/xTxpictFiAQ5h+Ignk96+aSS1VS77XFTVsyq3cYGRtw2ByUtffG1TUlBu9sg
mAw9P7I=
=GXsL
-----END PGP SIGNATURE-----
Merge tag 'sound-4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"As a usual pattern, we've got relatively large updates at rc5:
- A fix for races in ALSA control user elements
- ASoC DAPM regression due to component refactoring
- A fix in error handling of ASoC iteration macro
- ASoC Intel SST Skylake kconfig fix; a new Kconfig will appear as a
consequence, but in the end it's a good cleanup
- HD-audio and USB-audio quirks as always
- Assort of ASoC driver fixes (pcm186x, Intel cht, rockchip, pcm3060,
rsnd, omap, wm_adsp, qcom, sunxi, stm32)"
* tag 'sound-4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (34 commits)
ALSA: usb-audio: Add vendor and product name for Dell WD19 Dock
ALSA: hda/realtek - Support ALC300
ALSA: hda/realtek - Add auto-mute quirk for HP Spectre x360 laptop
ALSA: hda/realtek - fix the pop noise on headphone for lenovo laptops
ALSA: control: Fix race between adding and removing a user element
ALSA: sparc: Fix invalid snd_free_pages() at error path
ALSA: wss: Fix invalid snd_free_pages() at error path
ALSA: hda/realtek - fix headset mic detection for MSI MS-B171
ALSA: hda: Add ASRock N68C-S UCC the power_save blacklist
ALSA: ac97: Fix incorrect bit shift at AC97-SPSA control write
ASoC: omap-dmic: Add pm_qos handling to avoid overruns with CPU_IDLE
ASoC: omap-mcpdm: Add pm_qos handling to avoid under/overruns with CPU_IDLE
ASoC: omap-mcbsp: Fix latency value calculation for pm_qos
ASoC: acpi: fix: continue searching when machine is ignored
ASoC: Intel: Skylake: fix Kconfigs, make HDaudio codec optional
MAINTAINERS: add ASoC maintainers for sound dt-bindings
ASoC: pcm186x: Fix device reset-registers trigger value
ASoC: dapm: Recalculate audio map forcely when card instantiated
ASoC: omap-abe-twl6040: Fix missing audio card caused by deferred probing
ASoC: pcm3060: Rename output widgets
...
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEq1nRK9aeMoq1VSgcnJ2qBz9kQNkFAlv/mEEACgkQnJ2qBz9k
QNm0kggA8SckBccdUZqpjxohASx9crp+jJeor2TRYCwyVfqdbDjkCOfv9k7+ddD4
D1qN/AEudQXPzr/DrjI0W9fnFG957FLo60RQ0aGwsq/3wfmzfMJ0qXIw2tyoqjIH
VxFecL2f3TKMr5zU9N1QoxJVAMAo5LOGbXO+qNYgTaOJ0EBpw9kxK14ib9JOi+pQ
CItZkAv4eOWMsA/AaRsWN7AGmsziwcMdoAZYRT2wiWdTmubYn66Negnffq2jVHjP
/kYlFjNcgpsuTg1AiTM+JlBwctEeLm37PUyimip3cdYwu6HcfNmCHDjEIzN2YphJ
twzAauTEr0bjNFiNWYraUPVHEcspNw==
=kKDs
-----END PGP SIGNATURE-----
Merge tag 'fixes_for_v4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
Pull ext2 and udf fixes from Jan Kara:
"Three small ext2 and udf fixes"
* tag 'fixes_for_v4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
ext2: fix potential use after free
ext2: initialize opts.s_mount_opt as zero before using it
udf: Allow mounting volumes with incorrect identification strings
If we have that hook, we know the driver handles bd->last == true in
a smart fashion. If it does, even for multiple hardware queues, it's
a good idea to flush batches of requests to the device, if we have
batches of requests from the submitter.
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
If we are issuing a list of requests, we know if we're at the last one.
If we fail issuing, ensure that we call ->commits_rqs() to flush any
potential previous requests.
Reviewed-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
We need this for blk-mq to kick things into gear, if we told it that
we had more IO coming, but then failed to deliver on that promise.
Reviewed-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
We need this for blk-mq to kick things into gear, if we told it that
we had more IO coming, but then failed to deliver on that promise.
Reviewed-by: Omar Sandoval <osandov@fb.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Split the command submission and the SQ doorbell ring, and add the
doorbell ring as our ->commit_rqs() hook. This allows a list of
requests to be issued, with nvme only writing the SQ update when
it's necessary. This is more efficient if we have lists of requests
to issue, particularly on virtualized hardware, where writing the
SQ doorbell is more expensive than on real hardware. For those cases,
performance increases of 2-3x have been observed.
The use case for this is plugged IO, where blk-mq flushes a batch of
requests at the time.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
blk-mq passes information to the hardware about any given request being
the last that we will issue in this sequence. The point is that hardware
can defer costly doorbell type writes to the last request. But if we run
into errors issuing a sequence of requests, we may never send the request
with bd->last == true set. For that case, we need a hook that tells the
hardware that nothing else is coming right now.
For failures returned by the drivers ->queue_rq() hook, the driver is
responsible for flushing pending requests, if it uses bd->last to
optimize that part. This works like before, no changes there.
Reviewed-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Only do it if we have requests for multiple queues in the same
plug.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
kfree() is incorrectly used to release the pages allocated by
__get_free_page() and __get_free_pages(). Use the matching deallocators
i.e., free_page() and free_pages(), respectively.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
This reverts commit b3cf8528bb.
That commit unintentionally broke Xen balloon memory hotplug with
"hotplug_unpopulated" set to 1. As long as "System RAM" resource
got assigned under a new "Unusable memory" resource in IO/Mem tree
any attempt to online this memory would fail due to general kernel
restrictions on having "System RAM" resources as 1st level only.
The original issue that commit has tried to workaround fa564ad963
("x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f,
60-7f)") also got amended by the following 03a551734 ("x86/PCI: Move
and shrink AMD 64-bit window to avoid conflict") which made the
original fix to Xen ballooning unnecessary.
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Failure of an element of a Xen multicall is signalled via a WARN()
only if the kernel is compiled with MC_DEBUG. It is impossible to
know which element failed and why it did so.
Change that by printing the related information even without MC_DEBUG,
even if maybe in some limited form (e.g. without information which
caller produced the failing element).
Move the printing out of the switch statement in order to have the
same information for a single call.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Since commit 4378a7d4be ("arm64: implement syscall wrappers")
introduced "__arm64_" prefix to all syscall wrapper symbols in
sys_call_table, syscall tracer can not find corresponding
metadata from syscall name. In the result, we have no syscall
ftrace events on arm64 kernel, and some bpf testcases are failed
on arm64.
To fix this issue, this introduces custom
arch_syscall_match_sym_name() which skips first 8 bytes when
comparing the syscall and symbol names.
Fixes: 4378a7d4be ("arm64: implement syscall wrappers")
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
On the affected Cortex-A76 cores (r0p0 to r3p0), if a virtual address
for a cacheable mapping of a location is being accessed by a core while
another core is remapping the virtual address to a new physical page
using the recommended break-before-make sequence, then under very rare
circumstances TLBI+DSB completes before a read using the translation
being invalidated has been observed by other observers. The workaround
repeats the TLBI+DSB operation and is shared with the Qualcomm Falkor
erratum 1009
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Commit 32a4f5ecd7 ("net: sched: introduce chain object to uapi")
added new RTM_* definitions without properly updating SELinux, this
patch adds the necessary SELinux support.
While there was a BUILD_BUG_ON() in the SELinux code to protect from
exactly this case, it was bypassed in the broken commit. In order to
hopefully prevent this from happening in the future, add additional
comments which provide some instructions on how to resolve the
BUILD_BUG_ON() failures.
Fixes: 32a4f5ecd7 ("net: sched: introduce chain object to uapi")
Cc: <stable@vger.kernel.org> # 4.19
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Moore <paul@paul-moore.com>
I recently found some code which called blk_mq_free_map_and_requests()
with a NULL set->tags pointer. I fixed the caller, but it seems like a
good idea to add a NULL check here as well. Now we can call:
blk_mq_free_tag_set(set);
blk_mq_free_tag_set(set);
twice in a row and it's harmless.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Smatch complains that there is an off by one if the allocation fails in:
DMABuffer = atari_stram_alloc(BUFFER_SIZE+512, "ataflop");
In that situation, "i" would be point to one element beyond the end of
the unit[] array.
There is a second bug because the error handling calls
blk_mq_free_tag_set(&unit[i].tag_set); regardless of whether
"disk->queue" is NULL or non-NULL. So if blk_mq_init_sq_queue() fails,
then that means unit[i].tag_set->tags is NULL and it leads to an Oops.
It's easiest to call put_disk() before the goto to clean up the partial
iteration. Then the earlier unit[] elements are fully allocated so we
can remove the checks whether "disk->queue" is NULL and the code is
simpler.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
of_dma_controller_free() was not called on module onloading.
This lead to a soft lockup:
watchdog: BUG: soft lockup - CPU#0 stuck for 23s!
Modules linked in: at_hdmac [last unloaded: at_hdmac]
when of_dma_request_slave_channel() tried to call ofdma->of_dma_xlate().
Cc: stable@vger.kernel.org
Fixes: bbe89c8e3d ("at_hdmac: move to generic DMA binding")
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The leak was found when opening/closing a serial port a great number of
time, increasing kmalloc-32 in slabinfo.
Each time the port was opened, dma_request_slave_channel() was called.
Then, in at_dma_xlate(), atslave was allocated with devm_kzalloc() and
never freed. (Well, it was free at module unload, but that's not what we
want).
So, here, kzalloc is more suited for the job since it has to be freed in
atc_free_chan_resources().
Cc: stable@vger.kernel.org
Fixes: bbe89c8e3d ("at_hdmac: move to generic DMA binding")
Reported-by: Mario Forner <m.forner@be4energy.com>
Suggested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
In this second set of fixes for the current -rc cycle, we have some
regressions fixes for the old omap_udc driver done by Aaro Koskinen.
We're also reverting an old patch on dwc3 which is, now, known to
break USB certification in some cases.
We have a fix on u_ether for an unsafe list iteration.
-----BEGIN PGP SIGNATURE-----
iQJRBAABCAA7FiEElLzh7wn96CXwjh2IzL64meEamQYFAlv/quMdHGZlbGlwZS5i
YWxiaUBsaW51eC5pbnRlbC5jb20ACgkQzL64meEamQZIZg//f3aKa9ndfOXfUI60
GRN9orxj8qRnXhEP0AgjCH6tjdl0PzCcZFD2URkuQWtcbSDEvVzteirpWio4ysUX
pD24Tl+KHX9Sv1HcdDSHoQXduoyxbsOactYRdPlY6AsBM4oRlvjEpGIFhk8Sk1+y
8gCdL04Z5opCUi3grmXdzp7yBkThKNsJGzDnQO6sqp/S2LLjwnKDHjSwkxhq8aCu
0qaRYm1IEWV7pUi1Vjy+1xacbEz6ag2nsergGsJRoT647Hizgx57k9EoT9Yhlhjt
LQ/ZnCNp91hvZpjb7cnIx1bSv/wuIN4dlrRuP3chGXvOUYYXZStLGfmr7hROZ6BD
/LhiO5RzLYNjruoktr/mlArLM14u3aPKh0H5mq1vyJ1HFUfcdcEvD379UrFEBaEO
SEoPa/ZKifLQK3taQtU3nZLdhBUTmJWgXLtw9NqkMe8R5SuiUBQ2Rzc7XCrhhrBn
xp/iQBYejsRNhGoK8cPz8/lqb4eO7gRMj6zmz57K/yU4VwKFoz2DY440/u10v6oH
q+mtcBRQPq0bX25jdWi0LB3OGgSUObbZSCnpN2pUtKfN8RK7Sqv+ZTMlo82Mx56t
OWhbef84y6HbIiiNXdD+1GwJNqaz7+JqTP4DpSpGtpHuujvj3d/A1PgWYFxAZ8LQ
LW59BUmSCACC/BRQMrWY7+39xHc=
=MIKU
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v4.20-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
USB: fixes for v4.20-rc4
In this second set of fixes for the current -rc cycle, we have some
regressions fixes for the old omap_udc driver done by Aaro Koskinen.
We're also reverting an old patch on dwc3 which is, now, known to
break USB certification in some cases.
We have a fix on u_ether for an unsafe list iteration.
* tag 'fixes-for-v4.20-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb:
usb: gadget: u_ether: fix unsafe list iteration
USB: omap_udc: fix rejection of out transfers when DMA is used
USB: omap_udc: fix USB gadget functionality on Palm Tungsten E
USB: omap_udc: fix omap_udc_start() on 15xx machines
USB: omap_udc: fix crashes on probe error and module removal
USB: omap_udc: use devm_request_irq()
Revert "usb: dwc3: gadget: skip Set/Clear Halt when invalid"