BMC/Intel-BMC/linux.git/drivers, branch v4.19.29

driver core: Postpone DMA tear-down until after devres release

2019-03-13T21:02:41+00:00

commit 376991db4b6464e906d699ef07681e2ffa8ab08c upstream. When unbinding the (IOMMU-enabled) R-Car SATA device on Salvator-XS (R-Car H3 ES2.0), in preparation of rebinding against vfio-platform for device pass-through for virtualization: echo ee300000.sata > /sys/bus/platform/drivers/sata_rcar/unbind the kernel crashes with: Unable to handle kernel paging request at virtual address ffffffbf029ffffc Mem abort info: ESR = 0x96000006 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp = 000000007e8c586c [ffffffbf029ffffc] pgd=000000073bfc6003, pud=000000073bfc6003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] SMP Modules linked in: CPU: 0 PID: 1098 Comm: bash Not tainted 5.0.0-rc5-salvator-x-00452-g37596f884f4318ef #287 Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT) pstate: 60400005 (nZCv daif +PAN -UAO) pc : __free_pages+0x8/0x58 lr : __dma_direct_free_pages+0x50/0x5c sp : ffffff801268baa0 x29: ffffff801268baa0 x28: 0000000000000000 x27: ffffffc6f9c60bf0 x26: ffffffc6f9c60bf0 x25: ffffffc6f9c60810 x24: 0000000000000000 x23: 00000000fffff000 x22: ffffff8012145000 x21: 0000000000000800 x20: ffffffbf029fffc8 x19: 0000000000000000 x18: ffffffc6f86c42c8 x17: 0000000000000000 x16: 0000000000000070 x15: 0000000000000003 x14: 0000000000000000 x13: ffffff801103d7f8 x12: 0000000000000028 x11: ffffff8011117604 x10: 0000000000009ad8 x9 : ffffff80110126d0 x8 : ffffffc6f7563000 x7 : 6b6b6b6b6b6b6b6b x6 : 0000000000000018 x5 : ffffff8011cf3cc8 x4 : 0000000000004000 x3 : 0000000000080000 x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffffffbf029fffc8 Process bash (pid: 1098, stack limit = 0x00000000c38e3e32) Call trace: __free_pages+0x8/0x58 __dma_direct_free_pages+0x50/0x5c arch_dma_free+0x1c/0x98 dma_direct_free+0x14/0x24 dma_free_attrs+0x9c/0xdc dmam_release+0x18/0x20 release_nodes+0x25c/0x28c devres_release_all+0x48/0x4c device_release_driver_internal+0x184/0x1f0 device_release_driver+0x14/0x1c unbind_store+0x70/0xb8 drv_attr_store+0x24/0x34 sysfs_kf_write+0x4c/0x64 kernfs_fop_write+0x154/0x1c4 __vfs_write+0x34/0x164 vfs_write+0xb4/0x16c ksys_write+0x5c/0xbc __arm64_sys_write+0x14/0x1c el0_svc_common+0x98/0x114 el0_svc_handler+0x1c/0x24 el0_svc+0x8/0xc Code: d51b4234 17fffffa a9bf7bfd 910003fd (b9403404) ---[ end trace 8c564cdd3a1a840f ]--- While I've bisected this to commit e8e683ae9a736407 ("iommu/of: Fix probe-deferral"), and reverting that commit on post-v5.0-rc4 kernels does fix the problem, this turned out to be a red herring. On arm64, arch_teardown_dma_ops() resets dev->dma_ops to NULL. Hence if a driver has used a managed DMA allocation API, the allocated DMA memory will be freed using the direct DMA ops, while it may have been allocated using a custom DMA ops (iommu_dma_ops in this case). Fix this by reversing the order of the calls to devres_release_all() and arch_teardown_dma_ops(). Signed-off-by: Geert Uytterhoeven Acked-by: Christoph Hellwig Reviewed-by: Rafael J. Wysocki Cc: stable Reviewed-by: Robin Murphy [rm: backport for 4.12-4.19 - kernels before 5.0 will not see the crash above, but may get silent memory corruption instead] Signed-off-by: Robin Murphy Signed-off-by: Greg Kroah-Hartman

ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom

