- 14 Jul, 2019 40 commits
-
-
Douglas Anderson authored
commit dbc3117d upstream. In reboot tests on several devices we were seeing a "use after free" when slub_debug or KASAN was enabled. The kernel complained about: Unable to handle kernel paging request at virtual address 6b6b6c2b ...which is a classic sign of use after free under slub_debug. The stack crawl in kgdb looked like: 0 test_bit (addr=<optimized out>, nr=<optimized out>) 1 bfq_bfqq_busy (bfqq=<optimized out>) 2 bfq_select_queue (bfqd=<optimized out>) 3 __bfq_dispatch_request (hctx=<optimized out>) 4 bfq_dispatch_request (hctx=<optimized out>) 5 0xc056ef00 in blk_mq_do_dispatch_sched (hctx=0xed249440) 6 0xc056f728 in blk_mq_sched_dispatch_requests (hctx=0xed249440) 7 0xc0568d24 in __blk_mq_run_hw_queue (hctx=0xed249440) 8 0xc0568d94 in blk_mq_run_work_fn (work=<optimized out>) 9 0xc024c5c4 in process_one_work (worker=0xec6d4640, work=0xed249480) 10 0xc024cff4 in worker_thread (__worker=0xec6d4640) Digging in kgdb, it could be found that, though bfqq looked fine, bfqq->bic had been freed. Through further digging, I postulated that perhaps it is illegal to access a "bic" (AKA an "icq") after bfq_exit_icq() had been called because the "bic" can be freed at some point in time after this call is made. I confirmed that there certainly were cases where the exact crashing code path would access the "bic" after bfq_exit_icq() had been called. Sspecifically I set the "bfqq->bic" to (void *)0x7 and saw that the bic was 0x7 at the time of the crash. To understand a bit more about why this crash was fairly uncommon (I saw it only once in a few hundred reboots), you can see that much of the time bfq_exit_icq_fbqq() fully frees the bfqq and thus it can't access the ->bic anymore. The only case it doesn't is if bfq_put_queue() sees a reference still held. However, even in the case when bfqq isn't freed, the crash is still rare. Why? I tracked what happened to the "bic" after the exit routine. It doesn't get freed right away. Rather, put_io_context_active() eventually called put_io_context() which queued up freeing on a workqueue. The freeing then actually happened later than that through call_rcu(). Despite all these delays, some extra debugging showed that all the hoops could be jumped through in time and the memory could be freed causing the original crash. Phew! To make a long story short, assuming it truly is illegal to access an icq after the "exit_icq" callback is finished, this patch is needed. Cc: stable@vger.kernel.org Reviewed-by:
Paolo Valente <paolo.valente@unimore.it> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vadim Sukhomlinov authored
commit db4d8cb9 upstream. TPM 2.0 Shutdown involve sending TPM2_Shutdown to TPM chip and disabling future TPM operations. TPM 1.2 behavior was different, future TPM operations weren't disabled, causing rare issues. This patch ensures that future TPM operations are disabled. Fixes: d1bd4a79 ("tpm: Issue a TPM2_Shutdown for TPM2 devices.") Cc: stable@vger.kernel.org Signed-off-by:
Vadim Sukhomlinov <sukhomlinov@google.com> [dianders: resolved merge conflicts with mainline] Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
-
Kees Cook authored
commit 782779b6 upstream. A "get random" may fail with a TPM error, but those codes were returned as-is to the caller, which assumed the result was the number of bytes that had been written to the target buffer, which could lead to a kernel heap memory exposure and over-read. This fixes tpm1_get_random() to mask positive TPM errors into -EIO, as before. [ 18.092103] tpm tpm0: A TPM error (379) occurred attempting get random [ 18.092106] usercopy: Kernel memory exposure attempt detected from SLUB object 'kmalloc-64' (offset 0, size 379)! Link: https://bugzilla.redhat.com/show_bug.cgi?id=1650989Reported-by:
Phil Baker <baker1tex@gmail.com> Reported-by:
Craig Robson <craig@zhatt.com> Fixes: 7aee9c52 ("tpm: tpm1: rewrite tpm1_get_random() using tpm_buf structure") Cc: Laura Abbott <labbott@redhat.com> Cc: Tomas Winkler <tomas.winkler@intel.com> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Tomas Winkler <tomas.winkler@intel.com> Tested-by:
Bartosz Szczepanek <bsz@semihalf.com> Reviewed-by:
-
Kailang Yang authored
commit d07a9a4f upstream. Dell headset mode platform with ALC236. It doesn't recording after system resume from S3. S3 mode was deep. s2idle was not has this issue. S3 deep will cut of codec power. So, the register will back to default after resume back. This patch will solve this issue. Signed-off-by:
Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit ca95c7bf upstream. Extension Unit (XU) is used to have a compatible layout with Processing Unit (PU) on UAC1, and the usb-audio driver code assumed it for parsing the descriptors. Meanwhile, on UAC2, XU became slightly incompatible with PU; namely, XU has a one-byte bmControls bitmap while PU has two bytes bmControls bitmap. This incompatibility results in the read of a wrong address for the last iExtension field, which ended up with an incorrect string for the mixer element name, as recently reported for Focusrite Scarlett 18i20 device. This patch corrects this misalignment by introducing a couple of new macros and calling them depending on the descriptor type. Fixes: 23caaf19 ("ALSA: usb-mixer: Add support for Audio Class v2.0") Reported-by:
Stefan Sauer <ensonic@hora-obscura.de> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit b09a2ab2 upstream. There was a typo at the lower frequency limit for a DVB-C card, causing the driver to fail while tuning channels at the VHF range. https://bugzilla.kernel.org/show_bug.cgi?id=202083 Fixes: f1b1eabf ("media: dvb: represent min/max/step/tolerance freqs in Hz") Reported-by:
Ari Kohtamäki <ari.kohtamaki@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Steven J. Magnani authored
commit fa33cdbf upstream. In some cases, using the 'truncate' command to extend a UDF file results in a mismatch between the length of the file's extents (specifically, due to incorrect length of the final NOT_ALLOCATED extent) and the information (file) length. The discrepancy can prevent other operating systems (i.e., Windows 10) from opening the file. Two particular errors have been observed when extending a file: 1. The final extent is larger than it should be, having been rounded up to a multiple of the block size. B. The final extent is not shorter than it should be, due to not having been updated when the file's information length was increased. [JK: simplified udf_do_extend_final_block(), fixed up some types] Fixes: 2c948b3f ("udf: Avoid IO in udf_clear_inode") CC: stable@vger.kernel.org Signed-off-by:
Steven J. Magnani <steve@digidescorp.com> Link: https://lore.kernel.org/r/1561948775-5878-1-git-send-email-steve@digidescorp.comSigned-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Hongjie Fang authored
commit 5858bdad upstream. The directory may have been removed when entering fscrypt_ioctl_set_policy(). If so, the empty_dir() check will return error for ext4 file system. ext4_rmdir() sets i_size = 0, then ext4_empty_dir() reports an error because 'inode->i_size < EXT4_DIR_REC_LEN(1) + EXT4_DIR_REC_LEN(2)'. If the fs is mounted with errors=panic, it will trigger a panic issue. Add the check IS_DEADDIR() to fix this problem. Fixes: 9bd8212f ("ext4 crypto: add encryption policy and password salt support") Cc: <stable@vger.kernel.org> # v4.1+ Signed-off-by:
Hongjie Fang <hongjiefang@asrmicro.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Benjamin Coddington authored
[ Upstream commit 90910519 ] We can end up in nfs4_opendata_alloc during task exit, in which case current->fs has already been cleaned up. This leads to a crash in current_umask(). Fix this by only setting creation opendata if we are actually doing an open with O_CREAT. We can drop the check for NULL nfs4_open_createattrs, since O_CREAT will never be set for the recovery path. Suggested-by:
Trond Myklebust <trondmy@hammerspace.com> Signed-off-by:
Benjamin Coddington <bcodding@redhat.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Andrew Jones authored
[ Upstream commit e4e5a865 ] The emulated ptimer needs to track the level changes, otherwise the the interrupt will never get deasserted, resulting in the guest getting stuck in an interrupt storm if it enables ptimer interrupts. This was found with kvm-unit-tests; the ptimer tests hung as soon as interrupts were enabled. Typical Linux guests don't have a problem as they prefer using the virtual timer. Fixes: bee038a6 ("KVM: arm/arm64: Rework the timer code to use a timer_map") Signed-off-by:
Andrew Jones <drjones@redhat.com> [Simplified the patch to res we only care about emulated timers here] Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Rasmus Villemoes authored
[ Upstream commit 48620e34 ] The comment is correct, but the code ends up moving the bits four places too far, into the VTUOp field. Fixes: 11ea809f (net: dsa: mv88e6xxx: support 256 databases) Signed-off-by:
Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
yangerkun authored
[ Upstream commit c6d9c35d ] Run below script as root, dquot_add_space will return -EDQUOT since __dquot_transfer call dquot_add_space with flags=0, and dquot_add_space think it's a preallocation. Fix it by set flags as DQUOT_SPACE_WARN. mkfs.ext4 -O quota,project /dev/vdb mount -o prjquota /dev/vdb /mnt setquota -P 23 1 1 0 0 /dev/vdb dd if=/dev/zero of=/mnt/test-file bs=4K count=1 chattr -p 23 test-file Fixes: 7b9ca4c6 ("quota: Reduce contention on dq_data_lock") Signed-off-by:
yangerkun <yangerkun@huawei.com> Signed-off-by:
-
Christoph Hellwig authored
[ Upstream commit 9739ab7e ] With the strict dma mask checking introduced with the switch to the generic DMA direct code common wifi chips on 32-bit powerbooks stopped working. Add a 30-bit ZONE_DMA to the 32-bit pmac builds to allow them to reliably allocate dma coherent memory. Fixes: 65a21b71 ("powerpc/dma: remove dma_nommu_dma_supported") Reported-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
Christoph Hellwig <hch@lst.de> Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Acked-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Nilesh Javali authored
[ Upstream commit 1ac3549e ] The kernel panic was observed during iSCSI discovery via offload with below call trace, [ 2115.646901] BUG: unable to handle kernel NULL pointer dereference at (null) [ 2115.646909] IP: [<ffffffffacf7f0cc>] strncmp+0xc/0x60 [ 2115.646927] PGD 0 [ 2115.646932] Oops: 0000 [#1] SMP [ 2115.647107] CPU: 24 PID: 264 Comm: kworker/24:1 Kdump: loaded Tainted: G OE ------------ 3.10.0-957.el7.x86_64 #1 [ 2115.647133] Workqueue: slowpath-13:00. qed_slowpath_task [qed] [ 2115.647135] task: ffff8d66af80b0c0 ti: ffff8d66afb80000 task.ti: ffff8d66afb80000 [ 2115.647136] RIP: 0010:[<ffffffffacf7f0cc>] [<ffffffffacf7f0cc>] strncmp+0xc/0x60 [ 2115.647141] RSP: 0018:ffff8d66afb83c68 EFLAGS: 00010206 [ 2115.647143] RAX: 0000000000000001 RBX: 0000000000000007 RCX: 000000000000000a [ 2115.647144] RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffff8d632b3ba040 [ 2115.647145] RBP: ffff8d66afb83c68 R08: 0000000000000000 R09: 000000000000ffff [ 2115.647147] R10: 0000000000000007 R11: 0000000000000800 R12: ffff8d66a30007a0 [ 2115.647148] R13: ffff8d66747a3c10 R14: ffff8d632b3ba000 R15: ffff8d66747a32f8 [ 2115.647149] FS: 0000000000000000(0000) GS:ffff8d66aff00000(0000) knlGS:0000000000000000 [ 2115.647151] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2115.647152] CR2: 0000000000000000 CR3: 0000000509610000 CR4: 00000000007607e0 [ 2115.647153] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2115.647154] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2115.647155] PKRU: 00000000 [ 2115.647157] Call Trace: [ 2115.647165] [<ffffffffc0634cc5>] qedi_get_protocol_tlv_data+0x2c5/0x510 [qedi] [ 2115.647184] [<ffffffffc05968f5>] ? qed_mfw_process_tlv_req+0x245/0xbe0 [qed] [ 2115.647195] [<ffffffffc05496cb>] qed_mfw_fill_tlv_data+0x4b/0xb0 [qed] [ 2115.647206] [<ffffffffc0596911>] qed_mfw_process_tlv_req+0x261/0xbe0 [qed] [ 2115.647215] [<ffffffffacce0e8e>] ? dequeue_task_fair+0x41e/0x660 [ 2115.647221] [<ffffffffacc2a59e>] ? __switch_to+0xce/0x580 [ 2115.647230] [<ffffffffc0546013>] qed_slowpath_task+0xa3/0x160 [qed] [ 2115.647278] RIP [<ffffffffacf7f0cc>] strncmp+0xc/0x60 Fix kernel panic by validating the session targetname before providing TLV data and confirming the presence of boot targets. Signed-off-by:
Nilesh Javali <njavali@marvell.com> Reviewed-by:
Lee Duncan <lduncan@suse.com> Reviewed-by:
Chris Leech <cleech@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 94762740 ] Left shifting the signed int value 1 by 31 bits has undefined behaviour and the shift amount oq_no can be as much as 63. Fix this by using BIT_ULL(oq_no) instead. Addresses-Coverity: ("Bad shift operation") Fixes: f21fb3ed ("Add support of Cavium Liquidio ethernet adapters") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Xin Long authored
[ Upstream commit 6f6a8622 ] A similar fix to Patch "ip_tunnel: allow not to count pkts on tstats by setting skb's dev to NULL" is also needed by ip6_tunnel. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 74b67efa ] The copy_from_user() function returns the number of bytes remaining to be copied but we want to return a negative error code. Otherwise the callers treat it as a successful copy. Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190618131843.GA29463@mwandaSigned-off-by:
-
Mauro S. M. Rodrigues authored
[ Upstream commit cf18cecc ] Some transceivers may comply with SFF-8472 even though they do not implement the Digital Diagnostic Monitoring (DDM) interface described in the spec. The existence of such area is specified by the 6th bit of byte 92, set to 1 if implemented. Currently, without checking this bit, bnx2x fails trying to read sfp module's EEPROM with the follow message: ethtool -m enP5p1s0f1 Cannot get Module EEPROM data: Input/output error Because it fails to read the additional 256 bytes in which it is assumed to exist the DDM data. This issue was noticed using a Mellanox Passive DAC PN 01FT738. The EEPROM data was confirmed by Mellanox as correct and similar to other Passive DACs from other manufacturers. Signed-off-by:
Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com> Acked-by:
Sudarsana Reddy Kalluru <skalluru@marvell.com> Signed-off-by:
-
Mariusz Tkaczyk authored
[ Upstream commit 9642fa73 ] Stopping external metadata arrays during resync/recovery causes retries, loop of interrupting and starting reconstruction, until it hit at good moment to stop completely. While these retries curr_mark_cnt can be small- especially on HDD drives, so subtraction result can be smaller than 0. However it is casted to uint without checking. As a result of it the status bar in /proc/mdstat while stopping is strange (it jumps between 0% and 99%). The real problem occurs here after commit 72deb455 ("block: remove CONFIG_LBDAF"). Sector_div() macro has been changed, now the divisor is casted to uint32. For db = -8 the divisior(db/32-1) becomes 0. Check if db value can be really counted and replace these macro by div64_u64() inline. Signed-off-by:
Mariusz Tkaczyk <mariusz.tkaczyk@intel.com> Signed-off-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
-
Mike Marciniszyn authored
[ Upstream commit 942a8993 ] The call to sc_buffer_alloc currently returns NULL (no buffer) or a buffer descriptor. There is a third case when the port is down. Currently that returns NULL and this prevents the caller from properly handling the sc_buffer_alloc() failure. A verbs code link test after the call is racy so the indication needs to come from the state check inside the allocation routine to be valid. Fix by encoding the ECOMM failure like SDMA. IS_ERR_OR_NULL() tests are added at all call sites. For verbs send, this needs to treat any error by returning a completion without any MMIO copy. Fixes: 77241056 ("IB/hfi1: add driver files") Reviewed-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Mike Marciniszyn authored
[ Upstream commit 099a884b ] Once a send context is taken down due to a link failure, any QPs waiting for pio credits will stay on the waitlist indefinitely. Fix by wakeing up all QPs linked to piowait list. Fixes: 77241056 ("IB/hfi1: add driver files") Reviewed-by:
-
Mike Marciniszyn authored
[ Upstream commit f972775b ] Once an SDMA engine is taken down due to a link failure, any waiting QPs that do not have outstanding descriptors in the ring will stay on the dmawait list as long as the port is down. Since there is no timer running, they will stay there for a long time. The fix is to wake up all iowaits linked to dmawait. The send engine will build and post packets that get flushed back. Fixes: 77241056 ("IB/hfi1: add driver files") Reviewed-by:
Kaike Wan <kaike.wan@intel.com> Signed-off-by:
-
Mike Marciniszyn authored
[ Upstream commit 4bb02e95 ] SDMA and pio flushes will cause a lot of packets to be transmitted after a link has gone down, using a lot of CPU to retransmit packets. Fix for RC QPs by recognizing the flush status and: - Forcing a timer start - Putting the QP into a "send one" mode Fixes: 77241056 ("IB/hfi1: add driver files") Reviewed-by:
-
Mike Marciniszyn authored
[ Upstream commit 9755f724 ] This paves the way for another patch that reacts to a flush sdma completion for RC. Fixes: 81cd3891 ("IB/hfi1: Add support for 16B Management Packets") Reviewed-by:
-
Wolfram Sang authored
[ Upstream commit b0e370b9 ] We don't have a reproducible error case, yet our BSP team suggested that the mmc_switch_status() command in mmc_select_hs400() should come after the callback into the driver completing HS400 setup. It makes sense to me because we want the status of a fully setup HS400, so it will increase the reliability of the mmc_switch_status() command. Reported-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Fixes: ba6c7ac3 ("mmc: core: more fine-grained hooks for HS400 tuning") Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Reinhard Speyerer authored
[ Upstream commit 36815b41 ] Permit mux_id values up to 254 to be used in qmimux_register_device() for compatibility with ip(8) and the rmnet driver. Fixes: c6adf779 ("net: usb: qmi_wwan: add qmap mux protocol support") Cc: Daniele Palmas <dnlplm@gmail.com> Signed-off-by:
Reinhard Speyerer <rspmn@arcor.de> Signed-off-by:
-
Reinhard Speyerer authored
[ Upstream commit a8fdde1c ] Switch qmimux_unregister_device() and qmi_wwan_disconnect() to use unregister_netdevice_queue() and unregister_netdevice_many() instead of unregister_netdevice(). This avoids RCU stalls which have been observed on device disconnect in certain setups otherwise. Fixes: c6adf779 ("net: usb: qmi_wwan: add qmap mux protocol support") Cc: Daniele Palmas <dnlplm@gmail.com> Signed-off-by:
-
Reinhard Speyerer authored
[ Upstream commit 61356088 ] The QMAP code in the qmi_wwan driver is based on the CodeAurora GobiNet driver which does not process QMAP padding in the RX path correctly. Add support for QMAP padding to qmimux_rx_fixup() according to the description of the rmnet driver. Fixes: c6adf779 ("net: usb: qmi_wwan: add qmap mux protocol support") Cc: Daniele Palmas <dnlplm@gmail.com> Signed-off-by:
-
Alexei Starovoitov authored
[ Upstream commit fe8d9571 ] Since commit 177366bf the %rbp stopped pointing to %rbp of the previous stack frame. That broke frame pointer based stack unwinding. This commit is a partial revert of it. Note that the location of tail_call_cnt is fixed, since the verifier enforces MAX_BPF_STACK stack size for programs with tail calls. Fixes: 177366bf ("bpf: change x86 JITed program stack layout") Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Toshiaki Makita authored
[ Upstream commit 86723c86 ] .ndo_xdp_xmit() assumes it is called under RCU. For example virtio_net uses RCU to detect it has setup the resources for tx. The assumption accidentally broke when introducing bulk queue in devmap. Fixes: 5d053f9d ("bpf: devmap prepare xdp frames for bulking") Reported-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
Toshiaki Makita <toshiaki.makita1@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Toshiaki Makita authored
[ Upstream commit edabf4d9 ] dev_map_free() forgot to free bulk queue when freeing its entries. Fixes: 5d053f9d ("bpf: devmap prepare xdp frames for bulking") Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
Toshiaki Makita authored
[ Upstream commit d4dd153d ] dev_map_free() waits for flush_needed bitmap to be empty in order to ensure all flush operations have completed before freeing its entries. However the corresponding clear_bit() was called before using the entries, so the entries could be used after free. All access to the entries needs to be done before clearing the bit. It seems commit a5e2da6e ("bpf: netdev is never null in __dev_map_flush") accidentally changed the clear_bit() and memory access order. Note that the problem happens only in __dev_map_flush(), not in dev_map_flush_old(). dev_map_flush_old() is called only after nulling out the corresponding netdev_map entry, so dev_map_free() never frees the entry thus no such race happens there. Fixes: a5e2da6e ("bpf: netdev is never null in __dev_map_flush") Signed-off-by:
-
Avraham Stern authored
[ Upstream commit b6584202 ] Instead of reporting the AP's TSF, host time was reported. Fix it. Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Mordechay Goodstein authored
[ Upstream commit 1a473d60 ] The bits of Rx MCS Map in VHT capability were enumerated with index transform - index i -> (i + 1) bit => nss i. BUG! while it should be - index i -> (i + 1) bit => (i + 1) nss. The bug was exposed in commit a53b2a0b ("iwlwifi: mvm: implement VHT extended NSS support in rs.c"), where iwlwifi started using the function. Signed-off-by:
Mordechay Goodstein <mordechay.goodstein@intel.com> Fixes: b0aa75f0 ("ieee80211: add new VHT capability fields/parsing") Signed-off-by:
-
Naftali Goldstein authored
[ Upstream commit f8891461 ] It is not a good idea to try to perform any work (e.g. send an auth frame) during reconfigure flow. Prevent this from happening, and at the end of the reconfigure flow requeue all the works. Signed-off-by:
Naftali Goldstein <naftali.goldstein@intel.com> Signed-off-by:
-
Yibo Zhao authored
[ Upstream commit 56357234 ] In multiple SSID cases, it takes time to prepare every AP interface to be ready in initializing phase. If a sta already knows everything it needs to join one of the APs and sends authentication to the AP which is not fully prepared at this point of time, AP's channel context could be NULL. As a result, warning message occurs. Even worse, if the AP is under attack via tools such as MDK3 and massive authentication requests are received in a very short time, console will be hung due to kernel warning messages. WARN_ON_ONCE() could be a better way for indicating warning messages without duplicate messages to flood the console. Johannes: We still need to address the underlying problem, but we don't really have a good handle on it yet. Suppress the worst side-effects for now. Signed-off-by:
Zhi Chen <zhichen@codeaurora.org> Signed-off-by:
Yibo Zhao <yiboz@codeaurora.org> [johannes: add note, change subject] Signed-off-by:
-
Steve Longerbeam authored
[ Upstream commit 912bbf7e ] The output of the IC downsizer unit in both dimensions must be <= 1024 before being passed to the IC resizer unit. This was causing corrupted images when: input_dim > 1024, and input_dim / 2 < output_dim < input_dim Some broken examples were 1920x1080 -> 1024x768 and 1920x1080 -> 1280x1080. Fixes: 70b9b6b3 ("gpu: ipu-v3: image-convert: calculate per-tile resize coefficients") Signed-off-by:
Steve Longerbeam <slongerbeam@gmail.com> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Steve Longerbeam authored
[ Upstream commit bca4d70c ] The input bytesperline calculation for packed pixel formats was incorrect. The min/max clamping values must be multiplied by the packed bits-per-pixel. This was causing corrupted converted images when the input format was RGB4 (probably also other input packed formats). Fixes: d966e23d ("gpu: ipu-v3: image-convert: fix bytesperline adjustment") Reported-by:
Harsha Manjula Mallikarjun <Harsha.ManjulaMallikarjun@in.bosch.com> Suggested-by:
-
Steve Longerbeam authored
[ Upstream commit ff391ecd ] The output width and height alignment values were being used in the input bytesperline calculation. Fix by separating local vars w_align and h_align into w_align_in, h_align_in, w_align_out, and h_align_out. Fixes: d966e23d ("gpu: ipu-v3: image-convert: fix bytesperline adjustment") Signed-off-by:
-
Bartosz Golaszewski authored
[ Upstream commit 68f2515b ] The lcdc device is missing the dma_coherent_mask definition causing the following warning on da850-evm: da8xx_lcdc da8xx_lcdc.0: found Sharp_LK043T1DG01 panel ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at kernel/dma/mapping.c:247 dma_alloc_attrs+0xc8/0x110 Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.2.0-rc3-00077-g16d72dd4 #18 Hardware name: DaVinci DA850/OMAP-L138/AM18x EVM [<c000fce8>] (unwind_backtrace) from [<c000d900>] (show_stack+0x10/0x14) [<c000d900>] (show_stack) from [<c001a4f8>] (__warn+0xec/0x114) [<c001a4f8>] (__warn) from [<c001a634>] (warn_slowpath_null+0x3c/0x48) [<c001a634>] (warn_slowpath_null) from [<c0065860>] (dma_alloc_attrs+0xc8/0x110) [<c0065860>] (dma_alloc_attrs) from [<c02820f8>] (fb_probe+0x228/0x5a8) [<c02820f8>] (fb_probe) from [<c02d3e9c>] (platform_drv_probe+0x48/0x9c) [<c02d3e9c>] (platform_drv_probe) from [<c02d221c>] (really_probe+0x1d8/0x2d4) [<c02d221c>] (really_probe) from [<c02d2474>] (driver_probe_device+0x5c/0x168) [<c02d2474>] (driver_probe_device) from [<c02d2728>] (device_driver_attach+0x58/0x60) [<c02d2728>] (device_driver_attach) from [<c02d27b0>] (__driver_attach+0x80/0xbc) [<c02d27b0>] (__driver_attach) from [<c02d047c>] (bus_for_each_dev+0x64/0xb4) [<c02d047c>] (bus_for_each_dev) from [<c02d1590>] (bus_add_driver+0xe4/0x1d8) [<c02d1590>] (bus_add_driver) from [<c02d301c>] (driver_register+0x78/0x10c) [<c02d301c>] (driver_register) from [<c000a5c0>] (do_one_initcall+0x48/0x1bc) [<c000a5c0>] (do_one_initcall) from [<c05cae6c>] (kernel_init_freeable+0x10c/0x1d8) [<c05cae6c>] (kernel_init_freeable) from [<c048a000>] (kernel_init+0x8/0xf4) [<c048a000>] (kernel_init) from [<c00090e0>] (ret_from_fork+0x14/0x34) Exception stack(0xc6837fb0 to 0xc6837ff8) 7fa0: 00000000 00000000 00000000 00000000 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ---[ end trace 8a8073511be81dd2 ]--- Add a 32-bit mask to the platform device's definition. Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
