commit 12ae58ca7ec42fe23df5d0b0d01bce2ccb728fd5 Author: Greg Kroah-Hartman Date: Wed Apr 3 06:23:29 2019 +0200 Linux 4.4.178 commit b1b1efe07ea030c400c9bd2cfba2f9b8ec66e3a9 Author: Geert Uytterhoeven Date: Tue Dec 22 17:25:15 2015 +0200 stm class: Hide STM-specific options if STM is disabled [ Upstream commit 4a2e2b19f96acfc037a9773c7729d133ce1e7e3b ] If STM=n, it doesn't make sense to ask about STM_DUMMY and STM_SOURCE_CONSOLE support, which are not even built when enabled anyway. Hence hide these options if STM=n. Reported-by: Linus Torvalds Signed-off-by: Geert Uytterhoeven Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c003b5675d3479e46e5aa8c677c153a556a45110 Author: Mathieu Poirier Date: Tue Feb 2 14:14:00 2016 -0700 coresight: removing bind/unbind options from sysfs [ Upstream commit b15f0fb657e040401d875d11ae13b269af8a16e0 ] The coresight drivers have absolutely no control over bind and unbind operations triggered from sysfs. The operations simply can't be cancelled or denied event when one or several tracing sessions are under way. Since the memory associated to individual device is invariably freed, the end result is a kernel crash when the path from source to sink is travelled again as demonstrated here[1]. One solution could be to keep track of all the path (i.e tracing session) that get created and iterate through the elements of those path looking for the coresight device that is being removed. This proposition doesn't scale well since there is no upper bound on the amount of concurrent trace session that can be created. With the above in mind, this patch prevent devices from being unbounded from their driver by using the driver->suppress_bind_attr option. That way trace sessions can be managed without fearing to loose devices. Since device can't be removed anymore the xyz_remove() functions found in each driver is also removed. [1]. http://www.spinics.net/lists/arm-kernel/msg474952.html Reported-by: Rabin Vincent Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 455b9a675ecfad505d9c4e59b827107073fb71ce Author: Eric Biggers Date: Wed Mar 8 16:27:04 2017 -0800 arm64: support keyctl() system call in 32-bit mode [ Upstream commit 5c2a625937ba49bc691089370638223d310cda9a ] As is the case for a number of other architectures that have a 32-bit compat mode, enable KEYS_COMPAT if both COMPAT and KEYS are enabled. This allows AArch32 programs to use the keyctl() system call when running on an AArch64 kernel. Signed-off-by: Eric Biggers Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit d14ac4368f22216ad06b40017094714150c6ed45 Author: Greg Kroah-Hartman Date: Wed Dec 13 11:59:39 2017 +0100 Revert "USB: core: only clean up what we allocated" commit cf4df407e0d7cde60a45369c2a3414d18e2d4fdd upstream. This reverts commit 32fd87b3bbf5f7a045546401dfe2894dbbf4d8c3. Alan wrote a better fix for this... Cc: Andrey Konovalov Cc: stable Cc: Nathan Chancellor Cc: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 78d145f71db5c2b32b24baba875da651c92a7b1f Author: Mathias Nyman Date: Fri Mar 22 17:50:15 2019 +0200 xhci: Fix port resume done detection for SS ports with LPM enabled commit 6cbcf596934c8e16d6288c7cc62dfb7ad8eadf15 upstream. A suspended SS port in U3 link state will go to U0 when resumed, but can almost immediately after that enter U1 or U2 link power save states before host controller driver reads the port status. Host controller driver only checks for U0 state, and might miss the finished resume, leaving flags unclear and skip notifying usb code of the wake. Add U1 and U2 to the possible link states when checking for finished port resume. Cc: stable Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 9aacea736c9a218d04cb01fff289a35d67d358cf Author: Sean Christopherson Date: Fri Feb 15 12:48:39 2019 -0800 KVM: Reject device ioctls from processes other than the VM's creator commit ddba91801aeb5c160b660caed1800eb3aef403f8 upstream. KVM's API requires thats ioctls must be issued from the same process that created the VM. In other words, userspace can play games with a VM's file descriptors, e.g. fork(), SCM_RIGHTS, etc..., but only the creator can do anything useful. Explicitly reject device ioctls that are issued by a process other than the VM's creator, and update KVM's API documentation to extend its requirements to device ioctls. Fixes: 852b6d57dc7f ("kvm: add device control API") Cc: Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 5ce6e5bd23f01ac83d912887267e60c319fda969 Author: Thomas Gleixner Date: Tue Mar 26 17:36:06 2019 +0100 x86/smp: Enforce CONFIG_HOTPLUG_CPU when SMP=y commit bebd024e4815b1a170fcd21ead9c2222b23ce9e6 upstream. The SMT disable 'nosmt' command line argument is not working properly when CONFIG_HOTPLUG_CPU is disabled. The teardown of the sibling CPUs which are required to be brought up due to the MCE issues, cannot work. The CPUs are then kept in a half dead state. As the 'nosmt' functionality has become popular due to the speculative hardware vulnerabilities, the half torn down state is not a proper solution to the problem. Enforce CONFIG_HOTPLUG_CPU=y when SMP is enabled so the full operation is possible. Reported-by: Tianyu Lan Signed-off-by: Thomas Gleixner Acked-by: Greg Kroah-Hartman Cc: Konrad Wilk Cc: Josh Poimboeuf Cc: Mukesh Ojha Cc: Peter Zijlstra Cc: Jiri Kosina Cc: Rik van Riel Cc: Andy Lutomirski Cc: Micheal Kelley Cc: "K. Y. Srinivasan" Cc: Linus Torvalds Cc: Borislav Petkov Cc: K. Y. Srinivasan Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20190326163811.598166056@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 0fe681f4ef50062e3ca11aced9f56429d5c048b8 Author: Adrian Hunter Date: Mon Mar 25 15:51:35 2019 +0200 perf intel-pt: Fix TSC slip commit f3b4e06b3bda759afd042d3d5fa86bea8f1fe278 upstream. A TSC packet can slip past MTC packets so that the timestamp appears to go backwards. One estimate is that can be up to about 40 CPU cycles, which is certainly less than 0x1000 TSC ticks, but accept slippage an order of magnitude more to be on the safe side. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org Fixes: 79b58424b821c ("perf tools: Add Intel PT support for decoding MTC packets") Link: http://lkml.kernel.org/r/20190325135135.18348-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit e250a5ac0e12ddba89d2ece260d167999af8a7c2 Author: Axel Lin Date: Mon Mar 11 21:29:37 2019 +0800 gpio: adnp: Fix testing wrong value in adnp_gpio_direction_input commit c5bc6e526d3f217ed2cc3681d256dc4a2af4cc2b upstream. Current code test wrong value so it does not verify if the written data is correctly read back. Fix it. Also make it return -EPERM if read value does not match written bit, just like it done for adnp_gpio_direction_output(). Fixes: 5e969a401a01 ("gpio: Add Avionic Design N-bit GPIO expander support") Cc: Signed-off-by: Axel Lin Reviewed-by: Thierry Reding Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 6271fa6fc366827c0249864157e8fd18c4eac68a Author: YueHaibing Date: Thu Mar 28 20:44:40 2019 -0700 fs/proc/proc_sysctl.c: fix NULL pointer dereference in put_links commit 23da9588037ecdd4901db76a5b79a42b529c4ec3 upstream. Syzkaller reports: kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN PTI CPU: 1 PID: 5373 Comm: syz-executor.0 Not tainted 5.0.0-rc8+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 RIP: 0010:put_links+0x101/0x440 fs/proc/proc_sysctl.c:1599 Code: 00 0f 85 3a 03 00 00 48 8b 43 38 48 89 44 24 20 48 83 c0 38 48 89 c2 48 89 44 24 28 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 fe 02 00 00 48 8b 74 24 20 48 c7 c7 60 2a 9d 91 RSP: 0018:ffff8881d828f238 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff8881e01b1140 RCX: ffffffff8ee98267 RDX: 0000000000000007 RSI: ffffc90001479000 RDI: ffff8881e01b1178 RBP: dffffc0000000000 R08: ffffed103ee27259 R09: ffffed103ee27259 R10: 0000000000000001 R11: ffffed103ee27258 R12: fffffffffffffff4 R13: 0000000000000006 R14: ffff8881f59838c0 R15: dffffc0000000000 FS: 00007f072254f700(0000) GS:ffff8881f7100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fff8b286668 CR3: 00000001f0542002 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: drop_sysctl_table+0x152/0x9f0 fs/proc/proc_sysctl.c:1629 get_subdir fs/proc/proc_sysctl.c:1022 [inline] __register_sysctl_table+0xd65/0x1090 fs/proc/proc_sysctl.c:1335 br_netfilter_init+0xbc/0x1000 [br_netfilter] do_one_initcall+0xfa/0x5ca init/main.c:887 do_init_module+0x204/0x5f6 kernel/module.c:3460 load_module+0x66b2/0x8570 kernel/module.c:3808 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x462e99 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f072254ec58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99 RDX: 0000000000000000 RSI: 0000000020000280 RDI: 0000000000000003 RBP: 00007f072254ec70 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f072254f6bc R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004 Modules linked in: br_netfilter(+) dvb_usb_dibusb_mc_common dib3000mc dibx000_common dvb_usb_dibusb_common dvb_usb_dw2102 dvb_usb classmate_laptop palmas_regulator cn videobuf2_v4l2 v4l2_common snd_soc_bd28623 mptbase snd_usb_usx2y snd_usbmidi_lib snd_rawmidi wmi libnvdimm lockd sunrpc grace rc_kworld_pc150u rc_core rtc_da9063 sha1_ssse3 i2c_cros_ec_tunnel adxl34x_spi adxl34x nfnetlink lib80211 i5500_temp dvb_as102 dvb_core videobuf2_common videodev media videobuf2_vmalloc videobuf2_memops udc_core lnbp22 leds_lp3952 hid_roccat_ryos s1d13xxxfb mtd vport_geneve openvswitch nf_conncount nf_nat_ipv6 nsh geneve udp_tunnel ip6_udp_tunnel snd_soc_mt6351 sis_agp phylink snd_soc_adau1761_spi snd_soc_adau1761 snd_soc_adau17x1 snd_soc_core snd_pcm_dmaengine ac97_bus snd_compress snd_soc_adau_utils snd_soc_sigmadsp_regmap snd_soc_sigmadsp raid_class hid_roccat_konepure hid_roccat_common hid_roccat c2port_duramar2150 core mdio_bcm_unimac iptable_security iptable_raw iptable_mangle iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr veth netdevsim devlink vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon dummy team bonding vcan bridge stp llc ip6_gre gre ip6_tunnel tunnel6 tun crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel joydev mousedev ide_pci_generic piix aesni_intel aes_x86_64 ide_core crypto_simd atkbd cryptd glue_helper serio_raw ata_generic pata_acpi i2c_piix4 floppy sch_fq_codel ip_tables x_tables ipv6 [last unloaded: lm73] Dumping ftrace buffer: (ftrace buffer empty) ---[ end trace 770020de38961fd0 ]--- A new dir entry can be created in get_subdir and its 'header->parent' is set to NULL. Only after insert_header success, it will be set to 'dir', otherwise 'header->parent' is set to NULL and drop_sysctl_table is called. However in err handling path of get_subdir, drop_sysctl_table also be called on 'new->header' regardless its value of parent pointer. Then put_links is called, which triggers NULL-ptr deref when access member of header->parent. In fact we have multiple error paths which call drop_sysctl_table() there, upon failure on insert_links() we also call drop_sysctl_table().And even in the successful case on __register_sysctl_table() we still always call drop_sysctl_table().This patch fix it. Link: http://lkml.kernel.org/r/20190314085527.13244-1-yuehaibing@huawei.com Fixes: 0e47c99d7fe25 ("sysctl: Replace root_list with links between sysctl_table_sets") Signed-off-by: YueHaibing Reported-by: Hulk Robot Acked-by: Luis Chamberlain Cc: Kees Cook Cc: Alexey Dobriyan Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Al Viro Cc: Eric W. Biederman Cc: [3.4+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 98bc2f91e918979b3b660b38cca9697ca1178330 Author: Wentao Wang Date: Wed Mar 20 15:30:39 2019 +0000 Disable kgdboc failed by echo space to /sys/module/kgdboc/parameters/kgdboc commit 3ec8002951ea173e24b466df1ea98c56b7920e63 upstream. Echo "" to /sys/module/kgdboc/parameters/kgdboc will fail with "No such device” error. This is caused by function "configure_kgdboc" who init err to ENODEV when the config is empty (legal input) the code go out with ENODEV returned. Fixes: 2dd453168643 ("kgdboc: Fix restrict error") Signed-off-by: Wentao Wang Cc: stable Acked-by: Daniel Thompson Signed-off-by: Greg Kroah-Hartman commit 6c1c9cfc2fdd3044bba1059e1caea075019fb45c Author: Bjørn Mork Date: Wed Mar 27 15:25:32 2019 +0100 USB: serial: option: add Olicard 600 commit 84f3b43f7378b98b7e3096d5499de75183d4347c upstream. This is a Qualcomm based device with a QMI function on interface 4. It is mode switched from 2020:2030 using a standard eject message. T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2020 ProdID=2031 Rev= 2.32 S: Manufacturer=Mobile Connect S: Product=Mobile Connect S: SerialNumber=0123456789ABCDEF C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none) E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us Cc: stable@vger.kernel.org Signed-off-by: Bjørn Mork [ johan: use tabs to align comments in adjacent lines ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 09d3f1eb8499b92456cdc5d0e8937572467f651a Author: Mans Rullgard Date: Tue Feb 26 17:07:10 2019 +0000 USB: serial: option: set driver_info for SIM5218 and compatibles commit f8df5c2c3e2df5ffaf9fb5503da93d477a8c7db4 upstream. The SIMCom SIM5218 and compatible devices have 5 USB interfaces, only 4 of which are serial ports. The fifth is a network interface supported by the qmi-wwan driver. Furthermore, the serial ports do not support modem control signals. Add driver_info flags to reflect this. Signed-off-by: Mans Rullgard Fixes: ec0cd94d881c ("usb: option: add SIMCom SIM5218") Cc: stable # 3.2 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 6ef819f7158ae71edd690e8c4c1ddc0ed52c809f Author: Lin Yi Date: Wed Mar 20 19:04:56 2019 +0800 USB: serial: mos7720: fix mos_parport refcount imbalance on error path commit 2908b076f5198d231de62713cb2b633a3a4b95ac upstream. The write_parport_reg_nonblock() helper takes a reference to the struct mos_parport, but failed to release it in a couple of error paths after allocation failures, leading to a memory leak. Johan said that move the kref_get() and mos_parport assignment to the end of urbtrack initialisation is a better way, so move it. and mos_parport do not used until urbtrack initialisation. Signed-off-by: Lin Yi Fixes: b69578df7e98 ("USB: usbserial: mos7720: add support for parallel port on moschip 7715") Cc: stable # 2.6.35 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ef0d78184aff9a8f8bdad79ddb84d8838e0fea40 Author: George McCollister Date: Tue Mar 5 16:05:03 2019 -0600 USB: serial: ftdi_sio: add additional NovaTech products commit 422c2537ba9d42320f8ab6573940269f87095320 upstream. Add PIDs for the NovaTech OrionLX+ and Orion I/O so they can be automatically detected. Signed-off-by: George McCollister Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 7139e4d5bf835123d7bb75199ac463d865f665db Author: Greg Kroah-Hartman Date: Wed Mar 27 10:11:14 2019 +0900 USB: serial: cp210x: add new device id commit a595ecdd5f60b2d93863cebb07eec7f935839b54 upstream. Lorenz Messtechnik has a device that is controlled by the cp210x driver, so add the device id to the driver. The device id was provided by Silicon-Labs for the devices from this vendor. Reported-by: Uli Signed-off-by: Greg Kroah-Hartman Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 327ee45823eb2c757e3c5507e763dea88568e424 Author: Hoan Nguyen An Date: Mon Mar 18 18:26:32 2019 +0900 serial: sh-sci: Fix setting SCSCR_TIE while transferring data commit 93bcefd4c6bad4c69dbc4edcd3fbf774b24d930d upstream. We disable transmission interrupt (clear SCSCR_TIE) after all data has been transmitted (if uart_circ_empty(xmit)). While transmitting, if the data is still in the tty buffer, re-enable the SCSCR_TIE bit, which was done at sci_start_tx(). This is unnecessary processing, wasting CPU operation if the data transmission length is large. And further, transmit end, FIFO empty bits disabling have also been performed in the step above. Signed-off-by: Hoan Nguyen An Cc: stable Signed-off-by: Greg Kroah-Hartman commit 7124c71944ee422c0f56b1f2093bfdb7bd6f5f97 Author: Aditya Pakki Date: Mon Mar 18 18:44:14 2019 -0500 serial: max310x: Fix to avoid potential NULL pointer dereference commit 3a10e3dd52e80b9a97a3346020024d17b2c272d6 upstream. of_match_device can return a NULL pointer when matching device is not found. This patch avoids a scenario causing NULL pointer derefernce. Signed-off-by: Aditya Pakki Cc: stable Signed-off-by: Greg Kroah-Hartman commit 2e7c2f25e902579fc81636c0f5c9f856f4428d7c Author: Malcolm Priestley Date: Sun Mar 24 18:53:49 2019 +0000 staging: vt6655: Fix interrupt race condition on device start up. commit 3b9c2f2e0e99bb67c96abcb659b3465efe3bee1f upstream. It appears on some slower systems that the driver can find its way out of the workqueue while the interrupt is disabled by continuous polling by it. Move MACvIntEnable to vnt_interrupt_work so that it is always enabled on all routes out of vnt_interrupt_process. Move MACvIntDisable so that the device doesn't keep polling the system while the workqueue is being processed. Signed-off-by: Malcolm Priestley CC: stable@vger.kernel.org # v4.2+ Signed-off-by: Greg Kroah-Hartman commit 17400647682ac54e88e97b28ee0df85f9305a0dc Author: Malcolm Priestley Date: Wed Mar 27 18:45:26 2019 +0000 staging: vt6655: Remove vif check from vnt_interrupt commit cc26358f89c3e493b54766b1ca56cfc6b14db78a upstream. A check for vif is made in vnt_interrupt_work. There is a small chance of leaving interrupt disabled while vif is NULL and the work hasn't been scheduled. Signed-off-by: Malcolm Priestley CC: stable@vger.kernel.org # v4.2+ Signed-off-by: Greg Kroah-Hartman commit 13f6808ec2bb43cffafd3a24b01692676bdfccfc Author: Kangjie Lu Date: Fri Mar 15 12:16:06 2019 -0500 tty: atmel_serial: fix a potential NULL pointer dereference commit c85be041065c0be8bc48eda4c45e0319caf1d0e5 upstream. In case dmaengine_prep_dma_cyclic fails, the fix returns a proper error code to avoid NULL pointer dereference. Signed-off-by: Kangjie Lu Fixes: 34df42f59a60 ("serial: at91: add rx dma support") Acked-by: Richard Genoud Cc: stable Signed-off-by: Greg Kroah-Hartman commit 21da2b461fbda5570e17e10269bb6ca739d099e4 Author: Steffen Maier Date: Tue Mar 26 14:36:59 2019 +0100 scsi: zfcp: fix scsi_eh host reset with port_forced ERP for non-NPIV FCP devices commit 242ec1455151267fe35a0834aa9038e4c4670884 upstream. Suppose more than one non-NPIV FCP device is active on the same channel. Send I/O to storage and have some of the pending I/O run into a SCSI command timeout, e.g. due to bit errors on the fibre. Now the error situation stops. However, we saw FCP requests continue to timeout in the channel. The abort will be successful, but the subsequent TUR fails. Scsi_eh starts. The LUN reset fails. The target reset fails. The host reset only did an FCP device recovery. However, for non-NPIV FCP devices, this does not close and reopen ports on the SAN-side if other non-NPIV FCP device(s) share the same open ports. In order to resolve the continuing FCP request timeouts, we need to explicitly close and reopen ports on the SAN-side. This was missing since the beginning of zfcp in v2.6.0 history commit ea127f975424 ("[PATCH] s390 (7/7): zfcp host adapter."). Note: The FSF requests for forced port reopen could run into FSF request timeouts due to other reasons. This would trigger an internal FCP device recovery. Pending forced port reopen recoveries would get dismissed. So some ports might not get fully reopened during this host reset handler. However, subsequent I/O would trigger the above described escalation and eventually all ports would be forced reopen to resolve any continuing FCP request timeouts due to earlier bit errors. Signed-off-by: Steffen Maier Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: #3.0+ Reviewed-by: Jens Remus Reviewed-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d8007fb2e81618e08c4cd44ea8d63f5872ce5840 Author: Steffen Maier Date: Tue Mar 26 14:36:58 2019 +0100 scsi: zfcp: fix rport unblock if deleted SCSI devices on Scsi_Host commit fe67888fc007a76b81e37da23ce5bd8fb95890b0 upstream. An already deleted SCSI device can exist on the Scsi_Host and remain there because something still holds a reference. A new SCSI device with the same H:C:T:L and FCP device, target port WWPN, and FCP LUN can be created. When we try to unblock an rport, we still find the deleted SCSI device and return early because the zfcp_scsi_dev of that SCSI device is not ZFCP_STATUS_COMMON_UNBLOCKED. Hence we miss to unblock the rport, even if the new proper SCSI device would be in good state. Therefore, skip deleted SCSI devices when iterating the sdevs of the shost. [cf. __scsi_device_lookup{_by_target}() or scsi_device_get()] The following abbreviated trace sequence can indicate such problem: Area : REC Tag : ersfs_3 LUN : 0x4045400300000000 WWPN : 0x50050763031bd327 LUN status : 0x40000000 not ZFCP_STATUS_COMMON_UNBLOCKED Ready count : n not incremented yet Running count : 0x00000000 ERP want : 0x01 ERP need : 0xc1 ZFCP_ERP_ACTION_NONE Area : REC Tag : ersfs_3 LUN : 0x4045400300000000 WWPN : 0x50050763031bd327 LUN status : 0x41000000 Ready count : n+1 Running count : 0x00000000 ERP want : 0x01 ERP need : 0x01 ... Area : REC Level : 4 only with increased trace level Tag : ertru_l LUN : 0x4045400300000000 WWPN : 0x50050763031bd327 LUN status : 0x40000000 Request ID : 0x0000000000000000 ERP status : 0x01800000 ERP step : 0x1000 ERP action : 0x01 ERP count : 0x00 NOT followed by a trace record with tag "scpaddy" for WWPN 0x50050763031bd327. Signed-off-by: Steffen Maier Fixes: 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race with LUN recovery") Cc: #2.6.32+ Reviewed-by: Jens Remus Reviewed-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 2f369124b97a8992262c632478be904cde85325a Author: Bart Van Assche Date: Mon Mar 25 10:01:46 2019 -0700 scsi: sd: Fix a race between closing an sd device and sd I/O commit c14a57264399efd39514a2329c591a4b954246d8 upstream. The scsi_end_request() function calls scsi_cmd_to_driver() indirectly and hence needs the disk->private_data pointer. Avoid that that pointer is cleared before all affected I/O requests have finished. This patch avoids that the following crash occurs: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: scsi_mq_uninit_cmd+0x1c/0x30 scsi_end_request+0x7c/0x1b8 scsi_io_completion+0x464/0x668 scsi_finish_command+0xbc/0x160 scsi_eh_flush_done_q+0x10c/0x170 sas_scsi_recover_host+0x84c/0xa98 [libsas] scsi_error_handler+0x140/0x5b0 kthread+0x100/0x12c ret_from_fork+0x10/0x18 Cc: Christoph Hellwig Cc: Ming Lei Cc: Hannes Reinecke Cc: Johannes Thumshirn Cc: Jason Yan Cc: Signed-off-by: Bart Van Assche Reported-by: Jason Yan Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 49ad739854431e23da239f03116addc16ba3e81a Author: Takashi Iwai Date: Mon Mar 25 10:38:58 2019 +0100 ALSA: pcm: Don't suspend stream in unrecoverable PCM state commit 113ce08109f8e3b091399e7cc32486df1cff48e7 upstream. Currently PCM core sets each opened stream forcibly to SUSPENDED state via snd_pcm_suspend_all() call, and the user-space is responsible for re-triggering the resume manually either via snd_pcm_resume() or prepare call. The scheme works fine usually, but there are corner cases where the stream can't be resumed by that call: the streams still in OPEN state before finishing hw_params. When they are suspended, user-space cannot perform resume or prepare because they haven't been set up yet. The only possible recovery is to re-open the device, which isn't nice at all. Similarly, when a stream is in DISCONNECTED state, it makes no sense to change it to SUSPENDED state. Ditto for in SETUP state; which you can re-prepare directly. So, this patch addresses these issues by filtering the PCM streams to be suspended by checking the PCM state. When a stream is in either OPEN, SETUP or DISCONNECTED as well as already SUSPENDED, the suspend action is skipped. To be noted, this problem was originally reported for the PCM runtime PM on HD-audio. And, the runtime PM problem itself was already addressed (although not intended) by the code refactoring commits 3d21ef0b49f8 ("ALSA: pcm: Suspend streams globally via device type PM ops") and 17bc4815de58 ("ALSA: pci: Remove superfluous snd_pcm_suspend*() calls"). These commits eliminated the snd_pcm_suspend*() calls from the runtime PM suspend callback code path, hence the racy OPEN state won't appear while runtime PM. (FWIW, the race window is between snd_pcm_open_substream() and the first power up in azx_pcm_open().) Although the runtime PM issue was already "fixed", the same problem is still present for the system PM, hence this patch is still needed. And for stable trees, this patch alone should suffice for fixing the runtime PM problem, too. Reported-and-tested-by: Jon Hunter Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c07db6f073aba3513f5896dd9b736acf490d8d1c Author: Takashi Iwai Date: Fri Mar 22 16:00:54 2019 +0100 ALSA: pcm: Fix possible OOB access in PCM oss plugins commit ca0214ee2802dd47239a4e39fb21c5b00ef61b22 upstream. The PCM OSS emulation converts and transfers the data on the fly via "plugins". The data is converted over the dynamically allocated buffer for each plugin, and recently syzkaller caught OOB in this flow. Although the bisection by syzbot pointed out to the commit 65766ee0bf7f ("ALSA: oss: Use kvzalloc() for local buffer allocations"), this is merely a commit to replace vmalloc() with kvmalloc(), hence it can't be the cause. The further debug action revealed that this happens in the case where a slave PCM doesn't support only the stereo channels while the OSS stream is set up for a mono channel. Below is a brief explanation: At each OSS parameter change, the driver sets up the PCM hw_params again in snd_pcm_oss_change_params_lock(). This is also the place where plugins are created and local buffers are allocated. The problem is that the plugins are created before the final hw_params is determined. Namely, two snd_pcm_hw_param_near() calls for setting the period size and periods may influence on the final result of channels, rates, etc, too, while the current code has already created plugins beforehand with the premature values. So, the plugin believes that channels=1, while the actual I/O is with channels=2, which makes the driver reading/writing over the allocated buffer size. The fix is simply to move the plugin allocation code after the final hw_params call. Reported-by: syzbot+d4503ae45b65c5bc1194@syzkaller.appspotmail.com Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f98242a8debb8dd9fbbabc3ae1fc80c316cf8945 Author: Gustavo A. R. Silva Date: Wed Mar 20 18:42:01 2019 -0500 ALSA: seq: oss: Fix Spectre v1 vulnerability commit c709f14f0616482b67f9fbcb965e1493a03ff30b upstream. dev is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/core/seq/oss/seq_oss_synth.c:626 snd_seq_oss_synth_make_info() warn: potential spectre issue 'dp->synths' [w] (local cap) Fix this by sanitizing dev before using it to index dp->synths. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 619ae9f179dea5cae3a297ca3f06071fe2068c8a Author: Gustavo A. R. Silva Date: Wed Mar 20 16:15:24 2019 -0500 ALSA: rawmidi: Fix potential Spectre v1 vulnerability commit 2b1d9c8f87235f593826b9cf46ec10247741fff9 upstream. info->stream is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/core/rawmidi.c:604 __snd_rawmidi_info_select() warn: potential spectre issue 'rmidi->streams' [r] (local cap) Fix this by sanitizing info->stream before using it to index rmidi->streams. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e162927cd1617028a3e2e775a24a89fccb7f67fd Author: Ravindra Lokhande Date: Mon Dec 7 12:08:31 2015 +0530 ALSA: compress: add support for 32bit calls in a 64bit kernel commit c10368897e104c008c610915a218f0fe5fa4ec96 upstream. Compress offload does not support ioctl calls from a 32bit userspace in a 64 bit kernel. This patch adds support for ioctls from a 32bit userspace in a 64bit kernel Signed-off-by: Ravindra Lokhande Acked-by: Vinod Koul Signed-off-by: Takashi Iwai Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit ed2f3c82b0b48de01d9c74e73daef58d00035274 Author: Kohji Okuno Date: Tue Feb 26 11:34:13 2019 +0900 ARM: imx6q: cpuidle: fix bug that CPU might not wake up at expected time commit 91740fc8242b4f260cfa4d4536d8551804777fae upstream. In the current cpuidle implementation for i.MX6q, the CPU that sets 'WAIT_UNCLOCKED' and the CPU that returns to 'WAIT_CLOCKED' are always the same. While the CPU that sets 'WAIT_UNCLOCKED' is in IDLE state of "WAIT", if the other CPU wakes up and enters IDLE state of "WFI" istead of "WAIT", this CPU can not wake up at expired time. Because, in the case of "WFI", the CPU must be waked up by the local timer interrupt. But, while 'WAIT_UNCLOCKED' is set, the local timer is stopped, when all CPUs execute "wfi" instruction. As a result, the local timer interrupt is not fired. In this situation, this CPU will wake up by IRQ different from local timer. (e.g. broacast timer) So, this fix changes CPU to return to 'WAIT_CLOCKED'. Signed-off-by: Kohji Okuno Fixes: e5f9dec8ff5f ("ARM: imx6q: support WAIT mode using cpuidle") Cc: Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 61bde5e5af49f42c7d398d8bbbf4f0e9fae7ca72 Author: Andrea Righi Date: Thu Mar 14 08:56:28 2019 +0100 btrfs: raid56: properly unmap parity page in finish_parity_scrub() commit 3897b6f0a859288c22fb793fad11ec2327e60fcd upstream. Parity page is incorrectly unmapped in finish_parity_scrub(), triggering a reference counter bug on i386, i.e.: [ 157.662401] kernel BUG at mm/highmem.c:349! [ 157.666725] invalid opcode: 0000 [#1] SMP PTI The reason is that kunmap(p_page) was completely left out, so we never did an unmap for the p_page and the loop unmapping the rbio page was iterating over the wrong number of stripes: unmapping should be done with nr_data instead of rbio->real_stripes. Test case to reproduce the bug: - create a raid5 btrfs filesystem: # mkfs.btrfs -m raid5 -d raid5 /dev/sdb /dev/sdc /dev/sdd /dev/sde - mount it: # mount /dev/sdb /mnt - run btrfs scrub in a loop: # while :; do btrfs scrub start -BR /mnt; done BugLink: https://bugs.launchpad.net/bugs/1812845 Fixes: 5a6ac9eacb49 ("Btrfs, raid56: support parity scrub on raid56") CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Johannes Thumshirn Signed-off-by: Andrea Righi Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit a23f00416aaeb2c5b71fd954917d073c8f068c06 Author: Josef Bacik Date: Wed Mar 6 17:13:04 2019 -0500 btrfs: remove WARN_ON in log_dir_items commit 2cc8334270e281815c3850c3adea363c51f21e0d upstream. When Filipe added the recursive directory logging stuff in 2f2ff0ee5e430 ("Btrfs: fix metadata inconsistencies after directory fsync") he specifically didn't take the directory i_mutex for the children directories that we need to log because of lockdep. This is generally fine, but can lead to this WARN_ON() tripping if we happen to run delayed deletion's in between our first search and our second search of dir_item/dir_indexes for this directory. We expect this to happen, so the WARN_ON() isn't necessary. Drop the WARN_ON() and add a comment so we know why this case can happen. CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 48b22ac589985f10153afe09624950bb91aeb99a Author: Finn Thain Date: Sat Mar 16 14:21:19 2019 +1100 mac8390: Fix mmio access size probe [ Upstream commit bb9e5c5bcd76f4474eac3baf643d7a39f7bac7bb ] The bug that Stan reported is as follows. After a restart, a 16-bit NIC may be incorrectly identified as a 32-bit NIC and stop working. mac8390 slot.E: Memory length resource not found, probing mac8390 slot.E: Farallon EtherMac II-C (type farallon) mac8390 slot.E: MAC 00:00:c5:30:c2:99, IRQ 61, 32 KB shared memory at 0xfeed0000, 32-bit access. The bug never arises after a cold start and only intermittently after a warm start. (I didn't investigate why the bug is intermittent.) It turns out that memcpy_toio() is deprecated and memcmp_withio() also has issues. Replacing these calls with mmio accessors fixes the problem. Reported-and-tested-by: Stan Johnson Fixes: 2964db0f5904 ("m68k: Mac DP8390 update") Signed-off-by: Finn Thain Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 981cb03ec5a650c9ea06a3f7a7d316be1e0f00f1 Author: Xin Long Date: Mon Mar 18 19:47:00 2019 +0800 sctp: get sctphdr by offset in sctp_compute_cksum [ Upstream commit 273160ffc6b993c7c91627f5a84799c66dfe4dee ] sctp_hdr(skb) only works when skb->transport_header is set properly. But in Netfilter, skb->transport_header for ipv6 is not guaranteed to be right value for sctphdr. It would cause to fail to check the checksum for sctp packets. So fix it by using offset, which is always right in all places. v1->v2: - Fix the changelog. Fixes: e6d8b64b34aa ("net: sctp: fix and consolidate SCTP checksumming code") Reported-by: Li Shuang Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c5874f35b86b861ee33e377e5d10fa5d8c2cd981 Author: Zhiqiang Liu Date: Sat Mar 16 17:02:54 2019 +0800 vxlan: Don't call gro_cells_destroy() before device is unregistered [ Upstream commit cc4807bb609230d8959fd732b0bf3bd4c2de8eac ] Commit ad6c9986bcb62 ("vxlan: Fix GRO cells race condition between receive and link delete") fixed a race condition for the typical case a vxlan device is dismantled from the current netns. But if a netns is dismantled, vxlan_destroy_tunnels() is called to schedule a unregister_netdevice_queue() of all the vxlan tunnels that are related to this netns. In vxlan_destroy_tunnels(), gro_cells_destroy() is called and finished before unregister_netdevice_queue(). This means that the gro_cells_destroy() call is done too soon, for the same reasons explained in above commit. So we need to fully respect the RCU rules, and thus must remove the gro_cells_destroy() call or risk use after-free. Fixes: 58ce31cca1ff ("vxlan: GRO support at tunnel layer") Signed-off-by: Suanming.Mou Suggested-by: Eric Dumazet Reviewed-by: Stefano Brivio Reviewed-by: Zhiqiang Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6c362ffe2a22861c121e92dddb3f90047b1bb75d Author: Eric Dumazet Date: Tue Mar 19 05:45:35 2019 -0700 tcp: do not use ipv6 header for ipv4 flow [ Upstream commit 89e4130939a20304f4059ab72179da81f5347528 ] When a dual stack tcp listener accepts an ipv4 flow, it should not attempt to use an ipv6 header or tcp_v6_iif() helper. Fixes: 1397ed35f22d ("ipv6: add flowinfo for tcp6 pkt_options for all cases") Fixes: df3687ffc665 ("ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 617ac1aa4dd453bed175531894723f3fe2d763dc Author: Maxime Chevallier Date: Sat Mar 16 14:41:30 2019 +0100 packets: Always register packet sk in the same order [ Upstream commit a4dc6a49156b1f8d6e17251ffda17c9e6a5db78a ] When using fanouts with AF_PACKET, the demux functions such as fanout_demux_cpu will return an index in the fanout socket array, which corresponds to the selected socket. The ordering of this array depends on the order the sockets were added to a given fanout group, so for FANOUT_CPU this means sockets are bound to cpus in the order they are configured, which is OK. However, when stopping then restarting the interface these sockets are bound to, the sockets are reassigned to the fanout group in the reverse order, due to the fact that they were inserted at the head of the interface's AF_PACKET socket list. This means that traffic that was directed to the first socket in the fanout group is now directed to the last one after an interface restart. In the case of FANOUT_CPU, traffic from CPU0 will be directed to the socket that used to receive traffic from the last CPU after an interface restart. This commit introduces a helper to add a socket at the tail of a list, then uses it to register AF_PACKET sockets. Note that this changes the order in which sockets are listed in /proc and with sock_diag. Fixes: dc99f600698d ("packet: Add fanout support") Signed-off-by: Maxime Chevallier Acked-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dd3351b81fac8a7b431fe636fe35415e35f00fa0 Author: David S. Miller Date: Sat Apr 23 18:26:24 2016 -0400 Add hlist_add_tail_rcu() (Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) commit 1602f49b58abcb0d34a5f0a29d68e7c1769547aa upstream. [This commit was a merge, but it added hlist_add_tail_rcu(), which is what we need in this stable tree, so I've changed the subject to be more descriptive - gregkh] Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2c2d8a1c8f12537371b8ca1ca09702474072787d Author: Eric Dumazet Date: Fri Mar 15 10:41:14 2019 -0700 net: rose: fix a possible stack overflow [ Upstream commit e5dcc0c3223c45c94100f05f28d8ef814db3d82c ] rose_write_internal() uses a temp buffer of 100 bytes, but a manual inspection showed that given arbitrary input, rose_create_facilities() can fill up to 110 bytes. Lets use a tailroom of 256 bytes for peace of mind, and remove the bounce buffer : we can simply allocate a big enough skb and adjust its length as needed. syzbot report : BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:352 [inline] BUG: KASAN: stack-out-of-bounds in rose_create_facilities net/rose/rose_subr.c:521 [inline] BUG: KASAN: stack-out-of-bounds in rose_write_internal+0x597/0x15d0 net/rose/rose_subr.c:116 Write of size 7 at addr ffff88808b1ffbef by task syz-executor.0/24854 CPU: 0 PID: 24854 Comm: syz-executor.0 Not tainted 5.0.0+ #97 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187 kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x123/0x190 mm/kasan/generic.c:191 memcpy+0x38/0x50 mm/kasan/common.c:131 memcpy include/linux/string.h:352 [inline] rose_create_facilities net/rose/rose_subr.c:521 [inline] rose_write_internal+0x597/0x15d0 net/rose/rose_subr.c:116 rose_connect+0x7cb/0x1510 net/rose/af_rose.c:826 __sys_connect+0x266/0x330 net/socket.c:1685 __do_sys_connect net/socket.c:1696 [inline] __se_sys_connect net/socket.c:1693 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:1693 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x458079 Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f47b8d9dc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000458079 RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000004 RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f47b8d9e6d4 R13: 00000000004be4a4 R14: 00000000004ceca8 R15: 00000000ffffffff The buggy address belongs to the page: page:ffffea00022c7fc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0 flags: 0x1fffc0000000000() raw: 01fffc0000000000 0000000000000000 ffffffff022c0101 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88808b1ffa80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88808b1ffb00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 03 >ffff88808b1ffb80: f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 04 f3 ^ ffff88808b1ffc00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 ffff88808b1ffc80: 00 00 00 00 00 00 00 f1 f1 f1 f1 f1 f1 01 f2 01 Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b969da5f7e8de296757f23723a85819ec336e33d Author: Christoph Paasch Date: Mon Mar 18 23:14:52 2019 -0700 net/packet: Set __GFP_NOWARN upon allocation in alloc_pg_vec [ Upstream commit 398f0132c14754fcd03c1c4f8e7176d001ce8ea1 ] Since commit fc62814d690c ("net/packet: fix 4gb buffer limit due to overflow check") one can now allocate packet ring buffers >= UINT_MAX. However, syzkaller found that that triggers a warning: [ 21.100000] WARNING: CPU: 2 PID: 2075 at mm/page_alloc.c:4584 __alloc_pages_nod0 [ 21.101490] Modules linked in: [ 21.101921] CPU: 2 PID: 2075 Comm: syz-executor.0 Not tainted 5.0.0 #146 [ 21.102784] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011 [ 21.103887] RIP: 0010:__alloc_pages_nodemask+0x2a0/0x630 [ 21.104640] Code: fe ff ff 65 48 8b 04 25 c0 de 01 00 48 05 90 0f 00 00 41 bd 01 00 00 00 48 89 44 24 48 e9 9c fe 3 [ 21.107121] RSP: 0018:ffff88805e1cf920 EFLAGS: 00010246 [ 21.107819] RAX: 0000000000000000 RBX: ffffffff85a488a0 RCX: 0000000000000000 [ 21.108753] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000000000 [ 21.109699] RBP: 1ffff1100bc39f28 R08: ffffed100bcefb67 R09: ffffed100bcefb67 [ 21.110646] R10: 0000000000000001 R11: ffffed100bcefb66 R12: 000000000000000d [ 21.111623] R13: 0000000000000000 R14: ffff88805e77d888 R15: 000000000000000d [ 21.112552] FS: 00007f7c7de05700(0000) GS:ffff88806d100000(0000) knlGS:0000000000000000 [ 21.113612] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.114405] CR2: 000000000065c000 CR3: 000000005e58e006 CR4: 00000000001606e0 [ 21.115367] Call Trace: [ 21.115705] ? __alloc_pages_slowpath+0x21c0/0x21c0 [ 21.116362] alloc_pages_current+0xac/0x1e0 [ 21.116923] kmalloc_order+0x18/0x70 [ 21.117393] kmalloc_order_trace+0x18/0x110 [ 21.117949] packet_set_ring+0x9d5/0x1770 [ 21.118524] ? packet_rcv_spkt+0x440/0x440 [ 21.119094] ? lock_downgrade+0x620/0x620 [ 21.119646] ? __might_fault+0x177/0x1b0 [ 21.120177] packet_setsockopt+0x981/0x2940 [ 21.120753] ? __fget+0x2fb/0x4b0 [ 21.121209] ? packet_release+0xab0/0xab0 [ 21.121740] ? sock_has_perm+0x1cd/0x260 [ 21.122297] ? selinux_secmark_relabel_packet+0xd0/0xd0 [ 21.123013] ? __fget+0x324/0x4b0 [ 21.123451] ? selinux_netlbl_socket_setsockopt+0x101/0x320 [ 21.124186] ? selinux_netlbl_sock_rcv_skb+0x3a0/0x3a0 [ 21.124908] ? __lock_acquire+0x529/0x3200 [ 21.125453] ? selinux_socket_setsockopt+0x5d/0x70 [ 21.126075] ? __sys_setsockopt+0x131/0x210 [ 21.126533] ? packet_release+0xab0/0xab0 [ 21.127004] __sys_setsockopt+0x131/0x210 [ 21.127449] ? kernel_accept+0x2f0/0x2f0 [ 21.127911] ? ret_from_fork+0x8/0x50 [ 21.128313] ? do_raw_spin_lock+0x11b/0x280 [ 21.128800] __x64_sys_setsockopt+0xba/0x150 [ 21.129271] ? lockdep_hardirqs_on+0x37f/0x560 [ 21.129769] do_syscall_64+0x9f/0x450 [ 21.130182] entry_SYSCALL_64_after_hwframe+0x49/0xbe We should allocate with __GFP_NOWARN to handle this. Cc: Kal Conley Cc: Andrey Konovalov Fixes: fc62814d690c ("net/packet: fix 4gb buffer limit due to overflow check") Signed-off-by: Christoph Paasch Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3f1c0e4b79652cea3cecadf9af4ee5047a2de3d3 Author: Bjorn Helgaas Date: Mon Mar 18 08:51:06 2019 -0500 mISDN: hfcpci: Test both vendor & device ID for Digium HFC4S [ Upstream commit fae846e2b7124d4b076ef17791c73addf3b26350 ] The device ID alone does not uniquely identify a device. Test both the vendor and device ID to make sure we don't mistakenly think some other vendor's 0xB410 device is a Digium HFC4S. Also, instead of the bare hex ID, use the same constant (PCI_DEVICE_ID_DIGIUM_HFC4S) used in the device ID table. No functional change intended. Signed-off-by: Bjorn Helgaas Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2f242b299bcd79a8e4471c9c6e21c62219d350d7 Author: Eric Dumazet Date: Tue Mar 19 05:46:18 2019 -0700 dccp: do not use ipv6 header for ipv4 flow [ Upstream commit e0aa67709f89d08c8d8e5bdd9e0b649df61d0090 ] When a dual stack dccp listener accepts an ipv4 flow, it should not attempt to use an ipv6 header or inet6_iif() helper. Fixes: 3df80d9320bc ("[DCCP]: Introduce DCCPv6") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 46c8459158ae79db789d46b7cb6f1958e2627e9a Author: Bhadram Varka Date: Fri Oct 27 08:22:02 2017 +0530 stmmac: copy unicast mac address to MAC registers [ Upstream commit a830405ee452ddc4101c3c9334e6fedd42c6b357 ] Currently stmmac driver not copying the valid ethernet MAC address to MAC registers. This patch takes care of updating the MAC register with MAC address. Signed-off-by: Bhadram Varka Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 949c4ef45eee38d9aad5af5d28078be356c82360 Author: Johannes Berg Date: Mon Jan 9 11:10:42 2017 +0100 cfg80211: size various nl80211 messages correctly [ Upstream commit 4ef8c1c93f848e360754f10eb2e7134c872b6597 ] Ilan reported that sometimes nl80211 messages weren't working if the frames being transported got very large, which was really a problem for userspace-to-kernel messages, but prompted me to look at the code. Upon review, I found various places where variable-length data is transported in an nl80211 message but the message isn't allocated taking that into account. This shouldn't cause any problems since the frames aren't really that long, apart in one place where two (possibly very long frames) might not fit. Fix all the places (that I found) that get variable length data from the driver and put it into a message to take the length of the variable data into account. The 100 there is just a safe constant for the remaining message overhead (it's usually around 50 for most messages.) Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 695fc282c337c5f520582eaf3bda9b53319384e4 Author: Chaotian Jing Date: Thu May 19 16:47:42 2016 +0800 mmc: mmc: fix switch timeout issue caused by jiffies precision [ Upstream commit 987aa5f8059613bf85cbb6f64ffbd34f5cb7a9d1 ] with CONFIG_HZ=100, the precision of jiffies is 10ms, and the generic_cmd6_time of some card is also 10ms. then, may be current time is only 5ms, but already timed out caused by jiffies precision. Signed-off-by: Chaotian Jing Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit c89eceddfaeb07249b5043d98f8b51e7d04ec386 Author: Ezequiel Garcia Date: Wed Apr 27 13:55:28 2016 -0300 arm64: kconfig: drop CONFIG_RTC_LIB dependency [ Upstream commit 99a507771fa57238dc7ffe674ae06090333d02c9 ] The rtc-lib dependency is not required, and seems it was just copy-pasted from ARM's Kconfig. If platform requires rtc-lib, they should select it individually. Reviewed-by: Arnd Bergmann Signed-off-by: Ezequiel Garcia Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 4a024ea936b649db60f3f28f4c39d31984004b19 Author: Christoffer Dall Date: Tue Jul 3 17:43:09 2018 +0200 video: fbdev: Set pixclock = 0 in goldfishfb [ Upstream commit ace6033ec5c356615eaa3582fb1946e9eaff6662 ] User space Android code identifies pixclock == 0 as a sign for emulation and will set the frame rate to 60 fps when reading this value, which is the desired outcome. Signed-off-by: Christoffer Dall Signed-off-by: Peter Maydell Signed-off-by: Roman Kiryanov Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin commit d200cc995188b88832350fae508f79211a284ff7 Author: Lianwei Wang Date: Thu Jun 9 23:43:28 2016 -0700 cpu/hotplug: Handle unbalanced hotplug enable/disable [ Upstream commit 01b41159066531cc8d664362ff0cd89dd137bbfa ] When cpu_hotplug_enable() is called unbalanced w/o a preceeding cpu_hotplug_disable() the code emits a warning, but happily decrements the disabled counter. This causes the next operations to malfunction. Prevent the decrement and just emit a warning. Signed-off-by: Lianwei Wang Cc: peterz@infradead.org Cc: linux-pm@vger.kernel.org Cc: oleg@redhat.com Link: http://lkml.kernel.org/r/1465541008-12476-1-git-send-email-lianwei.wang@gmail.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 13e84cdbd790a9a567dcb6f206f755e20162ff43 Author: Xerox Lin Date: Wed Jun 29 14:34:21 2016 +0530 usb: gadget: rndis: free response queue during REMOTE_NDIS_RESET_MSG [ Upstream commit 207707d8fd48ebc977fb2b2794004a020e1ee08e ] When rndis data transfer is in progress, some Windows7 Host PC is not sending the GET_ENCAPSULATED_RESPONSE command for receiving the response for the previous SEND_ENCAPSULATED_COMMAND processed. The rndis function driver appends each response for the SEND_ENCAPSULATED_COMMAND in a queue. As the above process got corrupted, the Host sends a REMOTE_NDIS_RESET_MSG command to do a soft-reset. As the rndis response queue is not freed, the previous response is sent as a part of this REMOTE_NDIS_RESET_MSG's reset response and the Host block any more Rndis transfers. Hence free the rndis response queue as a part of this soft-reset so that the correct response for REMOTE_NDIS_RESET_MSG is sent properly during the response command. Signed-off-by: Rajkumar Raghupathy Signed-off-by: Xerox Lin [AmitP: Cherry-picked this patch and folded other relevant fixes from Android common kernel android-4.4] Signed-off-by: Amit Pundir Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 0752035a776efeaf615e9ebc0d94dafd1f209898 Author: Winter Wang Date: Wed Jul 27 10:03:19 2016 +0800 usb: gadget: configfs: add mutex lock before unregister gadget [ Upstream commit cee51c33f52ebf673a088a428ac0fecc33ab77fa ] There may be a race condition if f_fs calls unregister_gadget_item in ffs_closed() when unregister_gadget is called by UDC store at the same time. this leads to a kernel NULL pointer dereference: [ 310.644928] Unable to handle kernel NULL pointer dereference at virtual address 00000004 [ 310.645053] init: Service 'adbd' is being killed... [ 310.658938] pgd = c9528000 [ 310.662515] [00000004] *pgd=19451831, *pte=00000000, *ppte=00000000 [ 310.669702] Internal error: Oops: 817 [#1] PREEMPT SMP ARM [ 310.675211] Modules linked in: [ 310.678294] CPU: 0 PID: 1537 Comm: ->transport Not tainted 4.1.15-03725-g793404c #2 [ 310.685958] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 310.692493] task: c8e24200 ti: c945e000 task.ti: c945e000 [ 310.697911] PC is at usb_gadget_unregister_driver+0xb4/0xd0 [ 310.703502] LR is at __mutex_lock_slowpath+0x10c/0x16c [ 310.708648] pc : [] lr : [] psr: 600f0113 [ 311.565585] [] (usb_gadget_unregister_driver) from [] (unregister_gadget_item+0x1c/0x34) [ 311.575426] [] (unregister_gadget_item) from [] (ffs_closed+0x8c/0x9c) [ 311.583702] [] (ffs_closed) from [] (ffs_data_reset+0xc/0xa0) [ 311.591194] [] (ffs_data_reset) from [] (ffs_data_closed+0x90/0xd0) [ 311.599208] [] (ffs_data_closed) from [] (ffs_ep0_release+0xc/0x14) [ 311.607224] [] (ffs_ep0_release) from [] (__fput+0x80/0x1d0) [ 311.614635] [] (__fput) from [] (task_work_run+0xb0/0xe8) [ 311.621788] [] (task_work_run) from [] (do_work_pending+0x7c/0xa4) [ 311.629718] [] (do_work_pending) from [] (work_pending+0xc/0x20) for functions using functionFS, i.e. android adbd will close /dev/usb-ffs/adb/ep0 when usb IO thread fails, but switch adb from on to off also triggers write "none" > UDC. These 2 operations both call unregister_gadget, which will lead to the panic above. add a mutex before calling unregister_gadget for api used in f_fs. Signed-off-by: Winter Wang Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 01855b6299eb71f9d9aee7d2c8d5573ad1fd13c2 Author: Hannes Frederic Sowa Date: Sat Jun 11 20:32:06 2016 +0200 ipv6: fix endianness error in icmpv6_err [ Upstream commit dcb94b88c09ce82a80e188d49bcffdc83ba215a6 ] IPv6 ping socket error handler doesn't correctly convert the new 32 bit mtu to host endianness before using. Cc: Lorenzo Colitti Fixes: 6d0bfe22611602f ("net: ipv6: Add IPv6 support to the ping socket.") Signed-off-by: Hannes Frederic Sowa Acked-by: Lorenzo Colitti Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b0351a51ffda593b2b1b35dd0c00a73505edb256 Author: Alexander Shishkin Date: Fri Mar 4 16:48:14 2016 +0200 stm class: Fix stm device initialization order [ Upstream commit 389b6699a2aa0b457aa69986e9ddf39f3b4030fd ] Currently, stm_register_device() makes the device visible and then proceeds to initializing spinlocks and other properties, which leaves a window when the device can already be opened but is not yet fully operational. Fix this by reversing the initialization order. Reported-by: Alan Cox Signed-off-by: Alexander Shishkin Reviewed-by: Laurent Fert Signed-off-by: Sasha Levin commit 2040e80d8095e6aff0743944011cbaf94252ecc0 Author: Alexander Shishkin Date: Fri Mar 4 16:36:10 2016 +0200 stm class: Do not leak the chrdev in error path [ Upstream commit cbe4a61d1ddc4790d950ca8c33ef79ee68ef5e2b ] Currently, the error path of stm_register_device() forgets to unregister the chrdev. Fix this. Reported-by: Alan Cox Signed-off-by: Alexander Shishkin Reviewed-by: Laurent Fert Signed-off-by: Sasha Levin commit fbfaa26fa9e77f4b8b141f650340195f23cd7029 Author: James Morse Date: Wed Apr 27 17:47:11 2016 +0100 PM / Hibernate: Call flush_icache_range() on pages restored in-place [ Upstream commit f6cf0545ec697ddc278b7457b7d0c0d86a2ea88e ] Some architectures require code written to memory as if it were data to be 'cleaned' from any data caches before the processor can fetch them as new instructions. During resume from hibernate, the snapshot code copies some pages directly, meaning these architectures do not get a chance to perform their cache maintenance. Modify the read and decompress code to call flush_icache_range() on all pages that are restored, so that the restored in-place pages are guaranteed to be executable on these architectures. Signed-off-by: James Morse Acked-by: Pavel Machek Acked-by: Rafael J. Wysocki Acked-by: Catalin Marinas [will: make clean_pages_on_* static and remove initialisers] Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 60e4a50d332bbbb3cc62acee58fd04236f9d57a1 Author: James Morse Date: Wed Apr 27 17:47:08 2016 +0100 arm64: kernel: Include _AC definition in page.h [ Upstream commit 812264550dcba6cdbe84bfac2f27e7d23b5b8733 ] page.h uses '_AC' in the definition of PAGE_SIZE, but doesn't include linux/const.h where this is defined. This produces build warnings when only asm/page.h is included by asm code. Signed-off-by: James Morse Acked-by: Mark Rutland Acked-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 2ba2cca736d852cf0ec2fcd0b3e7148a3882adaa Author: Alexander Shishkin Date: Fri Mar 4 15:42:45 2016 +0200 perf/ring_buffer: Refuse to begin AUX transaction after rb->aux_mmap_count drops [ Upstream commit dcb10a967ce82d5ad20570693091139ae716ff76 ] When ring buffer's AUX area is unmapped and rb->aux_mmap_count drops to zero, new AUX transactions into this buffer can still be started, even though the buffer in en route to deallocation. This patch adds a check to perf_aux_output_begin() for rb->aux_mmap_count being zero, in which case there is no point starting new transactions, in other words, the ring buffers that pass a certain point in perf_mmap_close will not have their events sending new data, which clears path for freeing those buffers' pages right there and then, provided that no active transactions are holding the AUX reference. Signed-off-by: Alexander Shishkin Signed-off-by: Peter Zijlstra (Intel) Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: vince@deater.net Link: http://lkml.kernel.org/r/1457098969-21595-2-git-send-email-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit e5a19cf78a23d7b9d87ce3421fce27ffcd4ca986 Author: Jeff Mahoney Date: Mon Apr 4 14:15:23 2016 -0400 mac80211: fix "warning: ‘target_metric’ may be used uninitialized" [ Upstream commit b4201cc4fc6e1c57d6d306b1f787865043d60129 ] This fixes: net/mac80211/mesh_hwmp.c:603:26: warning: ‘target_metric’ may be used uninitialized in this function target_metric is only consumed when reply = true so no bug exists here, but not all versions of gcc realize it. Initialize to 0 to remove the warning. Signed-off-by: Jeff Mahoney Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 08d870c51ec512d9a7ec243aa24180e517243b32 Author: Ard Biesheuvel Date: Fri Mar 18 10:58:09 2016 +0100 arm64/kernel: fix incorrect EL0 check in inv_entry macro [ Upstream commit b660950c60a7278f9d8deb7c32a162031207c758 ] The implementation of macro inv_entry refers to its 'el' argument without the required leading backslash, which results in an undefined symbol 'el' to be passed into the kernel_entry macro rather than the index of the exception level as intended. This undefined symbol strangely enough does not result in build failures, although it is visible in vmlinux: $ nm -n vmlinux |head U el 0000000000000000 A _kernel_flags_le_hi32 0000000000000000 A _kernel_offset_le_hi32 0000000000000000 A _kernel_size_le_hi32 000000000000000a A _kernel_flags_le_lo32 ..... However, it does result in incorrect code being generated for invalid exceptions taken from EL0, since the argument check in kernel_entry assumes EL1 if its argument does not equal '0'. Signed-off-by: Ard Biesheuvel Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 823e262919f9c09cb077df5727fb85d1760aa275 Author: Lorenzo Pieralisi Date: Mon Feb 1 18:01:29 2016 +0100 ARM: 8510/1: rework ARM_CPU_SUSPEND dependencies [ Upstream commit 1b9bdf5c1661873a10e193b8cbb803a87fe5c4a1 ] The code enabled by the ARM_CPU_SUSPEND config option is used by kernel subsystems for purposes that go beyond system suspend so its config entry should be augmented to take more default options into account and avoid forcing its selection to prevent dependencies override. To achieve this goal, this patch reworks the ARM_CPU_SUSPEND config entry and updates its default config value (by adding the BL_SWITCHER option to it) and its dependencies (ARCH_SUSPEND_POSSIBLE), so that the symbol is still selected by default by the subsystems requiring it and at the same time enforcing the dependencies correctly. Signed-off-by: Lorenzo Pieralisi Cc: Nicolas Pitre Signed-off-by: Russell King Signed-off-by: Sasha Levin commit a99d340dc70bf970e8bb9872dd5766ed7c546cfe Author: Greg Hackmann Date: Fri Feb 26 19:00:18 2016 +0000 staging: goldfish: audio: fix compiliation on arm [ Upstream commit 4532150762ceb0d6fd765ebcb3ba6966fbb8faab ] We do actually need slab.h, by luck we get it on other platforms but not always on ARM. Include it properly. Signed-off-by: Greg Hackmann Signed-off-by: Jin Qian Signed-off-by: Alan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9d4b4395067b41e5065a20851f73979de41bd0f8 Author: Rajmal Menariya Date: Fri Jan 29 22:07:35 2016 -0800 staging: ion: Set minimum carveout heap allocation order to PAGE_SHIFT [ Upstream commit 1328d8efef17d5e16bd6e9cfe59130a833674534 ] In carveout heap, change minimum allocation order from 12 to PAGE_SHIFT. After this change each bit in bitmap (genalloc - General purpose special memory pool) represents one page size memory. Cc: sprd-ind-kernel-group@googlegroups.com Cc: sanjeev.yadav@spreadtrum.com Cc: Colin Cross Cc: Android Kernel Team Cc: Greg KH Cc: Sumit Semwal Signed-off-by: Rajmal Menariya [jstultz: Reworked commit message] Signed-off-by: John Stultz Acked-by: Laura Abbott Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit efa2ec29dd4ef93c1e5a7bd719f9b2e283513e76 Author: Rom Lemarchand Date: Fri Jan 29 22:07:31 2016 -0800 staging: ashmem: Add missing include [ Upstream commit 90a2f171383b5ae43b33ab4d9d566b9765622ac7 ] Include into ashmem.h to ensure referenced types are defined Cc: Android Kernel Team Cc: Greg KH Signed-off-by: Rom Lemarchand [jstultz: Minor commit message tweaks] Signed-off-by: John Stultz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4dcbf6fa3b47536e74be573ff5a2ff1d670a25aa Author: Laura Abbott Date: Fri Jan 29 22:07:30 2016 -0800 staging: ashmem: Avoid deadlock with mmap/shrink [ Upstream commit 18e77054de741ef3ed2a2489bc9bf82a318b2d5e ] Both ashmem_mmap and ashmem_shrink take the ashmem_lock. It may be possible for ashmem_mmap to invoke ashmem_shrink: -000|mutex_lock(lock = 0x0) -001|ashmem_shrink(?, sc = 0x0) <--- try to take ashmem_mutex again -002|shrink_slab(shrink = 0xDA5F1CC0, nr_pages_scanned = 0, lru_pages -002|= -002|124) -003|try_to_free_pages(zonelist = 0x0, ?, ?, ?) -004|__alloc_pages_nodemask(gfp_mask = 21200, order = 1, zonelist = -004|0xC11D0940, -005|new_slab(s = 0xE4841E80, ?, node = -1) -006|__slab_alloc.isra.43.constprop.50(s = 0xE4841E80, gfpflags = -006|2148925462, ad -007|kmem_cache_alloc(s = 0xE4841E80, gfpflags = 208) -008|shmem_alloc_inode(?) -009|alloc_inode(sb = 0xE480E800) -010|new_inode_pseudo(?) -011|new_inode(?) -012|shmem_get_inode(sb = 0xE480E800, dir = 0x0, ?, dev = 0, flags = -012|187) -013|shmem_file_setup(?, ?, flags = 187) -014|ashmem_mmap(?, vma = 0xC5D64210) <---- Acquire ashmem_mutex -015|mmap_region(file = 0xDF8E2C00, addr = 1772974080, len = 233472, -015|flags = 57, -016|sys_mmap_pgoff(addr = 0, len = 230400, prot = 3, flags = 1, fd = -016|157, pgoff -017|ret_fast_syscall(asm) -->|exception -018|NUR:0x40097508(asm) ---|end of frame Avoid this deadlock by using mutex_trylock in ashmem_shrink; if the mutex is already held, do not attempt to shrink. Cc: Greg KH Cc: Android Kernel Team Reported-by: Matt Wagantall Reported-by: Syed Rameez Mustafa Reported-by: Osvaldo Banuelos Reported-by: Subbaraman Narayanamurthy Signed-off-by: Laura Abbott [jstultz: Minor commit message tweaks] Signed-off-by: John Stultz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 021c0d5cdfc0e228963ade79c18015ce7cc181bb Author: Mark Rutland Date: Mon Jan 25 11:44:55 2016 +0000 asm-generic: Fix local variable shadow in __set_fixmap_offset [ Upstream commit 3694bd76781b76c4f8d2ecd85018feeb1609f0e5 ] Currently __set_fixmap_offset is a macro function which has a local variable called 'addr'. If a caller passes a 'phys' parameter which is derived from a variable also called 'addr', the local variable will shadow this, and the compiler will complain about the use of an uninitialized variable. To avoid the issue with namespace clashes, 'addr' is prefixed with a liberal sprinkling of underscores. Turning __set_fixmap_offset into a static inline breaks the build for several architectures. Fixing this properly requires updates to a number of architectures to make them agree on the prototype of __set_fixmap (it could be done as a subsequent patch series). Signed-off-by: Mark Rutland Cc: Arnd Bergmann [catalin.marinas@arm.com: squashed the original function patch and macro fixup] Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 43ea28e71c2d54cd40eeb97fcdf71da38f84c963 Author: Eric Long Date: Wed Feb 17 17:51:44 2016 -0700 coresight: etm4x: Check every parameter used by dma_xx_coherent. [ Upstream commit 61390593f72377c3a8f41ef998462e2d3985adac ] The dma_alloc_coherent return an "void *" not an "void __iomen *". It uses the wrong parameters when calls dma_free_coherent function. The sparse tool output logs as the following: coresight-tmc.c:199:23: expected void * coresight-tmc.c:199:23: got void [noderef] *vaddr coresight-tmc.c:336:30: warning: incorrect type in assignment (different address spaces) coresight-tmc.c:336:30: expected char *buf coresight-tmc.c:336:30: got void [noderef] * coresight-tmc.c:769:50: warning: incorrect type in argument 4 (different base types) coresight-tmc.c:769:50: expected unsigned long long [unsigned] [usertype] dma_handle coresight-tmc.c:769:50: got restricted gfp_t Signed-off-by: Eric Long Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 58af2f0f6fdfe07c031ecc2181428cfcdc63584b Author: Eric Long Date: Wed Feb 17 17:51:43 2016 -0700 coresight: "DEVICE_ATTR_RO" should defined as static. [ Upstream commit bf16e5b8cdeabc1fe6565af0be475bb2084dc388 ] "DEVICE_ATTR_RO(name)" should be defined as static. And there is an unnecessary space at the front of the code. The sparse tool output logs as the following: coresight-etm4x.c:2224:1: warning: symbol 'dev_attr_trcoslsr' was not declared. Should it be static? coresight-etm4x.c:2225:1: warning: symbol 'dev_attr_trcpdcr' was not declared. Should it be static? coresight-etm4x.c:2226:1: warning: symbol 'dev_attr_trcpdsr' was not declared. Should it be static? And the smatch tool output logs as the following: of_coresight.c:89 of_coresight_alloc_memory() warn: inconsistent indenting Signed-off-by: Eric Long Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c66866b13b3c43606bf12d55988d1948e5e03511 Author: Alexander Shishkin Date: Mon Feb 15 19:12:08 2016 +0200 stm class: Fix a race in unlinking [ Upstream commit b4ca34aaf78ed0cdfc15956d377064104257a437 ] There is a window in stm_source_link_drop(), during which the source's link may change before locks are acquired. When this happens, it throws a warning, since this is not an expected scenario. This patch handles the race in such a way that if the link appears to have changed by the time we took the locks, it will release them and repeat the whole unlinking procedure from the beginning, unless the other contender beat us to it. Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8c0bfd9d7cb3e306df32057bc120d1ea8c17830d Author: Alexander Shishkin Date: Mon Feb 15 19:12:07 2016 +0200 stm class: Fix unbalanced module/device refcounting [ Upstream commit f7c81c7176c72c7899390754b4b038a64b296e4d ] STM code takes references to the stm device and its module for the duration of the character device's existence or the stm_source link. Dropping these references is not well balanced everywhere, which may lead to leaks. This patch balances the acquisition and releasing of these two references and annotates each site so that it's easier to verify correctness by reading the code. Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f34bc5ad7a8415944a0bfe7dc005f50811651260 Author: Alexander Shishkin Date: Mon Feb 15 19:12:06 2016 +0200 stm class: Guard output assignment against concurrency [ Upstream commit cde4ad8368840e414ecf67db258fe1dabaa5fd2e ] It is possible to concurrently assign the same output (a character device writer or an stm_source device) to different stm devices, which sets off a strategically placed warning in stm_output_assign(). To avoid this, use a spinlock to serialize (un)assignments between outputs and stm devices. Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bc9d781bed9db2fc53da97d9559479e30f509374 Author: Alexander Shishkin Date: Mon Feb 15 19:12:05 2016 +0200 stm class: Fix unlocking braino in the error path [ Upstream commit 1810f2c44817c74ca3d05d1e3981e3a2e2ceb6f5 ] If an illegal attempt is made to unlink stm source device from an stm device, the stm device's link spinlock mistakenly remains locked. While this really shouldn't happen (there's a warning in place), the locking should remain in order so that we can still recover from this situation if it indeed does happen. This patch unifies the unlocking in the exit path of __stm_source_link_drop() to fix this. Reported-by: Laurent Fert Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 65b52bbc35a6c996e92f67301fd0fc85cf523496 Author: Alexander Shishkin Date: Mon Feb 15 19:12:02 2016 +0200 stm class: Support devices with multiple instances [ Upstream commit 59be422e4ce10e3d49d4c9407a80fab8a9b7bc84 ] By convention, the name of the stm policy directory in configfs consists of the device name to which it applies and the actual policy name, separated by a dot. Now, some devices already have dots in their names that separate name of the actual device from its instance identifier. Such devices will result in two (or more, who can tell) dots in the policy directory name. Existing policy code, however, will treat the first dot as the one that separates device name from policy name, therefore failing the above case. This patch makes the last dot in the directory name be the separator, thus prohibiting dots from being used in policy names. Suggested-by: Chunyan Zhang Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ffb2f3f86b3a6e0ef2b9c6f53e1e98931061db9b Author: Alexander Shishkin Date: Tue Dec 22 17:25:21 2015 +0200 stm class: Prevent user-controllable allocations [ Upstream commit f08b18266c7116e2ec6885dd53a928f580060a71 ] Currently, the character device write method allocates a temporary buffer for user's data, but the user's data size is not sanitized and can cause arbitrarily large allocations via kzalloc() or an integer overflow that will then result in overwriting kernel memory. This patch trims the input buffer size to avoid these issues. Reported-by: Sasha Levin Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 30e94dc24edd8d028da6a02d1a85028ead2f40ed Author: Alexander Shishkin Date: Tue Dec 22 17:25:19 2015 +0200 stm class: Fix link list locking [ Upstream commit c74f7e8281add80bdfa0ad2998b8df287b13df73 ] Currently, the list of stm_sources linked to an stm device is protected by a spinlock, which also means that sources' .unlink() method is called under this spinlock. However, this method may (and does) sleep, which means trouble. This patch slightly reworks locking around stm::link_list so that bits that might_sleep() are called with a mutex held instead. Modification of this list requires both mutex and spinlock to be held, while looking at the list can be done under either mutex or spinlock. Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a556f0babe56eacf66aee9cc88f4cff98d90d727 Author: Alexander Shishkin Date: Tue Dec 22 17:25:18 2015 +0200 stm class: Fix locking in unbinding policy path [ Upstream commit 4c127fd16e6b33ecb7badc091480c84ea9aebeb6 ] Right now, if stm device removal has to unbind from a policy (that is, an stm device that has STP policy, gets removed), it will trigger a nested lock on the stm device's policy mutex. This patch fixes the problem by moving the locking from the policy unbinding to policy removal (configfs path), where it's actually needed; the other caller of the policy unbinding function already takes the mutex around the call. Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 03d7b4edf78a976f5d7e74f7ed17a10bb7550e9a Author: Mathieu Poirier Date: Tue Feb 2 14:13:59 2016 -0700 coresight: remove csdev's link from topology [ Upstream commit ad725aee070caf8fa93d84d6fb78321f9642db18 ] In function 'coresight_unregister()', all references to the csdev that is being taken away need to be removed from the topology. Otherwise building the next coresight path from source to sink may use memory that has been released. Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a2828b9445919489c10afb2dab09b1e41676df6f Author: Mathieu Poirier Date: Tue Feb 2 14:13:58 2016 -0700 coresight: release reference taken by 'bus_find_device()' [ Upstream commit f2dfab3568fc32afeac8b698481e80e7ab2dc658 ] The reference count taken by function bus_find_device() needs to be released if a child device is found, something this patch is adding. Reported-by: Rabin Vincent Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3e2070abcc90909d6a10e32ba8cda5529a978e8c Author: Mathieu Poirier Date: Tue Feb 2 14:13:57 2016 -0700 coresight: coresight_unregister() function cleanup [ Upstream commit fae54158792aec705620bdc3938d342879204f0c ] In its current form the code never frees csdev->refcnt allocated in coresight_register(). There is also a problem with csdev->conns that is freed before device_unregister() rather than in the device release function. This patch addresses both issues by moving kfree(csdev->conns) to coresight_device_release() and freeing csdev->refcnt, also in the same function. Reported-by: Rabin Vincent Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f485f972de3d1d8497a5bffd84f8dd6ba5aee3ad Author: Mathieu Poirier Date: Tue Feb 2 14:13:56 2016 -0700 coresight: fixing lockdep error [ Upstream commit a9ddc71f5840c2711e530f2e055b278f79948b29 ] On some platform the following lockdep error occurs when doing simple manipulations: [ 23.197021] [ 23.198608] ====================================================== [ 23.205078] [ INFO: possible circular locking dependency detected ] [ 23.211639] 4.4.0-rc8-00025-gbbf360b #172 Not tainted [ 23.216918] ------------------------------------------------------- [ 23.223480] sh/858 is trying to acquire lock: [ 23.228057] (coresight_mutex){+.+.+.}, at: [] coresight_enable+0x1c/0x1b4 [ 23.236206] [ 23.236206] but task is already holding lock: [ 23.242309] (s_active#52){++++.+}, at: [] kernfs_fop_write+0x5c/0x1c0 [ 23.250122] [ 23.250122] which lock already depends on the new lock. [ 23.250122] [ 23.258697] [ 23.258697] the existing dependency chain (in reverse order) is: [ 23.266510] -> #1 (s_active#52){++++.+}: [ 23.270843] [] __kernfs_remove+0x294/0x35c [ 23.276672] [] kernfs_remove_by_name_ns+0x44/0x8c [ 23.283172] [] remove_files+0x3c/0x84 [ 23.288543] [] sysfs_remove_group+0x48/0x9c [ 23.294494] [] sysfs_remove_groups+0x2c/0x3c [ 23.300506] [] device_remove_attrs+0x5c/0x74 [ 23.306549] [] device_del+0x110/0x218 [ 23.311950] [] device_unregister+0x2c/0x6c [ 23.317779] [] coresight_unregister+0x30/0x40 [ 23.323883] [] etm_probe+0x228/0x2e8 [ 23.329193] [] amba_probe+0xe4/0x160 [ 23.334503] [] driver_probe_device+0x23c/0x480 [ 23.340728] [] __driver_attach+0x9c/0xa0 [ 23.346374] [] bus_for_each_dev+0x70/0xa4 [ 23.352142] [] driver_attach+0x24/0x28 [ 23.357604] [] bus_add_driver+0x1e0/0x278 [ 23.363372] [] driver_register+0x80/0x100 [ 23.369110] [] amba_driver_register+0x58/0x5c [ 23.375244] [] etm_driver_init+0x18/0x1c [ 23.380889] [] do_one_initcall+0xc4/0x20c [ 23.386657] [] kernel_init_freeable+0x160/0x208 [ 23.392974] [] kernel_init+0x18/0xf0 [ 23.398254] [] ret_from_fork+0x14/0x24 [ 23.403747] -> #0 (coresight_mutex){+.+.+.}: [ 23.408447] [] lock_acquire+0xe4/0x210 [ 23.413909] [] mutex_lock_nested+0x74/0x450 [ 23.419860] [] coresight_enable+0x1c/0x1b4 [ 23.425689] [] enable_source_store+0x58/0x68 [ 23.431732] [] dev_attr_store+0x20/0x2c [ 23.437286] [] sysfs_kf_write+0x50/0x54 [ 23.442871] [] kernfs_fop_write+0xc4/0x1c0 [ 23.448699] [] __vfs_write+0x34/0xe4 [ 23.454040] [] vfs_write+0x98/0x174 [ 23.459228] [] SyS_write+0x4c/0xa8 [ 23.464355] [] ret_fast_syscall+0x0/0x1c [ 23.470031] [ 23.470031] other info that might help us debug this: [ 23.470031] [ 23.478393] Possible unsafe locking scenario: [ 23.478393] [ 23.484619] CPU0 CPU1 [ 23.489349] ---- ---- [ 23.494079] lock(s_active#52); [ 23.497497] lock(coresight_mutex); [ 23.503906] lock(s_active#52); [ 23.509918] lock(coresight_mutex); [ 23.513702] [ 23.513702] *** DEADLOCK *** [ 23.513702] [ 23.519897] 3 locks held by sh/858: [ 23.523529] #0: (sb_writers#7){.+.+.+}, at: [] __sb_start_write+0xa8/0xd4 [ 23.531799] #1: (&of->mutex){+.+...}, at: [] kernfs_fop_write+0x54/0x1c0 [ 23.539916] #2: (s_active#52){++++.+}, at: [] kernfs_fop_write+0x5c/0x1c0 [ 23.548156] [ 23.548156] stack backtrace: [ 23.552734] CPU: 0 PID: 858 Comm: sh Not tainted 4.4.0-rc8-00025-gbbf360b #172 [ 23.560302] Hardware name: Generic OMAP4 (Flattened Device Tree) [ 23.566589] Backtrace: [ 23.569152] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [ 23.577087] r7:ed4b8570 r6:c0936400 r5:c07ae71c r4:00000000 [ 23.583038] [] (show_stack) from [] (dump_stack+0x98/0xc0) [ 23.590606] [] (dump_stack) from [] (print_circular_bug+0x21c/0x33c) [ 23.599090] r5:c0939d60 r4:c0936400 [ 23.602874] [] (print_circular_bug) from [] (__lock_acquire+0x1c98/0x1d88) [ 23.611877] r10:00000003 r9:c0fd7a5c r8:ed4b8550 r7:ed4b8570 r6:ed4b8000 r5:c0ff69e4 [ 23.620117] r4:c0936400 r3:ed4b8550 [ 23.623901] [] (__lock_acquire) from [] (lock_acquire+0xe4/0x210) [ 23.632080] r10:00000000 r9:00000000 r8:60000013 r7:c07cb7b4 r6:00000001 r5:00000000 [ 23.640350] r4:00000000 [ 23.643005] [] (lock_acquire) from [] (mutex_lock_nested+0x74/0x450) [ 23.651458] r10:ecc0bf80 r9:edbe7dcc r8:ed4b8000 r7:c0fd7a5c r6:c0415d40 r5:00000000 [ 23.659729] r4:c07cb780 [ 23.662384] [] (mutex_lock_nested) from [] (coresight_enable+0x1c/0x1b4) [ 23.671234] r10:ecc0bf80 r9:edbe7dcc r8:ed733c00 r7:00000000 r6:ed733c00 r5:00000002 [ 23.679473] r4:ed762140 [ 23.682128] [] (coresight_enable) from [] (enable_source_store+0x58/0x68) [ 23.691070] r7:00000000 r6:ed733c00 r5:00000002 r4:ed762160 [ 23.697052] [] (enable_source_store) from [] (dev_attr_store+0x20/0x2c) [ 23.705780] r5:edbe7dc0 r4:c0415fd8 [ 23.709533] [] (dev_attr_store) from [] (sysfs_kf_write+0x50/0x54) [ 23.717834] r5:edbe7dc0 r4:c030b338 [ 23.721618] [] (sysfs_kf_write) from [] (kernfs_fop_write+0xc4/0x1c0) [ 23.730163] r7:00000000 r6:00000000 r5:00000002 r4:edbe7dc0 [ 23.736145] [] (kernfs_fop_write) from [] (__vfs_write+0x34/0xe4) [ 23.744323] r10:00000000 r9:ecc0a000 r8:c0010964 r7:ecc0bf80 r6:00000002 r5:c01d4ae4 [ 23.752593] r4:ee385a40 [ 23.755249] [] (__vfs_write) from [] (vfs_write+0x98/0x174) [ 23.762908] r9:ecc0a000 r8:c0010964 r7:ecc0bf80 r6:000ab0d8 r5:00000002 r4:ee385a40 [ 23.771057] [] (vfs_write) from [] (SyS_write+0x4c/0xa8) [ 23.778442] r8:c0010964 r7:00000002 r6:000ab0d8 r5:ee385a40 r4:ee385a40 [ 23.785522] [] (SyS_write) from [] (ret_fast_syscall+0x0/0x1c) [ 23.793457] r7:00000004 r6:00000001 r5:000ab0d8 r4:00000002 [ 23.799652] coresight-etb10 54162000.etb: ETB enabled [ 23.805084] coresight-funnel 54164000.funnel: FUNNEL inport 0 enabled [ 23.811859] coresight-replicator 44000000.ocp:replicator: REPLICATOR enabled [ 23.819335] coresight-funnel 54158000.funnel: FUNNEL inport 0 enabled [ 23.826110] coresight-etm3x 5414c000.ptm: ETM tracing enabled The locking in coresight_unregister() is not required as the only customers of the function are drivers themselves when an initialisation failure has been encoutered. Reported-by: Rabin Vincent Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9bda5e6b1819daf09fafb66c2e9d4f0625ac8ad4 Author: Tahsin Erdogan Date: Tue Feb 16 13:34:39 2016 -0800 writeback: initialize inode members that track writeback history [ Upstream commit 3d65ae4634ed8350aee98a4e6f4e41fe40c7d282 ] inode struct members that track cgroup writeback information should be reinitialized when inode gets allocated from kmem_cache. Otherwise, their values remain and get used by the new inode. Signed-off-by: Tahsin Erdogan Acked-by: Tejun Heo Fixes: d10c80955265 ("writeback: implement foreign cgroup inode bdi_writeback switching") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cb8251f8d66785fbd8cc8f3ffc38bafdd5017272 Author: Ulf Hansson Date: Thu Feb 11 16:42:58 2016 +0100 Revert "mmc: block: don't use parameter prefix if built as module" [ Upstream commit a5ebb87db84392edfd3142c3a6a78431d820a789 ] This reverts commit 829b6962f7e3cfc06f7c5c26269fd47ad48cf503. Revert this change as it causes a sysfs path to change and therefore introduces and ABI regression. More precisely Android's vold is not being able to access /sys/module/mmcblk/parameters/perdev_minors any more, since the path becomes changed to: "/sys/module/mmc_block/..." Fixes: 829b6962f7e3 ("mmc: block: don't use parameter prefix if built as module") Reported-by: John Stultz Cc: Andy Shevchenko Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit ab3f1a5b9ce54a4509824ae4336e3fa5ca65ffa6 Author: Eric Dumazet Date: Wed Jan 20 16:25:01 2016 -0800 net: diag: support v4mapped sockets in inet_diag_find_one_icsk() [ Upstream commit 7c1306723ee916ea9f1fa7d9e4c7a6d029ca7aaf ] Lorenzo reported that we could not properly find v4mapped sockets in inet_diag_find_one_icsk(). This patch fixes the issue. Reported-by: Lorenzo Colitti Signed-off-by: Eric Dumazet Acked-by: Lorenzo Colitti Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6f311381f318a1c756075848784cd39cf32fa6e3 Author: Alexander Shishkin Date: Tue Jan 19 17:14:29 2016 +0200 perf: Synchronously free aux pages in case of allocation failure [ Upstream commit 45c815f06b80031659c63d7b93e580015d6024dd ] We are currently using asynchronous deallocation in the error path in AUX mmap code, which is unnecessary and also presents a problem for users that wish to probe for the biggest possible buffer size they can get: they'll get -EINVAL on all subsequent attemts to allocate a smaller buffer before the asynchronous deallocation callback frees up the pages from the previous unsuccessful attempt. Currently, gdb does that for allocating AUX buffers for Intel PT traces. More specifically, overwrite mode of AUX pmus that don't support hardware sg (some implementations of Intel PT, for instance) is limited to only one contiguous high order allocation for its buffer and there is no way of knowing its size without trying. This patch changes error path freeing to be synchronous as there won't be any contenders for the AUX pages at that point. Reported-by: Markus Metzger Signed-off-by: Alexander Shishkin Signed-off-by: Peter Zijlstra (Intel) Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: David Ahern Cc: Jiri Olsa Cc: Linus Torvalds Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: vince@deater.net Link: http://lkml.kernel.org/r/1453216469-9509-1-git-send-email-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit b6496f00a29def9176bae3b63b739ff7454b783a Author: Ard Biesheuvel Date: Fri Jan 15 13:28:57 2016 +0100 arm64: hide __efistub_ aliases from kallsyms [ Upstream commit 75feee3d9d51775072d3a04f47d4a439a4c4590e ] Commit e8f3010f7326 ("arm64/efi: isolate EFI stub from the kernel proper") isolated the EFI stub code from the kernel proper by prefixing all of its symbols with __efistub_, and selectively allowing access to core kernel symbols from the stub by emitting __efistub_ aliases for functions and variables that the stub can access legally. As an unintended side effect, these aliases are emitted into the kallsyms symbol table, which means they may turn up in backtraces, e.g., ... PC is at __efistub_memset+0x108/0x200 LR is at fixup_init+0x3c/0x48 ... [] __efistub_memset+0x108/0x200 [] free_initmem+0x2c/0x40 [] kernel_init+0x20/0xe0 [] ret_from_fork+0x10/0x40 The backtrace in question has nothing to do with the EFI stub, but simply returns one of the several aliases of memset() that have been recorded in the kallsyms table. This is undesirable, since it may suggest to people who are not aware of this that the issue they are seeing is somehow EFI related. So hide the __efistub_ aliases from kallsyms, by emitting them as absolute linker symbols explicitly. The distinction between those and section relative symbols is completely irrelevant to these definitions, and to the final link we are performing when these definitions are being taken into account (the distinction is only relevant to symbols defined inside a section definition when performing a partial link), and so the resulting values are identical to the original ones. Since absolute symbols are ignored by kallsyms, this will result in these values to be omitted from its symbol table. After this patch, the backtrace generated from the same address looks like this: ... PC is at __memset+0x108/0x200 LR is at fixup_init+0x3c/0x48 ... [] __memset+0x108/0x200 [] free_initmem+0x2c/0x40 [] kernel_init+0x20/0xe0 [] ret_from_fork+0x10/0x40 Signed-off-by: Ard Biesheuvel Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 2aeca9a27ba4155e413648cc1f498e68c9dd46f0 Author: Nicolas Pitre Date: Tue Nov 3 17:01:46 2015 -0500 hid-sensor-hub.c: fix wrong do_div() usage [ Upstream commit 8d43b49e7e0070f96ac46d30659a336c0224fa0b ] do_div() must only be used with a u64 dividend. Signed-off-by: Nicolas Pitre Signed-off-by: Sasha Levin commit bdf3c006b9a2308f481ca070d3a85baf1bc5d48f Author: Christoph Lameter Date: Thu Jan 14 15:21:40 2016 -0800 vmstat: make vmstat_updater deferrable again and shut down on idle [ Upstream commit 0eb77e9880321915322d42913c3b53241739c8aa ] Currently the vmstat updater is not deferrable as a result of commit ba4877b9ca51 ("vmstat: do not use deferrable delayed work for vmstat_update"). This in turn can cause multiple interruptions of the applications because the vmstat updater may run at Make vmstate_update deferrable again and provide a function that folds the differentials when the processor is going to idle mode thus addressing the issue of the above commit in a clean way. Note that the shepherd thread will continue scanning the differentials from another processor and will reenable the vmstat workers if it detects any changes. Fixes: ba4877b9ca51 ("vmstat: do not use deferrable delayed work for vmstat_update") Signed-off-by: Christoph Lameter Cc: Michal Hocko Cc: Johannes Weiner Cc: Tetsuo Handa Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 119dbcde59da0d44c6f39a4d83b01577910303d4 Author: Dmitry Torokhov Date: Mon Dec 14 17:34:08 2015 -0800 android: unconditionally remove callbacks in sync_fence_free() [ Upstream commit 699f685569434510d944e419f4048c4e3ba8d631 ] Using fence->status to determine whether or not there are callbacks remaining on the sync_fence is racy since fence->status may have been decremented to 0 on another CPU before fence_check_cb_func() has completed. By unconditionally calling fence_remove_callback() for each fence in the sync_fence, we guarantee that each callback has either completed (since fence_remove_callback() grabs the fence lock) or been removed. Signed-off-by: Andrew Bresticker Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7276c3fbd3b680df29732e443780de6117546b9e Author: Jungseung Lee Date: Tue Dec 29 05:47:00 2015 +0100 ARM: 8494/1: mm: Enable PXN when running non-LPAE kernel on LPAE processor [ Upstream commit ad84f56bf6d620fe6ed4d57ce6ec9945684d7f35 ] The VMSA field of MMFR0 (bottom 4 bits) is incremented for each added feature. PXN is supported if the value is >= 4 and LPAE is supported if it is >= 5. In case a kernel with CONFIG_ARM_LPAE disabled is used on a processor that supports LPAE, we can still use PXN in short descriptors. So check for >= 4 not == 4. Signed-off-by: Jungseung Lee Acked-by: Catalin Marinas Signed-off-by: Ben Hutchings Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 717da8c75b412e6873259ccc878a99fc932ac969 Author: Arnd Bergmann Date: Thu Nov 19 15:49:23 2015 +0100 ARM: 8458/1: bL_switcher: add GIC dependency [ Upstream commit 6c044fecdf78be3fda159a5036bb33700cdd5e59 ] It is not possible to build the bL_switcher code if the GIC driver is disabled, because it relies on calling into some gic specific interfaces, and that would result in this build error: arch/arm/common/built-in.o: In function `bL_switch_to': :(.text+0x1230): undefined reference to `gic_get_sgir_physaddr' :(.text+0x1244): undefined reference to `gic_send_sgi' :(.text+0x1268): undefined reference to `gic_migrate_target' arch/arm/common/built-in.o: In function `bL_switcher_enable.part.4': :(.text.unlikely+0x2f8): undefined reference to `gic_get_cpu_id' This adds a Kconfig dependency to ensure we only build the big-little switcher if the GIC driver is present as well. Almost all ARMv7 platforms come with a GIC anyway, but it is possible to build a kernel that disables all platforms. Signed-off-by: Arnd Bergmann Acked-by: Nicolas Pitre Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 1f2c3b46811d9fa157e3e8a4b0f700a5c488ee1a Author: Ard Biesheuvel Date: Wed Dec 23 10:29:28 2015 +0100 efi: stub: define DISABLE_BRANCH_PROFILING for all architectures [ Upstream commit b523e185bba36164ca48a190f5468c140d815414 ] This moves the DISABLE_BRANCH_PROFILING define from the x86 specific to the general CFLAGS definition for the stub. This fixes build errors when building for arm64 with CONFIG_PROFILE_ALL_BRANCHES_ENABLED. Reviewed-by: Matt Fleming Reported-by: Will Deacon Signed-off-by: Ard Biesheuvel Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 599dcbf7e8c65094bfc3b5e5d8adb9236eef465b Author: Yury Norov Date: Wed Dec 2 14:00:10 2015 +0000 arm64: fix COMPAT_SHMLBA definition for large pages [ Upstream commit b9b7aebb42d1b1392f3111de61136bb6cf3aae3f ] ARM glibc uses (4 * __getpagesize()) for SHMLBA, which is correct for 4KB pages and works fine for 64KB pages, but the kernel uses a hardcoded 16KB that is too small for 64KB page based kernels. This changes the definition to what user space sees when using 64KB pages. Acked-by: Arnd Bergmann Signed-off-by: Yury Norov Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 4afe1affaa6d3ffac7bf97ff05fca442c61a36a3 Author: Colin Cross Date: Thu Oct 22 10:00:41 2015 -0700 mmc: block: Allow more than 8 partitions per card [ Upstream commit 382c55f88ffeb218c446bf0c46d0fc25d2795fe2 ] It is quite common for Android devices to utilize more then 8 partitions on internal eMMC storage. The vanilla kernel can support this via CONFIG_MMC_BLOCK_MINORS, however that solution caps the system to 256 minors total, which limits the number of mmc cards the system can support. This patch, which has been carried for quite awhile in the AOSP common tree, provides an alternative solution that doesn't seem to limit the total card count. So I wanted to submit it for consideration upstream. This patch sets the GENHD_FL_EXT_DEVT flag, which will allocate minor number in major 259 for partitions past disk->minors. It also removes the use of disk_devt to determine devidx from md->disk. md->disk->first_minor is always initialized from devidx and can always be used to recover it. Cc: Ulf Hansson Cc: Adrian Hunter Cc: Ben Hutchings Cc: Chuanxiao Dong Cc: Shawn Lin Cc: Austin S Hemmelgarn Cc: Arnd Bergmann Cc: Android Kernel Team Cc: linux-mmc@vger.kernel.org Signed-off-by: Colin Cross [jstultz: Added context to commit message] Signed-off-by: John Stultz Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit e43196819cc3d2ac044f1669741f440397b82692 Author: Yuyang Du Date: Thu Dec 17 07:34:27 2015 +0800 sched/fair: Fix new task's load avg removed from source CPU in wake_up_new_task() [ Upstream commit 0905f04eb21fc1c2e690bed5d0418a061d56c225 ] If a newly created task is selected to go to a different CPU in fork balance when it wakes up the first time, its load averages should not be removed from the source CPU since they are never added to it before. The same is also applicable to a never used group entity. Fix it in remove_entity_load_avg(): when entity's last_update_time is 0, simply return. This should precisely identify the case in question, because in other migrations, the last_update_time is set to 0 after remove_entity_load_avg(). Reported-by: Steve Muckle Signed-off-by: Yuyang Du [peterz: cfs_rq_last_update_time] Signed-off-by: Peter Zijlstra (Intel) Cc: Dietmar Eggemann Cc: Juri Lelli Cc: Linus Torvalds Cc: Mike Galbraith Cc: Morten Rasmussen Cc: Patrick Bellasi Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Vincent Guittot Link: http://lkml.kernel.org/r/20151216233427.GJ28098@intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit ade4560e4fea198866e033fe1c02f063d6d7db2e Author: Marcel Holtmann Date: Fri Jan 18 13:43:19 2019 +0100 Bluetooth: Verify that l2cap_get_conf_opt provides large enough buffer commit 7c9cbd0b5e38a1672fcd137894ace3b042dfbf69 upstream. The function l2cap_get_conf_opt will return L2CAP_CONF_OPT_SIZE + opt->len as length value. The opt->len however is in control over the remote user and can be used by an attacker to gain access beyond the bounds of the actual packet. To prevent any potential leak of heap memory, it is enough to check that the resulting len calculation after calling l2cap_get_conf_opt is not below zero. A well formed packet will always return >= 0 here and will end with the length value being zero after the last option has been parsed. In case of malformed packets messing with the opt->len field the length value will become negative. If that is the case, then just abort and ignore the option. In case an attacker uses a too short opt->len value, then garbage will be parsed, but that is protected by the unknown option handling and also the option parameter size checks. Signed-off-by: Marcel Holtmann Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hedberg Signed-off-by: Greg Kroah-Hartman commit d22036003893cbe479404e20fdae10addc6c18dd Author: Marcel Holtmann Date: Fri Jan 18 12:56:20 2019 +0100 Bluetooth: Check L2CAP option sizes returned from l2cap_get_conf_opt commit af3d5d1c87664a4f150fcf3534c6567cb19909b0 upstream. When doing option parsing for standard type values of 1, 2 or 4 octets, the value is converted directly into a variable instead of a pointer. To avoid being tricked into being a pointer, check that for these option types that sizes actually match. In L2CAP every option is fixed size and thus it is prudent anyway to ensure that the remote side sends us the right option size along with option paramters. If the option size is not matching the option type, then that option is silently ignored. It is a protocol violation and instead of trying to give the remote attacker any further hints just pretend that option is not present and proceed with the default values. Implementation following the specification and its qualification procedures will always use the correct size and thus not being impacted here. To keep the code readable and consistent accross all options, a few cosmetic changes were also required. Signed-off-by: Marcel Holtmann Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hedberg Signed-off-by: Greg Kroah-Hartman commit a1402232e193e76066f55573236dbaf02a3dc5e2 Author: Arnd Bergmann Date: Thu Mar 29 00:06:10 2018 +0200 ath10k: avoid possible string overflow commit 6707ba0105a2d350710bc0a537a98f49eb4b895d upstream. The way that 'strncat' is used here raised a warning in gcc-8: drivers/net/wireless/ath/ath10k/wmi.c: In function 'ath10k_wmi_tpc_stats_final_disp_tables': drivers/net/wireless/ath/ath10k/wmi.c:4649:4: error: 'strncat' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation] Effectively, this is simply a strcat() but the use of strncat() suggests some form of overflow check. Regardless of whether this might actually overflow, using strlcat() instead of strncat() avoids the warning and makes the code more robust. Fixes: bc64d05220f3 ("ath10k: debugfs support to get final TPC stats for 10.4 variants") Signed-off-by: Arnd Bergmann Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit ee8f5d476dc91a570cf8ab9babf2b85485f509c1 Author: Baolin Wang Date: Mon Dec 25 19:10:37 2017 +0800 rtc: Fix overflow when converting time64_t to rtc_time commit 36d46cdb43efea74043e29e2a62b13e9aca31452 upstream. If we convert one large time values to rtc_time, in the original formula 'days * 86400' can be overflowed in 'unsigned int' type to make the formula get one incorrect remain seconds value. Thus we can use div_s64_rem() function to avoid this situation. Signed-off-by: Baolin Wang Acked-by: Arnd Bergmann Signed-off-by: Alexandre Belloni Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 0cd08672e0aa514364ff619975067731e39207ab Author: Andrey Konovalov Date: Mon Dec 11 22:48:41 2017 +0100 USB: core: only clean up what we allocated commit 32fd87b3bbf5f7a045546401dfe2894dbbf4d8c3 upstream. When cleaning up the configurations, make sure we only free the number of configurations and interfaces that we could have allocated. Reported-by: Andrey Konovalov Cc: stable Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 466ab66b5c2fa7ba0ee372495833af08cce17a52 Author: Peter Zijlstra Date: Fri Nov 17 15:28:04 2017 -0800 lib/int_sqrt: optimize small argument commit 3f3295709edea6268ff1609855f498035286af73 upstream. The current int_sqrt() computation is sub-optimal for the case of small @x. Which is the interesting case when we're going to do cumulative distribution functions on idle times, which we assume to be a random variable, where the target residency of the deepest idle state gives an upper bound on the variable (5e6ns on recent Intel chips). In the case of small @x, the compute loop: while (m != 0) { b = y + m; y >>= 1; if (x >= b) { x -= b; y += m; } m >>= 2; } can be reduced to: while (m > x) m >>= 2; Because y==0, b==m and until x>=m y will remain 0. And while this is computationally equivalent, it runs much faster because there's less code, in particular less branches. cycles: branches: branch-misses: OLD: hot: 45.109444 +- 0.044117 44.333392 +- 0.002254 0.018723 +- 0.000593 cold: 187.737379 +- 0.156678 44.333407 +- 0.002254 6.272844 +- 0.004305 PRE: hot: 67.937492 +- 0.064124 66.999535 +- 0.000488 0.066720 +- 0.001113 cold: 232.004379 +- 0.332811 66.999527 +- 0.000488 6.914634 +- 0.006568 POST: hot: 43.633557 +- 0.034373 45.333132 +- 0.002277 0.023529 +- 0.000681 cold: 207.438411 +- 0.125840 45.333132 +- 0.002277 6.976486 +- 0.004219 Averages computed over all values <128k using a LFSR to generate order. Cold numbers have a LFSR based branch trace buffer 'confuser' ran between each int_sqrt() invocation. Link: http://lkml.kernel.org/r/20171020164644.876503355@infradead.org Fixes: 30493cc9dddb ("lib/int_sqrt.c: optimize square root algorithm") Signed-off-by: Peter Zijlstra (Intel) Suggested-by: Anshul Garg Acked-by: Linus Torvalds Cc: Davidlohr Bueso Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Will Deacon Cc: Joe Perches Cc: David Miller Cc: Matthew Wilcox Cc: Kees Cook Cc: Michael Davidson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 7a47e3c3232d7695bb334a306c839ebdf0c8ee32 Author: Lanqing Liu Date: Tue Jul 18 17:58:13 2017 +0800 serial: sprd: clear timeout interrupt only rather than all interrupts commit 4350782570b919f254c1e083261a21c19fcaee90 upstream. On Spreadtrum's serial device, nearly all of interrupts would be cleared by hardware except timeout interrupt. This patch removed the operation of clearing all interrupt in irq handler, instead added an if statement to check if the timeout interrupt is supposed to be cleared. Wrongly clearing timeout interrupt would lead to uart data stay in rx fifo, that means the driver cannot read them out anymore. Signed-off-by: Lanqing Liu Signed-off-by: Chunyan Zhang Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 4104b44e5d926fa4052ef37e41a053e17b7c00f4 Author: Yoshihiro Shimoda Date: Fri Jul 28 19:28:57 2017 +0900 usb: renesas_usbhs: gadget: fix unused-but-set-variable warning commit b7d44c36a6f6d956e1539e0dd42f98b26e5a4684 upstream. The commit b8b9c974afee ("usb: renesas_usbhs: gadget: disable all eps when the driver stops") causes the unused-but-set-variable warning. But, if the usbhsg_ep_disable() will return non-zero value, udc/core.c doesn't clear the ep->enabled flag. So, this driver should not return non-zero value, if the pipe is zero because this means the pipe is already disabled. Otherwise, the ep->enabled flag is never cleared when the usbhsg_ep_disable() is called by the renesas_usbhs driver first. Fixes: b8b9c974afee ("usb: renesas_usbhs: gadget: disable all eps when the driver stops") Fixes: 11432050f070 ("usb: renesas_usbhs: gadget: fix NULL pointer dereference in ep_disable()") Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit e86206bd875877825a3f0328adcc332f9bdf8ef1 Author: Qiao Zhou Date: Fri Jul 7 17:29:34 2017 +0800 arm64: traps: disable irq in die() commit 6f44a0bacb79a03972c83759711832b382b1b8ac upstream. In current die(), the irq is disabled for __die() handle, not including the possible panic() handling. Since the log in __die() can take several hundreds ms, new irq might come and interrupt current die(). If the process calling die() holds some critical resource, and some other process scheduled later also needs it, then it would deadlock. The first panic will not be executed. So here disable irq for the whole flow of die(). Signed-off-by: Qiao Zhou Signed-off-by: Will Deacon Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit a3fbab100127b99b82e13f1b9ad8ec91c9c6ed56 Author: Al Viro Date: Sat Jun 3 07:20:09 2017 +0100 Hang/soft lockup in d_invalidate with simultaneous calls commit 81be24d263dbeddaba35827036d6f6787a59c2c3 upstream. It's not hard to trigger a bunch of d_invalidate() on the same dentry in parallel. They end up fighting each other - any dentry picked for removal by one will be skipped by the rest and we'll go for the next iteration through the entire subtree, even if everything is being skipped. Morevoer, we immediately go back to scanning the subtree. The only thing we really need is to dissolve all mounts in the subtree and as soon as we've nothing left to do, we can just unhash the dentry and bugger off. Signed-off-by: Al Viro Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 4a97f086f1924032990e35884baca3af5d5abae8 Author: Wei Qiao Date: Mon Mar 27 14:06:42 2017 +0800 serial: sprd: adjust TIMEOUT to a big value commit e1dc9b08051a2c2e694edf48d1e704f07c7c143c upstream. SPRD_TIMEOUT was 256, which is too small to wait until the status switched to workable in a while loop, so that the earlycon could not work correctly. Signed-off-by: Wei Qiao Signed-off-by: Chunyan Zhang Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 7ed7c0386ef2a5cbe58e15af5014c9302d3593eb Author: Eric Dumazet Date: Wed Oct 26 09:27:57 2016 -0700 tcp/dccp: drop SYN packets if accept queue is full commit 5ea8ea2cb7f1d0db15762c9b0bb9e7330425a071 upstream. Per listen(fd, backlog) rules, there is really no point accepting a SYN, sending a SYNACK, and dropping the following ACK packet if accept queue is full, because application is not draining accept queue fast enough. This behavior is fooling TCP clients that believe they established a flow, while there is nothing at server side. They might then send about 10 MSS (if using IW10) that will be dropped anyway while server is under stress. Signed-off-by: Eric Dumazet Acked-by: Neal Cardwell Acked-by: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit a12cf3214235681a347a53c93378479caab3f404 Author: Baolin Wang Date: Thu Jun 30 17:10:23 2016 +0800 usb: gadget: Add the gserial port checking in gs_start_tx() commit 511a36d2f357724312bb3776d2f6eed3890928b2 upstream. When usb gadget is set gadget serial function, it will be crash in below situation. It will clean the 'port->port_usb' pointer in gserial_disconnect() function when usb link is inactive, but it will release lock for disabling the endpoints in this function. Druing the lock release period, it maybe complete one request to issue gs_write_complete()--->gs_start_tx() function, but the 'port->port_usb' pointer had been set NULL, thus it will be crash in gs_start_tx() function. This patch adds the 'port->port_usb' pointer checking in gs_start_tx() function to avoid this situation. Signed-off-by: Baolin Wang Signed-off-by: Felipe Balbi Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 36be44e1905d593402d373aa35b48ceec9ae46f0 Author: Peter Chen Date: Fri Jul 1 15:33:28 2016 +0800 usb: gadget: composite: fix dereference after null check coverify warning commit c526c62d565ea5a5bba9433f28756079734f430d upstream. cdev->config is checked for null pointer at above code, so cdev->config might be null, fix it by adding null pointer check. Signed-off-by: Peter Chen Signed-off-by: Felipe Balbi Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit c0f71babf7bbfeba850abeba2b56545a7eaf8a75 Author: Wolfram Sang Date: Mon Jun 6 21:00:38 2016 +0200 kbuild: setlocalversion: print error to STDERR commit 78283edf2c01c38eb840a3de5ffd18fe2992ab64 upstream. I tried to use 'make O=...' from an unclean source tree. This triggered the error path of setlocalversion. But by printing to STDOUT, it created a broken localversion which then caused another (unrelated) error: "4.7.0-rc2Error: kernelrelease not valid - run make prepare to update it" exceeds 64 characters After printing to STDERR, the true build error gets displayed later: /home/wsa/Kernel/linux is not clean, please run 'make mrproper' in the '/home/wsa/Kernel/linux' directory. Signed-off-by: Wolfram Sang Signed-off-by: Michal Marek Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 1e647cf23fb28b83c431411dd2f67b2947550e13 Author: Roger Quadros Date: Mon Apr 11 17:04:45 2016 +0300 extcon: usb-gpio: Don't miss event during suspend/resume commit 04c080080855ce84dcd490a2e04805608a21085d upstream. Pin state might have changed during suspend/resume while our interrupts were disabled and if device doesn't support wakeup. Scan for change during resume for such case. Signed-off-by: Roger Quadros Signed-off-by: Chanwoo Choi Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 7f69a980f6351e4390cc32341499abb13182e8c3 Author: Konstantin Khlebnikov Date: Thu May 19 17:11:46 2016 -0700 mm/rmap: replace BUG_ON(anon_vma->degree) with VM_WARN_ON commit e4c5800a3991f0c6a766983535dfc10d51802cf6 upstream. This check effectively catches anon vma hierarchy inconsistence and some vma corruptions. It was effective for catching corner cases in anon vma reusing logic. For now this code seems stable so check could be hidden under CONFIG_DEBUG_VM and replaced with WARN because it's not so fatal. Signed-off-by: Konstantin Khlebnikov Suggested-by: Vasily Averin Acked-by: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 1394b1bdfd00560beb1b1ea20b75ee1734007ac8 Author: Dong Aisheng Date: Thu Apr 21 00:51:30 2016 +0800 mmc: core: fix using wrong io voltage if mmc_select_hs200 fails commit e51534c806609c806d81bfb034f02737461f855c upstream. Currently MMC core will keep going if HS200/HS timing switch failed with -EBADMSG error by the assumption that the old timing is still valid. However, for mmc_select_hs200 case, the signal voltage may have already been switched. If the timing switch failed, we should fall back to the old voltage in case the card is continue run with legacy timing. If fall back signal voltage failed, we explicitly report an EIO error to force retry during the next power cycle. Signed-off-by: Dong Aisheng Signed-off-by: Ulf Hansson Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit aa8b7ed2168510efcf40f4efaa3fbc794ea4003f Author: James Morse Date: Wed Apr 13 13:40:00 2016 +0100 arm64: mm: Add trace_irqflags annotations to do_debug_exception() commit 6afedcd23cfd7ac56c011069e4a8db37b46e4623 upstream. With CONFIG_PROVE_LOCKING, CONFIG_DEBUG_LOCKDEP and CONFIG_TRACE_IRQFLAGS enabled, lockdep will compare current->hardirqs_enabled with the flags from local_irq_save(). When a debug exception occurs, interrupts are disabled in entry.S, but lockdep isn't told, resulting in: DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled) ------------[ cut here ]------------ WARNING: at ../kernel/locking/lockdep.c:3523 Modules linked in: CPU: 3 PID: 1752 Comm: perf Not tainted 4.5.0-rc4+ #2204 Hardware name: ARM Juno development board (r1) (DT) task: ffffffc974868000 ti: ffffffc975f40000 task.ti: ffffffc975f40000 PC is at check_flags.part.35+0x17c/0x184 LR is at check_flags.part.35+0x17c/0x184 pc : [] lr : [] pstate: 600003c5 [...] ---[ end trace 74631f9305ef5020 ]--- Call trace: [] check_flags.part.35+0x17c/0x184 [] lock_acquire+0xa8/0xc4 [] breakpoint_handler+0x118/0x288 [] do_debug_exception+0x3c/0xa8 [] el1_dbg+0x18/0x6c [] do_filp_open+0x64/0xdc [] do_sys_open+0x140/0x204 [] SyS_openat+0x10/0x18 [] el0_svc_naked+0x24/0x28 possible reason: unannotated irqs-off. irq event stamp: 65857 hardirqs last enabled at (65857): [] lookup_mnt+0xf4/0x1b4 hardirqs last disabled at (65856): [] lookup_mnt+0xbc/0x1b4 softirqs last enabled at (65790): [] __do_softirq+0x1f8/0x290 softirqs last disabled at (65757): [] irq_exit+0x9c/0xd0 This patch adds the annotations to do_debug_exception(), while trying not to call trace_hardirqs_off() if el1_dbg() interrupted a task that already had irqs disabled. Signed-off-by: James Morse Signed-off-by: Will Deacon Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit df2ca3271569367352835f981618e284fdc4ca94 Author: Roger Quadros Date: Tue Apr 12 11:33:29 2016 +0300 usb: dwc3: gadget: Fix suspend/resume during device mode commit 9772b47a4c2916d645c551228b6085ea24acbe5d upstream. Gadget controller might not be always active during system suspend/resume as gadget driver might not have yet been loaded or might have been unloaded prior to system suspend. Check if we're active and only then perform necessary actions during suspend/resume. Signed-off-by: Roger Quadros Signed-off-by: Felipe Balbi Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit f2427238c9ed72e7a8c56c0d342c3b283adce4c6 Author: Russell King Date: Fri Jan 29 09:43:50 2016 +0000 mmc: core: shut up "voltage-ranges unspecified" pr_info() commit 10a16a01d8f72e80f4780e40cf3122f4caffa411 upstream. Each time a driver such as sdhci-esdhc-imx is probed, we get a info printk complaining that the DT voltage-ranges property has not been specified. However, the DT binding specifically says that the voltage-ranges property is optional. That means we should not be complaining that DT hasn't specified this property: by indicating that it's optional, it is valid not to have the property in DT. Silence the warning if the property is missing. Signed-off-by: Russell King Signed-off-by: Ulf Hansson Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 6a0f5752f1fd5e98c87392e61e437907c149ed63 Author: Wolfram Sang Date: Fri Jan 29 09:27:50 2016 +0100 mmc: sanitize 'bus width' in debug output commit ed9feec72fc1fa194ebfdb79e14561b35decce63 upstream. The bus width is sometimes the actual bus width, and sometimes indices to different arrays encoding the bus width. In my debugging case "2" could mean 8-bit as well as 4-bit, which was extremly confusing. Let's use the human-readable actual bus width in all places. Signed-off-by: Wolfram Sang Signed-off-by: Ulf Hansson Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 40c01c8301b85d9454e4fb3b5dca436435266937 Author: Wolfram Sang Date: Mon Jan 25 20:18:12 2016 +0100 mmc: make MAN_BKOPS_EN message a debug commit 4ec96b4cbde8d5714a4477b5a2562c3dd40bc5fa upstream. IMO this info is only useful for developers. Most users won't need this information, since there is not much they can do about it. Signed-off-by: Wolfram Sang Signed-off-by: Ulf Hansson Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 282d5f0567be5abcc57a38ada569460ef63b5be9 Author: Chuanxiao Dong Date: Thu Jan 21 13:57:51 2016 +0100 mmc: debugfs: Add a restriction to mmc debugfs clock setting commit e5905ff1281f0a0f5c9863c430ac1ed5faaf5707 upstream. Clock frequency values written to an mmc host should not be less than the minimum clock frequency which the mmc host supports. Signed-off-by: Yuan Juntao Signed-off-by: Pawel Wodkowski Signed-off-by: Ulf Hansson Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit c8816bb0ed6dc34c888021a34891385c0a84566f Author: Martin Fuzzey Date: Wed Jan 20 16:08:03 2016 +0100 mmc: pwrseq_simple: Make reset-gpios optional to match doc commit 64a67d4762ce3ce4c9466eadd152d825fbf84967 upstream. The DT binding doc says reset-gpios is an optional property but the code currently bails out if it is omitted. This is a regression since it breaks previously working device trees. Fix it by restoring the original documented behaviour. Fixes: ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array API") Tested-by: Tony Lindgren Signed-off-by: Martin Fuzzey Signed-off-by: Ulf Hansson Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 4d026d221b3435144aac0920f77595bb1806fb5e Author: Hui Wang Date: Tue Mar 19 09:28:44 2019 +0800 ALSA: hda - Enforces runtime_resume after S3 and S4 for each codec commit b5a236c175b0d984552a5f7c9d35141024c2b261 upstream. Recently we found the audio jack detection stop working after suspend on many machines with Realtek codec. Sometimes the audio selection dialogue didn't show up after users plugged headhphone/headset into the headset jack, sometimes after uses plugged headphone/headset, then click the sound icon on the upper-right corner of gnome-desktop, it also showed the speaker rather than the headphone. The root cause is that before suspend, the codec already call the runtime_suspend since this codec is not used by any apps, then in resume, it will not call runtime_resume for this codec. But for some realtek codec (so far, alc236, alc255 and alc891) with the specific BIOS, if it doesn't run runtime_resume after suspend, all codec functions including jack detection stop working anymore. This problem existed for a long time, but it was not exposed, that is because when problem happens, if users play sound or open sound-setting to check audio device, this will trigger calling to runtime_resume (via snd_hda_power_up), then the codec starts working again before users notice this problem. Since we don't know how many codec and BIOS combinations have this problem, to fix it, let the driver call runtime_resume for all codecs in pm_resume, maybe for some codecs, this is not needed, but it is harmless. After a codec is runtime resumed, if it is not used by any apps, it will be runtime suspended soon and furthermore we don't run suspend frequently, this change will not add much power consumption. Fixes: cc72da7d4d06 ("ALSA: hda - Use standard runtime PM for codec power-save control") Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2569eed24d93ce94c34efd1a8eaf17d1d03eb66e Author: Takashi Iwai Date: Tue Jan 29 14:03:33 2019 +0100 ALSA: hda - Record the current power state before suspend/resume calls commit 98081ca62cbac31fb0f7efaf90b2e7384ce22257 upstream. Currently we deal with single codec and suspend codec callbacks for all S3, S4 and runtime PM handling. But it turned out that we want distinguish the call patterns sometimes, e.g. for applying some init sequence only at probing and restoring from hibernate. This patch slightly modifies the common PM callbacks for HD-audio codec and stores the currently processed PM event in power_state of the codec's device.power field, which is currently unused. The codec callback can take a look at this event value and judges which purpose it's being called. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4aada79c6793c59e484b69fd4ed591396e2d4b39 Author: Waiman Long Date: Wed Jan 9 23:03:25 2019 -0500 locking/lockdep: Add debug_locks check in __lock_downgrade() commit 71492580571467fb7177aade19c18ce7486267f5 upstream. Tetsuo Handa had reported he saw an incorrect "downgrading a read lock" warning right after a previous lockdep warning. It is likely that the previous warning turned off lock debugging causing the lockdep to have inconsistency states leading to the lock downgrade warning. Fix that by add a check for debug_locks at the beginning of __lock_downgrade(). Debugged-by: Tetsuo Handa Reported-by: Tetsuo Handa Reported-by: syzbot+53383ae265fb161ef488@syzkaller.appspotmail.com Signed-off-by: Waiman Long Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Link: https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-longman@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 786207750b492a14d07444992f49b26a4ee5bb97 Author: Hans Verkuil Date: Tue Dec 18 08:37:08 2018 -0500 media: v4l2-ctrls.c/uvc: zero v4l2_event commit f45f3f753b0a3d739acda8e311b4f744d82dc52a upstream. Control events can leak kernel memory since they do not fully zero the event. The same code is present in both v4l2-ctrls.c and uvc_ctrl.c, so fix both. It appears that all other event code is properly zeroing the structure, it's these two places. Signed-off-by: Hans Verkuil Reported-by: syzbot+4f021cf3697781dbd9fb@syzkaller.appspotmail.com Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit a8dea33440f1693caf42706f8c69248e24e3075a Author: Sergei Shtylyov Date: Mon Feb 18 20:45:40 2019 +0300 mmc: tmio_mmc_core: don't claim spurious interrupts commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream. I have encountered an interrupt storm during the eMMC chip probing (and the chip finally didn't get detected). It turned out that U-Boot left the DMAC interrupts enabled while the Linux driver didn't use those. The SDHI driver's interrupt handler somehow assumes that, even if an SDIO interrupt didn't happen, it should return IRQ_HANDLED. I think that if none of the enabled interrupts happened and got handled, we should return IRQ_NONE -- that way the kernel IRQ code recoginizes a spurious interrupt and masks it off pretty quickly... Fixes: 7729c7a232a9 ("mmc: tmio: Provide separate interrupt handlers") Signed-off-by: Sergei Shtylyov Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Reviewed-by: Simon Horman Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit c37fd9822514d1e76d3ab467da8e613e204fbd10 Author: zhangyi (F) Date: Sat Mar 23 11:43:05 2019 -0400 ext4: brelse all indirect buffer in ext4_ind_remove_space() commit 674a2b27234d1b7afcb0a9162e81b2e53aeef217 upstream. All indirect buffers get by ext4_find_shared() should be released no mater the branch should be freed or not. But now, we forget to release the lower depth indirect buffers when removing space from the same higher depth indirect block. It will lead to buffer leak and futher more, it may lead to quota information corruption when using old quota, consider the following case. - Create and mount an empty ext4 filesystem without extent and quota features, - quotacheck and enable the user & group quota, - Create some files and write some data to them, and then punch hole to some files of them, it may trigger the buffer leak problem mentioned above. - Disable quota and run quotacheck again, it will create two new aquota files and write the checked quota information to them, which probably may reuse the freed indirect block(the buffer and page cache was not freed) as data block. - Enable quota again, it will invoke vfs_load_quota_inode()->invalidate_bdev() to try to clean unused buffers and pagecache. Unfortunately, because of the buffer of quota data block is still referenced, quota code cannot read the up to date quota info from the device and lead to quota information corruption. This problem can be reproduced by xfstests generic/231 on ext3 file system or ext4 file system without extent and quota features. This patch fix this problem by releasing the missing indirect buffers, in ext4_ind_remove_space(). Reported-by: Hulk Robot Signed-off-by: zhangyi (F) Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2ebfb9ae0047e900a932e6219a1a8ee830cde940 Author: Lukas Czerner Date: Thu Mar 14 23:20:25 2019 -0400 ext4: fix data corruption caused by unaligned direct AIO commit 372a03e01853f860560eade508794dd274e9b390 upstream. Ext4 needs to serialize unaligned direct AIO because the zeroing of partial blocks of two competing unaligned AIOs can result in data corruption. However it decides not to serialize if the potentially unaligned aio is past i_size with the rationale that no pending writes are possible past i_size. Unfortunately if the i_size is not block aligned and the second unaligned write lands past i_size, but still into the same block, it has the potential of corrupting the previous unaligned write to the same block. This is (very simplified) reproducer from Frank // 41472 = (10 * 4096) + 512 // 37376 = 41472 - 4096 ftruncate(fd, 41472); io_prep_pwrite(iocbs[0], fd, buf[0], 4096, 37376); io_prep_pwrite(iocbs[1], fd, buf[1], 4096, 41472); io_submit(io_ctx, 1, &iocbs[1]); io_submit(io_ctx, 1, &iocbs[2]); io_getevents(io_ctx, 2, 2, events, NULL); Without this patch the 512B range from 40960 up to the start of the second unaligned write (41472) is going to be zeroed overwriting the data written by the first write. This is a data corruption. 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 * 0000a000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 With this patch the data corruption is avoided because we will recognize the unaligned_aio and wait for the unwritten extent conversion. 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 * 0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 * 0000b200 Reported-by: Frank Sorenson Signed-off-by: Lukas Czerner Signed-off-by: Theodore Ts'o Fixes: e9e3bcecf44c ("ext4: serialize unaligned asynchronous DIO") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2b6575ed8c7e13c957b9a64693f403486646e160 Author: Jiufei Xue Date: Thu Mar 14 23:19:22 2019 -0400 ext4: fix NULL pointer dereference while journal is aborted commit fa30dde38aa8628c73a6dded7cb0bba38c27b576 upstream. We see the following NULL pointer dereference while running xfstests generic/475: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 PGD 8000000c84bad067 P4D 8000000c84bad067 PUD c84e62067 PMD 0 Oops: 0000 [#1] SMP PTI CPU: 7 PID: 9886 Comm: fsstress Kdump: loaded Not tainted 5.0.0-rc8 #10 RIP: 0010:ext4_do_update_inode+0x4ec/0x760 ... Call Trace: ? jbd2_journal_get_write_access+0x42/0x50 ? __ext4_journal_get_write_access+0x2c/0x70 ? ext4_truncate+0x186/0x3f0 ext4_mark_iloc_dirty+0x61/0x80 ext4_mark_inode_dirty+0x62/0x1b0 ext4_truncate+0x186/0x3f0 ? unmap_mapping_pages+0x56/0x100 ext4_setattr+0x817/0x8b0 notify_change+0x1df/0x430 do_truncate+0x5e/0x90 ? generic_permission+0x12b/0x1a0 This is triggered because the NULL pointer handle->h_transaction was dereferenced in function ext4_update_inode_fsync_trans(). I found that the h_transaction was set to NULL in jbd2__journal_restart but failed to attached to a new transaction while the journal is aborted. Fix this by checking the handle before updating the inode. Fixes: b436b9bef84d ("ext4: Wait for proper transaction commit on fsync") Signed-off-by: Jiufei Xue Signed-off-by: Theodore Ts'o Reviewed-by: Joseph Qi Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2f59c12b47c187c8c221f11ee139365f9bb2b334 Author: Chen Jie Date: Fri Mar 15 03:44:38 2019 +0000 futex: Ensure that futex address is aligned in handle_futex_death() commit 5a07168d8d89b00fe1760120714378175b3ef992 upstream. The futex code requires that the user space addresses of futexes are 32bit aligned. sys_futex() checks this in futex_get_keys() but the robust list code has no alignment check in place. As a consequence the kernel crashes on architectures with strict alignment requirements in handle_futex_death() when trying to cmpxchg() on an unaligned futex address which was retrieved from the robust list. [ tglx: Rewrote changelog, proper sizeof() based alignement check and add comment ] Fixes: 0771dfefc9e5 ("[PATCH] lightweight robust futexes: core") Signed-off-by: Chen Jie Signed-off-by: Thomas Gleixner Cc: Cc: Cc: Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/1552621478-119787-1-git-send-email-chenjie6@huawei.com Signed-off-by: Greg Kroah-Hartman commit 8df0d57e5c085678645f27489d83ba434457c533 Author: Archer Yan Date: Fri Mar 8 03:29:19 2019 +0000 MIPS: Fix kernel crash for R6 in jump label branch function commit 47c25036b60f27b86ab44b66a8861bcf81cde39b upstream. Insert Branch instruction instead of NOP to make sure assembler don't patch code in forbidden slot. In jump label function, it might be possible to patch Control Transfer Instructions(CTIs) into forbidden slot, which will generate Reserved Instruction exception in MIPS release 6. Signed-off-by: Archer Yan Reviewed-by: Paul Burton [paul.burton@mips.com: - Add MIPS prefix to subject. - Mark for stable from v4.0, which introduced r6 support, onwards.] Signed-off-by: Paul Burton Cc: linux-mips@vger.kernel.org Cc: stable@vger.kernel.org # v4.0+ Signed-off-by: Greg Kroah-Hartman commit 5c06f2409550b5cd308c22637bba5422d9a5f769 Author: Yifeng Li Date: Tue Mar 5 06:00:22 2019 +0800 mips: loongson64: lemote-2f: Add IRQF_NO_SUSPEND to "cascade" irqaction. commit 5f5f67da9781770df0403269bc57d7aae608fecd upstream. Timekeeping IRQs from CS5536 MFGPT are routed to i8259, which then triggers the "cascade" IRQ on MIPS CPU. Without IRQF_NO_SUSPEND in cascade_irqaction, MFGPT interrupts will be masked in suspend mode, and the machine would be unable to resume once suspended. Previously, MIPS IRQs were not disabled properly, so the original code appeared to work. Commit a3e6c1eff5 ("MIPS: IRQ: Fix disable_irq on CPU IRQs") uncovers the bug. To fix it, add IRQF_NO_SUSPEND to cascade_irqaction. This commit is functionally identical to 0add9c2f1cff ("MIPS: Loongson-3: Add IRQF_NO_SUSPEND to Cascade irqaction"), but it forgot to apply the same fix to Loongson2. Signed-off-by: Yifeng Li Signed-off-by: Paul Burton Cc: linux-mips@vger.kernel.org Cc: Jiaxun Yang Cc: Huacai Chen Cc: Ralf Baechle Cc: James Hogan Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: Greg Kroah-Hartman commit c30b41bbbb874b31f9563fa5a42f057deaccbd4a Author: Jan Kara Date: Mon Mar 11 15:04:18 2019 +0100 udf: Fix crash on IO error during truncate commit d3ca4651d05c0ff7259d087d8c949bcf3e14fb46 upstream. When truncate(2) hits IO error when reading indirect extent block the code just bugs with: kernel BUG at linux-4.15.0/fs/udf/truncate.c:249! ... Fix the problem by bailing out cleanly in case of IO error. CC: stable@vger.kernel.org Reported-by: jean-luc malet Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 8b12fd7c5f36ad85926fa9e9d1107565fdbf75c2 Author: Thomas Zimmermann Date: Mon Mar 18 15:47:58 2019 +0100 drm/vmwgfx: Don't double-free the mode stored in par->set_mode commit c2d311553855395764e2e5bf401d987ba65c2056 upstream. When calling vmw_fb_set_par(), the mode stored in par->set_mode gets free'd twice. The first free is in vmw_fb_kms_detach(), the second is near the end of vmw_fb_set_par() under the name of 'old_mode'. The mode-setting code only works correctly if the mode doesn't actually change. Removing 'old_mode' in favor of using par->set_mode directly fixes the problem. Cc: Fixes: a278724aa23c ("drm/vmwgfx: Implement fbdev on kms v2") Signed-off-by: Thomas Zimmermann Reviewed-by: Deepak Rawat Signed-off-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman commit e884f7d5c6279452243c86c74112fc6f0639ebd8 Author: Arnd Bergmann Date: Thu Mar 7 11:09:19 2019 +0100 mmc: pxamci: fix enum type confusion commit e60a582bcde01158a64ff948fb799f21f5d31a11 upstream. clang points out several instances of mismatched types in this drivers, all coming from a single declaration: drivers/mmc/host/pxamci.c:193:15: error: implicit conversion from enumeration type 'enum dma_transfer_direction' to different enumeration type 'enum dma_data_direction' [-Werror,-Wenum-conversion] direction = DMA_DEV_TO_MEM; ~ ^~~~~~~~~~~~~~ drivers/mmc/host/pxamci.c:212:62: error: implicit conversion from enumeration type 'enum dma_data_direction' to different enumeration type 'enum dma_transfer_direction' [-Werror,-Wenum-conversion] tx = dmaengine_prep_slave_sg(chan, data->sg, host->dma_len, direction, The behavior is correct, so this must be a simply typo from dma_data_direction and dma_transfer_direction being similarly named types with a similar purpose. Fixes: 6464b7140951 ("mmc: pxamci: switch over to dmaengine use") Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Acked-by: Robert Jarzmik Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman