aboutsummaryrefslogtreecommitdiff
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* Bluetooth: hci_uart: check for missing tty operationsVladis Dronov2019-09-113-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit b36a1552d7319bbfd5cf7f08726c23c5c66d4f73 upstream. Certain ttys operations (pty_unix98_ops) lack tiocmget() and tiocmset() functions which are called by the certain HCI UART protocols (hci_ath, hci_bcm, hci_intel, hci_mrvl, hci_qca) via hci_uart_set_flow_control() or directly. This leads to an execution at NULL and can be triggered by an unprivileged user. Fix this by adding a helper function and a check for the missing tty operations in the protocols code. This fixes CVE-2019-10207. The Fixes: lines list commits where calls to tiocm[gs]et() or hci_uart_set_flow_control() were added to the HCI UART protocols. Change-Id: Ia8a38211661570912e9969262af239c021a13d5f Link: https://syzkaller.appspot.com/bug?id=1b42faa2848963564a5b1b7f8c837ea7b55ffa50 Reported-by: syzbot+79337b501d6aa974d0f6@syzkaller.appspotmail.com Fixes: b3190df62861 ("Bluetooth: Support for Atheros AR300x serial chip") Fixes: 118612fb9165 ("Bluetooth: hci_bcm: Add suspend/resume PM functions") Fixes: ff2895592f0f ("Bluetooth: hci_intel: Add Intel baudrate configuration support") Fixes: 162f812f23ba ("Bluetooth: hci_uart: Add Marvell support") Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990") Signed-off-by: Vladis Dronov <vdronov@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Reviewed-by: Yu-Chen, Cho <acho@suse.com> Tested-by: Yu-Chen, Cho <acho@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [bwh: Backported to 3.16: - Only hci_ath is affected - There is no serdev support] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* Security Patch: mt_idle: avoid sscanf heap overflowPiazza Lo2019-08-011-5/+5
| | | | | | | | | | | | | | [Detail] To add buffer size limitation in sscanf(%s) M-ALPS03353869 CVE-2017-0827 BUG:65994220 Change-Id: Icebd9e86ca533dcd5425ed89c0488a64ed921f75 Signed-off-by: Piazza Lo <piazza.lo@mediatek.com> Signed-off-by: Moyster <oysterized@gmail.com>
* (CR) ALPS03957020(For_mt6737m_35_n1_alps-mp-n1.mp1-V1_P118)lingsen12019-07-201-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch Type: Customer Request CR ID: ALPS03957020 Severity: Description: [Patch Request] [PMS] mt, Project: mt6737M_35_N1, SW Version: alps-mp-n1.mp1-V1N/A Associated Files: device/mt/mt6737m_35_n1/ProjectConfig.mk Patch Type: Customer Request CR ID: ALPS03913671 Severity: Critical Description: [Google Security P***h][CVE_2018_9369]EoP Vulnerability i***ootloader (Device Specific) [[Title fo***ustomer]] [Google Security P***h][CVE_2018_9369]EoP Vulnerability i***ootloader (Device Specific) [[Problem Description]] [Google Security P***h][CVE_2018_9369]EoP Vulnerability i***ootloader (Device Specific) [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Google Security P***h][CVE_2018_9369]EoP Vulnerability i***ootloader (Device Specific) [[問題現象]] [Google Security P***h][CVE_2018_9369]EoP Vulnerability i***ootloader (Device Specific) [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: vendor/mediatek/proprietary/bootable/bootloader/lk/app/mt_boot/fastboot.c Patch Type: Customer Request CR ID: ALPS03913728 Severity: Critical Description: [Google Security P***h][CVE_2018_9394]EoP Vulnerability in P2P (Device Specific) [[Title fo***ustomer]] [Google Security P***h][CVE_2018_9394]EoP Vulnerability in P2P (Device Specific) [[Problem Description]] [Google Security P***h][CVE_2018_9394]EoP Vulnerability in P2P (Device Specific) [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Google Security P***h][CVE_2018_9394]EoP Vulnerability in P2P (Device Specific) [[問題現象]] [Google Security P***h][CVE_2018_9394]EoP Vulnerability in P2P (Device Specific) [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: kernel-3.18/drivers/misc/mediatek/connectivity/wlan/gen2/os/linux/gl_p2p.c Patch Type: Customer Request CR ID: ALPS03913732 Severity: Critical Description: [Google Security P***h][CVE_2018_9396]EoP Vulnerability in C*** (Device Specific) [[Title fo***ustomer]] [Google Security P***h][CVE_2018_9396]EoP Vulnerability in C*** (Device Specific) [[Problem Description]] [Google Security P***h][CVE_2018_9396]EoP Vulnerability in C*** (Device Specific) [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Google Security P***h][CVE_2018_9396]EoP Vulnerability in C*** (Device Specific) [[問題現象]] [Google Security P***h][CVE_2018_9396]EoP Vulnerability in C*** (Device Specific) [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: kernel-3.18/drivers/misc/mediatek/eccci/port_rpc.c Patch Type: Customer Request CR ID: ALPS03921114 Severity: Critical Description: [IMS ***erface][version#0x68][AP] Added support fo***ountry-specific ur***o***o call response [[Title fo***ustomer]] IMS ***erface to support country-specific URN [[Problem Description]] Added support for IMS ***erface mo_call_c*** to country-specific URN which I***tack may send to MD side. [[Potential Impa*** of the solution]] Emergency call fun***ionality possible to implement as per ***PP and operator requirement. [[Modules to be verified after taking p***h]] VDM, VoLTE UA [[問題標題]] IMS ***erface to support country-specific URN [[問題現象]] Added support for IMS ***erface mo_call_c*** to country-specific URN which I***tack may send to MD side. [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) Emergency call fun***ionality possible to implement as per ***PP and operator requirement. [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) VDM, VoLTE UAN/A Associated Files: vendor/mt/libs/volte_imcb/arm/volte_imcb vendor/mt/libs/volte_stack/arm/volte_stack vendor/mt/libs/volte_ua/arm/volte_ua Change-Id: I0b947e82a40c6d2f7f63069ea73023cd61056223
* (CR) ALPS03877842(For_mt6737m_35_n1_alps-mp-n1.mp1-V1_P113)lingsen12019-07-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch Type: Customer Request CR ID: ALPS03877842 Severity: Description: [Patch Request] [PMS] mt, Project: mt6737M_35_N1, SW Version: alps-mp-n1.mp1-V1N/A Associated Files: device/mt/mt6737m_35_n1/ProjectConfig.mk vendor/mt/libs/libmtk-art-runtime/arm/libmtk-art-runtime.a Patch Type: Customer Request CR ID: ALPS03683903 Severity: Critical Description: [Buganizer]Security Vulnerability Issue 70515752 - [An***d GO Pen***ing] Mediatek Preloader Allows Arbitrary Peripheral Memory Reads and Writes [[Title fo***ustomer]] [Buganizer]Security Vulnerability Issue 70515752 - [An***d GO Pen***ing] Mediatek Preloader Allows Arbitrary Peripheral Memory Reads and Writes [[Problem Description]] [Buganizer]Security Vulnerability Issue 70515752 - [An***d GO Pen***ing] Mediatek Preloader Allows Arbitrary Peripheral Memory Reads and Writes [[Potential Impa*** of the solution]] No [[Modules to be verified after taking p***h]] No [[問題標題]] [Buganizer]Security Vulnerability Issue 70515752 - [An***d GO Pen***ing] Mediatek Preloader Allows Arbitrary Peripheral Memory Reads and Writes [[問題現象]] [Buganizer]Security Vulnerability Issue 70515752 - [An***d GO Pen***ing] Mediatek Preloader Allows Arbitrary Peripheral Memory Reads and Writes [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) No [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoN/A Associated Files: vendor/mediatek/proprietary/bootable/bootloader/preloader/platform/mt6735/src/core/download.c vendor/mediatek/proprietary/bootable/bootloader/preloader/platform/mt6735/src/core/inc/download.h vendor/mediatek/proprietary/bootable/bootloader/preloader/platform/mt6735/src/drivers/inc/mt6735.h vendor/mediatek/proprietary/bootable/bootloader/preloader/platform/mt6735/src/security/inc/sec_region.h vendor/mediatek/proprietary/bootable/bootloader/preloader/platform/mt6735/src/security/sec_region.c Patch Type: Customer Request CR ID: ALPS03693488 Severity: Critical Description: [Buganizer]Security Vulnerability Issue 70515281 - [An***d GO Pen***ing] Mediatek Preloader ¡§Download Mode¡¨ Memory Corruption [[Title fo***ustomer]] [Buganizer]Security Vulnerability Issue 70515281 - [An***d GO Pen***ing] Mediatek Preloader Download Mode Memory Corruption [[Problem Description]] [Buganizer]Security Vulnerability Issue 70515281 - [An***d GO Pen***ing] Mediatek Preloader Download Mode Memory Corruption [[Potential Impa*** of the solution]] no [[Modules to be verified after taking p***h]] boot [[問題標題]] [Buganizer]Security Vulnerability Issue 70515281 - [An***d GO Pen***ing] Mediatek Preloader Download Mode Memory Corruption [[問題現象]] [Buganizer]Security Vulnerability Issue 70515281 - [An***d GO Pen***ing] Mediatek Preloader Download Mode Memory Corruption [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) no [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) bootN/A Associated Files: vendor/mediatek/proprietary/bootable/bootloader/preloader/platform/mt6735/link_descriptor.ld vendor/mediatek/proprietary/bootable/bootloader/preloader/platform/mt6735/src/core/partition.c Patch Type: Customer Request CR ID: ALPS03740330 Severity: Critical Description: [Buganizer]Security Vulnerability Issue 71867247 - [An***d GO Pen***ing] - Remo***emory Corruption in Mediatek WiFi TLDS Frame Parser [[Title fo***ustomer]] [Buganizer]Security Vulnerability Issue 71867247 - [An***d GO Pen***ing] - Remo***emory Corruption in Mediatek WiFi TLDS Frame Parser [[Problem Description]] [Buganizer]Security Vulnerability Issue 71867247 - [An***d GO Pen***ing] - Remo***emory Corruption in Mediatek WiFi TLDS Frame Parser [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Buganizer]Security Vulnerability Issue 71867247 - [An***d GO Pen***ing] - Remo***emory Corruption in Mediatek WiFi TLDS Frame Parser [[問題現象]] [Buganizer]Security Vulnerability Issue 71867247 - [An***d GO Pen***ing] - Remo***emory Corruption in Mediatek WiFi TLDS Frame Parser [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: kernel-3.18/drivers/misc/mediatek/connectivity/wlan/gen2/mgmt/tdls.c Patch Type: Customer Request CR ID: ALPS03862169 Severity: Critical Description: [Google Security P***h][CVE_2017_13311]EoP Vulnerability in ProcessStats [[Title fo***ustomer]] [Google Security P***h][CVE_2017_13311]EoP Vulnerability in ProcessStats [[Problem Description]] [Google Security P***h][CVE_2017_13311]EoP Vulnerability in ProcessStats [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Google Security P***h][CVE_2017_13311]EoP Vulnerability in ProcessStats [[問題現象]] [Google Security P***h][CVE_2017_13311]EoP Vulnerability in ProcessStats [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: frameworks/base/core/java/com/android/internal/app/procstats/SparseMappingTable.java Patch Type: Customer Request CR ID: ALPS03862180 Severity: Critical Description: [Google Security P***h][CVE_2017_13316]ID Vulnerability in Speech recognizer [[Title fo***ustomer]] [Google Security P***h][CVE_2017_13316]ID Vulnerability in Speech recognizer [[Problem Description]] [Google Security P***h][CVE_2017_13316]ID Vulnerability in Speech recognizer [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Google Security P***h][CVE_2017_13316]ID Vulnerability in Speech recognizer [[問題現象]] [Google Security P***h][CVE_2017_13316]ID Vulnerability in Speech recognizer [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: frameworks/base/core/java/android/content/PermissionChecker.java frameworks/base/core/java/android/speech/RecognitionService.java Patch Type: Customer Request CR ID: ALPS03862195 Severity: Critical Description: [Google Security P***h][CVE_2017_13319]ID/DoS Vulnerability in MP3 codec [[Title fo***ustomer]] [Google Security P***h][CVE_2017_13319]ID/DoS Vulnerability in MP3 codec [[Problem Description]] [Google Security P***h][CVE_2017_13319]ID/DoS Vulnerability in MP3 codec [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Google Security P***h][CVE_2017_13319]ID/DoS Vulnerability in MP3 codec [[問題現象]] [Google Security P***h][CVE_2017_13319]ID/DoS Vulnerability in MP3 codec [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: frameworks/av/media/libstagefright/codecs/mp3dec/src/pvmp3_decode_header.cpp Patch Type: Customer Request CR ID: ALPS03862206 Severity: Critical Description: [Google Security P***h][CVE_2017_16643]ID Vulnerability in USB driver (Device Specific) [[Title fo***ustomer]] [Google Security P***h][CVE_2017_16643]ID Vulnerability in USB driver (Device Specific) [[Problem Description]] [Google Security P***h][CVE_2017_16643]ID Vulnerability in USB driver (Device Specific) [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Google Security P***h][CVE_2017_16643]ID Vulnerability in USB driver (Device Specific) [[問題現象]] [Google Security P***h][CVE_2017_16643]ID Vulnerability in USB driver (Device Specific) [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: kernel-3.18/drivers/input/tablet/gtco.c Change-Id: I584cb0ab7b367a80b61730adea475093ca98f3f4
* mm/oom_kill: squashed reverts to a stable stateCorinna Vinschen2019-07-192-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert "mm, oom: fix use-after-free in oom_kill_process" This reverts commit e1bebdeedb497f03d426c85a89c3807c7e75268d. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm,oom: make oom_killer_disable() killable" This reverts commit 65a7400a432639aa8d5e572f30687fbca204b6f8. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm: oom_kill: don't ignore oom score on exiting tasks" This reverts commit d60dae46b27a8f381e4a7ad9dde870faa49fa5f1. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm/oom_kill.c: avoid attempting to kill init sharing same memory" This reverts commit 10773c0325259d6640b93c0694b5598ddf84939f. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "CHROMIUM: DROP: mm/oom_kill: Double-check before killing a child in our place" This reverts commit 2bdd9a2042a0e12d96c545773d9d8038c920f813. Revert "mm/oom_kill: fix the wrong task->mm == mm checks in oom_kill_process()" This reverts commit 419a313435b31821e4d045ca4b7ea1cc5fa02035. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm/oom_kill: cleanup the "kill sharing same memory" loop" This reverts commit afda78c6de38f9f66eba0955153b380d540d8276. Revert "mm/oom_kill: remove the wrong fatal_signal_pending() check in oom_kill_process()" This reverts commit acde9c2ace298b249c06ec5b0b971c333449dc09. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm, oom: remove task_lock protecting comm printing" This reverts commit 9a9ca142d250ec9de1215284857f4528c6ddb080. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm/oom_kill.c: suppress unnecessary "sharing same memory" message" This reverts commit 1aa2960f7c70d65b1481f805ac73b988faff6747. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm/oom_kill.c: reverse the order of setting TIF_MEMDIE and sending SIGKILL" This reverts commit f028aedfcfd2e2bb98921b98d3ae183387ab8fed. Revert "mm, oom: remove unnecessary variable" This reverts commit 54b0b58224146d68a11bccb5e64683ab3029373a. Revert "mm/oom_kill.c: print points as unsigned int" This reverts commit 603f975a6d4f0b56c7f6df7889ef2a704eca94a3. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm: oom_kill: simplify OOM killer locking" This reverts commit 7951a52ed35d162063fa08b27894e302fd716ccd. Revert "mm: oom_kill: remove unnecessary locking in exit_oom_victim()" This reverts commit f0739b25ac884682865d6aae7485e79489107bfb. Revert "mm: oom_kill: generalize OOM progress waitqueue" This reverts commit eb4b1243c72ba0b392bbe05dbf9f91959f70eb18. Revert "mm: oom_kill: switch test-and-clear of known TIF_MEMDIE to clear" This reverts commit e611f16275c3642cb8a6345ff2470926fef52110. Revert "mm: oom_kill: clean up victim marking and exiting interfaces" This reverts commit c6fada01b9370e3d7603b4ad8c26b56759174667. Revert "mm: oom_kill: remove unnecessary locking in oom_enable()" This reverts commit 5dd152d7351b3805f59b2b1f624722ab2f3c5fd8. Revert "oom, PM: make OOM detection in the freezer path raceless" This reverts commit 5fc5b1ddee5404a7629dd7045f54eaf8941bc11c.
* DISP: Printk too muchElvin Zhang2019-07-181-1/+1
| | | | | | | | | | | | | [Detail] Replace DISPMSG() as DISPDBG() to reduce printk log MTK-Commit-Id: d9613f32bb286cea1ce1f4cd87a2af91557643fb Change-Id: I2d072885b6c83113490dc27823c822860ec201a5 Signed-off-by: Elvin Zhang <elvin.zhang@mediatek.com> CR-Id:ALPS03499038 Feature:Display Driver
* GPU DVFS: fix procfs write KEBrian-SY Yang2019-07-181-6/+16
| | | | | | | | | | | | | | | | [Detail] KE always happens when write /proc/gpufreq/gpufreq_fixed_freq by IoFuzz test [Solution] add input freq check MTK-Commit-Id: 74092efbcddc8d1584e56bb81df4722affa0b512 Change-Id: I10525c42e946088d63b8adeb29594f754710747f Signed-off-by: Brian-SY Yang <brian-sy.yang@mediatek.com> CR-Id: ALPS03519258 Feature: Others (cherry picked from commit bcbce651ad5b50bc7add53f65c0c355a3b932c33) (cherry picked from commit fa8f434d44293d39b89b3b1585ae114fa1f1d549)
* masp: fix ioctl: SEC_GET_RANDOM_ID memory check rangeChin-Ting Kuo2019-07-181-1/+5
| | | | | | | | | | | | | | | [Detail] Size of RID is 16 bytes instead of 4 bytes. Instead of using "unsigned int" as input type of _IOR(), a new struct "sec_rid" which is 16 bytes in size is declared and used in order to make memory access permission check range correct. MTK-Commit-Id: 4e1c03ca23666da29bbcd024839de5ad8a3fa143 Change-Id: I892b71fb082b5b2335d29436fee1bc61cf14fc15 Signed-off-by: Chin-Ting Kuo <chin-ting.kuo@mediatek.com> CR-Id: ALPS03523553 Feature: Vulnerability Scan
* smi: log only for wrong ioctlJacky Chen2019-07-181-1/+1
| | | | | | | | | | | [Detail] log only without aee for wrong ioctl MTK-Commit-Id: bb7c3da5b777f7841bf42f3d2b3e2b5f82bc135e Change-Id: I39b4360faeb297f9febefce9c3b3b9885e0c097b Signed-off-by: Jacky Chen <ming-fan.chen@mediatek.com> CR-Id: ALPS03592077 Feature: smi
* vibrator: delete more logShangbing Hu2019-07-181-6/+7
| | | | | | | | | | | | | | | | [Detail] delete more log [Solution] delete more log MTK-Commit-Id: 1f1494edf8bb600dfede431d102a5fbbaa04816a Change-Id: I6309eb44c76b588ff44dd7f2a937b3e4c5d5e7bb Signed-off-by: Shangbing Hu <shangbing.hu@mediatek.com> CR-Id: ALPS02571387 Feature: WiFi Calling Service (cherry picked from commit 93f355c2b37d923cd463bb71e20dc8c7e7596cca) (cherry picked from commit b0e147971dcd0d178a1ee6043dcd49dec5f434e7)
* msdc: mt6735: fix code defectEdison Liu2019-07-181-0/+2
| | | | | | | | | | | | | | | | | [Detail] A malicious userspace application can corrupt kernel memory. the offset is not limited, so it will becomes a powerful arbitrary memory read/write primitive. [Solution] set the limit of the offset from 0 to 0xFFFF MTK-Commit-Id: 91446a30b6123dd3391074062dc9833d09dbcc54 Change-Id: Icf733233133bd8ed734ec69a3567e06281d982ff Signed-off-by: Edison Liu <Edison.Liu@mediatek.com> CR-Id: ALPS03684210 Feature: Others
* mm: oom_kill: simplify OOM killer lockingJohannes Weiner2019-07-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The zonelist locking and the oom_sem are two overlapping locks that are used to serialize global OOM killing against different things. The historical zonelist locking serializes OOM kills from allocations with overlapping zonelists against each other to prevent killing more tasks than necessary in the same memory domain. Only when neither tasklists nor zonelists from two concurrent OOM kills overlap (tasks in separate memcgs bound to separate nodes) are OOM kills allowed to execute in parallel. The younger oom_sem is a read-write lock to serialize OOM killing against the PM code trying to disable the OOM killer altogether. However, the OOM killer is a fairly cold error path, there is really no reason to optimize for highly performant and concurrent OOM kills. And the oom_sem is just flat-out redundant. Replace both locking schemes with a single global mutex serializing OOM kills regardless of context. Change-Id: Ieb0b621bc3a391cc0a826a3ae53bf28ea4a8dbe5 Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Michal Hocko <mhocko@suse.cz> Acked-by: David Rientjes <rientjes@google.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Dave Chinner <david@fromorbit.com> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* mm: oom_kill: clean up victim marking and exiting interfacesJohannes Weiner2019-07-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | Rename unmark_oom_victim() to exit_oom_victim(). Marking and unmarking are related in functionality, but the interface is not symmetrical at all: one is an internal OOM killer function used during the killing, the other is for an OOM victim to signal its own death on exit later on. This has locking implications, see follow-up changes. While at it, rename mark_tsk_oom_victim() to mark_oom_victim(), which is easier on the eye. Change-Id: I8956f6357e98f17e0ae6096c6a2c7027886a4fda Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: David Rientjes <rientjes@google.com> Acked-by: Michal Hocko <mhocko@suse.cz> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Dave Chinner <david@fromorbit.com> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* oom, PM: make OOM detection in the freezer path racelessMichal Hocko2019-07-081-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 5695be142e20 ("OOM, PM: OOM killed task shouldn't escape PM suspend") has left a race window when OOM killer manages to note_oom_kill after freeze_processes checks the counter. The race window is quite small and really unlikely and partial solution deemed sufficient at the time of submission. Tejun wasn't happy about this partial solution though and insisted on a full solution. That requires the full OOM and freezer's task freezing exclusion, though. This is done by this patch which introduces oom_sem RW lock and turns oom_killer_disable() into a full OOM barrier. oom_killer_disabled check is moved from the allocation path to the OOM level and we take oom_sem for reading for both the check and the whole OOM invocation. oom_killer_disable() takes oom_sem for writing so it waits for all currently running OOM killer invocations. Then it disable all the further OOMs by setting oom_killer_disabled and checks for any oom victims. Victims are counted via mark_tsk_oom_victim resp. unmark_oom_victim. The last victim wakes up all waiters enqueued by oom_killer_disable(). Therefore this function acts as the full OOM barrier. The page fault path is covered now as well although it was assumed to be safe before. As per Tejun, "We used to have freezing points deep in file system code which may be reacheable from page fault." so it would be better and more robust to not rely on freezing points here. Same applies to the memcg OOM killer. out_of_memory tells the caller whether the OOM was allowed to trigger and the callers are supposed to handle the situation. The page allocation path simply fails the allocation same as before. The page fault path will retry the fault (more on that later) and Sysrq OOM trigger will simply complain to the log. Normally there wouldn't be any unfrozen user tasks after try_to_freeze_tasks so the function will not block. But if there was an OOM killer racing with try_to_freeze_tasks and the OOM victim didn't finish yet then we have to wait for it. This should complete in a finite time, though, because - the victim cannot loop in the page fault handler (it would die on the way out from the exception) - it cannot loop in the page allocator because all the further allocation would fail and __GFP_NOFAIL allocations are not acceptable at this stage - it shouldn't be blocked on any locks held by frozen tasks (try_to_freeze expects lockless context) and kernel threads and work queues are not frozen yet Change-Id: Ie72c2cfc39dad6420802b873053c739e804f956f Signed-off-by: Michal Hocko <mhocko@suse.cz> Suggested-by: Tejun Heo <tj@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* gpio: improve error path in gpiolibLinus Walleij2019-07-081-16/+25
| | | | | | | | | | | | | | | | | | | | | | | | At several places the gpiolib will proceed to handle a GPIO descriptor even if it's ->chip member is NULL and no gpiochip is associated. Fix this by checking that both the descriptor cookie *and* the chip pointer are valid. Also bail out earlier with more specific diagnostic messages on missing operations for setting as input/output or debounce. ChangeLog v1->v2: - Also return -EIO on gpiod_set_debounce() with missing operations in the vtable - Fix indentations. Change-Id: I4143419af27ecfe4ec6cfbfc8bd95ddfd9f8daa1 Suggested-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Frank Rowand <frank.rowand@sonymobile.com> Cc: Tim Bird <tim.bird@sonymobile.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* usb: ohci: Proper handling of ed_rm_list to handle race condition between ↵AMAN DEEP2019-05-031-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | usb_kill_urb() and finish_unlinks() commit 46408ea558df13b110e0866b99624384a33bdeba upstream. There is a race condition between finish_unlinks->finish_urb() function and usb_kill_urb() in ohci controller case. The finish_urb calls spin_unlock(&ohci->lock) before usb_hcd_giveback_urb() function call, then if during this time, usb_kill_urb is called for another endpoint, then new ed will be added to ed_rm_list at beginning for unlink, and ed_rm_list will point to newly added. When finish_urb() is completed in finish_unlinks() and ed->td_list becomes empty as in below code (in finish_unlinks() function): if (list_empty(&ed->td_list)) { *last = ed->ed_next; ed->ed_next = NULL; } else if (ohci->rh_state == OHCI_RH_RUNNING) { *last = ed->ed_next; ed->ed_next = NULL; ed_schedule(ohci, ed); } The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next and previously added ed by usb_kill_urb will be left unreferenced by ed_rm_list. This causes usb_kill_urb() hang forever waiting for finish_unlink to remove added ed from ed_rm_list. The main reason for hang in this race condtion is addition and removal of ed from ed_rm_list in the beginning during usb_kill_urb and later last* is modified in finish_unlinks(). As suggested by Alan Stern, the solution for proper handling of ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing any URBs. Then at the end, we can add ed back to the list if necessary. This properly handle the updated ohci->ed_rm_list in usb_kill_urb(). Fixes: 977dcfdc6031 ("USB: OHCI: don't lose track of EDs when a controller dies") Change-Id: I1b4bd2253db6e090fa5b7ffc4db356045c707e35 Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Aman Deep <aman.deep@samsung.com> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* ARM: 7933/1: rename ioremap_cached to ioremap_cacheRob Herring2019-05-031-1/+1
| | | | | | | | | | | | | | | | | | | | | ioremap_cache is more aligned with other architectures. There are only 2 users of this in the kernel: pxa2xx-flash and Xen. This fixes Xen build failures on arm64: drivers/tty/hvc/hvc_xen.c:233:2: error: implicit declaration of function 'ioremap_cached' [-Werror=implicit-function-declaration] drivers/xen/grant-table.c:1174:3: error: implicit declaration of function 'ioremap_cached' [-Werror=implicit-function-declaration] drivers/xen/xenbus/xenbus_probe.c:778:4: error: implicit declaration of function 'ioremap_cached' [-Werror=implicit-function-declaration] Signed-off-by: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: 0a5ccc86507f45b80831dac1049197c4d45be955 [joonwoop@codeaurora.org: fixed trivial merge conflict.] Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org> Change-Id: I867b893aa63bc8647ed0d7cbf66b7fbb464ef8f0
* driver core: dev_set_drvdata returns voidJean Delvare2019-05-033-12/+3
| | | | | | | | | | | | | dev_set_drvdata can no longer fail, so it could return void. All callers have hopefully been updated to no longer check for the return value. [apq8084: fix callers still expecting a return value] Change-Id: I5e8995b0783727139901dcc7a810e8d0d39a0eed Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cpufreq: Fix timer/workqueue corruption by protecting reading governor_enabledJane Li2019-05-033-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a CPU is hot removed we'll cancel all the delayed work items via gov_cancel_work(). Sometimes the delayed work function determines that it should adjust the delay for all other CPUs that the policy is managing. If this scenario occurs, the canceling CPU will cancel its own work but queue up the other CPUs works to run. Commit 3617f2 (cpufreq: Fix timer/workqueue corruption due to double queueing) has tried to fix this, but reading governor_enabled is not protected by cpufreq_governor_lock. Even though od_dbs_timer() checks governor_enabled before gov_queue_work(), this scenario may occur. For example: CPU0 CPU1 ---- ---- cpu_down() ... <work runs> __cpufreq_remove_dev() od_dbs_timer() __cpufreq_governor() policy->governor_enabled policy->governor_enabled = false; cpufreq_governor_dbs() case CPUFREQ_GOV_STOP: gov_cancel_work(dbs_data, policy); cpu0 work is canceled timer is canceled cpu1 work is canceled <waits for cpu1> gov_queue_work(*, *, true); cpu0 work queued cpu1 work queued cpu2 work queued ... cpu1 work is canceled cpu2 work is canceled ... At the end of the GOV_STOP case cpu0 still has a work queued to run although the code is expecting all of the works to be canceled. __cpufreq_remove_dev() will then proceed to re-initialize all the other CPUs works except for the CPU that is going down. The CPUFREQ_GOV_START case in cpufreq_governor_dbs() will trample over the queued work and debugobjects will spit out a warning: WARNING: at lib/debugobjects.c:260 debug_print_object+0x94/0xbc() ODEBUG: init active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x14 Modules linked in: CPU: 1 PID: 1205 Comm: sh Tainted: G W 3.10.0 #200 [<c01144f0>] (unwind_backtrace+0x0/0xf8) from [<c0111d98>] (show_stack+0x10/0x14) [<c0111d98>] (show_stack+0x10/0x14) from [<c01272cc>] (warn_slowpath_common+0x4c/0x68) [<c01272cc>] (warn_slowpath_common+0x4c/0x68) from [<c012737c>] (warn_slowpath_fmt+0x30/0x40) [<c012737c>] (warn_slowpath_fmt+0x30/0x40) from [<c034c640>] (debug_print_object+0x94/0xbc) [<c034c640>] (debug_print_object+0x94/0xbc) from [<c034c7f8>] (__debug_object_init+0xc8/0x3c0) [<c034c7f8>] (__debug_object_init+0xc8/0x3c0) from [<c01360e0>] (init_timer_key+0x20/0x104) [<c01360e0>] (init_timer_key+0x20/0x104) from [<c04872ac>] (cpufreq_governor_dbs+0x1dc/0x68c) [<c04872ac>] (cpufreq_governor_dbs+0x1dc/0x68c) from [<c04833a8>] (__cpufreq_governor+0x80/0x1b0) [<c04833a8>] (__cpufreq_governor+0x80/0x1b0) from [<c0483704>] (__cpufreq_remove_dev.isra.12+0x22c/0x380) [<c0483704>] (__cpufreq_remove_dev.isra.12+0x22c/0x380) from [<c0692f38>] (cpufreq_cpu_callback+0x48/0x5c) [<c0692f38>] (cpufreq_cpu_callback+0x48/0x5c) from [<c014fb40>] (notifier_call_chain+0x44/0x84) [<c014fb40>] (notifier_call_chain+0x44/0x84) from [<c012ae44>] (__cpu_notify+0x2c/0x48) [<c012ae44>] (__cpu_notify+0x2c/0x48) from [<c068dd40>] (_cpu_down+0x80/0x258) [<c068dd40>] (_cpu_down+0x80/0x258) from [<c068df40>] (cpu_down+0x28/0x3c) [<c068df40>] (cpu_down+0x28/0x3c) from [<c068e4c0>] (store_online+0x30/0x74) [<c068e4c0>] (store_online+0x30/0x74) from [<c03a7308>] (dev_attr_store+0x18/0x24) [<c03a7308>] (dev_attr_store+0x18/0x24) from [<c0256fe0>] (sysfs_write_file+0x100/0x180) [<c0256fe0>] (sysfs_write_file+0x100/0x180) from [<c01fec9c>] (vfs_write+0xbc/0x184) [<c01fec9c>] (vfs_write+0xbc/0x184) from [<c01ff034>] (SyS_write+0x40/0x68) [<c01ff034>] (SyS_write+0x40/0x68) from [<c010e200>] (ret_fast_syscall+0x0/0x48) In gov_queue_work(), lock cpufreq_governor_lock before gov_queue_work, and unlock it after __gov_queue_work(). In this way, governor_enabled is guaranteed not changed in gov_queue_work(). Signed-off-by: Jane Li <jiel@marvell.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Corinna Vinschen <xda@vinschen.de>
* oom: add helpers for setting and clearing TIF_MEMDIEMichal Hocko2019-05-021-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patchset addresses a race which was described in the changelog for 5695be142e20 ("OOM, PM: OOM killed task shouldn't escape PM suspend"): : PM freezer relies on having all tasks frozen by the time devices are : getting frozen so that no task will touch them while they are getting : frozen. But OOM killer is allowed to kill an already frozen task in order : to handle OOM situtation. In order to protect from late wake ups OOM : killer is disabled after all tasks are frozen. This, however, still keeps : a window open when a killed task didn't manage to die by the time : freeze_processes finishes. The original patch hasn't closed the race window completely because that would require a more complex solution as it can be seen by this patchset. The primary motivation was to close the race condition between OOM killer and PM freezer _completely_. As Tejun pointed out, even though the race condition is unlikely the harder it would be to debug weird bugs deep in the PM freezer when the debugging options are reduced considerably. I can only speculate what might happen when a task is still runnable unexpectedly. On a plus side and as a side effect the oom enable/disable has a better (full barrier) semantic without polluting hot paths. I have tested the series in KVM with 100M RAM: - many small tasks (20M anon mmap) which are triggering OOM continually - s2ram which resumes automatically is triggered in a loop echo processors > /sys/power/pm_test while true do echo mem > /sys/power/state sleep 1s done - simple module which allocates and frees 20M in 8K chunks. If it sees freezing(current) then it tries another round of allocation before calling try_to_freeze - debugging messages of PM stages and OOM killer enable/disable/fail added and unmark_oom_victim is delayed by 1s after it clears TIF_MEMDIE and before it wakes up waiters. - rebased on top of the current mmotm which means some necessary updates in mm/oom_kill.c. mark_tsk_oom_victim is now called under task_lock but I think this should be OK because __thaw_task shouldn't interfere with any locking down wake_up_process. Oleg? As expected there are no OOM killed tasks after oom is disabled and allocations requested by the kernel thread are failing after all the tasks are frozen and OOM disabled. I wasn't able to catch a race where oom_killer_disable would really have to wait but I kinda expected the race is really unlikely. [ 242.609330] Killed process 2992 (mem_eater) total-vm:24412kB, anon-rss:2164kB, file-rss:4kB [ 243.628071] Unmarking 2992 OOM victim. oom_victims: 1 [ 243.636072] (elapsed 2.837 seconds) done. [ 243.641985] Trying to disable OOM killer [ 243.643032] Waiting for concurent OOM victims [ 243.644342] OOM killer disabled [ 243.645447] Freezing remaining freezable tasks ... (elapsed 0.005 seconds) done. [ 243.652983] Suspending console(s) (use no_console_suspend to debug) [ 243.903299] kmem_eater: page allocation failure: order:1, mode:0x204010 [...] [ 243.992600] PM: suspend of devices complete after 336.667 msecs [ 243.993264] PM: late suspend of devices complete after 0.660 msecs [ 243.994713] PM: noirq suspend of devices complete after 1.446 msecs [ 243.994717] ACPI: Preparing to enter system sleep state S3 [ 243.994795] PM: Saving platform NVS memory [ 243.994796] Disabling non-boot CPUs ... The first 2 patches are simple cleanups for OOM. They should go in regardless the rest IMO. Patches 3 and 4 are trivial printk -> pr_info conversion and they should go in ditto. The main patch is the last one and I would appreciate acks from Tejun and Rafael. I think the OOM part should be OK (except for __thaw_task vs. task_lock where a look from Oleg would appreciated) but I am not so sure I haven't screwed anything in the freezer code. I have found several surprises there. This patch (of 5): This patch is just a preparatory and it doesn't introduce any functional change. Note: I am utterly unhappy about lowmemory killer abusing TIF_MEMDIE just to wait for the oom victim and to prevent from new killing. This is just a side effect of the flag. The primary meaning is to give the oom victim access to the memory reserves and that shouldn't be necessary here. Change-Id: If4188f68cdfb73f8cf2721f89c9739ec0a8f0e12 Signed-off-by: Michal Hocko <mhocko@suse.cz> Cc: Tejun Heo <tj@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* mm, oom: ensure memoryless node zonelist always includes zonesDavid Rientjes2019-05-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | With memoryless node support being worked on, it's possible that for optimizations that a node may not have a non-NULL zonelist. When CONFIG_NUMA is enabled and node 0 is memoryless, this means the zonelist for first_online_node may become NULL. The oom killer requires a zonelist that includes all memory zones for the sysrq trigger and pagefault out of memory handler. Ensure that a non-NULL zonelist is always passed to the oom killer. [akpm@linux-foundation.org: fix non-numa build] Signed-off-by: David Rientjes <rientjes@google.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Rik van Riel <riel@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Change-Id: Ic93a32abbf875a331244a0f95f2a0bcd0764360b
* PM / sleep: Mechanism for aborting system suspends unconditionallyRafael J. Wysocki2019-05-021-1/+16
| | | | | | | | | | | | | It sometimes may be necessary to abort a system suspend in progress or wake up the system from suspend-to-idle even if the pm_wakeup_event()/pm_stay_awake() mechanism is not enabled. For this purpose, introduce a new global variable pm_abort_suspend and make pm_wakeup_pending() check its value. Also add routines for manipulating that variable. Change-Id: I694bee866a1b9e85a724f3efec09326d47a4ef6e Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Staging: android: binder: Ratelimit binder debug messagesChris Fries2019-05-021-1/+3
| | | | | | | | | | | | | Ratelimit the binder debug messages, since they can get spammy and flood the entire kernel log. In some cases, enabling serial console with a spammy binder error can cause a watchdog panic (and we don't have reports of this happening with serial console disabled). Bug: 17613664 Change-Id: Iecdb4c3c80ccf00c43459e93c17f5369fd55e6e7 Signed-off-by: Chris Fries <cfries@motorola.com>
* BACKPORT: tty: Use unbound workqueue for all input workersPeter Hurley2019-05-022-2/+2
| | | | | | | | | | | | | | | | | | The commonly accepted wisdom that scheduling work on the same cpu that handled interrupt i/o benefits from cache-locality is only true if the cpu is idle (since bound kworkers are often the highest vruntime and thus the lowest priority). Measurements of scheduling via the unbound queue show lowered worst-case latency responses of up to 5x over bound workqueue, without increase in average latency or throughput. pty i/o test measurements show >3x (!) reduced total running time; tests previously taking ~8s now complete in <2.5s. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Change-Id: I949ba6dfa56a802bba7c03e7ddbc2bde37b868ba
* media: uvcvideo: Prevent heap overflow when accessing mapped controlsGuenter Roeck2019-05-021-0/+7
| | | | | | | | | | | | | | | | | | commit 7e09f7d5c790278ab98e5f2c22307ebe8ad6e8ba upstream. The size of uvc_control_mapping is user controlled leading to a potential heap overflow in the uvc driver. This adds a check to verify the user provided size fits within the bounds of the defined buffer size. Originally-from: Richard Simmons <rssimmo@amazon.com> Change-Id: Iecff8a3172e2096379d647ba4373cbd0b35d7479 Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: hiddev: fix potential Spectre v1Gustavo A. R. Silva2019-05-021-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 4f65245f2d178b9cba48350620d76faa4a098841 upstream. uref->field_index, uref->usage_index, finfo.field_index and cinfo.index can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/hid/usbhid/hiddev.c:473 hiddev_ioctl_usage() warn: potential spectre issue 'report->field' (local cap) drivers/hid/usbhid/hiddev.c:477 hiddev_ioctl_usage() warn: potential spectre issue 'field->usage' (local cap) drivers/hid/usbhid/hiddev.c:757 hiddev_ioctl() warn: potential spectre issue 'report->field' (local cap) drivers/hid/usbhid/hiddev.c:801 hiddev_ioctl() warn: potential spectre issue 'hid->collection' (local cap) Fix this by sanitizing such structure fields before using them to index report->field, field->usage and hid->collection Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Change-Id: Iaf59ae8d06c17da1240eec8e3b558ba41592cc05 Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* Makefile: fix make clean && make mrproperMoyster2018-12-211-2/+2
|
* Shrink ashmem directly through shmem_fallocateTobias Lindskog2018-12-211-1/+1
| | | | | | | | | | | | | | | | | | When ashmem_shrink is called from direct reclaim on a user thread, a call to do_fallocate will check for permissions against the security policy of that user thread. It can thus fail by chance if called on a thread that isn't permitted to modify the relevant ashmem areas. Because we know that we have a shmem file underneath, call the shmem implementation of fallocate directly instead of going through the user-space interface for fallocate. FIX=DMS06243560 Area: Kernel/Linux Kernel Bug: 21951515 Change-Id: Ie98fff18a2bdeb535cd24d4fbdd13677e12681a7 Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
* iio:st sensors: remove custom sampling frequence attribute in favour of core ↵Jonathan Cameron2018-12-114-35/+30
| | | | | | | | | | | | | support. This allows in kernel client drivers to access this Signed-off-by: Jonathan Cameron <jic23@kernel.org> Cc: Denis Ciocca <denis.ciocca@st.com> Reviewed-by: Hartmut Knaack <knaack.h@gmx.de> Signed-off-by: Moyster <oysterized@gmail.com> omitted pressure driver changes (missing in this kernel)
* iio:st_sensors: Fix oops when probing SPI devicesAlban Bedel2018-12-114-2/+3
| | | | | | | | | | | | | | | | | In SPI mode the transfer buffer is locked with a mutex. However this mutex is only initilized after the probe, but some transfer needs to be done in the probe. To fix this bug we move the mutex initialization at the beginning of the device probe. Signed-off-by: Alban Bedel <alban.bedel@avionic-design.de> Acked-by: Denis Ciocca <denis.ciocca@st.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Moyster <oysterized@gmail.com> omitted pressure driver changes (missing in this kernel)
* iio: sensors-core: st: Clean-up error handling in st_sensors_read_axis_data()Lee Jones2018-12-111-5/+3
| | | | | | | Gets rid of those unnecessary gotos. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: sensors-core: st: Clean-up error handling in st_sensors_init_sensor()Lee Jones2018-12-111-5/+4
| | | | | | | | | Strip out all those unnecessary gotos and just return the error right away. Aids to simplicity and reduces code. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio:st_sensors: Use iio_push_to_buffers_with_timestamp()Lars-Peter Clausen2018-12-111-5/+2
| | | | | | | | Makes the code a bit shorter and less ugly. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Cc: Denis Ciocca <denis.ciocca@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: sensors-core: st: Clean-up error handling in st_sensors_read_info_raw()Lee Jones2018-12-111-7/+4
| | | | | | | Saving a few lines of code. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: sensors-core: st: Allow full-scale to be an optional featureLee Jones2018-12-111-4/+7
| | | | | | | | | | | | Some chips either don't support it or fail to provide adequate documentation, so sometimes it's impossible to enable the feature even if it is supported. Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Moyster <oysterized@gmail.com> omitted pressure driver changes (missing in this kernel)
* iio: sensors-core: st: Support sensors which don't have a Data Ready pinLee Jones2018-12-111-11/+22
| | | | | | | | | | | Not all ST's sensors support data ready, so let's make the declaration of one conditional. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Moyster <oysterized@gmail.com> omitted pressure drive changes (missing in this kernel)
* iio: st_sensors: announce registered sensorsLinus Walleij2018-12-113-0/+9
| | | | | | | | | | | | | | It is pretty helpful to know already from dmesg that a certain device is successfully registered, instead of having to browse sysfs to see if it's actually there. Cc: Lee Jones <lee.jones@linaro.org> Cc: Denis CIOCCA <denis.ciocca@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Moyster <oysterized@gmail.com> omitted pressure driver changes (missing in this kernel)
* iio: imu: st_lsm6dsx: fix typo in gyro sensitivity definitionLorenzo Bianconi2018-12-111-3/+3
| | | | | | Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Moyster <oysterized@gmail.com>
* iio:accel: Register buffer also without specific triggerDenis CIOCCA2018-12-111-9/+8
| | | | | | | This patch fix buffer registration that allows to use generic IIO trigger. Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: accel-core: st: Clean up error handling in probe()Lee Jones2018-12-111-9/+10
| | | | | | | | | Reduce the amount of those unnecessary goto calls, as in most cases we can simply return immediately. We also only call for the IRQ number once and use that value throughout. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: accel: st_accel: Use devm_iio_device_allocSachin Kamat2018-12-113-23/+8
| | | | | | | | Using devm_iio_device_alloc makes code simpler. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: Added ST-sensors platform data to select the DRDY interrupt pinDenis CIOCCA2018-12-1113-30/+95
| | | | | | | | | | | This patch add support to redirect the DRDY interrupt on INT1 or INT2 on accelerometer and pressure sensors. Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Moyster <oysterized@gmail.com> omitted pressure drivers changes (missing on this kernel)
* iio:common: Removed stuff macros, added num_data_channels on st_sensors ↵Denis CIOCCA2018-12-115-31/+73
| | | | | | | | | | | | | | struct and added support on one-shot sysfs reads to 3 byte channel This patch introduce num_data_channels variable on st_sensors struct to manage different type of channels (size or number) in st_sensors_get_buffer_element function. Removed ST_SENSORS_NUMBER_DATA_CHANNELS and ST_SENSORS_BYTE_FOR_CHANNEL and used struct iio_chan_spec const *ch to catch data. Added 3 byte channel data support on one-shot reads. Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio:common: ST_SENSORS_LSM_CHANNELS macro changedDenis CIOCCA2018-12-113-33/+60
| | | | | Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* mediatek: backport ram_console from N alps kernelMoyster2018-12-015-199/+545
|
* mediatek: battery: fix uV/mV batt_volMoyster2018-12-011-1/+1
|
* power: rebase meizu changes against stock battery_common.CMoyster2018-12-011-19/+20
|
* max77819: fix build without has_earlysuspendMister Oyster2018-11-301-40/+8
|
* misc: fix a few Wundef warningsMoyster2018-11-302-4/+4
|
* misc: fix a bunch of 'warning: backslash and newline separated by space'Moyster2018-11-303-41/+41
|
generated by cgit v1.2.3 (git 2.39.1) at 2026-03-14 02:21:13 +0000