summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-04-24Galileo: dts: use array for motor strength and frequency setting for ↵sandbox/chanwoochoi/tizenjeongsup.jeong33-132/+66
multiple level TODO Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com> [cw00.choi Cherry-pick commit cec6d64be5c6 ("Galileo: dts: use array for motor strength and frequency setting for multiple level") from slp-info.sec.samsung.net and add commit-msg] Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-04-24Motor: use default frequency when platform frequency request is predefined ↵jeongsup.jeong2-21/+22
value, 0 TODO Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com> [cw00.choi: Cherry-pick commit c36cad40a5a2 ("Motor: use default frequency when platform frequency request is predefined value, 0") and add commit-msg] Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-04-24Motor: change motor control parameters for new haptic conceptjeongsup.jeong2-89/+122
TODO Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com> [cw00.choi: Cherry-pick commit 6e38aea914a8 ("Motor: change motor control parameters for new haptic concept") from slp-info.sec.samsung.net and add commit-msg] Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-04-24Motor: add handling freq, overdrive param on ff effectjeongsup.jeong2-56/+102
TODO Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com> [cw00.choi: Apply commit 84d896106285 ("Motor: add handling freq, overdrive param on ff effect") from slp-info.sec.samsung.net with fixing the merge conflit and add commit-msg] Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-04-24Motor: ztm620: add pm_notifierjeongsup.jeong2-90/+185
TODO Change-Id: I149410be0d38924867feea98dd6aa9da48d163b0 Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com> [cw00.choi: Cherry-pick commit 36764495ab76 ("Motor: ztm620: add pm_notifier") from slp-info.sec.samsung.net and add commit-msg] Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-04-01Bluetooth: Add GATT data batchingsubmit/tizen/20200331.090714accepted/tizen/unified/20200402.155630Wootak Jung5-0/+390
GATT batching is a function to reduce the AP's wake every time it receives the GATT data. If user set the timeout or threshold of the number of data packets and correspond to one condition, the collected data will be raised in order. Change-Id: I6968b73bd562a3b7a382f3253bb04dfcef399b57 Signed-off-by: Deokhyun Kim <dukan.kim@samsung.com> Signed-off-by: Wootak Jung <wootak.jung@samsung.com>
2020-03-02Input: tizen_bezel: Change event value of the bezel devicesubmit/tizen/20200323.012640accepted/tizen/unified/20200324.101622lsmin.lee2-19/+22
Until Tizen 5.0, for bezel input device, its event value was in between -2 and 2, but value 1. meant starting movement to counter clockwiseare or clockwise, and value -1, meant moving back to original position, never used. Change event value of the bezel device for Tizen 5.5 and later version. It changes bezel input driver event interface, so user input framework for bezel input should be also changed. Ref: https://review.tizen.org/gerrit/#/c/platform/upstream/enlightenment/+/220346/ Signed-off-by: lsmin.lee <lsmin.lee@samsung.com> [sw0312.kim: adjust commit-msg to public style] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: I1293db138c71d2a5c4f52b827f3a441b47710449
2020-03-02Bluetooth: SMP: fix crash in unpairingsubmit/tizen/20200302.034238accepted/tizen/unified/20200302.125741Matias Karhumaa3-10/+29
[ Upstream commit cb28c306b93b71f2741ce1a5a66289db26715f4d ] In case unpair_device() was called through mgmt interface at the same time when pairing was in progress, Bluetooth kernel module crash was seen. [ 600.351225] general protection fault: 0000 [#1] SMP PTI [ 600.351235] CPU: 1 PID: 11096 Comm: btmgmt Tainted: G OE 4.19.0-rc1+ #1 [ 600.351238] Hardware name: Dell Inc. Latitude E5440/08RCYC, BIOS A18 05/14/2017 [ 600.351272] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth] [ 600.351276] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01 [ 600.351279] RSP: 0018:ffffa9be839b3b50 EFLAGS: 00010246 [ 600.351282] RAX: ffff9c999ac565a0 RBX: ffff9c9996e98c00 RCX: ffff9c999aa28b60 [ 600.351285] RDX: dead000000000200 RSI: 0000000000000010 RDI: ffff9c999e403500 [ 600.351287] RBP: ffffa9be839b3b70 R08: 0000000000000000 R09: ffffffff92a25c00 [ 600.351290] R10: ffffa9be839b3ae8 R11: 0000000000000001 R12: ffff9c995375b800 [ 600.351292] R13: 0000000000000000 R14: ffff9c99619a5000 R15: ffff9c9962a01c00 [ 600.351295] FS: 00007fb2be27c700(0000) GS:ffff9c999e880000(0000) knlGS:0000000000000000 [ 600.351298] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 600.351300] CR2: 00007fb2bdadbad0 CR3: 000000041c328001 CR4: 00000000001606e0 [ 600.351302] Call Trace: [ 600.351325] smp_failure+0x4f/0x70 [bluetooth] [ 600.351345] smp_cancel_pairing+0x74/0x80 [bluetooth] [ 600.351370] unpair_device+0x1c1/0x330 [bluetooth] [ 600.351399] hci_sock_sendmsg+0x960/0x9f0 [bluetooth] [ 600.351409] ? apparmor_socket_sendmsg+0x1e/0x20 [ 600.351417] sock_sendmsg+0x3e/0x50 [ 600.351422] sock_write_iter+0x85/0xf0 [ 600.351429] do_iter_readv_writev+0x12b/0x1b0 [ 600.351434] do_iter_write+0x87/0x1a0 [ 600.351439] vfs_writev+0x98/0x110 [ 600.351443] ? ep_poll+0x16d/0x3d0 [ 600.351447] ? ep_modify+0x73/0x170 [ 600.351451] do_writev+0x61/0xf0 [ 600.351455] ? do_writev+0x61/0xf0 [ 600.351460] __x64_sys_writev+0x1c/0x20 [ 600.351465] do_syscall_64+0x5a/0x110 [ 600.351471] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 600.351474] RIP: 0033:0x7fb2bdb62fe0 [ 600.351477] Code: 73 01 c3 48 8b 0d b8 6e 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 69 c7 2c 00 00 75 10 b8 14 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 de 80 01 00 48 89 04 24 [ 600.351479] RSP: 002b:00007ffe062cb8f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 [ 600.351484] RAX: ffffffffffffffda RBX: 000000000255b3d0 RCX: 00007fb2bdb62fe0 [ 600.351487] RDX: 0000000000000001 RSI: 00007ffe062cb920 RDI: 0000000000000004 [ 600.351490] RBP: 00007ffe062cb920 R08: 000000000255bd80 R09: 0000000000000000 [ 600.351494] R10: 0000000000000353 R11: 0000000000000246 R12: 0000000000000001 [ 600.351497] R13: 00007ffe062cbbe0 R14: 0000000000000000 R15: 0000000000000000 [ 600.351501] Modules linked in: algif_hash algif_skcipher af_alg cmac ipt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat_ipv4 xt_addrtype iptable_filter ip_tables xt_conntrack x_tables nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c br_netfilter bridge stp llc overlay arc4 nls_iso8859_1 dm_crypt intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp dell_laptop kvm_intel crct10dif_pclmul dell_smm_hwmon crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper intel_cstate intel_rapl_perf uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev media hid_multitouch input_leds joydev serio_raw dell_wmi snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic dell_smbios dcdbas sparse_keymap [ 600.351569] snd_hda_intel btusb snd_hda_codec btrtl btbcm btintel snd_hda_core bluetooth(OE) snd_hwdep snd_pcm iwlmvm ecdh_generic wmi_bmof dell_wmi_descriptor snd_seq_midi mac80211 snd_seq_midi_event lpc_ich iwlwifi snd_rawmidi snd_seq snd_seq_device snd_timer cfg80211 snd soundcore mei_me mei dell_rbtn dell_smo8800 mac_hid parport_pc ppdev lp parport autofs4 hid_generic usbhid hid i915 nouveau kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi psmouse ahci sdhci_pci cqhci libahci fb_sys_fops sdhci drm e1000e video wmi [ 600.351637] ---[ end trace e49e9f1df09c94fb ]--- [ 600.351664] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth] [ 600.351666] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01 [ 600.351669] RSP: 0018:ffffa9be839b3b50 EFLAGS: 00010246 [ 600.351672] RAX: ffff9c999ac565a0 RBX: ffff9c9996e98c00 RCX: ffff9c999aa28b60 [ 600.351674] RDX: dead000000000200 RSI: 0000000000000010 RDI: ffff9c999e403500 [ 600.351676] RBP: ffffa9be839b3b70 R08: 0000000000000000 R09: ffffffff92a25c00 [ 600.351679] R10: ffffa9be839b3ae8 R11: 0000000000000001 R12: ffff9c995375b800 [ 600.351681] R13: 0000000000000000 R14: ffff9c99619a5000 R15: ffff9c9962a01c00 [ 600.351684] FS: 00007fb2be27c700(0000) GS:ffff9c999e880000(0000) knlGS:0000000000000000 [ 600.351686] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 600.351689] CR2: 00007fb2bdadbad0 CR3: 000000041c328001 CR4: 00000000001606e0 Crash happened because list_del_rcu() was called twice for smp->ltk. This was possible if unpair_device was called right after ltk was generated but before keys were distributed. In this commit smp_cancel_pairing was refactored to cancel pairing if it is in progress and otherwise just removes keys. Once keys are removed from rcu list, pointers to smp context's keys are set to NULL to make sure removed list items are not accessed later. This commit also adjusts the functionality of mgmt unpair_device() little bit. Previously pairing was canceled only if pairing was in state that keys were already generated. With this commit unpair_device() cancels pairing already in earlier states. Bug was found by fuzzing kernel SMP implementation using Synopsys Defensics. Reported-by: Pekka Oikarainen <pekka.oikarainen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> [dh79.pyun: apply mainline stable linux-4.9.y commit 83e158f93d66 to handle BT crash issue] Signed-off-by: DoHyun Pyun <dh79.pyun@samsung.com> Change-Id: Iaa7196d5bb49fe993ba9ca0bf9b9a1eece7b6200
2020-03-02Bluetooth: Fix missing encryption refresh on Security RequestSzymon Janc1-1/+7
commit 64e759f58f128730b97a3c3a26d283c075ad7c86 upstream. If Security Request is received on connection that is already encrypted with sufficient security master should perform encryption key refresh procedure instead of just ignoring Slave Security Request (Core Spec 5.0 Vol 3 Part H 2.4.6). > ACL Data RX: Handle 3585 flags 0x02 dlen 6 SMP: Security Request (0x0b) len 1 Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09) < HCI Command: LE Start Encryption (0x08|0x0019) plen 28 Handle: 3585 Random number: 0x0000000000000000 Encrypted diversifier: 0x0000 Long term key: 44264272a5c426a9e868f034cf0e69f3 > HCI Event: Command Status (0x0f) plen 4 LE Start Encryption (0x08|0x0019) ncmd 1 Status: Success (0x00) > HCI Event: Encryption Key Refresh Complete (0x30) plen 3 Status: Success (0x00) Handle: 3585 Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [dh79.pyun: apply mainline stable linux-4.9.y commit 24382a60331d to handle BT issue] Signed-off-by: DoHyun Pyun <dh79.pyun@samsung.com> Change-Id: Ifb94f389253d8515bcc4676fffcfd73c09f1242c
2020-01-02arm64: relocatable: fix inconsistencies in linker script and optionssubmit/tizen/20200102.014302accepted/tizen/unified/20200102.220848Ard Biesheuvel2-5/+6
commit 3bbd3db86470c701091fb1d67f1fab6621debf50 upstream. readelf complains about the section layout of vmlinux when building with CONFIG_RELOCATABLE=y (for KASLR): readelf: Warning: [21]: Link field (0) should index a symtab section. readelf: Warning: [21]: Info field (0) should index a relocatable section. Also, it seems that our use of '-pie -shared' is contradictory, and thus ambiguous. In general, the way KASLR is wired up at the moment is highly tailored to how ld.bfd happens to implement (and conflate) PIE executables and shared libraries, so given the current effort to support other toolchains, let's fix some of these issues as well. - Drop the -pie linker argument and just leave -shared. In ld.bfd, the differences between them are unclear (except for the ELF type of the produced image [0]) but lld chokes on seeing both at the same time. - Rename the .rela output section to .rela.dyn, as is customary for shared libraries and PIE executables, so that it is not misidentified by readelf as a static relocation section (producing the warnings above). - Pass the -z notext and -z norelro options to explicitly instruct the linker to permit text relocations, and to omit the RELRO program header (which requires a certain section layout that we don't adhere to in the kernel). These are the defaults for current versions of ld.bfd. - Discard .eh_frame and .gnu.hash sections to avoid them from being emitted between .head.text and .text, screwing up the section layout. These changes only affect the ELF image, and produce the same binary image. [0] b9dce7f1ba01 ("arm64: kernel: force ET_DYN ELF type for ...") Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Peter Smith <peter.smith@linaro.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [ Found solution for Tizen 6.0 toolchain by Mikhail Kashkarov <m.kashkarov@partner.samsung.com> ] [sw0312.kim: backport stable linux-4.14.y commit f21ce3cdff2f for gcc 9 built image] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: I0ddfedad20188dcd9d7b416370e95d175b595db0
2020-01-02arm64: remove no-op -p linker flagGreg Hackmann1-1/+1
(commit 1a381d4a0a9a0f999a13faaba22bf6b3fc80dcb9 upstream) Linking the ARM64 defconfig kernel with LLVM lld fails with the error: ld.lld: error: unknown argument: -p Makefile:1015: recipe for target 'vmlinux' failed Without this flag, the ARM64 defconfig kernel successfully links with lld and boots on Dragonboard 410c. After digging through binutils source and changelogs, it turns out that -p is only relevant to ancient binutils installations targeting 32-bit ARM. binutils accepts -p for AArch64 too, but it's always been undocumented and silently ignored. A comment in ld/emultempl/aarch64elf.em explains that it's "Only here for backwards compatibility". Since this flag is a no-op on ARM64, we can safely drop it. Acked-by: Will Deacon <will.deacon@arm.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org> [sw0312.kim: cherry-pick stable linux-4.9.y commit 272991176af2 for gcc 9 build] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: I47c82851c886f2b1d3af3e65ef7e7131ea877b62
2020-01-02arm64: prevent regressions in compressed kernel image size when upgrading to ↵Nick Desaulniers1-2/+6
binutils 2.27 [ Upstream commit fd9dde6abcb9bfe6c6bee48834e157999f113971 ] Upon upgrading to binutils 2.27, we found that our lz4 and gzip compressed kernel images were significantly larger, resulting is 10ms boot time regressions. As noted by Rahul: "aarch64 binaries uses RELA relocations, where each relocation entry includes an addend value. This is similar to x86_64. On x86_64, the addend values are also stored at the relocation offset for relative relocations. This is an optimization: in the case where code does not need to be relocated, the loader can simply skip processing relative relocations. In binutils-2.25, both bfd and gold linkers did this for x86_64, but only the gold linker did this for aarch64. The kernel build here is using the bfd linker, which stored zeroes at the relocation offsets for relative relocations. Since a set of zeroes compresses better than a set of non-zero addend values, this behavior was resulting in much better lz4 compression. The bfd linker in binutils-2.27 is now storing the actual addend values at the relocation offsets. The behavior is now consistent with what it does for x86_64 and what gold linker does for both architectures. The change happened in this upstream commit: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f56df9d0d5ad89806c24e71f296576d82344613 Since a bunch of zeroes got replaced by non-zero addend values, we see the side effect of lz4 compressed image being a bit bigger. To get the old behavior from the bfd linker, "--no-apply-dynamic-relocs" flag can be used: $ LDFLAGS="--no-apply-dynamic-relocs" make With this flag, the compressed image size is back to what it was with binutils-2.25. If the kernel is using ASLR, there aren't additional runtime costs to --no-apply-dynamic-relocs, as the relocations will need to be applied again anyway after the kernel is relocated to a random address. If the kernel is not using ASLR, then presumably the current default behavior of the linker is better. Since the static linker performed the dynamic relocs, and the kernel is not moved to a different address at load time, it can skip applying the relocations all over again." Some measurements: $ ld -v GNU ld (binutils-2.25-f3d35cf6) 2.25.51.20141117 ^ $ ls -l vmlinux -rwxr-x--- 1 ndesaulniers eng 300652760 Oct 26 11:57 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 16932627 Oct 26 11:57 Image.lz4-dtb $ ld -v GNU ld (binutils-2.27-53dd00a1) 2.27.0.20170315 ^ pre patch: $ ls -l vmlinux -rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 11:43 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 18159474 Oct 26 11:43 Image.lz4-dtb post patch: $ ls -l vmlinux -rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 12:06 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 16932466 Oct 26 12:06 Image.lz4-dtb By Siqi's measurement w/ gzip: binutils 2.27 with this patch (with --no-apply-dynamic-relocs): Image 41535488 Image.gz 13404067 binutils 2.27 without this patch (without --no-apply-dynamic-relocs): Image 41535488 Image.gz 14125516 Any compression scheme should be able to get better results from the longer runs of zeros, not just GZIP and LZ4. 10ms boot time savings isn't anything to get excited about, but users of arm64+compression+bfd-2.27 should not have to pay a penalty for no runtime improvement. Reported-by: Gopinath Elanchezhian <gelanchezhian@google.com> Reported-by: Sindhuri Pentyala <spentyala@google.com> Reported-by: Wei Wang <wvw@google.com> Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Suggested-by: Rahul Chaudhry <rahulchaudhry@google.com> Suggested-by: Siqi Lin <siqilin@google.com> Suggested-by: Stephen Hines <srhines@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> [will: added comment to Makefile] Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [sw0312.kim: cherry-pick stable linux-4.9.y commit b7ada2c0ea29 for gcc 9 build] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: I1b1afff5c639be9ab429f23b38b144c9cc8a7240
2019-12-31arm64: Don't unconditionally add -Wno-psabi to KBUILD_CFLAGSsubmit/tizen/20191231.055421accepted/tizen/unified/20200101.120530Nathan Chancellor1-1/+1
This is a GCC only option, which warns about ABI changes within GCC, so unconditionally adding it breaks Clang with tons of: warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option] and link time failures: ld.lld: error: undefined symbol: __efistub___stack_chk_guard >>> referenced by arm-stub.c:73 (/home/nathan/cbl/linux/drivers/firmware/efi/libstub/arm-stub.c:73) >>> arm-stub.stub.o:(__efistub_install_memreserve_table) in archive ./drivers/firmware/efi/libstub/lib.a These failures come from the lack of -fno-stack-protector, which is added via cc-option in drivers/firmware/efi/libstub/Makefile. When an unknown flag is added to KBUILD_CFLAGS, clang will noisily warn that it is ignoring the option like above, unlike gcc, who will just error. $ echo "int main() { return 0; }" > tmp.c $ clang -Wno-psabi tmp.c; echo $? warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option] 1 warning generated. 0 $ gcc -Wsometimes-uninitialized tmp.c; echo $? gcc: error: unrecognized command line option ‘-Wsometimes-uninitialized’; did you mean ‘-Wmaybe-uninitialized’? 1 For cc-option to work properly with clang and behave like gcc, -Werror is needed, which was done in commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to support clang"). $ clang -Werror -Wno-psabi tmp.c; echo $? error: unknown warning option '-Wno-psabi' [-Werror,-Wunknown-warning-option] 1 As a consequence of this, when an unknown flag is unconditionally added to KBUILD_CFLAGS, it will cause cc-option to always fail and those flags will never get added: $ clang -Werror -Wno-psabi -fno-stack-protector tmp.c; echo $? error: unknown warning option '-Wno-psabi' [-Werror,-Wunknown-warning-option] 1 This can be seen when compiling the whole kernel as some warnings that are normally disabled (see below) show up. The full list of flags missing from drivers/firmware/efi/libstub are the following (gathered from diffing .arm64-stub.o.cmd): -fno-delete-null-pointer-checks -Wno-address-of-packed-member -Wframe-larger-than=2048 -Wno-unused-const-variable -fno-strict-overflow -fno-merge-all-constants -fno-stack-check -Werror=date-time -Werror=incompatible-pointer-types -ffreestanding -fno-stack-protector Use cc-disable-warning so that it gets disabled for GCC and does nothing for Clang. Fixes: ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI drift") Link: https://github.com/ClangBuiltLinux/linux/issues/511 Reported-by: Qian Cai <cai@lca.pw> Acked-by: Dave Martin <Dave.Martin@arm.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> [sw0312.kim: backport mainline commit fa63da2ab046 for gcc 9 build] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: I4b6f775dd115a8eb92080c570b7727c143ede17c
2019-12-31arm64: Silence gcc warnings about arch ABI driftDave Martin1-0/+1
Since GCC 9, the compiler warns about evolution of the platform-specific ABI, in particular relating for the marshaling of certain structures involving bitfields. The kernel is a standalone binary, and of course nobody would be so stupid as to expose structs containing bitfields as function arguments in ABI. (Passing a pointer to such a struct, however inadvisable, should be unaffected by this change. perf and various drivers rely on that.) So these warnings do more harm than good: turn them off. We may miss warnings about future ABI drift, but that's too bad. Future ABI breaks of this class will have to be debugged and fixed the traditional way unless the compiler evolves finer-grained diagnostics. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> [sw0312.kim: backport mainline commit ebcc5928c5d9 for gcc 9 build] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: Ic7620fb77291c55e8237495d99285c8a14eac326
2019-12-27Input: zxt_ztm620_ts: Remove possible overflow by using strlcat()Seung-Woo Kim1-117/+63
The strncat() from a buffer to other buffer with same size can make overflow. Remove the possible overflow by replacing strncat() to strlcat(). Change-Id: I2d98f7548c87e048726bf4c3dc7ed942270565d9 Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
2019-12-27Input: zxt_ztm620_ts: Repalce meaningless strncat() to strcat()Seung-Woo Kim1-26/+26
The strncat() with length from strlen() of copied string is completely meaningless. Just replace the usage of strncat() to strcat(). Change-Id: Ibdd75a6cc7d5e2f9e80f20535f7d61b278fc29a3 Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
2019-12-27soc: samsung: cal-if: fix not to calculate array size from nullSeung-Woo Kim4-299/+327
Calculating array size from null causes sizeof-pointer-div warning. Fix not to calculate array size from null by adding pll macro without NULL array. Change-Id: I7002376523bd42cedaebc6443135c8410e5a1c46 Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
2019-12-27video: fbdev: exynos: dpu9110: panel: s6e36w3x01: remove buffer overflowSeung-Woo Kim1-1/+1
The memcpy to buffer has out of bounds for array. Remove the buffer overflow for by adding additional array length. Change-Id: I0aa5974fd39a6a7f705740ce1dcbf6ce15c2e935 Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
2019-12-27AsoC: speedy: fix sizeof-pointer-memaccess for strncpy()Seung-Woo Kim1-1/+1
The strncpy() is done with sizeof() for source. Fix warning from sizeof-pointer-memaccess by replacing sizeof() for destination. Change-Id: I2e4bbdda84e90391d8767358ebebb12bdc10154e Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
2019-12-27net: bcmdhd: Fix string concatenate with strncat()Seung-Woo Kim1-1/+1
There is stringop-overflow warning to use strncat and bound check for buffer size for the string is already done. Fix string concatenate with strncat() by replacing with strcat(). Change-Id: I8c009e4d76f5044601bacd596d4ca872bb69fd1f Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
2019-12-27arm64: tizen_tw3_defconfig: Enable CONFIG_CRYPTO_CCMAnupam Roy1-3/+4
Enable CONFIG_CRYPTO_CCM config option for using AEAD-AES_CCM encryption. AEAD socket with AES_CCM cipher type is used by Bluetooth Mesh functionality for encryption & decryption. Change-Id: I8b940288c2763ebc3007d5a419329f392b41ad8b Signed-off-by: Anupam Roy <anupam.r@samsung.com>
2019-12-27arm64: tizen_tw3_defconfig: sync USB_CONFIGFS related config optionsSeung-Woo Kim1-0/+19
After CONFIG_USB_CONFIGFS is enabled, defconfig was not fully updated. Sync realted config options. Change-Id: I96c99483933f0c84bd48b0f67110a469bf245ef7 Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
2019-12-23cfg80211: Fix array-bounds warning in fragment copyMatthias Kaehlcke1-3/+3
commit aa1702dd162f420bf85ecef0c77686ef0dbc1496 upstream. __ieee80211_amsdu_copy_frag intentionally initializes a pointer to array[-1] to increment it later to valid values. clang rightfully generates an array-bounds warning on the initialization statement. Initialize the pointer to array[0] and change the algorithm from increment before to increment after consume. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Cc: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [sw0312.kim: cherry-pick stable linux-4.9.y commit 4bb797afd7ba for gcc 9 build] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: Ibb581c74dc67fcc867f7fa58d20cb1b225caa852
2019-12-23ip_tunnel: Fix name string concatenate in __ip_tunnel_create()Sultan Alsawaf1-2/+2
commit 000ade8016400d93b4d7c89970d96b8c14773d45 upstream. By passing a limit of 2 bytes to strncat, strncat is limited to writing fewer bytes than what it's supposed to append to the name here. Since the bounds are checked on the line above this, just remove the string bounds checks entirely since they're unneeded. Signed-off-by: Sultan Alsawaf <sultanxda@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [sw0312.kim: cherry-pick stable linux-4.9.y commit 5569c10858be for gcc 9 build] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: Ida4f04d469c4d91f12faa5fe46bd443c43bfe333
2019-12-23tracing: Silence GCC 9 array bounds warningMiguel Ojeda3-10/+20
commit 0c97bf863efce63d6ab7971dad811601e6171d2f upstream. Starting with GCC 9, -Warray-bounds detects cases when memset is called starting on a member of a struct but the size to be cleared ends up writing over further members. Such a call happens in the trace code to clear, at once, all members after and including `seq` on struct trace_iterator: In function 'memset', inlined from 'ftrace_dump' at kernel/trace/trace.c:8914:3: ./include/linux/string.h:344:9: warning: '__builtin_memset' offset [8505, 8560] from the object at 'iter' is out of the bounds of referenced subobject 'seq' with type 'struct trace_seq' at offset 4368 [-Warray-bounds] 344 | return __builtin_memset(p, c, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ In order to avoid GCC complaining about it, we compute the address ourselves by adding the offsetof distance instead of referring directly to the member. Since there are two places doing this clear (trace.c and trace_kdb.c), take the chance to move the workaround into a single place in the internal header. Link: http://lkml.kernel.org/r/20190523124535.GA12931@gmail.com Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> [ Removed unnecessary parenthesis around "iter" ] Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [sw0312.kim: cherry-pick stable linux-4.9.y commit 2e41539ee26f for gcc 9 build] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: I82d986a1e1a6a447c2fd3b5c3af3145192e72748
2019-12-23gcc-9: silence 'address-of-packed-member' warningLinus Torvalds1-0/+1
commit 6f303d60534c46aa1a239f29c321f95c83dda748 upstream. We already did this for clang, but now gcc has that warning too. Yes, yes, the address may be unaligned. And that's kind of the point. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [sw0312.kim: cherry-pick stable linux-4.9.y commit 7601d81506ef for gcc 9 build] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: Id774c5d5a37b7761a7792be0fedc7282f19d45f8
2019-12-23unifdef: use memcpy instead of strncpyLinus Torvalds1-2/+2
commit 38c7b224ce22c25fed04007839edf974bd13439d upstream. New versions of gcc reasonably warn about the odd pattern of strncpy(p, q, strlen(q)); which really doesn't make sense: the strncpy() ends up being just a slow and odd way to write memcpy() in this case. There was a comment about _why_ the code used strncpy - to avoid the terminating NUL byte, but memcpy does the same and avoids the warning. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [sw0312.kim: cherry-pick stable linux-4.9.y commit 0d4a2de44713 for gcc 9 build] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: I3adb0d708af7d8a55216d6c81d1e691b8d30e8c1
2019-12-23arm64, vdso: Define vdso_{start,end} as arrayKees Cook1-5/+5
Commit dbbb08f500d6146398b794fdc68a8e811366b451 upstream. Adjust vdso_{start|end} to be char arrays to avoid compile-time analysis that flags "too large" memcmp() calls with CONFIG_FORTIFY_SOURCE. Cc: Jisheng Zhang <jszhang@marvell.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Suggested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org> [sw0312.kim: cherry-pick stable linux-4.9.y commit 830d3a71e1ce for gcc 9 build] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: I32aa68e1365d0389f05ab456f82b3b72f10b60da
2019-12-23Kbuild: suppress packed-not-aligned warning for default setting onlyXiongfeng Wang1-0/+3
commit 321cb0308a9e76841394b4bbab6a1107cfedbae0 upstream. gcc-8 reports many -Wpacked-not-aligned warnings. The below are some examples. ./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct ceph_entity_addr' is less than 8 [-Wpacked-not-aligned] } __attribute__ ((packed)); ./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct ceph_entity_addr' is less than 8 [-Wpacked-not-aligned] } __attribute__ ((packed)); ./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct ceph_entity_addr' is less than 8 [-Wpacked-not-aligned] } __attribute__ ((packed)); This patch suppresses this kind of warnings for default setting. Signed-off-by: Xiongfeng Wang <xiongfeng.wang@linaro.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [sw0312.kim: cherry-pick stable linux-4.9.y commit dfb64b8c3d26 for gcc 9 build] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: I9fe83e410fbf2ddd0ce52842ed1f5c24efce260a
2019-12-23disable stringop truncation warnings for nowStephen Rothwell1-0/+3
commit 217c3e0196758662aa0429863b09d1c13da1c5d6 upstream. They are too noisy Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [sw0312.kim: cherry-pick stable linux-4.9.y commit 5e2669c978b2 for gcc 9 build] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: I57286951ce59491105cc89ec99277a180b3c7478
2019-12-23kconfig: Avoid format overflow warning from GCC 8.1Nathan Chancellor1-1/+1
commit 2ae89c7a82ea9d81a19b4fc2df23bef4b112f24e upstream. In file included from scripts/kconfig/zconf.tab.c:2485: scripts/kconfig/confdata.c: In function ‘conf_write’: scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(newname, "%s%s", dirname, basename); ^~ scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes sprintf(newname, "%s%s", dirname, basename); ^~~~~~ scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097 sprintf(newname, "%s%s", dirname, basename); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~~~~~~~~~ scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097 sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Increase the size of tmpname and newname to make GCC happy. Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [sw0312.kim: cherry-pick stable linux-4.9.y commit 1ec1dfba0835 for gcc 9 build] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: I7ebafa60f7703732795fe226b1c1eb8c39a27c28
2019-12-23exec: avoid gcc-8 warning for get_task_commArnd Bergmann2-5/+8
commit 3756f6401c302617c5e091081ca4d26ab604bec5 upstream. gcc-8 warns about using strncpy() with the source size as the limit: fs/exec.c:1223:32: error: argument to 'sizeof' in 'strncpy' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess] This is indeed slightly suspicious, as it protects us from source arguments without NUL-termination, but does not guarantee that the destination is terminated. This keeps the strncpy() to ensure we have properly padded target buffer, but ensures that we use the correct length, by passing the actual length of the destination buffer as well as adding a build-time check to ensure it is exactly TASK_COMM_LEN. There are only 23 callsites which I all reviewed to ensure this is currently the case. We could get away with doing only the check or passing the right length, but it doesn't hurt to do both. Link: http://lkml.kernel.org/r/20171205151724.1764896-1-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: Kees Cook <keescook@chromium.org> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Ingo Molnar <mingo@kernel.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Serge Hallyn <serge@hallyn.com> Cc: James Morris <james.l.morris@oracle.com> Cc: Aleksa Sarai <asarai@suse.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Frederic Weisbecker <frederic@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> 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> [sw0312.kim: cherry-pick stable linux-4.9.y commit b9dd13488acb for gcc 9 build] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: I1d5a998bca751044ef2ac01e569ee500047beb0f
2019-12-23turn off -Wattribute-aliasArnd Bergmann1-0/+1
Starting with gcc-8.1, we get a warning about all system call definitions, which use an alias between functions with incompatible prototypes, e.g.: In file included from ../mm/process_vm_access.c:19: ../include/linux/syscalls.h:211:18: warning: 'sys_process_vm_readv' alias between functions of incompatible types 'long int(pid_t, const struct iovec *, long unsigned int, const struct iovec *, long unsigned int, long unsigned int)' {aka 'long int(int, const struct iovec *, long unsigned int, const struct iovec *, long unsigned int, long unsigned int)'} and 'long int(long int, long int, long int, long int, long int, long int)' [-Wattribute-alias] asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \ ^~~ ../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx' __SYSCALL_DEFINEx(x, sname, __VA_ARGS__) ^~~~~~~~~~~~~~~~~ ../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx' #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__) ^~~~~~~~~~~~~~~ ../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6' SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec, ^~~~~~~~~~~~~~~ ../include/linux/syscalls.h:215:18: note: aliased declaration here asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \ ^~~ ../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx' __SYSCALL_DEFINEx(x, sname, __VA_ARGS__) ^~~~~~~~~~~~~~~~~ ../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx' #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__) ^~~~~~~~~~~~~~~ ../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6' SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec, This is really noisy and does not indicate a real problem. In the latest mainline kernel, this was addressed by commit bee20031772a ("disable -Wattribute-alias warning for SYSCALL_DEFINEx()"), which seems too invasive to backport. This takes a much simpler approach and just disables the warning across the kernel. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [sw0312.kim: cherry-pick stable linux-4.9.y commit b1a1d9bdb1b5 for gcc 9 build] Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Change-Id: I930f1ed6c9350d8131e363f2feb0a73bee68007b
2019-12-23drm/tgm: tdm_pp: msc: check and adjust src/dest size parametersubmit/tizen/20191223.042319accepted/tizen/unified/20191223.060227Seung-Woo Kim1-0/+32
In msc hw, for both src and dest, image x plus image w should be equal or less than buffer size vsize and image y plus image shou.d be equal or less than buffer size hsize. Otherwise, hw tries to access out of buffer boundary and it causes msc sysmmu page fault. Fix to check and to adjust src/dest size parameter as the hw constraint. Change-Id: Ie6e9d431955e0c369164f2b1f46cf9f17e0b1d8b Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
2019-12-20usb: gadget: f_fs: Give chance to retry malloc for large size bufferDongwoo Lee1-3/+27
The f_fs daemons usually use large size buffer for increasing transfer performance, but it can cause memory allocation failure in case of that buddy space is fragmented. Since this, instead of just returning error in this case, give the chance to retry to allocate memory with a half length in order to prevent daemon crash due to failure of buffer allocation. Change-Id: I2171932b8cb565102d63eb82c114987b85d26ed9 Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
2019-12-17Bluetooth: Enables filter_policy and adv_type set by userAmit Purwar1-2/+11
This patch enables the filter_policy and adv_type in advertisement set by user on MGMT interface using set_advertising_params API. Currently filter policy and adv_type does not get applied on slot 0 during ADV enable. Change-Id: I18b2d5bb1db334f2f008b619503582c5eed29f08 Signed-off-by: Amit Purwar <amit.purwar@samsung.com>
2019-11-26arm64: tizen_tw3_defconfig: Use configfs instead of legacy usb gadgetsubmit/tizen/20191126.032220accepted/tizen/unified/20191127.020253Dongwoo Lee1-4/+6
This patch replaces legacy gadget driver with configfs with CDC ACM, rndis, functionfs support. Change-Id: I8d96a3e95273ab830b1adf045b641024ed4a50a1 Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
2019-11-26usb: gadget: configfs: fix concurrent issue between composite APIsPeter Chen1-5/+105
[ Upstream commit 1a1c851bbd706ea9f3a9756c2d3db28523506d3b ] We meet several NULL pointer issues if configfs_composite_unbind and composite_setup (or composite_disconnect) are running together. These issues occur when do the function switch stress test, the configfs_compsoite_unbind is called from user mode by echo "" to /sys/../UDC entry, and meanwhile, the setup interrupt or disconnect interrupt occurs by hardware. The composite_setup will get the cdev from get_gadget_data, but configfs_composite_unbind will set gadget data as NULL, so the NULL pointer issue occurs. This concurrent is hard to reproduce by native kernel, but can be reproduced by android kernel. In this commit, we introduce one spinlock belongs to structure gadget_info since we can't use the same spinlock in usb_composite_dev due to exclusive running together between composite_setup and configfs_composite_unbind. And one bit flag 'unbind' to indicate the code is at unbind routine, this bit is needed due to we release the lock at during configfs_composite_unbind sometimes, and composite_setup may be run at that time. Several oops: oops 1: android_work: sent uevent USB_STATE=CONNECTED configfs-gadget gadget: super-speed config #1: b android_work: sent uevent USB_STATE=CONFIGURED init: Received control message 'start' for 'adbd' from pid: 3515 (system_server) Unable to handle kernel NULL pointer dereference at virtual address 0000002a init: Received control message 'stop' for 'adbd' from pid: 3375 (/vendor/bin/hw/android.hardware.usb@1.1-servic) Mem abort info: Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgd = ffff8008f1b7f000 [000000000000002a] *pgd=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 4 PID: 2457 Comm: irq/125-5b11000 Not tainted 4.14.98-07846-g0b40a9b-dirty #16 Hardware name: Freescale i.MX8QM MEK (DT) task: ffff8008f2a98000 task.stack: ffff00000b7b8000 PC is at composite_setup+0x44/0x1508 LR is at android_setup+0xb8/0x13c pc : [<ffff0000089ffb3c>] lr : [<ffff000008a032fc>] pstate: 800001c5 sp : ffff00000b7bbb80 x29: ffff00000b7bbb80 x28: ffff8008f2a3c010 x27: 0000000000000001 x26: 0000000000000000 [1232/1897] audit: audit_lost=25791 audit_rate_limit=5 audit_backlog_limit=64 x25: 00000000ffffffa1 x24: ffff8008f2a3c010 audit: rate limit exceeded x23: 0000000000000409 x22: ffff000009c8e000 x21: ffff8008f7a8b428 x20: ffff00000afae000 x19: ffff0000089ff000 x18: 0000000000000000 x17: 0000000000000000 x16: ffff0000082b7c9c x15: 0000000000000000 x14: f1866f5b952aca46 x13: e35502e30d44349c x12: 0000000000000008 x11: 0000000000000008 x10: 0000000000000a30 x9 : ffff00000b7bbd00 x8 : ffff8008f2a98a90 x7 : ffff8008f27a9c90 x6 : 0000000000000001 x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000006 x1 : ffff0000089ff8d0 x0 : 732a010310b9ed00 X7: 0xffff8008f27a9c10: 9c10 00000002 00000000 00000001 00000000 13110000 ffff0000 00000002 00208040 9c30 00000000 00000000 00000000 00000000 00000000 00000005 00000029 00000000 9c50 00051778 00000001 f27a8e00 ffff8008 00000005 00000000 00000078 00000078 9c70 00000078 00000000 09031d48 ffff0000 00100000 00000000 00400000 00000000 9c90 00000001 00000000 00000000 00000000 00000000 00000000 ffefb1a0 ffff8008 9cb0 f27a9ca8 ffff8008 00000000 00000000 b9d88037 00000173 1618a3eb 00000001 9cd0 870a792a 0000002e 16188fe6 00000001 0000242b 00000000 00000000 00000000 using random self ethernet address 9cf0 019a4646 00000000 000547f3 00000000 ecfd6c33 00000002 00000000 using random host ethernet address 00000000 X8: 0xffff8008f2a98a10: 8a10 00000000 00000000 f7788d00 ffff8008 00000001 00000000 00000000 00000000 8a30 eb218000 ffff8008 f2a98000 ffff8008 f2a98000 ffff8008 09885000 ffff0000 8a50 f34df480 ffff8008 00000000 00000000 f2a98648 ffff8008 09c8e000 ffff0000 8a70 fff2c800 ffff8008 09031d48 ffff0000 0b7bbd00 ffff0000 0b7bbd00 ffff0000 8a90 080861bc ffff0000 00000000 00000000 00000000 00000000 00000000 00000000 8ab0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8ad0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8af0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 X21: 0xffff8008f7a8b3a8: b3a8 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 b3c8 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 b3e8 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 b408 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000000 b428 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 b448 0053004d 00540046 00300031 00010030 eb07b520 ffff8008 20011201 00000003 b468 e418d109 0104404e 00010302 00000000 eb07b558 ffff8008 eb07b558 ffff8008 b488 f7a8b488 ffff8008 f7a8b488 ffff8008 f7a8b300 ffff8008 00000000 00000000 X24: 0xffff8008f2a3bf90: bf90 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 bfb0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 bfd0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 bff0 00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008 c010 00000000 00000000 f2a3c018 ffff8008 f2a3c018 ffff8008 08a067dc ffff0000 c030 f2a5a000 ffff8008 091c3650 ffff0000 f716fd18 ffff8008 f716fe30 ffff8008 c050 f2ce4a30 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000 c070 f76c8010 ffff8008 f2ce4b00 ffff8008 095cac68 ffff0000 f2a5a028 ffff8008 X28: 0xffff8008f2a3bf90: bf90 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 bfb0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 bfd0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 bff0 00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008 c010 00000000 00000000 f2a3c018 ffff8008 f2a3c018 ffff8008 08a067dc ffff0000 c030 f2a5a000 ffff8008 091c3650 ffff0000 f716fd18 ffff8008 f716fe30 ffff8008 c050 f2ce4a30 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000 c070 f76c8010 ffff8008 f2ce4b00 ffff8008 095cac68 ffff0000 f2a5a028 ffff8008 Process irq/125-5b11000 (pid: 2457, stack limit = 0xffff00000b7b8000) Call trace: Exception stack(0xffff00000b7bba40 to 0xffff00000b7bbb80) ba40: 732a010310b9ed00 ffff0000089ff8d0 0000000000000006 0000000000000000 ba60: 0000000000000001 0000000000000000 0000000000000001 ffff8008f27a9c90 ba80: ffff8008f2a98a90 ffff00000b7bbd00 0000000000000a30 0000000000000008 baa0: 0000000000000008 e35502e30d44349c f1866f5b952aca46 0000000000000000 bac0: ffff0000082b7c9c 0000000000000000 0000000000000000 ffff0000089ff000 bae0: ffff00000afae000 ffff8008f7a8b428 ffff000009c8e000 0000000000000409 bb00: ffff8008f2a3c010 00000000ffffffa1 0000000000000000 0000000000000001 bb20: ffff8008f2a3c010 ffff00000b7bbb80 ffff000008a032fc ffff00000b7bbb80 bb40: ffff0000089ffb3c 00000000800001c5 ffff00000b7bbb80 732a010310b9ed00 bb60: ffffffffffffffff ffff0000080f777c ffff00000b7bbb80 ffff0000089ffb3c [<ffff0000089ffb3c>] composite_setup+0x44/0x1508 [<ffff000008a032fc>] android_setup+0xb8/0x13c [<ffff0000089bd9a8>] cdns3_ep0_delegate_req+0x44/0x70 [<ffff0000089bdff4>] cdns3_check_ep0_interrupt_proceed+0x33c/0x654 [<ffff0000089bca44>] cdns3_device_thread_irq_handler+0x4b0/0x4bc [<ffff0000089b77b4>] cdns3_thread_irq+0x48/0x68 [<ffff000008145bf0>] irq_thread_fn+0x28/0x88 [<ffff000008145e38>] irq_thread+0x13c/0x228 [<ffff0000080fed70>] kthread+0x104/0x130 [<ffff000008085064>] ret_from_fork+0x10/0x18 oops2: composite_disconnect: Calling disconnect on a Gadget that is not connected android_work: did not send uevent (0 0 (null)) init: Received control message 'stop' for 'adbd' from pid: 3359 (/vendor/bin/hw/android.hardware.usb@1.1-service.imx) init: Sending signal 9 to service 'adbd' (pid 22343) process group... ------------[ cut here ]------------ audit: audit_lost=180038 audit_rate_limit=5 audit_backlog_limit=64 audit: rate limit exceeded WARNING: CPU: 0 PID: 3468 at kernel_imx/drivers/usb/gadget/composite.c:2009 composite_disconnect+0x80/0x88 Modules linked in: CPU: 0 PID: 3468 Comm: HWC-UEvent-Thre Not tainted 4.14.98-07846-g0b40a9b-dirty #16 Hardware name: Freescale i.MX8QM MEK (DT) task: ffff8008f2349c00 task.stack: ffff00000b0a8000 PC is at composite_disconnect+0x80/0x88 LR is at composite_disconnect+0x80/0x88 pc : [<ffff0000089ff9b0>] lr : [<ffff0000089ff9b0>] pstate: 600001c5 sp : ffff000008003dd0 x29: ffff000008003dd0 x28: ffff8008f2349c00 x27: ffff000009885018 x26: ffff000008004000 Timeout for IPC response! x25: ffff000009885018 x24: ffff000009c8e280 x23: ffff8008f2d98010 x22: 00000000000001c0 x21: ffff8008f2d98394 x20: ffff8008f2d98010 x19: 0000000000000000 x18: 0000e3956f4f075a fxos8700 4-001e: i2c block read acc failed x17: 0000e395735727e8 x16: ffff00000829f4d4 x15: ffffffffffffffff x14: 7463656e6e6f6320 x13: 746f6e2009090920 x12: 7369207461687420 x11: 7465676461472061 x10: 206e6f207463656e x9 : 6e6f637369642067 x8 : ffff000009c8e280 x7 : ffff0000086ca6cc x6 : ffff000009f15e78 x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffffffffffffffff x2 : c3f28b86000c3900 x1 : c3f28b86000c3900 x0 : 000000000000004e X20: 0xffff8008f2d97f90: 7f90 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 7fb0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 libprocessgroup: Failed to kill process cgroup uid 0 pid 22343 in 215ms, 1 processes remain 7fd0 Timeout for IPC response! 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 using random self ethernet address 7ff0 00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008 8010 00000100 00000000 f2d98018 ffff8008 f2d98018 ffff8008 08a067dc using random host ethernet address ffff0000 8030 f206d800 ffff8008 091c3650 ffff0000 f7957b18 ffff8008 f7957730 ffff8008 8050 f716a630 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000 8070 f76c8010 ffff8008 f716a800 ffff8008 095cac68 ffff0000 f206d828 ffff8008 X21: 0xffff8008f2d98314: 8314 ffff8008 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8334 00000000 00000000 00000000 00000000 00000000 08a04cf4 ffff0000 00000000 8354 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8374 00000000 00000000 00000000 00001001 00000000 00000000 00000000 00000000 8394 e4bbe4bb 0f230000 ffff0000 0afae000 ffff0000 ae001000 00000000 f206d400 Timeout for IPC response! 83b4 ffff8008 00000000 00000000 f7957b18 ffff8008 f7957718 ffff8008 f7957018 83d4 ffff8008 f7957118 ffff8008 f7957618 ffff8008 f7957818 ffff8008 f7957918 83f4 ffff8008 f7957d18 ffff8008 00000000 00000000 00000000 00000000 00000000 X23: 0xffff8008f2d97f90: 7f90 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 7fb0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 7fd0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 7ff0 00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008 8010 00000100 00000000 f2d98018 ffff8008 f2d98018 ffff8008 08a067dc ffff0000 8030 f206d800 ffff8008 091c3650 ffff0000 f7957b18 ffff8008 f7957730 ffff8008 8050 f716a630 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000 8070 f76c8010 ffff8008 f716a800 ffff8008 095cac68 ffff0000 f206d828 ffff8008 X28: 0xffff8008f2349b80: 9b80 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9ba0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9bc0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9be0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9c00 00000022 00000000 ffffffff ffffffff 00010001 00000000 00000000 00000000 9c20 0b0a8000 ffff0000 00000002 00404040 00000000 00000000 00000000 00000000 9c40 00000001 00000000 00000001 00000000 001ebd44 00000001 f390b800 ffff8008 9c60 00000000 00000001 00000070 00000070 00000070 00000000 09031d48 ffff0000 Call trace: Exception stack(0xffff000008003c90 to 0xffff000008003dd0) 3c80: 000000000000004e c3f28b86000c3900 3ca0: c3f28b86000c3900 ffffffffffffffff 0000000000000000 0000000000000000 3cc0: ffff000009f15e78 ffff0000086ca6cc ffff000009c8e280 6e6f637369642067 3ce0: 206e6f207463656e 7465676461472061 7369207461687420 746f6e2009090920 3d00: 7463656e6e6f6320 ffffffffffffffff ffff00000829f4d4 0000e395735727e8 3d20: 0000e3956f4f075a 0000000000000000 ffff8008f2d98010 ffff8008f2d98394 3d40: 00000000000001c0 ffff8008f2d98010 ffff000009c8e280 ffff000009885018 3d60: ffff000008004000 ffff000009885018 ffff8008f2349c00 ffff000008003dd0 3d80: ffff0000089ff9b0 ffff000008003dd0 ffff0000089ff9b0 00000000600001c5 3da0: ffff8008f33f2cd8 0000000000000000 0000ffffffffffff 0000000000000000 init: Received control message 'start' for 'adbd' from pid: 3359 (/vendor/bin/hw/android.hardware.usb@1.1-service.imx) 3dc0: ffff000008003dd0 ffff0000089ff9b0 [<ffff0000089ff9b0>] composite_disconnect+0x80/0x88 [<ffff000008a044d4>] android_disconnect+0x3c/0x68 [<ffff0000089ba9f8>] cdns3_device_irq_handler+0xfc/0x2c8 [<ffff0000089b84c0>] cdns3_irq+0x44/0x94 [<ffff00000814494c>] __handle_irq_event_percpu+0x60/0x24c [<ffff000008144c0c>] handle_irq_event+0x58/0xc0 [<ffff00000814873c>] handle_fasteoi_irq+0x98/0x180 [<ffff000008143a10>] generic_handle_irq+0x24/0x38 [<ffff000008144170>] __handle_domain_irq+0x60/0xac [<ffff0000080819c4>] gic_handle_irq+0xd4/0x17c Signed-off-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> [dwoo08.lee: cherry-pick linux-4.9.y stable commit 59682e70c980 and resolve conflicts to stablize configfs] Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com> Change-Id: I891e07b46cb1783e5f1c7a1c5a6198bb62611b20
2019-11-26usb: gadget: configs: plug memory leakJohn Keeping1-0/+1
[ Upstream commit 38355b2a44776c25b0f2ad466e8c51bb805b3032 ] When binding a gadget to a device, "name" is stored in gi->udc_name, but this does not happen when unregistering and the string is leaked. Signed-off-by: John Keeping <john@metanate.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [dwoo08.lee: cherry-pick linux-4.9.y stable commit 59682e70c980 to stablize configfs] Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com> Change-Id: Ieb2bcfeed245a0b993ac6c4992af8fe27fc89d48
2019-11-26usb: gadget: Zero ffs_io_dataAndrzej Pietrasiewicz1-2/+4
[ Upstream commit 508595515f4bcfe36246e4a565cf280937aeaade ] In some cases the "Allocate & copy" block in ffs_epfile_io() is not executed. Consequently, in such a case ffs_alloc_buffer() is never called and struct ffs_io_data is not initialized properly. This in turn leads to problems when ffs_free_buffer() is called at the end of ffs_epfile_io(). This patch uses kzalloc() instead of kmalloc() in the aio case and memset() in non-aio case to properly initialize struct ffs_io_data. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> [dwoo08.lee: cherry-pick linux-4.9.y stable commit d585589e5f9b to stablize f_fs] Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com> Change-Id: I33ef7d5123301beb94b9d8530664d861464f4bb1
2019-11-26usb: f_fs: Avoid crash due to out-of-scope stack ptr accessJohn Stultz1-0/+1
[ Upstream commit 54f64d5c983f939901dacc8cfc0983727c5c742e ] Since the 5.0 merge window opened, I've been seeing frequent crashes on suspend and reboot with the trace: [ 36.911170] Unable to handle kernel paging request at virtual address ffffff801153d660 [ 36.912769] Unable to handle kernel paging request at virtual address ffffff800004b564 ... [ 36.950666] Call trace: [ 36.950670] queued_spin_lock_slowpath+0x1cc/0x2c8 [ 36.950681] _raw_spin_lock_irqsave+0x64/0x78 [ 36.950692] complete+0x28/0x70 [ 36.950703] ffs_epfile_io_complete+0x3c/0x50 [ 36.950713] usb_gadget_giveback_request+0x34/0x108 [ 36.950721] dwc3_gadget_giveback+0x50/0x68 [ 36.950723] dwc3_thread_interrupt+0x358/0x1488 [ 36.950731] irq_thread_fn+0x30/0x88 [ 36.950734] irq_thread+0x114/0x1b0 [ 36.950739] kthread+0x104/0x130 [ 36.950747] ret_from_fork+0x10/0x1c I isolated this down to in ffs_epfile_io(): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/gadget/function/f_fs.c#n1065 Where the completion done is setup on the stack: DECLARE_COMPLETION_ONSTACK(done); Then later we setup a request and queue it, and wait for it: if (unlikely(wait_for_completion_interruptible(&done))) { /* * To avoid race condition with ffs_epfile_io_complete, * dequeue the request first then check * status. usb_ep_dequeue API should guarantee no race * condition with req->complete callback. */ usb_ep_dequeue(ep->ep, req); interrupted = ep->status < 0; } The problem is, that we end up being interrupted, dequeue the request, and exit. But then the irq triggers and we try calling complete() on the context pointer which points to now random stack space, which results in the panic. Alan Stern pointed out there is a bug here, in that the snippet above "assumes that usb_ep_dequeue() waits until the request has been completed." And that: wait_for_completion(&done); Is needed right after the usb_ep_dequeue(). Thus this patch implements that change. With it I no longer see the crashes on suspend or reboot. This issue seems to have been uncovered by behavioral changes in the dwc3 driver in commit fec9095bdef4e ("usb: dwc3: gadget: remove wait_end_transfer"). Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Felipe Balbi <balbi@kernel.org> Cc: Zeng Tao <prime.zeng@hisilicon.com> Cc: Jack Pham <jackp@codeaurora.org> Cc: Thinh Nguyen <thinh.nguyen@synopsys.com> Cc: Chen Yu <chenyu56@huawei.com> Cc: Jerry Zhang <zhangjerry@google.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Vincent Pelletier <plr.vincent@gmail.com> Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Linux USB List <linux-usb@vger.kernel.org> Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> [dwoo08.lee: cherry-pick linux-4.9.y stable commit 49145924e804 to stablize f_fs] Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com> Change-Id: I5a786991ea9ceef96ff6c6b65dc807f842356fd6
2019-11-26usb: gadget: f_fs: Only return delayed status when len is 0Jerry Zhang1-1/+1
commit 4d644abf25698362bd33d17c9ddc8f7122c30f17 upstream. Commit 1b9ba000 ("Allow function drivers to pause control transfers") states that USB_GADGET_DELAYED_STATUS is only supported if data phase is 0 bytes. It seems that when the length is not 0 bytes, there is no need to explicitly delay the data stage since the transfer is not completed until the user responds. However, when the length is 0, there is no data stage and the transfer is finished once setup() returns, hence there is a need to explicitly delay completion. This manifests as the following bugs: Prior to 946ef68ad4e4 ('Let setup() return USB_GADGET_DELAYED_STATUS'), when setup is 0 bytes, ffs would require user to queue a 0 byte request in order to clear setup state. However, that 0 byte request was actually not needed and would hang and cause errors in other setup requests. After the above commit, 0 byte setups work since the gadget now accepts empty queues to ep0 to clear the delay, but all other setups hang. Fixes: 946ef68ad4e4 ("Let setup() return USB_GADGET_DELAYED_STATUS") Signed-off-by: Jerry Zhang <zhangjerry@google.com> Cc: stable <stable@vger.kernel.org> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [dwoo08.lee: cherry-pick linux-4.9.y stable commit 9e10043b6bdc to stablize f_fs] Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com> Change-Id: Idf5d504bd5059cc5141f4a3e98c572708c631079
2019-11-26usb: gadget: ffs: Execute copy_to_user() with USER_DS setLars-Peter Clausen1-0/+4
[ Upstream commit 4058ebf33cb0be88ca516f968eda24ab7b6b93e4 ] When using a AIO read() operation on the function FS gadget driver a URB is submitted asynchronously and on URB completion the received data is copied to the userspace buffer associated with the read operation. This is done from a kernel worker thread invoking copy_to_user() (through copy_to_iter()). And while the user space process memory is made available to the kernel thread using use_mm(), some architecture require in addition to this that the operation runs with USER_DS set. Otherwise the userspace memory access will fail. For example on ARM64 with Privileged Access Never (PAN) and User Access Override (UAO) enabled the following crash occurs. Internal error: Accessing user space memory with fs=KERNEL_DS: 9600004f [#1] SMP Modules linked in: CPU: 2 PID: 1636 Comm: kworker/2:1 Not tainted 4.9.0-04081-g8ab2dfb-dirty #487 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) Workqueue: events ffs_user_copy_worker task: ffffffc87afc8080 task.stack: ffffffc87a00c000 PC is at __arch_copy_to_user+0x190/0x220 LR is at copy_to_iter+0x78/0x3c8 [...] [<ffffff800847b790>] __arch_copy_to_user+0x190/0x220 [<ffffff80086f25d8>] ffs_user_copy_worker+0x70/0x130 [<ffffff80080b8c64>] process_one_work+0x1dc/0x460 [<ffffff80080b8f38>] worker_thread+0x50/0x4b0 [<ffffff80080bf5a0>] kthread+0xd8/0xf0 [<ffffff8008083680>] ret_from_fork+0x10/0x50 Address this by placing a set_fs(USER_DS) before of the copy operation and revert it again once the copy operation has finished. This patch is analogous to commit d7ffde35e31a ("vhost: use USER_DS in vhost_worker thread") which addresses the same underlying issue. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [dwoo08.lee: cherry-pick linux-4.9.y stable commit 5209c778346a to stablize f_fs] Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com> Change-Id: Iee47b31c16c2f83540e4e1f8bd3f3eaebd727ad2
2019-11-26usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUSLars-Peter Clausen1-1/+1
[ Upstream commit 946ef68ad4e45aa048a5fb41ce8823ed29da866a ] Some UDC drivers (like the DWC3) expect that the response to a setup() request is queued from within the setup function itself so that it is available as soon as setup() has completed. Upon receiving a setup request the function fs driver creates an event that is made available to userspace. And only once userspace has acknowledged that event the response to the setup request is queued. So it violates the requirement of those UDC drivers and random failures can be observed. This is basically a race condition and if userspace is able to read the event and queue the response fast enough all is good. But if it is not, for example because other processes are currently scheduled to run, the USB host that sent the setup request will observe an error. To avoid this the gadget framework provides the USB_GADGET_DELAYED_STATUS return code. If a setup() callback returns this value the UDC driver is aware that response is not yet available and can uses the appropriate methods to handle this case. Since in the case of function fs the response will never be available when the setup() function returns make sure that this status code is used. This fixed random occasional failures that were previously observed on a DWC3 based system under high system load. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [dwoo08.lee: cherry-pick linux-4.9.y stable commit 10be2659c629 to stablize f_fs] Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com> Change-Id: I1b88c4739c9007bfd515b670401035ef2bc541fc
2019-11-26usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb()Xinyong1-1/+0
commit 1a087f032111a88e826877449dfb93ceb22b78b9 upstream. When I debug a kernel crash issue in funcitonfs, found ffs_data.ref overflowed, While functionfs is unmounting, ffs_data is put twice. Commit 43938613c6fd ("drivers, usb: convert ffs_data.ref from atomic_t to refcount_t") can avoid refcount overflow, but that is risk some situations. So no need put ffs data in ffs_fs_kill_sb, already put in ffs_data_closed. The issue can be reproduced in Mediatek mt6763 SoC, ffs for ADB device. KASAN enabled configuration reports use-after-free errro. BUG: KASAN: use-after-free in refcount_dec_and_test+0x14/0xe0 at addr ffffffc0579386a0 Read of size 4 by task umount/4650 ==================================================== BUG kmalloc-512 (Tainted: P W O ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in ffs_fs_mount+0x194/0x844 age=22856 cpu=2 pid=566 alloc_debug_processing+0x1ac/0x1e8 ___slab_alloc.constprop.63+0x640/0x648 __slab_alloc.isra.57.constprop.62+0x24/0x34 kmem_cache_alloc_trace+0x1a8/0x2bc ffs_fs_mount+0x194/0x844 mount_fs+0x6c/0x1d0 vfs_kern_mount+0x50/0x1b4 do_mount+0x258/0x1034 INFO: Freed in ffs_data_put+0x25c/0x320 age=0 cpu=3 pid=4650 free_debug_processing+0x22c/0x434 __slab_free+0x2d8/0x3a0 kfree+0x254/0x264 ffs_data_put+0x25c/0x320 ffs_data_closed+0x124/0x15c ffs_fs_kill_sb+0xb8/0x110 deactivate_locked_super+0x6c/0x98 deactivate_super+0xb0/0xbc INFO: Object 0xffffffc057938600 @offset=1536 fp=0x (null) ...... Call trace: [<ffffff900808cf5c>] dump_backtrace+0x0/0x250 [<ffffff900808d3a0>] show_stack+0x14/0x1c [<ffffff90084a8c04>] dump_stack+0xa0/0xc8 [<ffffff900826c2b4>] print_trailer+0x158/0x260 [<ffffff900826d9d8>] object_err+0x3c/0x40 [<ffffff90082745f0>] kasan_report_error+0x2a8/0x754 [<ffffff9008274f84>] kasan_report+0x5c/0x60 [<ffffff9008273208>] __asan_load4+0x70/0x88 [<ffffff90084cd81c>] refcount_dec_and_test+0x14/0xe0 [<ffffff9008d98f9c>] ffs_data_put+0x80/0x320 [<ffffff9008d9d904>] ffs_fs_kill_sb+0xc8/0x110 [<ffffff90082852a0>] deactivate_locked_super+0x6c/0x98 [<ffffff900828537c>] deactivate_super+0xb0/0xbc [<ffffff90082af0c0>] cleanup_mnt+0x64/0xec [<ffffff90082af1b0>] __cleanup_mnt+0x10/0x18 [<ffffff90080d9e68>] task_work_run+0xcc/0x124 [<ffffff900808c8c0>] do_notify_resume+0x60/0x70 [<ffffff90080866e4>] work_pending+0x10/0x14 Cc: stable@vger.kernel.org Signed-off-by: Xinyong <xinyong.fang@linux.alibaba.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [dwoo08.lee: cherry-pick linux-4.9.y stable commit dddf4650cf64 to stablize f_fs] Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com> Change-Id: I32845cb6181c82662c8873505c2d9aff3f3f980c
2019-11-26usb: gadget: f_fs: Process all descriptors during bindJack Pham1-4/+2
commit 6cf439e0d37463e42784271179c8a308fd7493c6 upstream. During _ffs_func_bind(), the received descriptors are evaluated to prepare for binding with the gadget in order to allocate endpoints and optionally set up OS descriptors. However, the high- and super-speed descriptors are only parsed based on whether the gadget_is_dualspeed() and gadget_is_superspeed() calls are true, respectively. This is a problem in case a userspace program always provides all of the {full,high,super,OS} descriptors when configuring a function. Then, for example if a gadget device is not capable of SuperSpeed, the call to ffs_do_descs() for the SS descriptors is skipped, resulting in an incorrect offset calculation for the vla_ptr when moving on to the OS descriptors that follow. This causes ffs_do_os_descs() to fail as it is now looking at the SS descriptors' offset within the raw_descs buffer instead. _ffs_func_bind() should evaluate the descriptors unconditionally, so remove the checks for gadget speed. Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support") Cc: stable@vger.kernel.org Co-Developed-by: Mayank Rana <mrana@codeaurora.org> Signed-off-by: Mayank Rana <mrana@codeaurora.org> Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [dwoo08.lee: cherry-pick linux-4.9.y stable commit 8bedacf13d59 to stablize f_fs] Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com> Change-Id: I0ed8330a0e692ea80263f31b7804203edfbd2d4d
2019-11-26usb: f_fs: Prevent gadget unbind if it is already unboundHemant Kumar1-1/+2
commit ce5bf9a50daf2d9078b505aca1cea22e88ecb94a upstream. Upon usb composition switch there is possibility of ep0 file release happening after gadget driver bind. In case of composition switch from adb to a non-adb composition gadget will never gets bound again resulting into failure of usb device enumeration. Fix this issue by checking FFS_FL_BOUND flag and avoid extra gadget driver unbind if it is already done as part of composition switch. This fixes adb reconnection error reported on Android running v4.4 and above kernel versions. Verified on Hikey running vanilla v4.15-rc7 + few out of tree Mali patches. Reviewed-at: https://android-review.googlesource.com/#/c/582632/ Cc: Felipe Balbi <balbi@kernel.org> Cc: Greg KH <gregkh@linux-foundation.org> Cc: Michal Nazarewicz <mina86@mina86.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Dmitry Shmidt <dimitrysh@google.com> Cc: Badhri <badhri@google.com> Cc: Android Kernel Team <kernel-team@android.com> Signed-off-by: Hemant Kumar <hemantk@codeaurora.org> [AmitP: Cherry-picked it from android-4.14 and updated the commit log] Signed-off-by: Amit Pundir <amit.pundir@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [dwoo08.lee: cherry-pick linux-4.9.y stable commit f24d171a8100 to stablize f_fs] Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com> Change-Id: Ifbab9f182fa3779c57ab288958553c3711d50e28
2019-11-26usb: gadget: ffs: Forbid usb_ep_alloc_request from sleepingVincent Pelletier1-1/+1
commit 30bf90ccdec1da9c8198b161ecbff39ce4e5a9ba upstream. Found using DEBUG_ATOMIC_SLEEP while submitting an AIO read operation: [ 100.853642] BUG: sleeping function called from invalid context at mm/slab.h:421 [ 100.861148] in_atomic(): 1, irqs_disabled(): 1, pid: 1880, name: python [ 100.867954] 2 locks held by python/1880: [ 100.867961] #0: (&epfile->mutex){....}, at: [<f8188627>] ffs_mutex_lock+0x27/0x30 [usb_f_fs] [ 100.868020] #1: (&(&ffs->eps_lock)->rlock){....}, at: [<f818ad4b>] ffs_epfile_io.isra.17+0x24b/0x590 [usb_f_fs] [ 100.868076] CPU: 1 PID: 1880 Comm: python Not tainted 4.14.0-edison+ #118 [ 100.868085] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 [ 100.868093] Call Trace: [ 100.868122] dump_stack+0x47/0x62 [ 100.868156] ___might_sleep+0xfd/0x110 [ 100.868182] __might_sleep+0x68/0x70 [ 100.868217] kmem_cache_alloc_trace+0x4b/0x200 [ 100.868248] ? dwc3_gadget_ep_alloc_request+0x24/0xe0 [dwc3] [ 100.868302] dwc3_gadget_ep_alloc_request+0x24/0xe0 [dwc3] [ 100.868343] usb_ep_alloc_request+0x16/0xc0 [udc_core] [ 100.868386] ffs_epfile_io.isra.17+0x444/0x590 [usb_f_fs] [ 100.868424] ? _raw_spin_unlock_irqrestore+0x27/0x40 [ 100.868457] ? kiocb_set_cancel_fn+0x57/0x60 [ 100.868477] ? ffs_ep0_poll+0xc0/0xc0 [usb_f_fs] [ 100.868512] ffs_epfile_read_iter+0xfe/0x157 [usb_f_fs] [ 100.868551] ? security_file_permission+0x9c/0xd0 [ 100.868587] ? rw_verify_area+0xac/0x120 [ 100.868633] aio_read+0x9d/0x100 [ 100.868692] ? __fget+0xa2/0xd0 [ 100.868727] ? __might_sleep+0x68/0x70 [ 100.868763] SyS_io_submit+0x471/0x680 [ 100.868878] do_int80_syscall_32+0x4e/0xd0 [ 100.868921] entry_INT80_32+0x2a/0x2a [ 100.868932] EIP: 0xb7fbb676 [ 100.868941] EFLAGS: 00000292 CPU: 1 [ 100.868951] EAX: ffffffda EBX: b7aa2000 ECX: 00000002 EDX: b7af8368 [ 100.868961] ESI: b7fbb660 EDI: b7aab000 EBP: bfb6c658 ESP: bfb6c638 [ 100.868973] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [dwoo08.lee: cherry-pick linux-4.9.y stable commit 16648cbcd332 to stablize f_fs] Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com> Change-Id: I7716588e2a674be3f5f602273fd283273b87b730
2019-11-26usb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPATJohn Keeping1-2/+11
commit a3acc696085e112733d191a77b106e67a4fa110b upstream. The specification says that the Reserved1 field in OS_DESC_EXT_COMPAT must have the value "1", but when this feature was first implemented we rejected any non-zero values. This was adjusted to accept all non-zero values (while now rejecting zero) in commit 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT"), but that breaks any userspace programs that worked previously by returning EINVAL when Reserved1 == 0 which was previously the only value that succeeded! If we just set the field to "1" ourselves, both old and new userspace programs continue to work correctly and, as a bonus, old programs are now compliant with the specification without having to fix anything themselves. Fixes: 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT") Signed-off-by: John Keeping <john@metanate.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [dwoo08.lee: cherry-pick linux-4.9.y stable commit 112b8a8f558d to stablize f_fs] Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com> Change-Id: I00f7fce7bc2c5225c3f9ec00f30d1e4f4f0582de
2019-11-26usb: gadget: f_fs: Fix ExtCompat descriptor validationVincent Pelletier1-1/+1
[ Upstream commit 354bc45bf329494ef6051f3229ef50b9e2a7ea2a ] Reserved1 is documented as expected to be set to 0, but this test fails when it it set to 0. Reverse the condition. Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [dwoo08.lee: cherry-pick linux-4.9.y stable commit 5eb97be87981 to stablize f_fs] Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com> Change-Id: Id8bd89a9cb5343fd0830d480ad5b2900367d8056
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-17 18:04:31 +0000