20 Jan, 2021
6 commits
-
This is the 5.10.7 stable release
* tag 'v5.10.7': (144 commits)
Linux 5.10.7
scsi: target: Fix XCOPY NAA identifier lookup
rtlwifi: rise completion at the last step of firmware callback
...Signed-off-by: Jason Liu
-
This is the 5.10.6 stable release
* tag 'v5.10.6': (21 commits)
Linux 5.10.6
mwifiex: Fix possible buffer overflows in mwifiex_cmd_802_11_ad_hoc_start
exec: Transform exec_update_mutex into a rw_semaphore
...Signed-off-by: Jason Liu
Conflicts:
drivers/rtc/rtc-pcf2127.c -
This is the 5.10.5 stable release
* tag 'v5.10.5': (63 commits)
Linux 5.10.5
device-dax: Fix range release
ext4: avoid s_mb_prefetch to be zero in individual scenarios
...Signed-off-by: Jason Liu
-
This is a gpio driver to control the PINs which are managed by scu fw.
Signed-off-by: Shenwei Wang
-
The word of a message can arrive in any order and the current driver
cannot receive more than 4-word message.As the message can arrive in any order, the position where they
should be stored is stored in the sc_chan struct:
- initialized at the index of the MU slot
- incremented each time after a new word is storedSigned-off-by: Franck LENORMAND
-
The implementation was limiting the size of a message which can be
received to 4 but soem response can be bigger. For example the
response of the 'sc_seco_secvio_config' API is 6 words.This patch removes this limitation relying on the count of word
received instead of the index of the chan.
It does so by duplicating imx_scu_call_rpc as imx_scu_call_big_rpc
in order to cahnge the RX method using imx_scu_big_rx_callback
instead of imx_scu_rx_callback.Signed-off-by: Franck LENORMAND
19 Jan, 2021
2 commits
-
During suspend/resume stress test, we found descriptor write back by DMA
could exhibit unusual behavior, e.g.:
003 [0xc4310030]: 0x0 0x40 0x0 0xb5010040We can see that desc3 write back is 0xb5010040, it is still ownd by DMA,
so application would not recycle this buffer. It will trigger fatal bus
error when DMA try to use this descriptor again. When current descriptor
move to this bad descriptor, it would not receive any more. To fix this
issue, we should re-init all rx buffers when mac resume back. This issue
can be reproduced on i.MX8MP EVK board.Reviewed-by: Jun Li
Signed-off-by: Joakim Zhang -
stmmac_xmit() call stmmac_tx_timer_arm() at the end to modify tx timer to
do the transmission cleanup work. Imagine such a situation, stmmac enters
suspend immediately after tx timer modified, it's expire callback
stmmac_tx_clean() would not be invoked. This could affect BQL, since
netdev_tx_sent_queue() has been called, but netdev_tx_completed_queue()
have not been involved, as a result, dql_avail(&dev_queue->dql) finally always
return a negative value.__dev_queue_xmit->__dev_xmit_skb->qdisc_run->__qdisc_run->qdisc_restart->dequeue_skb:
if ((q->flags & TCQ_F_ONETXQUEUE) &&
netif_xmit_frozen_or_stopped(txq)) // __QUEUE_STATE_STACK_XOFF is setNet core will stop transmitting any more. Finillay, net watchdong would timeout.
To fix this issue, we should call netdev_tx_reset_queue() in stmmac_resume().Reviewed-by: Jun Li
Signed-off-by: Joakim Zhang
18 Jan, 2021
1 commit
-
Add explict memory barrier for the wdog unlock sequence.
Suggested-by: Ye Li
Signed-off-by: Jacky Bai
Reviewed-by: Ye Li
16 Jan, 2021
1 commit
-
There are cases when default / POR value for RTSDCTL[ENT_DLY] is
equal or greater than minimum value that kernel tries to program (3200).In this case, (re-)programming of RTSDCTL[ENT_DLY] and related RTFRQMIN,
RTFRQMAX is skipped - this logic is fine.
However, RNG sample size (RTSDCTL[SAMP_SIZE]) and associated self-test
parameters must be (re-)programmed irrespective of this condition.This solves the issue of RNG performance dropping after a suspend/resume
cycle on parts where caam loses power AND default value for
RTSDCTL[ENT_DLY] is >= 3200 AND RNG handles are successfully instantiated.Fixes: 29d925df53cf ("LF-2943 crypto: caam - optimize RNG sample size")
Signed-off-by: Horia Geantă
Reviewed-by: Varun Sethi
15 Jan, 2021
1 commit
-
There are cases when the interrupt status register (JRINTR) is non-zero,
even though:
1. An interrupt was generated, but it was masked OR
2. There was no interrupt generated at all
for the corresponding job ring.1. The case when interrupt is masked (JRCFGR_LS[IMSK]=1b'1)
while other events have happened and are being accounted for, e.g.
-JRINTR[HALT]=2b'10 - input job ring underwent a flush of all on-going
jobs and processing of still-existing jobs (sitting in the ring) has been
halted
-JRINTR[HALT]=2b'01 - input job ring is currently undergoing a flush
-JRINTR[ENTER_FAIL]=1b'1 - SecMon / SNVS transitioned to FAIL MODE
It doesn't matter whether these events would assert the interrupt signal
or not, interrupt is anyhow masked.2. The case when interrupt is not masked (JRCFGR_LS[IMSK]=1b'0), however
the events accounted for in JRINTR do not generate interrupts, e.g.:
-JRINTR[HALT]=2b'01
-JRINTR[ENTER_FAIL]=1b'1 and JRCFGR_MS[FAIL_MODE]=1b'0Currently in these cases, when the JR interrupt handler is invoked (as a
consequence of JR sharing the interrupt line with other devices - e.g.
the two JRs on i.MX7ULP) it continues execution instead of returning
IRQ_NONE.
This could lead to situations like interrupt handler clearing JRINTR (and
thus also the JRINTR[HALT] field) while corresponding job ring is
suspended and then that job ring failing on resume path, due to expecting
JRINTR[HALT]=b'10 and reading instead JRINTR[HALT]=b'00.Fix this by checking status of JRINTR[JRI] in the JR interrupt handler.
If JRINTR[JRI]=1b'0, there was no interrupt generated for this JR and
handler must return IRQ_NONE.Signed-off-by: Horia Geantă
Reviewed-by: Varun Sethi
14 Jan, 2021
5 commits
-
Fine tune hdmi phy to pass HDMI electrical CTS.
Signed-off-by: Sandor Yu
Reviewed-by: Robby Cai -
reset hdmi phy power.
Signed-off-by: Sandor Yu
Reviewed-by: Robby Cai -
Set the value of SS1-SS0 and SF3-SF0 to zero to pass CTS 7-30.
Signed-off-by: Sandor Yu
Reviewed-by: Shengjiu Wang -
We enable the virtio_ivshmem driver and add
shared memory region including pci devices in cell file. But we not
start backend.There might be garbage data in "vi_dev->virtio_header", so we need to
check peer_state to abort the probe earlier.Note: patch accepted by Jailhouse Linux repo
Signed-off-by: Peng Fan -
Call watchdog_stop_on_reboot in probe func
Signed-off-by: Zhao Qiang
13 Jan, 2021
24 commits
-
driver will use the data to report the skipped frame.
but the vpu driver of 8q can't get the skipped frame id,
so set it to an invalid value.Signed-off-by: Ming Qian
Reviewed-by: Shijie Qin
(cherry picked from commit f9782fd6e516647ad73476bb9d39eb2dd892ae05) -
…_G and V4L2_PIX_FMT_VC1_ANNEX_L
Due to historical reasons,
we have made a mistake abort vc1_l and vc1_g,
they are reversed.
so we need to exchange them in driver,
and the userspace also needs to be modified accordinglySigned-off-by: Ming Qian <ming.qian@nxp.com>
Reviewed-by: Shijie Qin <shijie.qin@nxp.com>
(cherry picked from commit 9e4f4f44257312c2b4df47d0005762e8068e1bd0) -
we have add a header file imx_vpu.h
to define the custom interface based on v4l2 driver.
to unify the interface,
we need to align the 8qm/qxp v4l2 driver to this header.Signed-off-by: Ming Qian
Reviewed-by: Shijie Qin
(cherry picked from commit 8cfb286daa653c5876c157d20bed6a44420bab27) -
commit 2896c93811e39d63a4d9b63ccf12a8fbc226e5e4 upstream.
When attempting to match EXTENDED COPY CSCD descriptors with corresponding
se_devices, target_xcopy_locate_se_dev_e4() currently iterates over LIO's
global devices list which includes all configured backstores.This change ensures that only initiator-accessible backstores are
considered during CSCD descriptor lookup, according to the session's
se_node_acl LUN list.To avoid LUN removal race conditions, device pinning is changed from being
configfs based to instead using the se_node_acl lun_ref.Reference: CVE-2020-28374
Fixes: cbf031f425fd ("target: Add support for EXTENDED_COPY copy offload emulation")
Reviewed-by: Lee Duncan
Signed-off-by: David Disseldorp
Signed-off-by: Mike Christie
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman -
commit 4dfde294b9792dcf8615b55c58f093d544f472f0 upstream.
request_firmware_nowait() which schedules another work is used to load
firmware when USB is probing. If USB is unplugged before running the
firmware work, it goes disconnect ops, and then causes use-after-free.
Though we wait for completion of firmware work before freeing the hw,
firmware callback rises completion too early. So I move it to the
last step.usb 5-1: Direct firmware load for rtlwifi/rtl8192cufw.bin failed with error -2
rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
rtlwifi: Selected firmware is not available
==================================================================
BUG: KASAN: use-after-free in rtl_fw_do_work.cold+0x68/0x6a drivers/net/wireless/realtek/rtlwifi/core.c:93
Write of size 4 at addr ffff8881454cff50 by task kworker/0:6/7379CPU: 0 PID: 7379 Comm: kworker/0:6 Not tainted 5.10.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: events request_firmware_work_func
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x107/0x163 lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xae/0x4c8 mm/kasan/report.c:385
__kasan_report mm/kasan/report.c:545 [inline]
kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562
rtl_fw_do_work.cold+0x68/0x6a drivers/net/wireless/realtek/rtlwifi/core.c:93
request_firmware_work_func+0x12c/0x230 drivers/base/firmware_loader/main.c:1079
process_one_work+0x933/0x1520 kernel/workqueue.c:2272
worker_thread+0x64c/0x1120 kernel/workqueue.c:2418
kthread+0x38c/0x460 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296The buggy address belongs to the page:
page:00000000f54435b3 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1454cf
flags: 0x200000000000000()
raw: 0200000000000000 0000000000000000 ffffea00051533c8 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detectedMemory state around the buggy address:
ffff8881454cfe00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff8881454cfe80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff8881454cff00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff8881454cff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff8881454d0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffReported-by: syzbot+65be4277f3c489293939@syzkaller.appspotmail.com
Signed-off-by: Ping-Ke Shih
Signed-off-by: Kalle Valo
Link: https://lore.kernel.org/r/20201214053106.7748-1-pkshih@realtek.com
Signed-off-by: Greg Kroah-Hartman -
commit ff58f7dd0c1352a01de3a40327895bd51e03de3a upstream.
The clean up is off by one so this will start at "i" and it should start
with "i - 1" and then it doesn't unregister the zeroeth elements in the
array.Fixes: c52ca478233c ("dmaengine: idxd: add configuration component of driver")
Signed-off-by: Dan Carpenter
Acked-by: Dave Jiang
Link: https://lore.kernel.org/r/X9nFeojulsNqUSnG@mwanda
Signed-off-by: Vinod Koul
Signed-off-by: Greg Kroah-Hartman -
commit b544011f0e58ce43c40105468d6dc67f980a0c7a upstream.
In case WQE includes inline header the vlan is inserted by driver even
if vlan offload is set. On geneve over vlan interface where software
parser is used the SWP offsets should be updated according to the added
vlan.Fixes: e3cfc7e6b7bd ("net/mlx5e: TX, Add geneve tunnel stateless offload support")
Signed-off-by: Moshe Shemesh
Reviewed-by: Tariq Toukan
Signed-off-by: Saeed Mahameed
Signed-off-by: Greg Kroah-Hartman -
commit b16671e8f493e3df40b1fb0dff4078f391c5099a upstream.
When large bucket feature was added, BCH_FEATURE_INCOMPAT_LARGE_BUCKET
was introduced into the incompat feature set. It used bucket_size_hi
(which was added at the tail of struct cache_sb_disk) to extend current
16bit bucket size to 32bit with existing bucket_size in struct
cache_sb_disk.This is not a good idea, there are two obvious problems,
- Bucket size is always value power of 2, if store log2(bucket size) in
existing bucket_size of struct cache_sb_disk, it is unnecessary to add
bucket_size_hi.
- Macro csum_set() assumes d[SB_JOURNAL_BUCKETS] is the last member in
struct cache_sb_disk, bucket_size_hi was added after d[] which makes
csum_set calculate an unexpected super block checksum.To fix the above problems, this patch introduces a new incompat feature
bit BCH_FEATURE_INCOMPAT_LOG_LARGE_BUCKET_SIZE, when this bit is set, it
means bucket_size in struct cache_sb_disk stores the order of power-of-2
bucket size value. When user specifies a bucket size larger than 32768
sectors, BCH_FEATURE_INCOMPAT_LOG_LARGE_BUCKET_SIZE will be set to
incompat feature set, and bucket_size stores log2(bucket size) more
than store the real bucket size value.The obsoleted BCH_FEATURE_INCOMPAT_LARGE_BUCKET won't be used anymore,
it is renamed to BCH_FEATURE_INCOMPAT_OBSO_LARGE_BUCKET and still only
recognized by kernel driver for legacy compatible purpose. The previous
bucket_size_hi is renmaed to obso_bucket_size_hi in struct cache_sb_disk
and not used in bcache-tools anymore.For cache device created with BCH_FEATURE_INCOMPAT_LARGE_BUCKET feature,
bcache-tools and kernel driver still recognize the feature string and
display it as "obso_large_bucket".With this change, the unnecessary extra space extend of bcache on-disk
super block can be avoided, and csum_set() may generate expected check
sum as well.Fixes: ffa470327572 ("bcache: add bucket_size_hi into struct cache_sb_disk for large bucket")
Signed-off-by: Coly Li
Cc: stable@vger.kernel.org # 5.9+
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 1dfc0686c29a9bbd3a446a29f9ccde3dec3bc75a upstream.
This patch adds the check for features which is incompatible for
current supported feature sets.Now if the bcache device created by bcache-tools has features that
current kernel doesn't support, read_super() will fail with error
messoage. E.g. if an unsupported incompatible feature detected,
bcache register will fail with dmesg "bcache: register_bcache() error :
Unsupported incompatible feature found".Fixes: d721a43ff69c ("bcache: increase super block version for cache device and backing device")
Fixes: ffa470327572 ("bcache: add bucket_size_hi into struct cache_sb_disk for large bucket")
Signed-off-by: Coly Li
Cc: stable@vger.kernel.org # 5.9+
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit f7b4943dea48a572ad751ce1f18a245d43debe7e upstream.
This patch fixes the following typos,
from BCH_FEATURE_COMPAT_SUUP to BCH_FEATURE_COMPAT_SUPP
from BCH_FEATURE_INCOMPAT_SUUP to BCH_FEATURE_INCOMPAT_SUPP
from BCH_FEATURE_INCOMPAT_SUUP to BCH_FEATURE_RO_COMPAT_SUPPFixes: d721a43ff69c ("bcache: increase super block version for cache device and backing device")
Fixes: ffa470327572 ("bcache: add bucket_size_hi into struct cache_sb_disk for large bucket")
Signed-off-by: Coly Li
Cc: stable@vger.kernel.org # 5.9+
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 641382e9b44fba81a0778e1914ee35b8471121f9 upstream.
The reloc batch is short lived but can exist in the user visible ppGTT,
and since it's backed by an internal object, which lacks page clearing,
we should take care to clear it upfront.Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
Link: https://patchwork.freedesktop.org/patch/msgid/20201224151358.401345-2-matthew.auld@intel.com
Cc: stable@vger.kernel.org
(cherry picked from commit 26ebc511e799f621357982ccc37a7987a56a00f4)
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 75353bcd2184010f08a3ed2f0da019bd9d604e1e upstream.
The shadow batch is an internal object, which doesn't have any page
clearing, and since the batch_len can be smaller than the object, we
should take care to clear it.Testcase: igt/gen9_exec_parse/shadow-peek
Fixes: 4f7af1948abc ("drm/i915: Support ro ppgtt mapped cmdparser shadow buffers")
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
Link: https://patchwork.freedesktop.org/patch/msgid/20201224151358.401345-1-matthew.auld@intel.com
Cc: stable@vger.kernel.org
(cherry picked from commit eeb52ee6c4a429ec301faf1dc48988744960786e)
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 05cd84691eafcd7959a1e120d5e72c0dd98c5d91 upstream.
It is observed 'use-after-free' on the dmabuf's file->f_inode with the
race between closing the dmabuf file and reading the dmabuf's debug
info.Consider the below scenario where P1 is closing the dma_buf file
and P2 is reading the dma_buf's debug info in the system:P1 P2
dma_buf_debug_show()
dma_buf_put()
__fput()
file->f_op->release()
dput()
....
dentry_unlink_inode()
iput(dentry->d_inode)
(where the inode is freed)
mutex_lock(&db_list.lock)
read 'dma_buf->file->f_inode'
(the same inode is freed by P1)
mutex_unlock(&db_list.lock)
dentry->d_op->d_release()-->
dma_buf_release()
.....
mutex_lock(&db_list.lock)
removes the dmabuf from the list
mutex_unlock(&db_list.lock)In the above scenario, when dma_buf_put() is called on a dma_buf, it
first frees the dma_buf's file->f_inode(=dentry->d_inode) and then
removes this dma_buf from the system db_list. In between P2 traversing
the db_list tries to access this dma_buf's file->f_inode that was freed
by P1 which is a use-after-free case.Since, __fput() calls f_op->release first and then later calls the
d_op->d_release, move the dma_buf's db_list removal from d_release() to
f_op->release(). This ensures that dma_buf's file->f_inode is not
accessed after it is released.Cc: # 5.4.x-
Fixes: 4ab59c3c638c ("dma-buf: Move dma_buf_release() from fops to dentry_ops")
Acked-by: Christian König
Signed-off-by: Charan Teja Reddy
Signed-off-by: Sumit Semwal
Signed-off-by: Thomas Zimmermann
Link: https://patchwork.freedesktop.org/patch/msgid/1609857399-31549-1-git-send-email-charante@codeaurora.org
Signed-off-by: Greg Kroah-Hartman -
commit 47f4469970d8861bc06d2d4d45ac8200ff07c693 upstream.
While commit d5dcce0c414f ("device property: Keep secondary firmware
node secondary by type") describes everything correct in its commit
message, the change it made does the opposite and original commit
c15e1bdda436 ("device property: Fix the secondary firmware node handling
in set_primary_fwnode()") was fully correct.Revert the former one here and improve documentation in the next patch.
Fixes: d5dcce0c414f ("device property: Keep secondary firmware node secondary by type")
Signed-off-by: Bard Liao
Reviewed-by: Andy Shevchenko
Reviewed-by: Heikki Krogerus
Cc: 5.10+ # 5.10+
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 9ad9f45b3b91162b33abfe175ae75ab65718dbf5 upstream.
'struct intel_svm' is shared by all devices bound to a give process,
but records only a single pointer to a 'struct intel_iommu'. Consequently,
cache invalidations may only be applied to a single DMAR unit, and are
erroneously skipped for the other devices.In preparation for fixing this, rework the structures so that the iommu
pointer resides in 'struct intel_svm_dev', allowing 'struct intel_svm'
to track them in its device list.Fixes: 1c4f88b7f1f9 ("iommu/vt-d: Shared virtual address in scalable mode")
Cc: Lu Baolu
Cc: Jacob Pan
Cc: Raj Ashok
Cc: David Woodhouse
Reported-by: Guo Kaijie
Reported-by: Xin Zeng
Signed-off-by: Guo Kaijie
Signed-off-by: Xin Zeng
Signed-off-by: Liu Yi L
Tested-by: Guo Kaijie
Cc: stable@vger.kernel.org # v5.0+
Acked-by: Lu Baolu
Link: https://lore.kernel.org/r/1609949037-25291-2-git-send-email-yi.l.liu@intel.com
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit 84e261553e6f919bf0b4d65244599ab2b41f1da5 upstream.
hwmon, specifically hwmon_num_channel_attrs, expects the config
array in the hwmon_channel_info structure to be terminated by
a zero entry. amd_energy does not honor this convention. As
result, a KASAN warning is possible. Fix this by adding an
additional entry and setting it to zero.Fixes: 8abee9566b7e ("hwmon: Add amd_energy driver to report energy counters")
Signed-off-by: David Arcari
Cc: Naveen Krishna Chatradhi
Cc: Jean Delvare
Cc: Guenter Roeck
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: David Arcari
Acked-by: Naveen Krishna Chatradhi
Link: https://lore.kernel.org/r/20210107144707.6927-1-darcari@redhat.com
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
Remove an unused variable which was mistakingly left by commit
37faf5061541 ("USB: serial: keyspan_pda: fix write-wakeup
use-after-free") and only removed by a later change.This is needed to suppress a W=1 warning about the unused variable in
the stable trees that the build bots triggers.Reported-by: kernel test robot
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit 64e6bbfff52db4bf6785fab9cffab850b2de6870 upstream.
There is a use-after-free issue, if access udc_name
in function gadget_dev_desc_UDC_store after another context
free udc_name in function unregister_gadget.Context 1:
gadget_dev_desc_UDC_store()->unregister_gadget()->
free udc_name->set udc_name to NULLContext 2:
gadget_dev_desc_UDC_show()-> access udc_nameCall trace:
dump_backtrace+0x0/0x340
show_stack+0x14/0x1c
dump_stack+0xe4/0x134
print_address_description+0x78/0x478
__kasan_report+0x270/0x2ec
kasan_report+0x10/0x18
__asan_report_load1_noabort+0x18/0x20
string+0xf4/0x138
vsnprintf+0x428/0x14d0
sprintf+0xe4/0x12c
gadget_dev_desc_UDC_show+0x54/0x64
configfs_read_file+0x210/0x3a0
__vfs_read+0xf0/0x49c
vfs_read+0x130/0x2b4
SyS_read+0x114/0x208
el0_svc_naked+0x34/0x38Add mutex_lock to protect this kind of scenario.
Signed-off-by: Eddie Hung
Signed-off-by: Macpaul Lin
Reviewed-by: Peter Chen
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1609239215-21819-1-git-send-email-macpaul.lin@mediatek.com
Signed-off-by: Greg Kroah-Hartman -
commit 6cd0fe91387917be48e91385a572a69dfac2f3f7 upstream.
When binding the ConfigFS gadget to a UDC, the functions in each
configuration are added in list order. However, if usb_add_function()
fails, the failed function is put back on its configuration's
func_list and purge_configs_funcs() is called to further clean up.purge_configs_funcs() iterates over the configurations and functions
in forward order, calling unbind() on each of the previously added
functions. But after doing so, each function gets moved to the
tail of the configuration's func_list. This results in reshuffling
the original order of the functions within a configuration such
that the failed function now appears first even though it may have
originally appeared in the middle or even end of the list. At this
point if the ConfigFS gadget is attempted to re-bind to the UDC,
the functions will be added in a different order than intended,
with the only recourse being to remove and relink the functions all
over again.An example of this as follows:
ln -s functions/mass_storage.0 configs/c.1
ln -s functions/ncm.0 configs/c.1
ln -s functions/ffs.adb configs/c.1 # oops, forgot to start adbd
echo "" > UDC # fails
start adbd
echo "" > UDC # now succeeds, but...
# bind order is
# "ADB", mass_storage, ncm[30133.118289] configfs-gadget gadget: adding 'Mass Storage Function'/ffffff810af87200 to config 'c'/ffffff817d6a2520
[30133.119875] configfs-gadget gadget: adding 'cdc_network'/ffffff80f48d1a00 to config 'c'/ffffff817d6a2520
[30133.119974] using random self ethernet address
[30133.120002] using random host ethernet address
[30133.139604] usb0: HOST MAC 3e:27:46:ba:3e:26
[30133.140015] usb0: MAC 6e:28:7e:42:66:6a
[30133.140062] configfs-gadget gadget: adding 'Function FS Gadget'/ffffff80f3868438 to config 'c'/ffffff817d6a2520
[30133.140081] configfs-gadget gadget: adding 'Function FS Gadget'/ffffff80f3868438 --> -19
[30133.140098] configfs-gadget gadget: unbind function 'Mass Storage Function'/ffffff810af87200
[30133.140119] configfs-gadget gadget: unbind function 'cdc_network'/ffffff80f48d1a00
[30133.173201] configfs-gadget a600000.dwc3: failed to start g1: -19
[30136.661933] init: starting service 'adbd'...
[30136.700126] read descriptors
[30136.700413] read strings
[30138.574484] configfs-gadget gadget: adding 'Function FS Gadget'/ffffff80f3868438 to config 'c'/ffffff817d6a2520
[30138.575497] configfs-gadget gadget: adding 'Mass Storage Function'/ffffff810af87200 to config 'c'/ffffff817d6a2520
[30138.575554] configfs-gadget gadget: adding 'cdc_network'/ffffff80f48d1a00 to config 'c'/ffffff817d6a2520
[30138.575631] using random self ethernet address
[30138.575660] using random host ethernet address
[30138.595338] usb0: HOST MAC 2e:cf:43:cd:ca:c8
[30138.597160] usb0: MAC 6a:f0:9f:ee:82:a0
[30138.791490] configfs-gadget gadget: super-speed config #1: cFix this by reversing the iteration order of the functions in
purge_config_funcs() when unbinding them, and adding them back to
the config's func_list at the head instead of the tail. This
ensures that we unbind and unwind back to the original list order.Fixes: 88af8bbe4ef7 ("usb: gadget: the start of the configfs interface")
Signed-off-by: Chandana Kishori Chiluveru
Signed-off-by: Jack Pham
Reviewed-by: Peter Chen
Link: https://lore.kernel.org/r/20201229224443.31623-1-jackp@codeaurora.org
Cc: stable
Signed-off-by: Greg Kroah-Hartman -
commit 5cc35c224a80aa5a5a539510ef049faf0d6ed181 upstream.
There is a spinlock lockup as part of composite_disconnect
when it tries to acquire cdev->lock as part of usb_gadget_deactivate.
This is because the usb_gadget_deactivate is called from
usb_function_deactivate with the same spinlock held.This would result in the below call stack and leads to stall.
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: 3-...0: (1 GPs behind) idle=162/1/0x4000000000000000
softirq=10819/10819 fqs=2356
(detected by 2, t=5252 jiffies, g=20129, q=3770)
Task dump for CPU 3:
task:uvc-gadget_wlhe state:R running task stack: 0 pid: 674 ppid:
636 flags:0x00000202
Call trace:
__switch_to+0xc0/0x170
_raw_spin_lock_irqsave+0x84/0xb0
composite_disconnect+0x28/0x78
configfs_composite_disconnect+0x68/0x70
usb_gadget_disconnect+0x10c/0x128
usb_gadget_deactivate+0xd4/0x108
usb_function_deactivate+0x6c/0x80
uvc_function_disconnect+0x20/0x58
uvc_v4l2_release+0x30/0x88
v4l2_release+0xbc/0xf0
__fput+0x7c/0x230
____fput+0x14/0x20
task_work_run+0x88/0x140
do_notify_resume+0x240/0x6f0
work_pending+0x8/0x200Fix this by doing an unlock on cdev->lock before the usb_gadget_deactivate
call from usb_function_deactivate.The same lockup can happen in the usb_gadget_activate path. Fix that path
as well.Reported-by: Peter Chen
Link: https://lore.kernel.org/linux-usb/20201102094936.GA29581@b29397-desktop/
Tested-by: Peter Chen
Signed-off-by: Sriharsha Allenki
Cc: stable
Link: https://lore.kernel.org/r/20201202130220.24926-1-sallenki@codeaurora.org
Signed-off-by: Greg Kroah-Hartman -
commit c91d3a6bcaa031f551ba29a496a8027b31289464 upstream.
If usb_otg_descriptor_alloc() failed, it need return ENOMEM.
Fixes: 578aa8a2b12c ("usb: gadget: acm_ms: allocate and init otg descriptor by otg capabilities")
Reported-by: Hulk Robot
Signed-off-by: Yang Yingliang
Cc: stable
Link: https://lore.kernel.org/r/20201117092955.4102785-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman -
commit 0a88fa221ce911c331bf700d2214c5b2f77414d3 upstream.
Fix the MTU size issue with RX packet size as the host sends the packet
with extra bytes containing ethernet header. This causes failure when
user sets the MTU size to the maximum i.e. 15412. In this case the
ethernet packet received will be of length 15412 plus the ethernet header
length. This patch fixes the issue where there is a check that RX packet
length must not be more than max packet length.Fixes: bba787a860fa ("usb: gadget: ether: Allow jumbo frames")
Signed-off-by: Manish Narani
Cc: stable
Link: https://lore.kernel.org/r/1605597215-122027-1-git-send-email-manish.narani@xilinx.com
Signed-off-by: Greg Kroah-Hartman -
commit 2cc332e4ee4febcbb685e2962ad323fe4b3b750a upstream.
When printer driver is loaded, the printer_func_bind function is called, in
this function, the interface descriptor be allocated memory, if after that,
the error occurred, the interface descriptor memory need to be free.Reviewed-by: Peter Chen
Cc:
Signed-off-by: Zqiang
Link: https://lore.kernel.org/r/20201210020148.6691-1-qiang.zhang@windriver.com
Signed-off-by: Greg Kroah-Hartman -
commit 9389044f27081d6ec77730c36d5bf9a1288bcda2 upstream.
With commit 913e4a90b6f9 ("usb: gadget: f_uac2: finalize wMaxPacketSize according to bandwidth")
wMaxPacketSize is computed dynamically but the value is never reset.Because of this, the actual maximum packet size can only decrease each time
the audio gadget is instantiated.Reset the endpoint maximum packet size and mark wMaxPacketSize as dynamic
to solve the problem.Fixes: 913e4a90b6f9 ("usb: gadget: f_uac2: finalize wMaxPacketSize according to bandwidth")
Signed-off-by: Jerome Brunet
Cc: stable
Link: https://lore.kernel.org/r/20201221173531.215169-2-jbrunet@baylibre.com
Signed-off-by: Greg Kroah-Hartman
