- 10 Dec, 2019 19 commits
-
-
Adrian Bunk authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 65a576e2 ] NL80211_TX_POWER_LIMITED was treated as NL80211_TX_POWER_AUTOMATIC, which is the opposite of what should happen and can cause nasty regulatory problems. if/else converted to a switch without default to make gcc warn on unhandled enum values. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit ea893695 ] A recent bugfix added a call to i8042_install_filter but did not add the dependency, leading to possible link errors: drivers/platform/built-in.o: In function `asus_nb_wmi_quirks': asus-nb-wmi.c:(.text+0x23af): undefined reference to `i8042_install_filter' This adds a dependency on SERIO_I8042||SERIO_I8042=n to indicate that we can build the driver when the i8042 driver is disabled, but it cannot be built-in when that is a loadable module. Fixes: b5643539 ("platform/x86: asus-wmi: Filter buggy scan codes on ASUS Q500A") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Kiernan Hager authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit db2582af ] This patch adds support for ALS on the Zenbook UX430UQ to the asus_nb_wmi driver. It also renames "quirk_asus_ux330uak" to "quirk_asus_forceals" because it is now used for more than one model of computer, and should thus have a more general name. Signed-off-by:
Kiernan Hager <kah.listaddress@gmail.com> [andy: massaged commit message, fixed indentation and commas in the code] Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Oleksij Rempel authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit e9b61518 ] some laptops, for example ASUS UX330UAK, have brocken als_get function but working als_set funktion. In this case, ALS will stay turned off. Method (WMNB, 3, Serialized) { ... If (Local0 == 0x53545344) { ... If (IIA0 == 0x00050001) { If (!ALSP) { Return (0x02) } Local0 = (GALS & 0x10) <<<---- bug, should be: (GALS () & 0x10) If (Local0) { Return (0x00050001) } Else { Return (0x00050000) } } ..... If (Local0 == 0x53564544) { ... If (IIA0 == 0x00050001) { Return (ALSC (IIA1)) } ...... Method (GALS, 0, NotSerialized) { Local0 = Zero Local0 |= 0x20 If (ALAE) { Local0 |= 0x10 } Local1 = 0x0A Local1 <<= 0x08 Local0 |= Local1 Return (Local0) } Since it works without problems on Windows I assume ASUS WMI driver for Win never trying to get ALS state, and instead it is setting it by default to ON. This patch will do the same. Turn ALS on by default. Signed-off-by:
Oleksij Rempel <linux@rempel-privat.de> Signed-off-by:
-
Oleksij Rempel authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit aca234f6 ] Asus Zenbook ux31a is providing ACPI0008 interface for ALS (Ambient Light Sensor), which is accessible for OS => Win 7. This sensor can be used with iio/acpi-als driver. Since it is disabled by default, we should use asus-wmi interface to enable it. Signed-off-by:
-
Kai-Chuan Hsieh authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 8023eff1 ] The bluetooth adapter Atheros AR3012 can't be enumerated and make the bluetooth function broken. T: Bus=02 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3362 Rev=00.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb The error is: usb 2-6: device not accepting address 7, error -62 usb usb2-port6: unable to enumerate USB device It is caused by adapter's connected port is mapped to xHC controller, but the xHCI is not supported by the usb device. The output of 'sudo lspci -nnxxx -s 00:14.0': 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04) 00: 86 80 31 9c 06 04 90 02 04 30 03 0c 00 00 00 00 10: 04 00 a0 f7 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 1f 20 30: 00 00 00 00 70 00 00 00 00 00 00 00 0b 01 00 00 40: fd 01 36 80 89 c6 0f 80 00 00 00 00 00 00 00 00 50: 5f 2e ce 0f 00 00 00 00 00 00 00 00 00 00 00 00 60: 30 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 01 80 c2 c1 08 00 00 00 00 00 00 00 00 00 00 00 80: 05 00 87 00 0c a0 e0 fe 00 00 00 00 a1 41 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 01 04 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 0f 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 03 c0 30 00 00 00 00 00 03 0c 00 00 00 00 00 00 d0: f9 01 00 00 f9 01 00 00 0f 00 00 00 0f 00 00 00 e0: 00 08 00 00 00 00 00 00 00 00 00 00 d8 d8 00 00 f0: 00 00 00 00 00 00 00 00 b1 0f 04 08 00 00 00 00 By referencing Intel Platform Controller Hub(PCH) datasheet, the xHC USB 2.0 Port Routing(XUSB2PR) at offset 0xD0-0xD3h decides the setting of mapping the port to EHCI controller or xHC controller. And the port mapped to xHC will enable xHCI during bus resume. The setting of disabling bluetooth adapter's connected port is 0x000001D9. The value can be obtained by few times 1 bit flip operation. The suited configuration should have the 'lsusb -t' result with bluetooth using ehci: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M |__ Port 5: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 5: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M |__ Port 6: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 6: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M Signed-off-by:
Kai-Chuan Hsieh <kai.chiuan@gmail.com> Acked-by:
Corentin Chary <corentin.chary@gmail.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> [andy: resolve merge conflict in asus-wmi.h] Signed-off-by:
-
zino lin authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 999d4376 ] acpi_video0 doesn't work, asus-wmi brightness interface doesn't work, too. So, we use native brightness interface to handle the brightness adjustion, and add quirk_asus_ux303ub. Signed-off-by:
zino lin <linzino7@gmail.com> Acked-by:
-
Oleksij Rempel authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit b5643539 ] Some revisions of the ASUS Q500A series have a keyboard related issue which is reproducible only after Windows with installed ASUS tools is started. In this case the Linux side will have a blocked keyboard or report incorrect or incomplete hotkey events. To make Linux work properly again, a complete power down (unplug power supply and remove battery) is needed. Linux/atkbd after a clean start will get the following code on VOLUME_UP key: {0xe0, 0x30, 0xe0, 0xb0}. After Windows, the same key will generate this codes: {0xe1, 0x23, 0xe0, 0x30, 0xe0, 0xb0}. As result atkdb will be confused by buggy codes. This patch is filtering this buggy code out. https://bugzilla.kernel.org/show_bug.cgi?id=119391Signed-off-by:
-
João Paulo Rechi Vita authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 6b7ff2af ] The Asus Z550MA has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from registering RFKill switches at all for this laptop and allows asus-wireless to drive the LED through the ASHS ACPI device. Signed-off-by:
João Paulo Rechi Vita <jprvita@endlessm.com> Reported-by:
Ming Shuo Chiu <chiu@endlessm.com> Reviewed-by:
-
João Paulo Rechi Vita authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 02db9ff7 ] The Asus U303LB has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from registering RFKill switches at all for this laptop and allows asus-wireless to drive the LED through the ASHS ACPI device. Signed-off-by:
Mousou Yuu <guogaishiwo@gmail.com> Reviewed-by:
-
João Paulo Rechi Vita authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 2d735244 ] The Asus N552VW has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from registering RFKill switches at all for this laptop and allows asus-wireless to drive the LED through the ASHS ACPI device. Signed-off-by:
-
João Paulo Rechi Vita authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit a961a285 ] The Asus X456UF has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from registering RFKill switches at all for this laptop and allows asus-wireless to drive the LED through the ASHS ACPI device. This laptop already has a quirk for setting WAPF=4, so this commit creates a new quirk, quirk_no_rfkill_wapf4, which both disables rfkill and sets WAPF=4. Signed-off-by:
Carlo Caione <carlo@endlessm.com> Reviewed-by:
-
João Paulo Rechi Vita authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit a977e59c ] Some Asus laptops that have an airplane-mode indicator LED, also have the WMI WLAN user bit set, and the following bits in their DSDT: Scope (_SB) { (...) Device (ATKD) { (...) Method (WMNB, 3, Serialized) { (...) If (LEqual (IIA0, 0x00010002)) { OWGD (IIA1) Return (One) } } } } So when asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, it drives the airplane-mode indicator LED (through the call to OWGD) in an inverted fashion: the LED is ON when airplane mode is OFF (since wlan is ON), and vice-versa. This commit creates a quirk to not register a RFKill switch at all for these laptops, to allow the asus-wireless driver to drive the airplane mode LED correctly through the ASHS ACPI device. It also adds a match to that quirk for the Asus X555UB, which is affected by this problem. Signed-off-by:
-
Andrey Ryabinin authored
BugLink: https://bugs.launchpad.net/bugs/1854855 commit 9a63236f upstream. It's possible to hit the WARN_ON_ONCE(page_mapped(page)) in remove_stable_node() when it races with __mmput() and squeezes in between ksm_exit() and exit_mmap(). WARNING: CPU: 0 PID: 3295 at mm/ksm.c:888 remove_stable_node+0x10c/0x150 Call Trace: remove_all_stable_nodes+0x12b/0x330 run_store+0x4ef/0x7b0 kernfs_fop_write+0x200/0x420 vfs_write+0x154/0x450 ksys_write+0xf9/0x1d0 do_syscall_64+0x99/0x510 entry_SYSCALL_64_after_hwframe+0x49/0xbe Remove the warning as there is nothing scary going on. Link: http://lkml.kernel.org/r/20191119131850.5675-1-aryabinin@virtuozzo.com Fixes: cbf86cfe ("ksm: remove old stable nodes more thoroughly") Signed-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Acked-by:
Hugh Dickins <hughd@google.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Joseph Qi authored
BugLink: https://bugs.launchpad.net/bugs/1854855 commit 94b07b6f upstream. This reverts commit 56e94ea1. Commit 56e94ea1 ("fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()") introduces a regression that fail to create directory with mount option user_xattr and acl. Actually the reported NULL pointer dereference case can be correctly handled by loc->xl_ops->xlo_add_entry(), so revert it. Link: http://lkml.kernel.org/r/1573624916-83825-1-git-send-email-joseph.qi@linux.alibaba.com Fixes: 56e94ea1 ("fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()") Signed-off-by:
Joseph Qi <joseph.qi@linux.alibaba.com> Reported-by:
Thomas Voegtle <tv@lio96.de> Acked-by:
Changwei Ge <gechangwei@live.cn> Cc: Jia-Ju Bai <baijiaju1990@gmail.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Gang He <ghe@suse.com> Cc: Jun Piao <piaojun@huawei.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit d658c8f56ec7b3de8051a24afb25da9ba3c388c5 ] The "ivm->vf" variable is a u32, but the problem is that a number of drivers cast it to an int and then forget to check for negatives. An example of this is in the cxgb4 driver. drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c 2890 static int cxgb4_mgmt_get_vf_config(struct net_device *dev, 2891 int vf, struct ifla_vf_info *ivi) ^^^^^^ 2892 { 2893 struct port_info *pi = netdev_priv(dev); 2894 struct adapter *adap = pi->adapter; 2895 struct vf_info *vfinfo; 2896 2897 if (vf >= adap->num_vfs) ^^^^^^^^^^^^^^^^^^^ 2898 return -EINVAL; 2899 vfinfo = &adap->vfinfo[vf]; ^^^^^^^^^^^^^^^^^^^^^^^^^^ There are 48 functions affected. drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c:8435 hclge_set_vf_vlan_filter() warn: can 'vfid' underflow 's32min-2147483646' drivers/net/ethernet/freescale/enetc/enetc_pf.c:377 enetc_pf_set_vf_mac() warn: can 'vf' underflow 's32min-2147483646' drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:2899 cxgb4_mgmt_get_vf_config() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:2960 cxgb4_mgmt_set_vf_rate() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3019 cxgb4_mgmt_set_vf_rate() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3038 cxgb4_mgmt_set_vf_vlan() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3086 cxgb4_mgmt_set_vf_link_state() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/chelsio/cxgb/cxgb2.c:791 get_eeprom() warn: can 'i' underflow 's32min-(-4),0,4-s32max' drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:82 bnxt_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:164 bnxt_set_vf_trust() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:186 bnxt_get_vf_config() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:228 bnxt_set_vf_mac() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:264 bnxt_set_vf_vlan() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:293 bnxt_set_vf_bw() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:333 bnxt_set_vf_link_state() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2595 bnx2x_vf_op_prep() warn: can 'vfidx' underflow 's32min-63' drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2595 bnx2x_vf_op_prep() warn: can 'vfidx' underflow 's32min-63' drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2281 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63' drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2285 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63' drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2286 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63' drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2292 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63' drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2297 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63' drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1832 qlcnic_sriov_set_vf_mac() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1864 qlcnic_sriov_set_vf_tx_rate() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1937 qlcnic_sriov_set_vf_vlan() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:2005 qlcnic_sriov_get_vf_config() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:2036 qlcnic_sriov_set_vf_spoofchk() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/emulex/benet/be_main.c:1914 be_get_vf_config() warn: can 'vf' underflow 's32min-65534' drivers/net/ethernet/emulex/benet/be_main.c:1915 be_get_vf_config() warn: can 'vf' underflow 's32min-65534' drivers/net/ethernet/emulex/benet/be_main.c:1922 be_set_vf_tvt() warn: can 'vf' underflow 's32min-65534' drivers/net/ethernet/emulex/benet/be_main.c:1951 be_clear_vf_tvt() warn: can 'vf' underflow 's32min-65534' drivers/net/ethernet/emulex/benet/be_main.c:2063 be_set_vf_tx_rate() warn: can 'vf' underflow 's32min-65534' drivers/net/ethernet/emulex/benet/be_main.c:2091 be_set_vf_link_state() warn: can 'vf' underflow 's32min-65534' drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:2609 ice_set_vf_port_vlan() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3050 ice_get_vf_cfg() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3103 ice_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3181 ice_set_vf_mac() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3237 ice_set_vf_trust() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3286 ice_set_vf_link_state() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:3919 i40e_validate_vf() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:3957 i40e_ndo_set_vf_mac() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4104 i40e_ndo_set_vf_port_vlan() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4263 i40e_ndo_set_vf_bw() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4309 i40e_ndo_get_vf_config() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4371 i40e_ndo_set_vf_link_state() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4441 i40e_ndo_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4441 i40e_ndo_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4504 i40e_ndo_set_vf_trust() warn: can 'vf_id' underflow 's32min-2147483646' Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Davide Caratti authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit f67169fe ] when configuring act_pedit rules, the number of keys is validated only on addition of a new entry. This is not sufficient to avoid hitting a WARN() in the traffic path: for example, it is possible to replace a valid entry with a new one having 0 extended keys, thus causing splats in dmesg like: pedit BUG: index 42 WARNING: CPU: 2 PID: 4054 at net/sched/act_pedit.c:410 tcf_pedit_act+0xc84/0x1200 [act_pedit] [...] RIP: 0010:tcf_pedit_act+0xc84/0x1200 [act_pedit] Code: 89 fa 48 c1 ea 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e ac 00 00 00 48 8b 44 24 10 48 c7 c7 a0 c4 e4 c0 8b 70 18 e8 1c 30 95 ea <0f> 0b e9 a0 fa ff ff e8 00 03 f5 ea e9 14 f4 ff ff 48 89 58 40 e9 RSP: 0018:ffff888077c9f320 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffac2983a2 RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888053927bec RBP: dffffc0000000000 R08: ffffed100a726209 R09: ffffed100a726209 R10: 0000000000000001 R11: ffffed100a726208 R12: ffff88804beea780 R13: ffff888079a77400 R14: ffff88804beea780 R15: ffff888027ab2000 FS: 00007fdeec9bd740(0000) GS:ffff888053900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffdb3dfd000 CR3: 000000004adb4006 CR4: 00000000001606e0 Call Trace: tcf_action_exec+0x105/0x3f0 tcf_classify+0xf2/0x410 __dev_queue_xmit+0xcbf/0x2ae0 ip_finish_output2+0x711/0x1fb0 ip_output+0x1bf/0x4b0 ip_send_skb+0x37/0xa0 raw_sendmsg+0x180c/0x2430 sock_sendmsg+0xdb/0x110 __sys_sendto+0x257/0x2b0 __x64_sys_sendto+0xdd/0x1b0 do_syscall_64+0xa5/0x4e0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7fdeeb72e993 Code: 48 8b 0d e0 74 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 0d d6 2c 00 00 75 13 49 89 ca b8 2c 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 4b cc 00 00 48 89 04 24 RSP: 002b:00007ffdb3de8a18 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055c81972b700 RCX: 00007fdeeb72e993 RDX: 0000000000000040 RSI: 000055c81972b700 RDI: 0000000000000003 RBP: 00007ffdb3dea130 R08: 000055c819728510 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040 R13: 000055c81972b6c0 R14: 000055c81972969c R15: 0000000000000080 Fix this moving the check on 'nkeys' earlier in tcf_pedit_init(), so that attempts to install rules having 0 keys are always rejected with -EINVAL. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Davide Caratti <dcaratti@redhat.com> Signed-off-by:
-
Martin Habets authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 723eb536 ] The workqueue only exists for the primary PF. For other functions we hit a WARN_ON in kernel/workqueue.c. Fixes: 7c236c43 ("sfc: Add support for IEEE-1588 PTP") Signed-off-by:
Martin Habets <mhabets@solarflare.com> Signed-off-by:
-
Luigi Rizzo authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 34e59836 ] ethtool expects ETHTOOL_GRXCLSRLALL to set ethtool_rxnfc->data with the total number of entries in the rx classifier table. Surprisingly, mlx4 is missing this part (in principle ethtool could still move forward and try the insert). Tested: compiled and run command: phh13:~# ethtool -N eth1 flow-type udp4 queue 4 Added rule with ID 255 Signed-off-by:
Luigi Rizzo <lrizzo@google.com> Reviewed-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
- 03 Dec, 2019 21 commits
-
-
Kleber Sacilotto de Souza authored
Signed-off-by: -
Kleber Sacilotto de Souza authored
BugLink: https://bugs.launchpad.net/bugs/1854835 Properties: no-test-build Signed-off-by:
-
qize wang authored
mwifiex_process_tdls_action_frame() without checking the incoming tdls infomation element's vality before use it, this may cause multi heap buffer overflows. Fix them by putting vality check before use it. Signed-off-by:
qize wang <wangqize888888888@gmail.com> CVE-2019-14901 (backported from https://patchwork.kernel.org/patch/11257535/) [smb: drop marvell subdirectory from path, plus manual context adjustments] Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Andrea Righi <andrea.righi@canonical.com> Signed-off-by:
-
Wen Huang authored
add_ie_rates() copys rates without checking the length in bss descriptor from remote AP.when victim connects to remote attacker, this may trigger buffer overflow. lbs_ibss_join_existing() copys rates without checking the length in bss descriptor from remote IBSS node.when victim connects to remote attacker, this may trigger buffer overflow. Fix them by putting the length check before performing copy. This fix addresses CVE-2019-14896 and CVE-2019-14897. Signed-off-by:
Wen Huang <huangwenabc@gmail.com> CVE-2019-14896 CVE-2019-14897 (backported from https://patchwork.kernel.org/patch/11257187/) [smb: drop marvell subdirectory from path] Signed-off-by:
-
Wen Huang authored
mwifiex_process_country_ie() function parse elements of bss descriptor in beacon packet. When processing WLAN_EID_COUNTRY element, there is no upper limit check for country_ie_len before calling memcpy. The destination buffer domain_info->triplet is an array of length MWIFIEX_MAX_TRIPLET_802_11D(83). The remote attacker can build a fake AP with the same ssid as real AP, and send malicous beacon packet with long WLAN_EID_COUNTRY elemen (country_ie_len > 83). Attacker can force STA connect to fake AP on a different channel. When the victim STA connects to fake AP, will trigger the heap buffer overflow. Fix this by checking for length and if found invalid, don not connect to the AP. This fix addresses CVE-2019-14895. Reported-by:
Ganapathi Bhat <gbhat@marvell.com> CVE-2019-14895 (backported from https://patchwork.kernel.org/patch/11256477/) [smb: drop marvell subdirectory from path] Signed-off-by:
-
Michael Ellerman authored
BugLink: https://bugs.launchpad.net/bugs/1853142 commit af2e8c68 upstream. On some systems that are vulnerable to Spectre v2, it is up to software to flush the link stack (return address stack), in order to protect against Spectre-RSB. When exiting from a guest we do some house keeping and then potentially exit to C code which is several stack frames deep in the host kernel. We will then execute a series of returns without preceeding calls, opening up the possiblity that the guest could have poisoned the link stack, and direct speculative execution of the host to a gadget of some sort. To prevent this we add a flush of the link stack on exit from a guest. Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> [dja: backport to v4.4, drop P9 support] Signed-off-by:
Daniel Axtens <dja@axtens.net> CVE-2019-18660 Signed-off-by:
Benjamin M Romer <benjamin.romer@canonical.com> Acked-by:
Sultan Alsawaf <sultan.alsawaf@canonical.com> Signed-off-by:
-
Michael Ellerman authored
BugLink: https://bugs.launchpad.net/bugs/1853142 commit 39e72bf9 upstream. In commit ee13cb24 ("powerpc/64s: Add support for software count cache flush"), I added support for software to flush the count cache (indirect branch cache) on context switch if firmware told us that was the required mitigation for Spectre v2. As part of that code we also added a software flush of the link stack (return address stack), which protects against Spectre-RSB between user processes. That is all correct for CPUs that activate that mitigation, which is currently Power9 Nimbus DD2.3. What I got wrong is that on older CPUs, where firmware has disabled the count cache, we also need to flush the link stack on context switch. To fix it we create a new feature bit which is not set by firmware, which tells us we need to flush the link stack. We set that when firmware tells us that either of the existing Spectre v2 mitigations are enabled. Then we adjust the patching code so that if we see that feature bit we enable the link stack flush. If we're also told to flush the count cache in software then we fall through and do that also. On the older CPUs we don't need to do do the software count cache flush, firmware has disabled it, so in that case we patch in an early return after the link stack flush. The naming of some of the functions is awkward after this patch, because they're called "count cache" but they also do link stack. But we'll fix that up in a later commit to ease backporting. This is the fix for CVE-2019-18660. Reported-by:
Anthony Steinhauser <asteinhauser@google.com> Fixes: ee13cb24 ("powerpc/64s: Add support for software count cache flush") Cc: stable@vger.kernel.org # v4.4+ Signed-off-by:
-
Christopher M. Riedl authored
BugLink: https://bugs.launchpad.net/bugs/1853142 commit d8f0e0b0 upstream. Add support for disabling the kernel implemented spectre v2 mitigation (count cache flush on context switch) via the nospectre_v2 and mitigations=off cmdline options. Suggested-by:
Christopher M. Riedl <cmr@informatik.wtf> Reviewed-by:
Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by:
-
Gerald Yang authored
BugLink: https://bugs.launchpad.net/bugs/1848481 Intel's VF drivers such as igbvf and ixgbevf are already available in generic. It makes sense to add i40evf especially for SR-IOV enabled clouds with Intel X710/XXV710/XL710. The module was renamed from i40evf to iavf since kernel 4.20, so there will be a separate SRU for other series Signed-off-by:
Gerald Yang <gerald.yang@canonical.com> Acked-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Current default non-adaptive tx interrupt moderation interval is 196 us. This commit sets it to 0, which is much more sensible as a default value. It can be modified using ethtool -C. Signed-off-by:
Arthur Kiyanovski <akiyano@amazon.com> Reference: https://lore.kernel.org/netdev/1572868728-5211-1-git-send-email-akiyano@amazon.com/Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
Khaled Elmously <khalid.elmously@canonical.com> Acked-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Issue 1: -------- Reproduction steps: 1. sudo ethtool -C eth0 rx-usecs 128 2. sudo ethtool -C eth0 adaptive-rx on 3. sudo ethtool -C eth0 adaptive-rx off 4. ethtool -c eth0 expected output: rx-usecs 128 actual output: rx-usecs 0 Reason for issue: In stage 3, ethtool userspace calls first the ena_get_coalesce() handler to get the current value of all properties, and then the ena_set_coalesce() handler. When ena_get_coalesce() is called the adaptive interrupt moderation is still on. There is an if in the code that returns the rx_coalesce_usecs only if the adaptive interrupt moderation is off. And since it is still on, rx_coalesce_usecs is not set, meaning it stays 0. Solution to issue: Remove this if static interrupt moderation intervals have nothing to do with dynamic ones. Issue 2: -------- Reproduction steps: 1. sudo ethtool -C eth0 rx-usecs 128 2. sudo ethtool -C eth0 adaptive-rx on 3. sudo ethtool -C eth0 rx-usecs 128 4. ethtool -c eth0 expected output: rx-usecs 128 actual output: rx-usecs 0 Reason for issue: In stage 3, when ena_set_coalesce() is called, the handler tests if rx adaptive interrupt moderation is on, and if it is, it returns before getting to the part in the function that sets the rx non-adaptive interrupt moderation interval. Solution to issue: Remove the return from the function when rx adaptive interrupt moderation is on. Additional small fixes in this commit: -------------------------------------- 1. Remove 2 unnecessary comments. 2. Remove 4 unnecesary "{}" in single row if statements. 3. Reorder ena_set_coalesce() to make sense. 4. Change the names of ena_update_tx/rx_rings_intr_moderation() functions to ena_update_tx/rx_rings_nonadaptive_intr_moderation() for clarity. Signed-off-by:
-
Mao Wenan authored
BugLink: https://bugs.launchpad.net/bugs/1853180 If CONFIG_ENA_ETHERNET=y and CONFIG_DIMLIB=n, below erros can be found: drivers/net/ethernet/amazon/ena/ena_netdev.o: In function `ena_dim_work': ena_netdev.c:(.text+0x21cc): undefined reference to `net_dim_get_rx_moderation' ena_netdev.c:(.text+0x21cc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `net_dim_get_rx_moderation' drivers/net/ethernet/amazon/ena/ena_netdev.o: In function `ena_io_poll': ena_netdev.c:(.text+0x7bd4): undefined reference to `net_dim' ena_netdev.c:(.text+0x7bd4): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `net_dim' After commit 282faf61 ("net: ena: switch to dim algorithm for rx adaptive interrupt moderation"), it introduces dim algorithm, which configured by CONFIG_DIMLIB. So, this patch is to select DIMLIB for ENA_ETHERNET. Fixes: 282faf61 ("net: ena: switch to dim algorithm for rx adaptive interrupt moderation") Signed-off-by:
Mao Wenan <maowenan@huawei.com> Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> (cherry picked from commit ff04cfba) Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 ena_dev->intr_moder_rx/tx_interval save the intervals received from the user after dividing them by ena_dev->intr_delay_resolution. Therefore when intr_delay_resolution changes, the code needs to first mutiply intr_moder_rx/tx_interval by the previous intr_delay_resolution to get the value originally given by the user, and only then divide it by the new intr_delay_resolution. Current code does not first multiply intr_moder_rx/tx_interval by the old intr_delay_resolution. This commit fixes it. Also initialize ena_dev->intr_delay_resolution to be 1. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Nonadaptive interrupt moderation intervals are assigned the value set by the user in ethtool -C divided by ena_dev->intr_delay_resolution. Therefore when the user tries to get the nonadaptive interrupt moderation intervals with ethtool -c the code needs to multiply the saved value by ena_dev->intr_delay_resolution. The current code erroneously divides instead of multiplying in ethtool -c. This patch fixes this. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Current implementation always updates the interrupt register with the smoothed_interval of the rx_ring. However this should be done only in case of adaptive interrupt moderation. If non-adaptive interrupt moderation is used, the non-adaptive interrupt moderation interval should be used. This commit fixes that. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Remove previous implementation of adaptive rx interrupt moderation from ena_com files. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Deleted unused 4 fields from struct ena_adapter and their only user ena_restore_ethtool_params(). Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 1. Out of the fields {per_napi_bytes, per_napi_packets} in struct ena_ring, only rx_ring->per_napi_packets are used to determine if napi did work for dim. This commit removes all other uses of these fields. 2. Remove ena_ring->moder_tbl_idx, which is not used by dim. 3. Remove all calls to ena_com_destroy_interrupt_moderation(), since all it did was to destroy the interrupt moderation table, which is removed as part of removing old interrupt moderation code. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Remove code duplication in: ena_com_update_nonadaptive_moderation_interval_tx() ena_com_update_nonadaptive_moderation_interval_rx() functions. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Add driver_supported_features to host_host info which is a new API used to communicate to the device which features are supported by the driver. Add the interrupt_moderation bit to host_info->driver_supported_features and enable it to signal the device that this driver supports interrupt moderation properly. Reserved bits are for features implemented in the future Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 1. Remove old adaptive interrupt moderation code from set/get_coalesce() 2. Add ena_update_rx_rings_intr_moderation() function for updating nonadaptive interrupt moderation intervals similarly to ena_update_tx_rings_intr_moderation(). 3. Remove checks of multiple unsupported received interrupt coalescing parameters. This makes code cleaner and cancels the need to update it every time a new coalescing parameter is invented. Signed-off-by:
-