2019-03-13T21:02:40+00:00

commit ce938231bd3b1d7af3cbd8836f084801090470e1 upstream. ath9k_of_init() function[0] was initially written on the assumption that if someone had an explicit ath9k OF node that "there must be something wrong, why would someone add an OF node if everything is fine"[1] (Quoting Martin Blumenstingl ) "it turns out it's not that simple. with your requirements I'm now aware of two use-cases where the current code in ath9k_of_init() doesn't work without modifications"[1] The "your requirements" Martin speaks of is the result of the fact that I have a device (PowerCloud Systems CR5000) has some kind of default - not unique mac address - set and requires to set the correct MAC address via mac-address devicetree property, however: "some cards come with a physical EEPROM chip [or OTP] so "qca,no-eeprom" should not be set (your use-case). in this case AH_USE_EEPROM should be set (which is the default when there is no OF node)"[1] The other use case is: the firmware on some PowerMac G5 seems to add a OF node for the ath9k card automatically. depending on the EEPROM on the card AH_NO_EEP_SWAP should be unset (which is the default when there is no OF node). see [3] After this patch to ath9k_of_init() the new behavior will be: if there's no OF node then everything is the same as before if there's an empty OF node then ath9k will use the hardware EEPROM (before ath9k would fail to initialize because no EEPROM data was provided by userspace) if there's an OF node with only a MAC address then ath9k will use the MAC address and the hardware EEPROM (see the case above) with "qca,no-eeprom" EEPROM data from userspace will be requested. the behavior here will not change [1] Martin provides additional background on EEPROM swapping[1]. Thanks to Christian Lamparter for all his help on troubleshooting this issue and the basis for this patch. [0]https://elixir.bootlin.com/linux/v4.20-rc7/source/drivers/net/wireless/ath/ath9k/init.c#L615 [1]https://github.com/openwrt/openwrt/pull/1645#issuecomment-448027058 [2]https://github.com/openwrt/openwrt/pull/1613 [3]https://patchwork.kernel.org/patch/10241731/ Fixes: 138b41253d9c ("ath9k: parse the device configuration from an OF node") Reviewed-by: Martin Blumenstingl Tested-by: Martin Blumenstingl Signed-off-by: Daniel F. Dickinson Signed-off-by: Kalle Valo Cc: Christian Lamparter Signed-off-by: Greg Kroah-Hartman

staging: erofs: keep corrupted fs from crashing kernel in erofs_namei()

2019-03-13T21:02:40+00:00

commit 419d6efc50e94bcf5d6b35cd8c71f79edadec564 upstream. As Al pointed out, " ... and while we are at it, what happens to unsigned int nameoff = le16_to_cpu(de[mid].nameoff); unsigned int matched = min(startprfx, endprfx); struct qstr dname = QSTR_INIT(data + nameoff, unlikely(mid >= ndirents - 1) ? maxsize - nameoff : le16_to_cpu(de[mid + 1].nameoff) - nameoff); /* string comparison without already matched prefix */ int ret = dirnamecmp(name, &dname, &matched); if le16_to_cpu(de[...].nameoff) is not monotonically increasing? I.e. what's to prevent e.g. (unsigned)-1 ending up in dname.len? Corrupted fs image shouldn't oops the kernel.. " Revisit the related lookup flow to address the issue. Fixes: d72d1ce60174 ("staging: erofs: add namei functions") Cc: # 4.19+ Suggested-by: Al Viro Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman

staging: erofs: fix race of initializing xattrs of a inode at the same time

2019-03-13T21:02:40+00:00

commit 62dc45979f3f8cb0ea67302a93bff686f0c46c5a upstream. In real scenario, there could be several threads accessing xattrs of the same xattr-uninitialized inode, and init_inode_xattrs() almost at the same time. That's actually an unexpected behavior, this patch closes the race. Fixes: b17500a0fdba ("staging: erofs: introduce xattr & acl support") Cc: # 4.19+ Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman

