aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-11-12s390/cpum_sf.c: fix file permission for cpum_sfb_sizeThomas Richter1-1/+1
This file is installed by the s390 CPU Measurement sampling facility device driver to export supported minimum and maximum sample buffer sizes. This file is read by lscpumf tool to display the details of the device driver capabilities. The lscpumf tool might be invoked by a non-root user. In this case it does not print anything because the file contents can not be read. Fix this by allowing read access for all users. Reading the file contents is ok, changing the file contents is left to the root user only. For further reference and details see: [1] https://github.com/ibm-s390-tools/s390-tools/issues/97 Fixes: 69f239ed335a ("s390/cpum_sf: Dynamically extend the sampling buffer if overflows occur") Cc: <[email protected]> # 3.14 Signed-off-by: Thomas Richter <[email protected]> Acked-by: Sumanth Korikkar <[email protected]> Signed-off-by: Heiko Carstens <[email protected]>
2020-11-12s390: update defconfigsHeiko Carstens1-0/+1
Signed-off-by: Heiko Carstens <[email protected]>
2020-11-12mac80211: minstrel: fix tx status processing corner caseFelix Fietkau1-1/+1
Some drivers fill the status rate list without setting the rate index after the final rate to -1. minstrel_ht already deals with this, but minstrel doesn't, which causes it to get stuck at the lowest rate on these drivers. Fix this by checking the count as well. Cc: [email protected] Fixes: cccf129f820e ("mac80211: add the 'minstrel' rate control algorithm") Signed-off-by: Felix Fietkau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2020-11-12mac80211: minstrel: remove deferred sampling codeFelix Fietkau2-22/+4
Deferring sampling attempts to the second stage has some bad interactions with drivers that process the rate table in hardware and use the probe flag to indicate probing packets (e.g. most mt76 drivers). On affected drivers it can lead to probing not working at all. If the link conditions turn worse, it might not be such a good idea to do a lot of sampling for lower rates in this case. Fix this by simply skipping the sample attempt instead of deferring it, but keep the checks that would allow it to be sampled if it was skipped too often, but only if it has less than 95% success probability. Also ensure that IEEE80211_TX_CTL_RATE_CTRL_PROBE is set for all probing packets. Cc: [email protected] Fixes: cccf129f820e ("mac80211: add the 'minstrel' rate control algorithm") Signed-off-by: Felix Fietkau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2020-11-12mac80211: fix memory leak on filtered powersave framesFelix Fietkau1-10/+8
After the status rework, ieee80211_tx_status_ext is leaking un-acknowledged packets for stations in powersave mode. To fix this, move the code handling those packets from __ieee80211_tx_status into ieee80211_tx_status_ext Reported-by: Tobias Waldvogel <[email protected]> Fixes: 3318111cf63d ("mac80211: reduce duplication in tx status functions") Signed-off-by: Felix Fietkau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2020-11-12serial: ar933x_uart: disable clk on error handling path in probeZheng Zengkai1-2/+4
ar933x_uart_probe() does not invoke clk_disable_unprepare() on one error handling path. This patch fixes that. Fixes: 9be1064fe524 ("serial: ar933x_uart: add RS485 support") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zheng Zengkai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-11-12tty: serial: imx: keep console clocks always onFugang Duan1-17/+3
For below code, there has chance to cause deadlock in SMP system: Thread 1: clk_enable_lock(); pr_info("debug message"); clk_enable_unlock(); Thread 2: imx_uart_console_write() clk_enable() clk_enable_lock(); Thread 1: Acuired clk enable_lock -> printk -> console_trylock_spinning Thread 2: console_unlock() -> imx_uart_console_write -> clk_disable -> Acquite clk enable_lock So the patch is to keep console port clocks always on like other console drivers. Fixes: 1cf93e0d5488 ("serial: imx: remove the uart_console() check") Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Fugang Duan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: stable <[email protected]> [fix up build warning - gregkh] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-11-12speakup: Do not let the line discipline be used several timesSamuel Thibault1-1/+11
Speakup has only one speakup_tty variable to store the tty it is managing. This makes sense since its codebase currently assumes that there is only one user who controls the screen reading. That however means that we have to forbid using the line discipline several times, otherwise the second closure would try to free a NULL ldisc_data, leading to general protection fault: 0000 [#1] SMP KASAN PTI RIP: 0010:spk_ttyio_ldisc_close+0x2c/0x60 Call Trace: tty_ldisc_release+0xa2/0x340 tty_release_struct+0x17/0xd0 tty_release+0x9d9/0xcc0 __fput+0x231/0x740 task_work_run+0x12c/0x1a0 do_exit+0x9b5/0x2230 ? release_task+0x1240/0x1240 ? __do_page_fault+0x562/0xa30 do_group_exit+0xd5/0x2a0 __x64_sys_exit_group+0x35/0x40 do_syscall_64+0x89/0x2b0 ? page_fault+0x8/0x30 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Cc: [email protected] Reported-by: 秦世松 <[email protected]> Signed-off-by: Samuel Thibault <[email protected]> Tested-by: Shisong Qin <[email protected]> Link: https://lore.kernel.org/r/20201110183541.fzgnlwhjpgqzjeth@function Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-11-12tty: serial: imx: fix potential deadlockSam Nobs1-2/+8
Enabling the lock dependency validator has revealed that the way spinlocks are used in the IMX serial port could result in a deadlock. Specifically, imx_uart_int() acquires a spinlock without disabling the interrupts, meaning that another interrupt could come along and try to acquire the same spinlock, potentially causing the two to wait for each other indefinitely. Use spin_lock_irqsave() instead to disable interrupts upon acquisition of the spinlock. Fixes: c974991d2620 ("tty:serial:imx: use spin_lock instead of spin_lock_irqsave in isr") Reviewed-by: Uwe Kleine-König <[email protected]> Signed-off-by: Sam Nobs <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-11-12rfkill: Fix use-after-free in rfkill_resume()Claire Chang1-0/+3
If a device is getting removed or reprobed during resume, use-after-free might happen. For example, h5_btrtl_resume() schedules a work queue for device reprobing, which of course requires removal first. If the removal happens in parallel with the device_resume() and wins the race to acquire device_lock(), removal may remove the device from the PM lists and all, but device_resume() is already running and will continue when the lock can be acquired, thus calling rfkill_resume(). During this, if rfkill_set_block() is then called after the corresponding *_unregister() and kfree() are called, there will be an use-after-free in hci_rfkill_set_block(): BUG: KASAN: use-after-free in hci_rfkill_set_block+0x58/0xc0 [bluetooth] ... Call trace: dump_backtrace+0x0/0x154 show_stack+0x20/0x2c dump_stack+0xbc/0x12c print_address_description+0x88/0x4b0 __kasan_report+0x144/0x168 kasan_report+0x10/0x18 check_memory_region+0x19c/0x1ac __kasan_check_write+0x18/0x24 hci_rfkill_set_block+0x58/0xc0 [bluetooth] rfkill_set_block+0x9c/0x120 rfkill_resume+0x34/0x70 dpm_run_callback+0xf0/0x1f4 device_resume+0x210/0x22c Fix this by checking rfkill->registered in rfkill_resume(). device_del() in rfkill_unregister() requires device_lock() and the whole rfkill_resume() is also protected by the same lock via device_resume(), we can make sure either the rfkill->registered is false before rfkill_resume() starts or the rfkill device won't be unregistered before rfkill_resume() returns. As async_resume() holds a reference to the device, at this level there can be no use-after-free; only in the user that doesn't expect this scenario. Fixes: 8589086f4efd ("Bluetooth: hci_h5: Turn off RTL8723BS on suspend, reprobe on resume") Signed-off-by: Claire Chang <[email protected]> Link: https://lore.kernel.org/r/[email protected] [edit commit message for clarity and add more info provided later] Signed-off-by: Johannes Berg <[email protected]>
2020-11-12drm/i915/gvt: Set ENHANCED_FRAME_CAP bitTina Zhang1-1/+1
Specification says the bit7 of the DPCD MAX_LANE_COUNT (offset 0x02) must be set to 1 when comes to the displayport version 1.2. This patch respects the definition. W/o this patch, guest i915 driver can only set the resolution to 1024*768, and complains about the unsuccessful link training: [ 5.692193] i915 0000:00:02.0: [drm] *ERROR* index 0, lane_count 1 Link Training Unsuccessful Fixes: e2e02cbb5beb ("drm/i915/gvt: make dpcd_fix_data supports DP1.2") Reviewed-by: Zhenyu Wang <[email protected]> Signed-off-by: Tina Zhang <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-11fscrypt: fix inline encryption not used on new filesEric Biggers1-1/+1
The new helper function fscrypt_prepare_new_inode() runs before S_ENCRYPTED has been set on the new inode. This accidentally made fscrypt_select_encryption_impl() never enable inline encryption on newly created files, due to its use of fscrypt_needs_contents_encryption() which only returns true when S_ENCRYPTED is set. Fix this by using S_ISREG() directly instead of fscrypt_needs_contents_encryption(), analogous to what select_encryption_mode() does. I didn't notice this earlier because by design, the user-visible behavior is the same (other than performance, potentially) regardless of whether inline encryption is used or not. Fixes: a992b20cd4ee ("fscrypt: add fscrypt_prepare_new_inode() and fscrypt_set_context()") Reviewed-by: Satya Tangirala <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]>
2020-11-11Input: elan_i2c - fix firmware update on newer ICsjingle.wu4-8/+9
The argument to iap page type command depends on the firmware page size. Fixes: bfd9b92bc8f9 ("Input: elan_i2c - handle firmware updated on newer ICs") Signed-off-by: Jingle Wu <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2020-11-11cosa: Add missing kfree in error path of cosa_writeWang Hai1-0/+1
If memory allocation for 'kbuf' succeed, cosa_write() doesn't have a corresponding kfree() in exception handling. Thus add kfree() for this function implementation. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Wang Hai <[email protected]> Acked-by: Jan "Yenya" Kasprzak <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11Input: resistive-adc-touch - fix kconfig dependency on IIO_BUFFERNecip Fazil Yildiran1-0/+1
When TOUCHSCREEN_ADC is enabled and IIO_BUFFER is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for IIO_BUFFER_CB Depends on [n]: IIO [=y] && IIO_BUFFER [=n] Selected by [y]: - TOUCHSCREEN_ADC [=y] && !UML && INPUT [=y] && INPUT_TOUCHSCREEN [=y] && IIO [=y] The reason is that TOUCHSCREEN_ADC selects IIO_BUFFER_CB without depending on or selecting IIO_BUFFER while IIO_BUFFER_CB depends on IIO_BUFFER. This can also fail building the kernel. Honor the kconfig dependency to remove unmet direct dependency warnings and avoid any potential build failures. Fixes: aa132ffb6b0a ("input: touchscreen: resistive-adc-touch: add generic resistive ADC touchscreen") Signed-off-by: Necip Fazil Yildiran <[email protected]> Acked-by: Jonathan Cameron <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]>
2020-11-11net: switch to the kernel.org patchwork instanceJakub Kicinski4-14/+14
Move to the kernel.org patchwork instance, it has significantly lower latency for accessing from Europe and the US. Other quirks include the reply bot. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11Merge branch 'cxgb4-ch_ktls-fixes-in-nic-tls-code'Jakub Kicinski7-228/+478
Rohit Maheshwari says: ==================== cxgb4/ch_ktls: Fixes in nic tls code This series helps in fixing multiple nic ktls issues. Series is broken into 12 patches. Patch 1 avoids deciding tls packet based on decrypted bit. If its a retransmit packet which has tls handshake and finish (for encryption), decrypted bit won't be set there, and so we can't rely on decrypted bit. Patch 2 helps supporting linear skb. SKBs were assumed non-linear. Corrected the length extraction. Patch 3 fixes the checksum offload update in WR. Patch 4 fixes kernel panic happening due to creating new skb for each record. As part of fix driver will use same skb to send out one tls record (partial data) of the same SKB. Patch 5 fixes the problem of skb data length smaller than remaining data of the record. Patch 6 fixes the handling of SKBs which has tls header alone pkt, but not starting from beginning. Patch 7 avoids sending extra data which is used to make a record 16 byte aligned. We don't need to retransmit those extra few bytes. Patch 8 handles the cases where retransmit packet has tls starting exchanges which are prior to tls start marker. Patch 9 fixes the problem os skb free before HW knows about tcp FIN. Patch 10 handles the small packet case which has partial TAG bytes only. HW can't handle those, hence using sw crypto for such pkts. Patch 11 corrects the potential tcb update problem. Patch 12 stops the queue if queue reaches threshold value. v1->v2: - Corrected fixes tag issue. - Marked chcr_ktls_sw_fallback() static. v2->v3: - Replaced GFP_KERNEL with GFP_ATOMIC. - Removed mixed fixes. v3->v4: - Corrected fixes tag issue. v4->v5: - Separated mixed fixes from patch 4. v5-v6: - Fixes tag should be at the end. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: stop the txq if reaches thresholdRohit Maheshwari1-3/+15
Stop the queue and ask for the credits if queue reaches to threashold. Fixes: 5a4b9fe7fece ("cxgb4/chcr: complete record tx handling") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: tcb update fails sometimesRohit Maheshwari1-4/+8
context id and port id should be filled while sending tcb update. Fixes: 5a4b9fe7fece ("cxgb4/chcr: complete record tx handling") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls/cxgb4: handle partial tag alone SKBsRohit Maheshwari4-1/+119
If TCP congestion caused a very small packets which only has some part fo the TAG, and that too is not till the end. HW can't handle such case, so falling back to sw crypto in such cases. v1->v2: - Marked chcr_ktls_sw_fallback() static. Fixes: dc05f3df8fac ("chcr: Handle first or middle part of record") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: don't free skb before sending FINRohit Maheshwari1-2/+10
If its a last packet and fin is set. Make sure FIN is informed to HW before skb gets freed. Fixes: 429765a149f1 ("chcr: handle partial end part of a record") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: packet handling prior to start markerRohit Maheshwari1-5/+33
There could be a case where ACK for tls exchanges prior to start marker is missed out, and by the time tls is offloaded. This pkt should not be discarded and handled carefully. It could be plaintext alone or plaintext + finish as well. Fixes: 5a4b9fe7fece ("cxgb4/chcr: complete record tx handling") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: Correction in middle record handlingRohit Maheshwari1-19/+31
If a record starts in middle, reset TCB UNA so that we could avoid sending out extra packet which is needed to make it 16 byte aligned to start AES CTR. Check also considers prev_seq, which should be what is actually sent, not the skb data length. Avoid updating partial TAG to HW at any point of time, that's why we need to check if remaining part is smaller than TAG size, then reset TX_MAX to be TAG starting sequence number. Fixes: 5a4b9fe7fece ("cxgb4/chcr: complete record tx handling") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: missing handling of header aloneRohit Maheshwari1-14/+11
If an skb has only header part which doesn't start from beginning, is not being handled properly. Fixes: dc05f3df8fac ("chcr: Handle first or middle part of record") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: Correction in trimmed_len calculationRohit Maheshwari1-4/+7
trimmed length calculation goes wrong if skb has only tag part to send. It should be zero if there is no data bytes apart from TAG. Fixes: dc05f3df8fac ("chcr: Handle first or middle part of record") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11cxgb4/ch_ktls: creating skbs causes panicRohit Maheshwari3-169/+226
Creating SKB per tls record and freeing the original one causes panic. There will be race if connection reset is requested. By freeing original skb, refcnt will be decremented and that means, there is no pending record to send, and so tls_dev_del will be requested in control path while SKB of related connection is in queue. Better approach is to use same SKB to send one record (partial data) at a time. We still have to create a new SKB when partial last part of a record is requested. This fix introduces new API cxgb4_write_partial_sgl() to send partial part of skb. Present cxgb4_write_sgl can only provide feasibility to start from an offset which limits to header only and it can write sgls for the whole skb len. But this new API will help in both. It can start from any offset and can end writing in middle of the skb. v4->v5: - Removed extra changes. Fixes: 429765a149f1 ("chcr: handle partial end part of a record") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: Update cheksum informationRohit Maheshwari1-4/+11
Checksum update was missing in the WR. Fixes: 429765a149f1 ("chcr: handle partial end part of a record") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: Correction in finding correct lengthRohit Maheshwari1-7/+8
There is a possibility of linear skbs coming in. Correcting the length extraction logic. v2->v3: - Separated un-related changes from this patch. Fixes: 5a4b9fe7fece ("cxgb4/chcr: complete record tx handling") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11cxgb4/ch_ktls: decrypted bit is not enoughRohit Maheshwari4-5/+8
If skb has retransmit data starting before start marker, e.g. ccs, decrypted bit won't be set for that, and if it has some data to encrypt, then it must be given to crypto ULD. So in place of decrypted, check if socket is tls offloaded. Also, unless skb has some data to encrypt, no need to give it for tls offload handling. v2->v3: - Removed ifdef. Fixes: 5a4b9fe7fece ("cxgb4/chcr: complete record tx handling") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11dt-bindings: can: fsl,flexcan.yaml: fix fsl,stop-modeMarc Kleine-Budde1-5/+6
The fsl,stop-mode property is a phandle-array and should consist of one phandle and two 32 bit integers, e.g.: fsl,stop-mode = <&gpr 0x34 28>; This patch fixes the following errors, which shows up during a dtbs_check: arch/arm/boot/dts/imx6dl-apf6dev.dt.yaml: can@2090000: fsl,stop-mode: [[1, 52, 28]] is too short From schema: Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml Fixes: e5ab9aa7e49b ("dt-bindings: can: flexcan: convert fsl,*flexcan bindings to yaml") Reported-by: Rob Herring <[email protected]> Cc: Oleksij Rempel <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]>
2020-11-11of/address: Fix of_node memory leak in of_dma_is_coherentEvan Nimmo1-1/+3
Commit dabf6b36b83a ("of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc") added a check to of_dma_is_coherent which returns early if OF_DMA_DEFAULT_COHERENT is enabled. This results in the of_node_put() being skipped causing a memory leak. Moved the of_node_get() below this check so we now we only get the node if OF_DMA_DEFAULT_COHERENT is not enabled. Fixes: dabf6b36b83a ("of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc") Signed-off-by: Evan Nimmo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]>
2020-11-11net/x25: Fix null-ptr-deref in x25_connectMartin Schiller1-1/+1
This fixes a regression for blocking connects introduced by commit 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect"). The x25->neighbour is already set to "NULL" by x25_disconnect() now, while a blocking connect is waiting in x25_wait_for_connection_establishment(). Therefore x25->neighbour must not be accessed here again and x25->state is also already set to X25_STATE_0 by x25_disconnect(). Fixes: 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect") Signed-off-by: Martin Schiller <[email protected]> Reviewed-by: Xie He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11arm64: dts: fsl-ls1028a-kontron-sl28: specify in-band mode for ENETCMichael Walle1-0/+1
Since commit 71b77a7a27a3 ("enetc: Migrate to PHYLINK and PCS_LYNX") the network port of the Kontron sl28 board is broken. After the migration to phylink the device tree has to specify the in-band-mode property. Add it. Fixes: 71b77a7a27a3 ("enetc: Migrate to PHYLINK and PCS_LYNX") Suggested-by: Vladimir Oltean <[email protected]> Signed-off-by: Michael Walle <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11tipc: fix memory leak in tipc_topsrv_start()Wang Hai1-2/+8
kmemleak report a memory leak as follows: unreferenced object 0xffff88810a596800 (size 512): comm "ip", pid 21558, jiffies 4297568990 (age 112.120s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 83 60 b0 ff ff ff ff ..........`..... backtrace: [<0000000022bbe21f>] tipc_topsrv_init_net+0x1f3/0xa70 [<00000000fe15ddf7>] ops_init+0xa8/0x3c0 [<00000000138af6f2>] setup_net+0x2de/0x7e0 [<000000008c6807a3>] copy_net_ns+0x27d/0x530 [<000000006b21adbd>] create_new_namespaces+0x382/0xa30 [<00000000bb169746>] unshare_nsproxy_namespaces+0xa1/0x1d0 [<00000000fe2e42bc>] ksys_unshare+0x39c/0x780 [<0000000009ba3b19>] __x64_sys_unshare+0x2d/0x40 [<00000000614ad866>] do_syscall_64+0x56/0xa0 [<00000000a1b5ca3c>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 'srv' is malloced in tipc_topsrv_start() but not free before leaving from the error handling cases. We need to free it. Fixes: 5c45ab24ac77 ("tipc: make struct tipc_server private for server.c") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Wang Hai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11Merge branch 'stable/for-linus-5.10-rc2' of ↵Linus Torvalds4-23/+17
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb Pull swiotlb fixes from Konrad Rzeszutek Wilk: "Two tiny fixes for issues that make drivers under Xen unhappy under certain conditions" * 'stable/for-linus-5.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb: swiotlb: remove the tbl_dma_addr argument to swiotlb_tbl_map_single swiotlb: fix "x86: Don't panic if can not alloc buffer for swiotlb"
2020-11-11Revert "ext4: fix superblock checksum calculation race"Theodore Ts'o1-11/+0
This reverts commit acaa532687cdc3a03757defafece9c27aa667546 which can result in a ext4_superblock_csum_set() trying to sleep while a spinlock is being held. For more discussion of this issue, please see: https://lore.kernel.org/r/[email protected] Reported-by: [email protected] Signed-off-by: Theodore Ts'o <[email protected]>
2020-11-11ext4: handle dax mount option collisionHarshad Shirwadkar1-3/+3
Mount options dax=inode and dax=never collided with fast_commit and journal checksum. Redefine the mount flags to remove the collision. Reported-by: Murphy Zhou <[email protected]> Fixes: 9cb20f94afcd2 ("fs/ext4: Make DAX mount option a tri-state") Signed-off-by: Harshad Shirwadkar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]>
2020-11-11io_uring: round-up cq size before comparing with rounded sq sizeJens Axboe1-1/+1
If an application specifies IORING_SETUP_CQSIZE to set the CQ ring size to a specific size, we ensure that the CQ size is at least that of the SQ ring size. But in doing so, we compare the already rounded up to power of two SQ size to the as-of yet unrounded CQ size. This means that if an application passes in non power of two sizes, we can return -EINVAL when the final value would've been fine. As an example, an application passing in 100/100 for sq/cq size should end up with 128 for both. But since we round the SQ size first, we compare the CQ size of 100 to 128, and return -EINVAL as that is too small. Cc: [email protected] Fixes: 33a107f0a1b8 ("io_uring: allow application controlled CQ ring size") Reported-by: Dan Melnic <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-11-11xfs: fix a missing unlock on error in xfs_fs_map_blocksChristoph Hellwig1-1/+1
We also need to drop the iolock when invalidate_inode_pages2 fails, not only on all other error or successful cases. Fixes: 527851124d10 ("xfs: implement pNFS export operations") Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2020-11-11spi: fsi: Fix transfer returning without finalizing messageEddie James1-1/+1
In the case that the SPI mux isn't set, the transfer_one_message function returns without finalizing the message. This means that the transfer never completes, resulting in hung tasks and an eventual kernel panic. Fix it by finalizing the transfer in this case. Fixes: 9211a441e606 ("spi: fsi: Check mux status before transfers") Signed-off-by: Eddie James <[email protected]> Reviewed-by: Joel Stanley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-11-11spi: fix client driver breakages when using GPIO descriptorsSven Van Asbroeck1-17/+6
Commit f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") introduced the optional use of GPIO descriptors for chip selects. A side-effect of this change: when a SPI bus uses GPIO descriptors, all its client devices have SPI_CS_HIGH set in spi->mode. This flag is required for the SPI bus to operate correctly. This unfortunately breaks many client drivers, which use the following pattern to configure their underlying SPI bus: static int client_device_probe(struct spi_device *spi) { ... spi->mode = SPI_MODE_0; spi->bits_per_word = 8; err = spi_setup(spi); .. } In short, many client drivers overwrite the SPI_CS_HIGH bit in spi->mode, and break the underlying SPI bus driver. This is especially true for Freescale/NXP imx ecspi, where large numbers of spi client drivers now no longer work. Proposed fix: ------------- When using gpio descriptors, depend on gpiolib to handle CS polarity. Existing quirks in gpiolib ensure that this is handled correctly. Existing gpiolib behaviour will force the polarity of any chip-select gpiod to active-high (if 'spi-active-high' devicetree prop present) or active-low (if 'spi-active-high' absent). Irrespective of whether the gpio is marked GPIO_ACTIVE_[HIGH|LOW] in the devicetree. Loose ends: ----------- If this fix is applied: - is commit 138c9c32f090 ("spi: spidev: Fix CS polarity if GPIO descriptors are used") still necessary / correct ? Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") Signed-off-by: Sven Van Asbroeck <[email protected]> Acked-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-11-11regulator: pfuze100: limit pfuze-support-disable-sw to pfuze{100,200}Sean Nyekjaer1-5/+8
Limit the fsl,pfuze-support-disable-sw to the pfuze100 and pfuze200 variants. When enabling fsl,pfuze-support-disable-sw and using a pfuze3000 or pfuze3001, the driver would choose pfuze100_sw_disable_regulator_ops instead of the newly introduced and correct pfuze3000_sw_regulator_ops. Signed-off-by: Sean Nyekjaer <[email protected]> Fixes: 6f1cf5257acc ("regualtor: pfuze100: correct sw1a/sw2 on pfuze3000") Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-11-11x86/platform/uv: Drop last traces of uv_flush_tlb_othersJiri Slaby1-10/+0
Commit 39297dde7390 ("x86/platform/uv: Remove UV BAU TLB Shootdown Handler") removed uv_flush_tlb_others. Its declaration was removed also from asm/uv/uv.h. But only for the CONFIG_X86_UV=y case. The inline definition (!X86_UV case) is still in place. So remove this implementation with everything what was added to support uv_flush_tlb_others: * include of asm/tlbflush.h * forward declarations of struct cpumask, mm_struct, and flush_tlb_info Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Mike Travis <[email protected]> Acked-by: Steve Wahl <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-11Drivers: hv: vmbus: Allow cleanup of VMBUS_CONNECT_CPU if disconnectedChris Co1-2/+6
When invoking kexec() on a Linux guest running on a Hyper-V host, the kernel panics. RIP: 0010:cpuhp_issue_call+0x137/0x140 Call Trace: __cpuhp_remove_state_cpuslocked+0x99/0x100 __cpuhp_remove_state+0x1c/0x30 hv_kexec_handler+0x23/0x30 [hv_vmbus] hv_machine_shutdown+0x1e/0x30 machine_shutdown+0x10/0x20 kernel_kexec+0x6d/0x96 __do_sys_reboot+0x1ef/0x230 __x64_sys_reboot+0x1d/0x20 do_syscall_64+0x6b/0x3d8 entry_SYSCALL_64_after_hwframe+0x44/0xa9 This was due to hv_synic_cleanup() callback returning -EBUSY to cpuhp_issue_call() when tearing down the VMBUS_CONNECT_CPU, even if the vmbus_connection.conn_state = DISCONNECTED. hv_synic_cleanup() should succeed in the case where vmbus_connection.conn_state is DISCONNECTED. Fix is to add an extra condition to test for vmbus_connection.conn_state == CONNECTED on the VMBUS_CONNECT_CPU and only return early if true. This way the kexec() path can still shut everything down while preserving the initial behavior of preventing CPU offlining on the VMBUS_CONNECT_CPU while the VM is running. Fixes: 8a857c55420f29 ("Drivers: hv: vmbus: Always handle the VMBus messages on CPU0") Signed-off-by: Chris Co <[email protected]> Reviewed-by: Andrea Parri (Microsoft) <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2020-11-11bpf: Fix unsigned 'datasec_id' compared with zero in check_pseudo_btf_idKaixu Xia1-1/+2
The unsigned variable datasec_id is assigned a return value from the call to check_pseudo_btf_id(), which may return negative error code. This fixes the following coccicheck warning: ./kernel/bpf/verifier.c:9616:5-15: WARNING: Unsigned expression compared with zero: datasec_id > 0 Fixes: eaa6bcb71ef6 ("bpf: Introduce bpf_per_cpu_ptr()") Reported-by: Tosk Robot <[email protected]> Signed-off-by: Kaixu Xia <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Acked-by: John Fastabend <[email protected]> Cc: Hao Luo <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-11-11gpio: sifive: Fix SiFive gpio probeDamien Le Moal1-1/+1
Fix the check on the number of IRQs to allow up to the maximum (32) instead of only the maximum minus one. Fixes: 96868dce644d ("gpio/sifive: Add GPIO driver for SiFive SoCs") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-11-11KVM: s390: remove diag318 reset codeCollin Walling1-2/+0
The diag318 data must be set to 0 by VM-wide reset events triggered by diag308. As such, KVM should not handle resetting this data via the VCPU ioctls. Fixes: 23a60f834406 ("s390/kvm: diagnose 0x318 sync and reset") Signed-off-by: Collin Walling <[email protected]> Reviewed-by: Christian Borntraeger <[email protected]> Reviewed-by: Janosch Frank <[email protected]> Acked-by: Cornelia Huck <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-11KVM: s390: pv: Mark mm as protected after the set secure parameters and ↵Janosch Frank3-2/+5
improve cleanup We can only have protected guest pages after a successful set secure parameters call as only then the UV allows imports and unpacks. By moving the test we can now also check for it in s390_reset_acc() and do an early return if it is 0. Signed-off-by: Janosch Frank <[email protected]> Fixes: 29b40f105ec8 ("KVM: s390: protvirt: Add initial vm and cpu lifecycle handling") Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]>
2020-11-11ALSA: hda/realtek: Add some Clove SSID in the ALC293(ALC1220)PeiSen Hou1-1/+49
Fix "use as headset mic, without its own jack detect" problem. [ Minor coding style fixes by tiwai ] Signed-off-by: PeiSen Hou <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-11-11ARM: dts: am437x-l4: fix compatible for cpsw switch dt nodeGrygorii Strashko1-1/+1
Fix compatible the new CPSW switchdev DT node to avoid probing of legacy CPSW driver which fails: [ 2.781009] cpsw 4a100000.switch: invalid resource Fixes: 7bf8f37aea82 ("ARM: dts: am437x-l4: add dt node for new cpsw switchdev driver") Signed-off-by: Grygorii Strashko <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.