I would repeat the same commit message that was in commit 5e4b7e82d4
("clk: qcom: gcc-sdm845: Use floor ops for sdcc clks") but it seems
silly to do so when you could just go read that commit.
NOTE: this is actually extra terrible because we're missing the 50 MHz
rate in the table (see the next patch AKA ("clk: qcom: gcc-sc7180: Add
50 MHz clock rate for SDC2")). That means then when you run an older
SD card it'll try to clock it at 100 MHz when it's only specced to run
at 50 MHz max. As you can probably guess that doesn't work super
well.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Fixes: 17269568f7 ("clk: qcom: Add Global Clock controller (GCC) driver for SC7180")
Link: https://lore.kernel.org/r/20201210102234.1.I096779f219625148900fc984dd0084ed1ba87c7f@changeid
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The scpi_clk_match (struct of_device_id) is referenced only with
CONFIG_OF builds thus mark it as __maybe_unused:
drivers/clk/clk-scpi.c:132:34: warning:
‘scpi_clk_match’ defined but not used [-Wunused-const-variable=]
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201103162435.13689-8-krzk@kernel.org
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The driver can match only via the DT table so the table should be always
used and the of_match_ptr does not have any sense (this also allows ACPI
matching via PRP0001, even though it might be not relevant here). This
fixes compile warning (!CONFIG_OF && !CONFIG_MODULES):
drivers/clk/clk-pwm.c:139:34: warning:
‘clk_pwm_dt_ids’ defined but not used [-Wunused-const-variable=]
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201103162435.13689-1-krzk@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Add new compatible strings to the DT binding documents to support SiFive
FU740-C000.
Signed-off-by: Yash Shah <yash.shah@sifive.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Add compatible string for AM64 SoC in device tree binding of OMAP I2C
modules as the same IP is used.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Commit cf11e85fc0 ("mm: hugetlb: optionally allocate gigantic hugepages
using cma") added support for allocating gigantic hugepages using CMA,
by specifying the hugetlb_cma= kernel parameter, which will disable any
boot-time allocation of gigantic hugepages.
This patch enables that option also for s390.
Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
The random longs to be pulled by arch_get_random_long() are
prepared in an 4K buffer which is filled from the NIST 800-90
compliant s390 drbg. By default the random long buffer is refilled
256 times before the drbg itself needs a reseed. The reseed of the
drbg is done with 32 bytes fetched from the high quality (but slow)
trng which is assumed to deliver 100% entropy. So the 32 * 8 = 256
bits of entropy are spread over 256 * 4KB = 1MB serving 131072
arch_get_random_long() invocations before reseeded.
How often the 4K random long buffer is refilled with the drbg
before the drbg is reseeded can be adjusted. There is a module
parameter 's390_arch_rnd_long_drbg_reseed' accessible via
/sys/module/arch_random/parameters/rndlong_drbg_reseed
or as kernel command line parameter
arch_random.rndlong_drbg_reseed=<value>
This parameter tells how often the drbg fills the 4K buffer before
it is re-seeded by fresh entropy from the trng.
A value of 16 results in reseeding the drbg at every 16 * 4 KB = 64
KB with 32 bytes of fresh entropy pulled from the trng. So a value
of 16 would result in 256 bits entropy per 64 KB.
A value of 256 results in 1MB of drbg output before a reseed of the
drbg is done. So this would spread the 256 bits of entropy among 1MB.
Setting this parameter to 0 forces the reseed to take place every
time the 4K buffer is depleted, so the entropy rises to 256 bits
entropy per 4K or 0.5 bit entropy per arch_get_random_long(). With
setting this parameter to negative values all this effort is
disabled, arch_get_random long() returns false and thus indicating
that the arch_get_random_long() feature is disabled at all.
arch_get_random_long() is used by random.c among others to provide
an initial hash value to be mixed with the entropy pool on every
random data pull. For about 64 bytes read from /dev/urandom there
is one call to arch_get_random_long(). So these additional random
long values count for performance of /dev/urandom with measurable
but low penalty.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Juergen Christ <jchrist@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Remove the the redundant 'of_match_ptr' macro to fix below warning
when the CONFIG_OF is not selected.
All warnings:
drivers/hwspinlock/sirf_hwspinlock.c:87:34: warning: unused variable
'sirf_hwpinlock_ids' [-Wunused-const-variable]
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/250d35cb489c3c4c066f7ce256d27f36712a1979.1591618255.git.baolin.wang7@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reads the IPI buffer offset from the FW binary. The information resides
in addr of .ipi_buffer section.
Moves scp_ipi_init() to rproc_ops::parse_fw() phase. The IPI buffer can
be initialized only if the offset is clear.
To backward compatible to MT8183 SCP, specify the offset in the board
specific mtk_scp_of_data. Reads the default offset if the firmware
doesn't have it.
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20201202044609.2501913-1-tzungbi@google.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
platform_get_resource() may fail and in this case a NULL dereference
will occur.
Fix it to use devm_platform_ioremap_resource() instead of calling
platform_get_resource() and devm_ioremap().
This is detected by Coccinelle semantic patch.
@@
expression pdev, res, n, t, e, e1, e2;
@@
res = \(platform_get_resource\|platform_get_resource_byname\)(pdev, t,
n);
+ if (!res)
+ return -EINVAL;
... when != res == NULL
e = devm_ioremap(e1, res->start, e2);
Fixes: dc160e4491 ("remoteproc: qcom: Introduce Non-PAS ADSP PIL driver")
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
Link: https://lore.kernel.org/r/1607392460-20516-1-git-send-email-zhangchangzhong@huawei.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
In case of error, the function devm_ioremap_wc() returns NULL pointer
not ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Fixes: 6edbe024ba ("remoteproc: k3-dsp: Add a remoteproc driver of K3 C66x DSPs")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20200905122503.17352-1-yuehaibing@huawei.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
If the pm_runtime_get_sync failed in adsp_pds_enable when
loop (i), The unroll_pd_votes will start from (i - 1), and
it will resulted in following problems:
1) pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak.
2) Have not reset pds[i] performance state.
Then we fix it.
Fixes: 17ee2fb4e8 ("remoteproc: qcom: pas: Vote for active/proxy power domains")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Link: https://lore.kernel.org/r/20201102143554.144707-1-zhangqilong3@huawei.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak in adsp_start, so we should fix it.
Fixes: dc160e4491 ("remoteproc: qcom: Introduce Non-PAS ADSP PIL driver")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Link: https://lore.kernel.org/r/20201102143534.144484-1-zhangqilong3@huawei.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
If the pm_runtime_get_sync failed in q6v5_pds_enable when
loop (i), The unroll_pd_votes will start from (i - 1), and
it will resulted in following problems:
1) pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak.
2) Have not reset pds[i] performance state.
Then we fix it.
Fixes: 4760a896be ("remoteproc: q6v5-mss: Vote for rpmh power domains")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Link: https://lore.kernel.org/r/20201102143433.143996-1-zhangqilong3@huawei.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Now that this driver can be compiled with COMPILE_TEST, we have no
guarantee that CONFIG_OF will also be defined. When that happens, a
warning about mtk_scp_of_match being defined but unused will be reported
so make sure this variable is only defined if of_match_ptr() actually
uses it.
Fixes: cbd2dca749 remoteproc: scp: add COMPILE_TEST dependency
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Link: https://lore.kernel.org/r/20201102074007.299222-1-acourbot@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Add minidump id for modem in sm8150 chipset so that the regions to be
included in the coredump generated upon a crash is based on the minidump
tables in SMEM instead of those in the ELF header.
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by, Reviewed-by or Tested-by that you received previously.:
Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
Link: https://lore.kernel.org/r/1605819935-10726-5-git-send-email-sidgup@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
This patch adds support for collecting minidump in the event of remoteproc
crash. Parse the minidump table based on remoteproc's unique minidump-id,
read all memory regions from the remoteproc's minidump table entry and
expose the memory to userspace. The remoteproc platform driver can choose
to collect a full/mini dump by specifying the coredump op.
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Co-developed-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
Co-developed-by: Gurbir Arora <gurbaror@codeaurora.org>
Signed-off-by: Gurbir Arora <gurbaror@codeaurora.org>
Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
Link: https://lore.kernel.org/r/1605819935-10726-4-git-send-email-sidgup@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
This change adds a new kind of core dump mechanism which instead of dumping
entire program segments of the firmware, dumps sections of the remoteproc
memory which are sufficient to allow debugging the firmware. This function
thus uses section headers instead of program headers during creation of the
core dump elf.
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Co-developed-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
Link: https://lore.kernel.org/r/1605819935-10726-3-git-send-email-sidgup@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Each remoteproc might have different requirements for coredumps and might
want to choose the type of dumps it wants to collect. This change allows
remoteproc drivers to specify their own custom dump function to be executed
in place of rproc_coredump. If the coredump op is not specified by the
remoteproc driver it will be set to rproc_coredump by default.
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
Link: https://lore.kernel.org/r/1605819935-10726-2-git-send-email-sidgup@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Recently syzbot reported[0] that there is a deadlock amongst the users
of exec_update_mutex. The problematic lock ordering found by lockdep
was:
perf_event_open (exec_update_mutex -> ovl_i_mutex)
chown (ovl_i_mutex -> sb_writes)
sendfile (sb_writes -> p->lock)
by reading from a proc file and writing to overlayfs
proc_pid_syscall (p->lock -> exec_update_mutex)
While looking at possible solutions it occured to me that all of the
users and possible users involved only wanted to state of the given
process to remain the same. They are all readers. The only writer is
exec.
There is no reason for readers to block on each other. So fix
this deadlock by transforming exec_update_mutex into a rw_semaphore
named exec_update_lock that only exec takes for writing.
Cc: Jann Horn <jannh@google.com>
Cc: Vasiliy Kulikov <segoon@openwall.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Christopher Yeoh <cyeoh@au1.ibm.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Sargun Dhillon <sargun@sargun.me>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Fixes: eea9673250 ("exec: Add exec_update_mutex to replace cred_guard_mutex")
[0] https://lkml.kernel.org/r/00000000000063640c05ade8e3de@google.com
Reported-by: syzbot+db9cdf3dd1f64252c6ef@syzkaller.appspotmail.com
Link: https://lkml.kernel.org/r/87ft4mbqen.fsf@x220.int.ebiederm.org
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Fix incorrect type of max_entries in UVERBS_METHOD_QUERY_GID_TABLE -
max_entries is of type size_t although it can take negative values.
The following static check revealed it:
drivers/infiniband/core/uverbs_std_types_device.c:338 ib_uverbs_handler_UVERBS_METHOD_QUERY_GID_TABLE() warn: 'max_entries' unsigned <= 0
Fixes: 9f85cbe50a ("RDMA/uverbs: Expose the new GID query API to user space")
Link: https://lore.kernel.org/r/20201208073545.9723-4-leon@kernel.org
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Avihai Horon <avihaih@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
In procedure ib_register_device, procedure kobject_uevent is called
(advertising that the device is ready for userspace usage) even when
device_enable_and_get() returned an error.
As a result, various RDMA modules attempted to register for the device
even while the device driver was preparing to unregister the device.
Fix this by advertising the device availability only after enabling the
device succeeds.
Fixes: e7a5b4aafd ("RDMA/device: Don't fire uevent before device is fully initialized")
Link: https://lore.kernel.org/r/20201208073545.9723-3-leon@kernel.org
Suggested-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
The CQ pool mechanism had two problems:
1. The CQ pool lists were uninitialized in the device registration error
flow. As a result, all the list pointers remained NULL. This caused
the kernel to crash (in procedure ib_cq_pool_destroy) when that error
flow was taken (and unregister called). The stack trace snippet:
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0×0000) ? not-present page
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
. . .
RIP: 0010:ib_cq_pool_destroy+0x1b/0×70 [ib_core]
. . .
Call Trace:
disable_device+0x9f/0×130 [ib_core]
__ib_unregister_device+0x35/0×90 [ib_core]
ib_register_device+0x529/0×610 [ib_core]
__mlx5_ib_add+0x3a/0×70 [mlx5_ib]
mlx5_add_device+0x87/0×1c0 [mlx5_core]
mlx5_register_interface+0x74/0xc0 [mlx5_core]
do_one_initcall+0x4b/0×1f4
do_init_module+0x5a/0×223
load_module+0x1938/0×1d40
2. At device unregister, when cleaning up the cq pool, the cq's in the
pool lists were freed, but the cq entries were left in the list.
The fix for the first issue is to initialize the cq pool lists when the
ib_device structure is allocated for a new device (in procedure
_ib_alloc_device).
The fix for the second problem is to delete cq entries from the pool lists
when cleaning up the cq pool.
In addition, procedure ib_cq_pool_destroy() is renamed to the more
appropriate name ib_cq_pool_cleanup().
Fixes: 4aa1615268 ("RDMA/core: Fix ordering of CQ pool destruction")
Link: https://lore.kernel.org/r/20201208073545.9723-2-leon@kernel.org
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Two user triggerable crashers and a some EFA related regressions:
- Syzkaller found bug in CM
- Restore access to the GID table and fix modify_qp for EFA
- Crasher in qedr
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEfB7FMLh+8QxL+6i3OG33FX4gmxoFAl/SIhwACgkQOG33FX4g
mxpGJA//avv3jik7oQYssmuCy1QwIT/aRVcigvYdhgO7f1JbIs7DkVwQRz1rYYSv
SgtoFESutwgutQacuEg6DPn2xvan04gdGxK5dxPCU8RXm19yKmHi68U2yevMfVdI
VFjgMM2+JA+i91l8rfgXcz+Ygs4gUTeppM7Znv/1RAdY+d0BNeNEsZgA5Dm95y3F
p3Fa0wTHO1UKVNnpTi4TypFELfAsP2O8oascLkV7GwN86V/asenefsfdUlrXSxK4
687y3/AnBC8/pJp9RRLFbEkS6+wKZIRg1DyHMptkf6gFcVvx9AzeQqmqGnAz/9GG
9LusGUxdI4EQeADxpRQ56STs4U+5NtPWZdmSwOZFBZConaO2TQtjYWleBZUl3WQw
rKUwOYcyZU6AwF4V72x1RnEFzzIkF7EHTJLKKDCUxnW6UGz3jo+tCwR593pTnlon
ue+6ibktk1ZcFU4rhf80Y1OUHytmFLM3j2ynXZ/SE1uUahECHDDMmC5XUOvkR5Fn
ytL9wbFoPqs7zZ8vB1lvo/MYJy9P/qOMmHGLbca8YczWaZ5yzlZF1RibalmzblES
UJeKNe6MC0+vNaDWeSY474kP1r7XXMUGPrXVX1GOsqdDVrw2Li0FksgcBFAd0oIi
BizkmKth+p10XmsjxqmHCWOjDLylB4fmgSzKjmjXLejyn3BVJgY=
=CJih
-----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:
"Two user triggerable crashers and a some EFA related regressions:
- Syzkaller found a bug in CM
- Restore access to the GID table and fix modify_qp for EFA
- Crasher in qedr"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
RDMA/cm: Fix an attempt to use non-valid pointer when cleaning timewait
RDMA/core: Fix empty gid table for non IB/RoCE devices
RDMA/efa: Use the correct current and new states in modify QP
RDMA/qedr: iWARP invalid(zero) doorbell address fix
A problem exists in enabling silent stream when connection type is
DisplayPort. Silent stream programming is completed when a new DP
receiver is connected, but infoframe transmission does not actually
start until PCM is opened for the first time. This can result in audible
gap of multiple seconds. This only affects the first PCM open.
Fix the issue by properly assigning a converter to the silent stream,
and modifying the required stream ID programming sequence.
This change only affects Intel display audio codecs.
BugLink: https://github.com/thesofproject/linux/issues/2468
Fixes: 951894cf30 ("ALSA: hda/hdmi: Add Intel silent stream support")
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20201210174445.3134104-1-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now that unshare_files happens in begin_new_exec after the point of no
return, io_uring_task_cancel can also happen later.
Effectively this means io_uring activities for a task are only canceled
when exec succeeds.
Link: https://lkml.kernel.org/r/878saih2op.fsf@x220.int.ebiederm.org
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Oleg Nesterov recently asked[1] why is there an unshare_files in
do_coredump. After digging through all of the callers of lookup_fd it
turns out that it is
arch/powerpc/platforms/cell/spufs/coredump.c:coredump_next_context
that needs the unshare_files in do_coredump.
Looking at the history[2] this code was also the only piece of coredump code
that required the unshare_files when the unshare_files was added.
Looking at that code it turns out that cell is also the only
architecture that implements elf_coredump_extra_notes_size and
elf_coredump_extra_notes_write.
I looked at the gdb repo[3] support for cell has been removed[4] in binutils
2.34. Geoff Levand reports he is still getting questions on how to
run modern kernels on the PS3, from people using 3rd party firmware so
this code is not dead. According to Wikipedia the last PS3 shipped in
Japan sometime in 2017. So it will probably be a little while before
everyone's hardware dies.
Add some comments briefly documenting the coredump code that exists
only to support cell spufs to make it easier to understand the
coredump code. Eventually the hardware will be dead, or their won't
be userspace tools, or the coredump code will be refactored and it
will be too difficult to update a dead architecture and these comments
make it easy to tell where to pull to remove cell spufs support.
[1] https://lkml.kernel.org/r/20201123175052.GA20279@redhat.com
[2] 179e037fc1 ("do_coredump(): make sure that descriptor table isn't shared")
[3] git://sourceware.org/git/binutils-gdb.git
[4] abf516c6931a ("Remove Cell Broadband Engine debugging support").
Link: https://lkml.kernel.org/r/87h7pdnlzv.fsf_-_@x220.int.ebiederm.org
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Steinberg UR22 (with USB ID 0499:1509) requires the implicit feedback
for the proper playback, otherwise it causes occasional cracks.
This patch adds the corresponding the quirk table entry with the
recently added generic implicit fb support.
Reported-and-tested-by: Kilian <meschi@posteo.de>
Link: https://lore.kernel.org/r/20201209161835.13625-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It seems that the HD-audio clear and reconfig sysfs don't work any
longer after the recent driver core change. There are multiple issues
around that: the linked list corruption and the dead device handling.
The former issue is fixed by another patch for the driver core itself,
while the latter patch needs to be addressed in HD-audio side.
This patch corresponds to the latter, it recovers those broken
functions by replacing the device detach and attach actions with the
standard core API functions, which are almost equivalent with unbind
and bind actions.
Fixes: 654888327e ("driver core: Avoid binding drivers to dead devices")
Cc: <stable@vger.kernel.org>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209207
Link: https://lore.kernel.org/r/20201209150119.7705-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A while ago it was reported that posix file locking goes wrong when a
multi-threaded process calls exec. I looked into the history and this
is definitely a regression, that should be fixed if we can.
This set of changes cleanups of the code in exec so hopefully this code
will not regress again. Then it adds helpers and fixes the users of
files_struct so the reference count is only incremented if COPY_FILES is
passed to clone (or if io_uring takes a reference). Then it removes
helpers (get_files_struct, __install_fd, __alloc_fd, __close_fd) that
are no longer needed and if used would encourage code that increments
the count of files_struct somewhere besides in clone when COPY_FILES is
passed.
In addition to fixing the bug in exec and simplifing the code this set
of changes by virtue of getting files_struct.count correct it optimizes
fdget. With proc and other places not temporarily increasing the count
on files_struct __fget_light should succeed more often in being able to
return a struct file without touching it's reference count.
Fixing the count in files_struct was suggested by Oleg[1].
For those that are interested in the history of this issue I have
included as much of it as I could find in the first change.
Since v1:
- Renamed the functions
__fcheck_files -> files_lookup_fd_raw
fcheck_files -> files_lookup_fd_locked
fcheck_files -> files_lookup_fd_rcu
fcheck_files -> lookup_fd_rcu
fcheck_task -> task_lookup_fd_rcu
fnext_task -> task_lookup_next_fd_rcu
__close_fd_get_file -> close_fd_get_file
- Simplified get_file_raw_ptr
- Removed ksys_close
- Examined the penalty for taking task_lock. The helper
task_lookup_next_fd_rcu takes task_lock each iteration. Concern was
expressed that this might be a problem. The function tid_fd_mode
isn called from tid_fd_revalidate which is called when ever a file
descriptor file is stat'ed, opened, or otherwise accessed. The
function tid_fd_mode histrocally called get_files_struct which took
and dropped task_lock. So the volume of task_lock calls is already
proportional to the number of file descriptors. A micro benchmark
did not see the move to task_lookup_next_fd_rcu making a difference
in performance. Which suggests that the change to taking the task
lock for every file descriptor found in task_lookup_next_fd will not
be a problem.
- Reviewed the code for conflicts with io_uring (especially the
removal of get_files_struct). To my surprise no conflicts were
found as io_uring does not use standard helpers but instead rolls
it's own version of get_files_struct by hand.
Documentation/filesystems/files.rst | 8 +-
arch/powerpc/platforms/cell/spufs/coredump.c | 2 +-
drivers/android/binder.c | 2 +-
fs/autofs/dev-ioctl.c | 5 +-
fs/coredump.c | 5 +-
fs/exec.c | 29 +++----
fs/file.c | 124 +++++++++++++--------------
fs/io_uring.c | 2 +-
fs/locks.c | 14 +--
fs/notify/dnotify/dnotify.c | 2 +-
fs/open.c | 2 +-
fs/proc/fd.c | 48 ++++-------
include/linux/fdtable.h | 40 +++++----
include/linux/syscalls.h | 12 ---
kernel/bpf/syscall.c | 20 +----
kernel/bpf/task_iter.c | 44 +++-------
kernel/fork.c | 12 +--
kernel/kcmp.c | 29 ++-----
18 files changed, 153 insertions(+), 247 deletions(-)
Eric W. Biederman (25):
exec: Don't open code get_close_on_exec
exec: Move unshare_files to fix posix file locking during exec
exec: Simplify unshare_files
exec: Remove reset_files_struct
kcmp: In kcmp_epoll_target use fget_task
bpf: In bpf_task_fd_query use fget_task
proc/fd: In proc_fd_link use fget_task
file: Rename __fcheck_files to files_lookup_fd_raw
file: Factor files_lookup_fd_locked out of fcheck_files
file: Replace fcheck_files with files_lookup_fd_rcu
file: Rename fcheck lookup_fd_rcu
file: Implement task_lookup_fd_rcu
proc/fd: In tid_fd_mode use task_lookup_fd_rcu
kcmp: In get_file_raw_ptr use task_lookup_fd_rcu
file: Implement task_lookup_next_fd_rcu
proc/fd: In proc_readfd_common use task_lookup_next_fd_rcu
bpf/task_iter: In task_file_seq_get_next use task_lookup_next_fd_rcu
proc/fd: In fdinfo seq_show don't use get_files_struct
file: Merge __fd_install into fd_install
file: In f_dupfd read RLIMIT_NOFILE once.
file: Merge __alloc_fd into alloc_fd
file: Rename __close_fd to close_fd and remove the files parameter
file: Replace ksys_close with close_fd
file: Rename __close_fd_get_file close_fd_get_file
file: Remove get_files_struct
[1] https://lkml.kernel.org/r/20180915160423.GA31461@redhat.com
v1: https://lkml.kernel.org/r/87ft8l6ic3.fsf@x220.int.ebiederm.org
Reported-by: Jeff Layton <jlayton@redhat.com>
Reported-by: Daniel P. Berrangé <berrange@redhat.com>
Suggested-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lkml.kernel.org/r/87r1on1v62.fsf@x220.int.ebiederm.org
Link: https://lists.openvz.org/pipermail/criu/2020-November/045123.html
Link: https://marc.info/?l=openvz-criu&m=160591423214257
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+QmuaPwR3wnBdVwACF8+vY7k4RUFAl/SAkAACgkQCF8+vY7k
4RXd2A/7B2hPds737XVei8/b/Av1HmE9AMsfy77iXP7gm3BBBBamhFlCohM6e8bG
3s2YmOsJ/1tCN4SY6yKNHBDJciYWKC6ql1GLUmlgW+uvJMMRN9SsrmRRs9Ws4q6B
N2J1eD399SYpnPwcvtbsoaS6A8LQXFHQZVnoqiPRamyUEMQYvXSGdeDgw1032EL5
+74ZMbJQgs6ri3mCkX9FIp3z9foZaSD5bmjrFJKXqllkFBLgpaIxv8C6KjTwCvT/
sgvj1ihnjO4b+atC4QoYi4gyWBEU31dMxzL32riRin8gafA42IAvaUaoS+vpBY6N
yDhS8HH6vpOXVkPtzfrBXzz/7ZiZoBFJWBMdzoeHX41Nrd2D6LKWsUp9ZqC+uBmF
zb7NC20IZr8XwO8KGNSmsZ4jzw7wDbA5LstSZVQSv5WbOtnrGMQ0q2NWgMn7SziS
pk3nbZ4JtFp4SkxP/wNYyN+KdWoHRet67Fj+jOjJghw8KlnUmqoAv2+CuHYSlDEQ
e+VW63EVGZ/MNBzTdGWZMnw8meZ0QR2LXq61sIvbDoxIdVWEK2XA4cmMRBm2pZ8P
9mqITdmgeH8xy5CsEvr+hcRl/pmjqGZ9jo9u3kKshbyL1vnb8jmWo+TaEopeBE4R
LHzk+/FLAKUTuzK+lMc0wELGHVjHUa8p+TPr7yQvmSa+dIfGZCM=
=D71n
-----END PGP SIGNATURE-----
Merge tag 'media/v5.10-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media fixes from Mauro Carvalho Chehab:
"A couple of fixes:
- videobuf2: fix a DMABUF bug, preventing it to properly handle cache
sync/flush
- vidtv: an usage after free and a few sparse/smatch warning fixes
- pulse8-cec: a duplicate free and a bug related to new firmware
usage
- mtk-cir: fix a regression on a clock setting"
* tag 'media/v5.10-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
media: vidtv: fix some warnings
media: vidtv: fix kernel-doc markups
media: [next] media: vidtv: fix a read from an object after it has been freed
media: vb2: set cache sync hints when init buffers
media: pulse8-cec: add support for FW v10 and up
media: pulse8-cec: fix duplicate free at disconnect or probe error
media: mtk-cir: fix calculation of chk period
Added retry mechanism to ensure VMM enable bit is set during the
block transfer of data between host and WILC FW.
Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201208103739.28597-1-ajay.kathat@microchip.com
* A few fixes and improvements in the FW debugging framework;
* A fix in the HE capabilities settings;
* Small fix in the logs for SAR;
* Move queue code to a common place;
* Support for 6GHz;
* Improve validation of firmware notifications;
* Debugging improvements and fixes;
* Replace terminology with inclusive words determined by the guidelines;
* Convert copyright notices to SPDX tags;
* Added more validations for firmware notifications;
* A couple of debugging/recovery fixes;
* Added some more validations for firmware notifications;
* Support for a new type of HW;
* A couple of channel switch fixes;
* Support new FW reset handshake;
* Add a couple of RX handlers that were accidentally left out;
* Some other clean-ups and small fixes;
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEF3LNfgb2BPWm68smoUecoho8xfoFAl/RTY8ACgkQoUecoho8
xfofyxAAidnwDIo/iMX8c6xSbvrAy9Svys0NSgkQnEIkpMOx+t2nD8wyYC/jRUKD
vEOZT9MvPvM/i2ZSnN5Krj6oGhuoIxLVhO98MXpy9OOy783ajLC3gx8COzCnlnWW
bJdCSlHAPkN2oTD5S2NP0Y2REZA3e7I/Q9exHhMAQD0iDqVUN6AA5/7X+6b0JRKT
8ClMoCUZ8Dza41b1wlKvwzzZYoct76fvYb7ygsyot5uZXzN7sF1Mag9pNnLyK3yx
Sa1ytJDChUIqn/LfLW/4svS99+/eRwmwU9J45fisv86Pk5Fvcx+VORS6MRqvPvCP
SuirOfrEy/K7b5lHhzTIv6Ta6WM8XaCRVNubk6dnc5dT1n+uYHBwsNEO5ePUnmCN
P+mq0xm+zXUC37Ng7Cmxhm2Z9QImTgD1zbNc1UkIWjP4+IsW6swMh7JyAXHl2RIh
tQeiNYJ85BxCFl5oqJhSIjFTR0DJM6SkNF+uwisluS0k/WgeQMcgovx7+XsZR5+p
YQHRT3wxWk9Dx9iWmfrVHyeLGDezUqN9ICSdsMkXYpwNoDQ7sZJpwTQXn2fG+maT
97KcOPQbz7TazZipKjzY5Y+JLX+NG6nG2BsImEkzPv8L074GnW7djVbcOTP7cWN0
yyxsVZcQmAu4/38/J45C7aqm5ovmkI4YQBx0x3BO4FXDCcMxpak=
=0gIs
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-next-for-kalle-2020-12-09' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
iwlwifi patches intended for v5.11
* A few fixes and improvements in the FW debugging framework;
* A fix in the HE capabilities settings;
* Small fix in the logs for SAR;
* Move queue code to a common place;
* Support for 6GHz;
* Improve validation of firmware notifications;
* Debugging improvements and fixes;
* Replace terminology with inclusive words determined by the guidelines;
* Convert copyright notices to SPDX tags;
* Added more validations for firmware notifications;
* A couple of debugging/recovery fixes;
* Added some more validations for firmware notifications;
* Support for a new type of HW;
* A couple of channel switch fixes;
* Support new FW reset handshake;
* Add a couple of RX handlers that were accidentally left out;
* Some other clean-ups and small fixes;
# gpg: Signature made Thu 10 Dec 2020 12:19:59 AM EET using RSA key ID 1A3CC5FA
# gpg: Good signature from "Luciano Roth Coelho (Luca) <luca@coelho.fi>"
# gpg: aka "Luciano Roth Coelho (Intel) <luciano.coelho@intel.com>"
When discussing[1] exec and posix file locks it was realized that none
of the callers of get_files_struct fundamentally needed to call
get_files_struct, and that by switching them to helper functions
instead it will both simplify their code and remove unnecessary
increments of files_struct.count. Those unnecessary increments can
result in exec unnecessarily unsharing files_struct which breaking
posix locks, and it can result in fget_light having to fallback to
fget reducing system performance.
Now that get_files_struct has no more users and can not cause the
problems for posix file locking and fget_light remove get_files_struct
so that it does not gain any new users.
[1] https://lkml.kernel.org/r/20180915160423.GA31461@redhat.com
Suggested-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
v1: https://lkml.kernel.org/r/20200817220425.9389-13-ebiederm@xmission.com
Link: https://lkml.kernel.org/r/20201120231441.29911-24-ebiederm@xmission.com
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
The function close_fd_get_file is explicitly a variant of
__close_fd[1]. Now that __close_fd has been renamed close_fd, rename
close_fd_get_file to be consistent with close_fd.
When __alloc_fd, __close_fd and __fd_install were introduced the
double underscore indicated that the function took a struct
files_struct parameter. The function __close_fd_get_file never has so
the naming has always been inconsistent. This just cleans things up
so there are not any lingering mentions or references __close_fd left
in the code.
[1] 80cd795630 ("binder: fix use-after-free due to ksys_close() during fdget()")
Link: https://lkml.kernel.org/r/20201120231441.29911-23-ebiederm@xmission.com
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
The function __close_fd was added to support binder[1]. Now that
binder has been fixed to no longer need __close_fd[2] all calls
to __close_fd pass current->files.
Therefore transform the files parameter into a local variable
initialized to current->files, and rename __close_fd to close_fd to
reflect this change, and keep it in sync with the similar changes to
__alloc_fd, and __fd_install.
This removes the need for callers to care about the extra care that
needs to be take if anything except current->files is passed, by
limiting the callers to only operation on current->files.
[1] 483ce1d4b8 ("take descriptor-related part of close() to file.c")
[2] 44d8047f1d ("binder: use standard functions to allocate fds")
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
v1: https://lkml.kernel.org/r/20200817220425.9389-17-ebiederm@xmission.com
Link: https://lkml.kernel.org/r/20201120231441.29911-21-ebiederm@xmission.com
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
The function __alloc_fd was added to support binder[1]. With binder
fixed[2] there are no more users.
As alloc_fd just calls __alloc_fd with "files=current->files",
merge them together by transforming the files parameter into a
local variable initialized to current->files.
[1] dcfadfa4ec ("new helper: __alloc_fd()")
[2] 44d8047f1d ("binder: use standard functions to allocate fds")
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
v1: https://lkml.kernel.org/r/20200817220425.9389-16-ebiederm@xmission.com
Link: https://lkml.kernel.org/r/20201120231441.29911-20-ebiederm@xmission.com
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Simplify the code, and remove the chance of races by reading
RLIMIT_NOFILE only once in f_dupfd.
Pass the read value of RLIMIT_NOFILE into alloc_fd which is the other
location the rlimit was read in f_dupfd. As f_dupfd is the only
caller of alloc_fd this changing alloc_fd is trivially safe.
Further this causes alloc_fd to take all of the same arguments as
__alloc_fd except for the files_struct argument.
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
v1: https://lkml.kernel.org/r/20200817220425.9389-15-ebiederm@xmission.com
Link: https://lkml.kernel.org/r/20201120231441.29911-19-ebiederm@xmission.com
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
The function __fd_install was added to support binder[1]. With binder
fixed[2] there are no more users.
As fd_install just calls __fd_install with "files=current->files",
merge them together by transforming the files parameter into a
local variable initialized to current->files.
[1] f869e8a7f7 ("expose a low-level variant of fd_install() for binder")
[2] 44d8047f1d ("binder: use standard functions to allocate fds")
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
v1:https://lkml.kernel.org/r/20200817220425.9389-14-ebiederm@xmission.com
Link: https://lkml.kernel.org/r/20201120231441.29911-18-ebiederm@xmission.com
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
When discussing[1] exec and posix file locks it was realized that none
of the callers of get_files_struct fundamentally needed to call
get_files_struct, and that by switching them to helper functions
instead it will both simplify their code and remove unnecessary
increments of files_struct.count. Those unnecessary increments can
result in exec unnecessarily unsharing files_struct which breaking
posix locks, and it can result in fget_light having to fallback to
fget reducing system performance.
Instead hold task_lock for the duration that task->files needs to be
stable in seq_show. The task_lock was already taken in
get_files_struct, and so skipping get_files_struct performs less work
overall, and avoids the problems with the files_struct reference
count.
[1] https://lkml.kernel.org/r/20180915160423.GA31461@redhat.com
Suggested-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
v1: https://lkml.kernel.org/r/20200817220425.9389-12-ebiederm@xmission.com
Link: https://lkml.kernel.org/r/20201120231441.29911-17-ebiederm@xmission.com
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
When discussing[1] exec and posix file locks it was realized that none
of the callers of get_files_struct fundamentally needed to call
get_files_struct, and that by switching them to helper functions
instead it will both simplify their code and remove unnecessary
increments of files_struct.count. Those unnecessary increments can
result in exec unnecessarily unsharing files_struct which breaking
posix locks, and it can result in fget_light having to fallback to
fget reducing system performance.
Using task_lookup_next_fd_rcu simplifies task_file_seq_get_next, by
moving the checking for the maximum file descritor into the generic
code, and by remvoing the need for capturing and releasing a reference
on files_struct. As the reference count of files_struct no longer
needs to be maintained bpf_iter_seq_task_file_info can have it's files
member removed and task_file_seq_get_next no longer needs it's fstruct
argument.
The curr_fd local variable does need to become unsigned to be used
with fnext_task. As curr_fd is assigned from and assigned a u32
making curr_fd an unsigned int won't cause problems and might prevent
them.
[1] https://lkml.kernel.org/r/20180915160423.GA31461@redhat.com
Suggested-by: Oleg Nesterov <oleg@redhat.com>
v1: https://lkml.kernel.org/r/20200817220425.9389-11-ebiederm@xmission.com
Link: https://lkml.kernel.org/r/20201120231441.29911-16-ebiederm@xmission.com
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
When discussing[1] exec and posix file locks it was realized that none
of the callers of get_files_struct fundamentally needed to call
get_files_struct, and that by switching them to helper functions
instead it will both simplify their code and remove unnecessary
increments of files_struct.count. Those unnecessary increments can
result in exec unnecessarily unsharing files_struct which breaking
posix locks, and it can result in fget_light having to fallback to
fget reducing system performance.
Using task_lookup_next_fd_rcu simplifies proc_readfd_common, by moving
the checking for the maximum file descritor into the generic code, and
by remvoing the need for capturing and releasing a reference on
files_struct.
As task_lookup_fd_rcu may update the fd ctx->pos has been changed
to be the fd +2 after task_lookup_fd_rcu returns.
[1] https://lkml.kernel.org/r/20180915160423.GA31461@redhat.com
Suggested-by: Oleg Nesterov <oleg@redhat.com>
Tested-by: Andy Lavr <andy.lavr@gmail.com>
v1: https://lkml.kernel.org/r/20200817220425.9389-10-ebiederm@xmission.com
Link: https://lkml.kernel.org/r/20201120231441.29911-15-ebiederm@xmission.com
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
As a companion to fget_task and task_lookup_fd_rcu implement
task_lookup_next_fd_rcu that will return the struct file for the first
file descriptor number that is equal or greater than the fd argument
value, or NULL if there is no such struct file.
This allows file descriptors of foreign processes to be iterated
through safely, without needed to increment the count on files_struct.
Some concern[1] has been expressed that this function takes the task_lock
for each iteration and thus for each file descriptor. This place
where this function will be called in a commonly used code path is for
listing /proc/<pid>/fd. I did some small benchmarks and did not see
any measurable performance differences. For ordinary users ls is
likely to stat each of the directory entries and tid_fd_mode called
from tid_fd_revalidae has always taken the task lock for each file
descriptor. So this does not look like it will be a big change in
practice.
At some point is will probably be worth changing put_files_struct to
free files_struct after an rcu grace period so that task_lock won't be
needed at all.
[1] https://lkml.kernel.org/r/20200817220425.9389-10-ebiederm@xmission.com
v1: https://lkml.kernel.org/r/20200817220425.9389-9-ebiederm@xmission.com
Link: https://lkml.kernel.org/r/20201120231441.29911-14-ebiederm@xmission.com
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