staging: erofs: fix memleak of inode's shared xattr array

2019-03-13T21:02:40+00:00

From: Sheng Yong commit 3b1b5291f79d040d549d7c746669fc30e8045b9b upstream. If it fails to read a shared xattr page, the inode's shared xattr array is not freed. The next time the inode's xattr is accessed, the previously allocated array is leaked. Signed-off-by: Sheng Yong Fixes: b17500a0fdba ("staging: erofs: introduce xattr & acl support") Cc: # 4.19+ Reviewed-by: Gao Xiang Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman

staging: erofs: fix fast symlink w/o xattr when fs xattr is on

2019-03-13T21:02:40+00:00

commit 7077fffcb0b0b65dc75e341306aeef4d0e7f2ec6 upstream. Currently, this will hit a BUG_ON for these symlinks as follows: - kernel message ------------[ cut here ]------------ kernel BUG at drivers/staging/erofs/xattr.c:59! SMP PTI CPU: 1 PID: 1170 Comm: getllxattr Not tainted 4.20.0-rc6+ #92 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 RIP: 0010:init_inode_xattrs+0x22b/0x270 Code: 48 0f 45 ea f0 ff 4d 34 74 0d 41 83 4c 24 e0 01 31 c0 e9 00 fe ff ff 48 89 ef e8 e0 31 9e ff eb e9 89 e8 e9 ef fd ff ff 0f 0$ <0f> 0b 48 89 ef e8 fb f6 9c ff 48 8b 45 08 a8 01 75 24 f0 ff 4d 34 RSP: 0018:ffffa03ac026bdf8 EFLAGS: 00010246 ------------[ cut here ]------------ ... Call Trace: erofs_listxattr+0x30/0x2c0 ? selinux_inode_listxattr+0x5a/0x80 ? kmem_cache_alloc+0x33/0x170 ? security_inode_listxattr+0x27/0x40 listxattr+0xaf/0xc0 path_listxattr+0x5a/0xa0 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ... ---[ end trace 3c24b49408dc0c72 ]--- Fix it by checking ->xattr_isize in init_inode_xattrs(), and it also fixes improper return value -ENOTSUPP (it should be -ENODATA if xattr is enabled) for those inodes. Fixes: b17500a0fdba ("staging: erofs: introduce xattr & acl support") Cc: # 4.19+ Reported-by: Li Guifu Tested-by: Li Guifu Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman

staging: erofs: add error handling for xattr submodule

2019-03-13T21:02:40+00:00

commit cadf1ccf1b0021d0b7a9347e102ac5258f9f98c8 upstream. This patch enhances the missing error handling code for xattr submodule, which improves the stability for the rare cases. Reviewed-by: Chao Yu Signed-off-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman

scsi: aacraid: Fix missing break in switch statement

2019-03-13T21:02:39+00:00

commit 5e420fe635813e5746b296cfc8fff4853ae205a2 upstream. Add missing break statement and fix identation issue. This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough. Fixes: 9cb62fa24e0d ("aacraid: Log firmware AIF messages") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

iscsi_ibft: Fix missing break in switch statement

2019-03-13T21:02:39+00:00

commit df997abeebadaa4824271009e2d2b526a70a11cb upstream. Add missing break statement in order to prevent the code from falling through to case ISCSI_BOOT_TGT_NAME, which is unnecessary. This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough. Fixes: b33a84a38477 ("ibft: convert iscsi_ibft module to iscsi boot lib") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

Input: elan_i2c - add id for touchpad found in Lenovo s21e-20

2019-03-13T21:02:39+00:00

commit e154ab69321ce2c54f19863d75c77b4e2dc9d365 upstream. Lenovo s21e-20 uses ELAN0601 in its ACPI tables for the Elan touchpad. Signed-off-by: Vincent Batts Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman