aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-12-06drm/ast: Fix connector leak during driver unloadSam Bobroff1-0/+1
When unloading the ast driver, a warning message is printed by drm_mode_config_cleanup() because a reference is still held to one of the drm_connector structs. Correct this by calling drm_crtc_force_disable_all() in ast_fbdev_destroy(). Signed-off-by: Sam Bobroff <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1e613f3c630c7bbc72e04a44b178259b9164d2f6.1543798395.git.sbobroff@linux.ibm.com
2018-12-06Merge tag 'drm-misc-fixes-2018-12-05' of ↵Dave Airlie9-39/+60
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes UAPI: - Distinguish lease events from hotplug (Daniel) Other: - omap: Restore panel-dpi bus flags (Tomi) - omap: Fix a couple of dsi issues (Sebastian) Cc: Sebastian Reichel <[email protected]> Cc: Tomi Valkeinen <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]> From: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20181205201428.GA35447@art_vandelay
2018-12-06Merge branch 'drm-fixes-4.20' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie14-53/+104
into drm-fixes Fixes for 4.20: - Fix banding regression on 6 bpc panels - Vega20 fix for six 4k displays - Fix LRU handling in ttm_buffer_object_transfer - Use proper MC firmware for newer polaris variants - Vega20 powerplay fixes - VCN suspend/resume fix for PCO - Misc other fixes Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-12-06Merge tag 'msm-fixes-2018-12-04' of ↵Dave Airlie14-65/+70
https://gitlab.freedesktop.org/seanpaul/dpu-staging into drm-fixes - Several related to incorrect error checking/handling (Various) - Prevent IRQ storm on MDP5 HDMI hotplug (Todor) - Don't capture crash state if unsupported (Sharat) - Properly grab vblank reference in atomic wait for commit done (Sean) Cc: Sharat Masetty <[email protected]> Cc: Todor Tomov <[email protected]> Cc: Sean Paul <[email protected]> Signed-off-by: Dave Airlie <[email protected]> From: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20181205194207.GY154160@art_vandelay
2018-12-05Uprobes: Fix kernel oops with delayed_uprobe_remove()Ravi Bangoria1-0/+2
There could be a race between task exit and probe unregister: exit_mm() mmput() __mmput() uprobe_unregister() uprobe_clear_state() put_uprobe() delayed_uprobe_remove() delayed_uprobe_remove() put_uprobe() is calling delayed_uprobe_remove() without taking delayed_uprobe_lock and thus the race sometimes results in a kernel crash. Fix this by taking delayed_uprobe_lock before calling delayed_uprobe_remove() from put_uprobe(). Detailed crash log can be found at: Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Acked-by: Oleg Nesterov <[email protected]> Reviewed-by: Srikar Dronamraju <[email protected]> Reported-by: [email protected] Fixes: 1cc33161a83d ("uprobes: Support SDT markers having reference count (semaphore)") Signed-off-by: Ravi Bangoria <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-12-05stackleak: Mark stackleak_track_stack() as notraceAnders Roxell1-1/+1
Function graph tracing recurses into itself when stackleak is enabled, causing the ftrace graph selftest to run for up to 90 seconds and trigger the softlockup watchdog. Breakpoint 2, ftrace_graph_caller () at ../arch/arm64/kernel/entry-ftrace.S:200 200 mcount_get_lr_addr x0 // pointer to function's saved lr (gdb) bt \#0 ftrace_graph_caller () at ../arch/arm64/kernel/entry-ftrace.S:200 \#1 0xffffff80081d5280 in ftrace_caller () at ../arch/arm64/kernel/entry-ftrace.S:153 \#2 0xffffff8008555484 in stackleak_track_stack () at ../kernel/stackleak.c:106 \#3 0xffffff8008421ff8 in ftrace_ops_test (ops=0xffffff8009eaa840 <graph_ops>, ip=18446743524091297036, regs=<optimized out>) at ../kernel/trace/ftrace.c:1507 \#4 0xffffff8008428770 in __ftrace_ops_list_func (regs=<optimized out>, ignored=<optimized out>, parent_ip=<optimized out>, ip=<optimized out>) at ../kernel/trace/ftrace.c:6286 \#5 ftrace_ops_no_ops (ip=18446743524091297036, parent_ip=18446743524091242824) at ../kernel/trace/ftrace.c:6321 \#6 0xffffff80081d5280 in ftrace_caller () at ../arch/arm64/kernel/entry-ftrace.S:153 \#7 0xffffff800832fd10 in irq_find_mapping (domain=0xffffffc03fc4bc80, hwirq=27) at ../kernel/irq/irqdomain.c:876 \#8 0xffffff800832294c in __handle_domain_irq (domain=0xffffffc03fc4bc80, hwirq=27, lookup=true, regs=0xffffff800814b840) at ../kernel/irq/irqdesc.c:650 \#9 0xffffff80081d52b4 in ftrace_graph_caller () at ../arch/arm64/kernel/entry-ftrace.S:205 Rework so we mark stackleak_track_stack as notrace Co-developed-by: Arnd Bergmann <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Anders Roxell <[email protected]> Acked-by: Steven Rostedt (VMware) <[email protected]> Signed-off-by: Kees Cook <[email protected]>
2018-12-05Merge tag 'scsi-fixes' of ↵Linus Torvalds5-37/+39
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Four obvious bug fixes. The vmw_pscsi is so old that it's amazing no-one noticed before now" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: storvsc: Fix a race in sub-channel creation that can cause panic scsi: vmw_pscsi: Rearrange code to avoid multiple calls to free_irq during unload scsi: libiscsi: Fix NULL pointer dereference in iscsi_eh_session_reset scsi: lpfc: fix block guard enablement on SLI3 adapters
2018-12-05tcp: fix NULL ref in tail loss probeYuchung Cheng1-4/+7
TCP loss probe timer may fire when the retranmission queue is empty but has a non-zero tp->packets_out counter. tcp_send_loss_probe will call tcp_rearm_rto which triggers NULL pointer reference by fetching the retranmission queue head in its sub-routines. Add a more detailed warning to help catch the root cause of the inflight accounting inconsistency. Reported-by: Rafael Tinoco <[email protected]> Signed-off-by: Yuchung Cheng <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: Neal Cardwell <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-12-05tcp: Do not underestimate rwnd_limitedEric Dumazet1-1/+4
If available rwnd is too small, tcp_tso_should_defer() can decide it is worth waiting before splitting a TSO packet. This really means we are rwnd limited. Fixes: 5615f88614a4 ("tcp: instrument how long TCP is limited by receive window") Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Soheil Hassas Yeganeh <[email protected]> Reviewed-by: Yuchung Cheng <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-12-05Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller13-95/+732
Alexei Starovoitov says: ==================== pull-request: bpf 2018-12-05 The following pull-request contains BPF updates for your *net* tree. The main changes are: 1) fix bpf uapi pointers for 32-bit architectures, from Daniel. 2) improve verifer ability to handle progs with a lot of branches, from Alexei. 3) strict btf checks, from Yonghong. 4) bpf_sk_lookup api cleanup, from Joe. 5) other misc fixes ==================== Signed-off-by: David S. Miller <[email protected]>
2018-12-05net: use skb_list_del_init() to remove from RX sublistsEdward Cree3-8/+8
list_del() leaves the skb->next pointer poisoned, which can then lead to a crash in e.g. OVS forwarding. For example, setting up an OVS VXLAN forwarding bridge on sfc as per: ======== $ ovs-vsctl show 5dfd9c47-f04b-4aaa-aa96-4fbb0a522a30 Bridge "br0" Port "br0" Interface "br0" type: internal Port "enp6s0f0" Interface "enp6s0f0" Port "vxlan0" Interface "vxlan0" type: vxlan options: {key="1", local_ip="10.0.0.5", remote_ip="10.0.0.4"} ovs_version: "2.5.0" ======== (where 10.0.0.5 is an address on enp6s0f1) and sending traffic across it will lead to the following panic: ======== general protection fault: 0000 [#1] SMP PTI CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.20.0-rc3-ehc+ #701 Hardware name: Dell Inc. PowerEdge R710/0M233H, BIOS 6.4.0 07/23/2013 RIP: 0010:dev_hard_start_xmit+0x38/0x200 Code: 53 48 89 fb 48 83 ec 20 48 85 ff 48 89 54 24 08 48 89 4c 24 18 0f 84 ab 01 00 00 48 8d 86 90 00 00 00 48 89 f5 48 89 44 24 10 <4c> 8b 33 48 c7 03 00 00 00 00 48 8b 05 c7 d1 b3 00 4d 85 f6 0f 95 RSP: 0018:ffff888627b437e0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: dead000000000100 RCX: ffff88862279c000 RDX: ffff888614a342c0 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888618a88000 R08: 0000000000000001 R09: 00000000000003e8 R10: 0000000000000000 R11: ffff888614a34140 R12: 0000000000000000 R13: 0000000000000062 R14: dead000000000100 R15: ffff888616430000 FS: 0000000000000000(0000) GS:ffff888627b40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6d2bc6d000 CR3: 000000000200a000 CR4: 00000000000006e0 Call Trace: <IRQ> __dev_queue_xmit+0x623/0x870 ? masked_flow_lookup+0xf7/0x220 [openvswitch] ? ep_poll_callback+0x101/0x310 do_execute_actions+0xaba/0xaf0 [openvswitch] ? __wake_up_common+0x8a/0x150 ? __wake_up_common_lock+0x87/0xc0 ? queue_userspace_packet+0x31c/0x5b0 [openvswitch] ovs_execute_actions+0x47/0x120 [openvswitch] ovs_dp_process_packet+0x7d/0x110 [openvswitch] ovs_vport_receive+0x6e/0xd0 [openvswitch] ? dst_alloc+0x64/0x90 ? rt_dst_alloc+0x50/0xd0 ? ip_route_input_slow+0x19a/0x9a0 ? __udp_enqueue_schedule_skb+0x198/0x1b0 ? __udp4_lib_rcv+0x856/0xa30 ? __udp4_lib_rcv+0x856/0xa30 ? cpumask_next_and+0x19/0x20 ? find_busiest_group+0x12d/0xcd0 netdev_frame_hook+0xce/0x150 [openvswitch] __netif_receive_skb_core+0x205/0xae0 __netif_receive_skb_list_core+0x11e/0x220 netif_receive_skb_list+0x203/0x460 ? __efx_rx_packet+0x335/0x5e0 [sfc] efx_poll+0x182/0x320 [sfc] net_rx_action+0x294/0x3c0 __do_softirq+0xca/0x297 irq_exit+0xa6/0xb0 do_IRQ+0x54/0xd0 common_interrupt+0xf/0xf </IRQ> ======== So, in all listified-receive handling, instead pull skbs off the lists with skb_list_del_init(). Fixes: 9af86f933894 ("net: core: fix use-after-free in __netif_receive_skb_list_core") Fixes: 7da517a3bc52 ("net: core: Another step of skb receive list processing") Fixes: a4ca8b7df73c ("net: ipv4: fix drop handling in ip_list_rcv() and ip_list_rcv_finish()") Fixes: d8269e2cbf90 ("net: ipv6: listify ipv6_rcv() and ip6_rcv_finish()") Signed-off-by: Edward Cree <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-12-05Merge tag 'arc-4.20-rc6' of ↵Linus Torvalds20-20/+133
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc Pull ARC fixes/updates from Vineet Gupta - Missing reads{x}()/writes{x}() getting in the way of some drivers [Jose Abreu] - Builds defaulting to ARCv2 ISA based configsa [Kevin Hilman] - Misc fixes * tag 'arc-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARC: io.h: Implement reads{x}()/writes{x}() ARC: change defconfig defaults to ARCv2 arc: [devboards] Add support of NFSv3 ACL ARC: mm: fix uninitialised signal code in do_page_fault ARC: [plat-hsdk] Enable DW APB GPIO support ARCv2: boot log unaligned access in use ARC: IOC: panic if kernel was started with previously enabled IOC ARC: remove redundant 'default n' from Kconfig
2018-12-05mm, thp: restore node-local hugepage allocationsDavid Rientjes3-29/+17
This is a full revert of ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings") and a partial revert of 89c83fb539f9 ("mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask"). By not setting __GFP_THISNODE, applications can allocate remote hugepages when the local node is fragmented or low on memory when either the thp defrag setting is "always" or the vma has been madvised with MADV_HUGEPAGE. Remote access to hugepages often has much higher latency than local pages of the native page size. On Haswell, ac5b2c18911f was shown to have a 13.9% access regression after this commit for binaries that remap their text segment to be backed by transparent hugepages. The intent of ac5b2c18911f is to address an issue where a local node is low on memory or fragmented such that a hugepage cannot be allocated. In every scenario where this was described as a fix, there is abundant and unfragmented remote memory available to allocate from, even with a greater access latency. If remote memory is also low or fragmented, not setting __GFP_THISNODE was also measured on Haswell to have a 40% regression in allocation latency. Restore __GFP_THISNODE for thp allocations. Fixes: ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings") Fixes: 89c83fb539f9 ("mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask") Cc: Andrea Arcangeli <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Andrew Morton <[email protected]> Signed-off-by: David Rientjes <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-12-05acpi/nfit: Fix user-initiated ARS to be "ARS-long" rather than "ARS-short"Dan Williams1-1/+1
A "short" ARS (address range scrub) instructs the platform firmware to return known errors. In contrast, a "long" ARS instructs platform firmware to arrange every data address on the DIMM to be read / checked for poisoned data. The conversion of the flags in commit d3abaf43bab8 "acpi, nfit: Fix Address Range Scrub completion tracking", changed the meaning of passing '0' to acpi_nfit_ars_rescan(). Previously '0' meant "not short", now '0' is ARS_REQ_SHORT. Pass ARS_REQ_LONG to restore the expected scrub-type behavior of user-initiated ARS sessions. Fixes: d3abaf43bab8 ("acpi, nfit: Fix Address Range Scrub completion tracking") Reported-by: Jacek Zloch <[email protected]> Cc: Vishal Verma <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Reviewed-by: Vishal Verma <[email protected]> Signed-off-by: Dan Williams <[email protected]>
2018-12-05libnvdimm, pfn: Pad pfn namespaces relative to other regionsDan Williams3-27/+80
Commit cfe30b872058 "libnvdimm, pmem: adjust for section collisions with 'System RAM'" enabled Linux to workaround occasions where platform firmware arranges for "System RAM" and "Persistent Memory" to collide within a single section boundary. Unfortunately, as reported in this issue [1], platform firmware can inflict the same collision between persistent memory regions. The approach of interrogating iomem_resource does not work in this case because platform firmware may merge multiple regions into a single iomem_resource range. Instead provide a method to interrogate regions that share the same parent bus. This is a stop-gap until the core-MM can grow support for hotplug on sub-section boundaries. [1]: https://github.com/pmem/ndctl/issues/76 Fixes: cfe30b872058 ("libnvdimm, pmem: adjust for section collisions with...") Cc: <[email protected]> Reported-by: Patrick Geary <[email protected]> Tested-by: Patrick Geary <[email protected]> Reviewed-by: Vishal Verma <[email protected]> Signed-off-by: Dan Williams <[email protected]>
2018-12-05tools/testing/nvdimm: Align test resources to 128MDan Williams1-2/+33
In preparation for libnvdimm growing new restrictions to detect section conflicts between persistent memory regions, enable nfit_test to allocate aligned resources. Use a gen_pool to allocate nfit_test's fake resources in a separate address space from the virtual translation of the same. Reviewed-by: Vishal Verma <[email protected]> Tested-by: Vishal Verma <[email protected]> Signed-off-by: Dan Williams <[email protected]>
2018-12-05Merge tag 'for-linus-20181205' of git://git.kernel.dk/linux-blockLinus Torvalds2-1/+26
Pull block fixes from Jens Axboe: "A bit earlier in the week as usual, but there's a fix here that should go in sooner rather than later. Under a combination of circumstance, the direct issue path in blk-mq could corrupt data. This wasn't easy to hit, but the ones that are affected by it, seem to hit it pretty easily. Full explanation in the patch. None of the regular filesystem and storage testing has triggered it, even though it's been around since 4.19-rc1. Outside of that, whitelist trim tweak for certain Samsung devices for libata" * tag 'for-linus-20181205' of git://git.kernel.dk/linux-block: blk-mq: fix corruption with direct issue libata: whitelist all SAMSUNG MZ7KM* solid-state disks
2018-12-05USB: check usb_get_extra_descriptor for proper sizeMathias Payer4-7/+7
When reading an extra descriptor, we need to properly check the minimum and maximum size allowed, to prevent from invalid data being sent by a device. Reported-by: Hui Peng <[email protected]> Reported-by: Mathias Payer <[email protected]> Co-developed-by: Linus Torvalds <[email protected]> Signed-off-by: Hui Peng <[email protected]> Signed-off-by: Mathias Payer <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-12-05Merge tag 'mac80211-for-davem-2018-12-05' of ↵David S. Miller11-23/+44
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg: ==================== As it's been a while, we have various fixes for * hwsim * AP mode (client powersave related) * CSA/FTM interaction * a busy loop in IE handling * and similar ==================== Signed-off-by: David S. Miller <[email protected]>
2018-12-05drm/amdgpu/vcn: Update vcn.cur_state during suspendJames Zhu1-1/+2
Replace vcn_v1_0_stop with vcn_v1_0_set_powergating_state during suspend, to keep adev->vcn.cur_state update. It will fix VCN S3 hung issue. Signed-off-by: James Zhu <[email protected]> Reviewed-by: Leo Liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-12-05Merge tag 'for-4.20-rc5-tag' of ↵Linus Torvalds1-5/+3
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fix from David Sterba: "A patch in 4.19 introduced a sanity check that was too strict and a filesystem cannot be mounted. This happens for filesystems with more than 10 devices and has been reported by a few users so we need the fix to propagate to stable" * tag 'for-4.20-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: tree-checker: Don't check max block group size as current max chunk size limit is unreliable
2018-12-05Merge tag 'pm-4.20-rc6' of ↵Linus Torvalds1-3/+2
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fix from Rafael Wysocki: "Revert a problematic recent commit that attempted to fix a system-wide suspend issue related to the freezer" * tag 'pm-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "exec: make de_thread() freezable"
2018-12-05Merge tag 'mfd-fixes-4.20' of ↵Linus Torvalds1-1/+7
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull mfd bugfix from Lee Jones: "Replace release function in cros_ec_dev" * tag 'mfd-fixes-4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: Revert "mfd: cros_ec: Use devm_kzalloc for private data"
2018-12-05ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860GChris Chiu1-0/+2
Acer AIO Veriton Z4860G/Z6860G with the same ALC286 codec has issues with the input from external microphone. The issue can be fixed by the fixup ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE for Veriton Z4660G. Signed-off-by: Jian-Hong Pan <[email protected]> Signed-off-by: Daniel Drake <[email protected]> Signed-off-by: Chris Chiu <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-12-05ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4660GChris Chiu1-0/+1
Acer AIO Veriton Z4660G with ALC286 codec has issue with the input from external microphones connecting via 'Front Mic' jack. The fixup ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE enables the jack sensing of the headset and fix the audio input issue of external microphone. Signed-off-by: Jian-Hong Pan <[email protected]> Signed-off-by: Daniel Drake <[email protected]> Signed-off-by: Chris Chiu <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-12-05ALSA: hda/realtek - Add support for Acer Aspire C24-860 headset micChris Chiu1-0/+1
The Acer AIO Aspire C24-860 with ALC286 can't detect the headset microphone. Just like another Acer AIO U27-880, it needs a different pin value for 0x18 and the headset fixup to make headset mic work. Signed-off-by: Jian-Hong Pan <[email protected]> Signed-off-by: Daniel Drake <[email protected]> Signed-off-by: Chris Chiu <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-12-05ALSA: hda/realtek: ALC286 mic and headset-mode fixups for Acer Aspire U27-880Chris Chiu1-0/+14
Acer Aspire U27-880(AIO) with ALC286 codec can not detect headset mic and internal mic not working either. It needs the similar quirk like Sony laptops to fix headphone jack sensing and enables use of the internal microphone. Unfortunately jack sensing for the headset mic is still not working. Signed-off-by: Jian-Hong Pan <[email protected]> Signed-off-by: Daniel Drake <[email protected]> Signed-off-by: Chris Chiu <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-12-05thermal: broadcom: constify thermal_zone_of_device_ops structureJulia Lawall1-1/+1
The thermal_zone_of_device_ops structure can be const as it is only passed as the last argument of thermal_zone_of_sensor_register and the corresponding parameter is declared as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <[email protected]> Reviewed-by: Daniel Lezcano <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2018-12-05thermal: armada: constify thermal_zone_of_device_ops structureJulia Lawall1-1/+1
The thermal_zone_of_device_ops structure can be const as it is only passed as the last argument of devm_thermal_zone_of_sensor_register and the corresponding parameter is declared as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <[email protected]> Reviewed-by: Daniel Lezcano <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2018-12-05SUNRPC: Don't force a redundant disconnection in xs_read_stream()Trond Myklebust1-7/+1
If the connection is broken, then xs_tcp_state_change() will take care of scheduling the socket close as soon as appropriate. xs_read_stream() just needs to report the error. Signed-off-by: Trond Myklebust <[email protected]>
2018-12-05SUNRPC: Fix up socket pollingTrond Myklebust1-2/+2
Ensure that we do not exit the socket read callback without clearing XPRT_SOCK_DATA_READY. Signed-off-by: Trond Myklebust <[email protected]>
2018-12-05SUNRPC: Use the discard iterator rather than MSG_TRUNCTrond Myklebust1-2/+3
When discarding message data from the stream, we're better off using the discard iterator, since that will work with non-TCP streams. Signed-off-by: Trond Myklebust <[email protected]>
2018-12-05SUNRPC: Treat EFAULT as a truncated message in xs_read_stream_request()Trond Myklebust1-1/+2
Signed-off-by: Trond Myklebust <[email protected]>
2018-12-05SUNRPC: Fix up handling of the XDRBUF_SPARSE_PAGES flagTrond Myklebust1-11/+11
If the allocator fails before it has reached the target number of pages, then we need to recheck that we're not seeking past the page buffer. Signed-off-by: Trond Myklebust <[email protected]>
2018-12-05SUNRPC: Fix RPC receive hangsTrond Myklebust1-20/+19
The RPC code is occasionally hanging when the receive code fails to empty the socket buffer due to a partial read of the data. When we convert that to an EAGAIN, it appears we occasionally leave data in the socket. The fix is to just keep reading until the socket returns EAGAIN/EWOULDBLOCK. Reported-by: Catalin Marinas <[email protected]> Reported-by: Cristian Marussi <[email protected]> Reported-by: Chuck Lever <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Tested-by: Catalin Marinas <[email protected]> Tested-by: Cristian Marussi <[email protected]>
2018-12-05cfg80211: Fix busy loop regression in ieee80211_ie_split_ric()Jouni Malinen1-0/+2
This function was modified to support the information element extension case (WLAN_EID_EXTENSION) in a manner that would result in an infinite loop when going through set of IEs that include WLAN_EID_RIC_DATA and contain an IE that is in the after_ric array. The only place where this can currently happen is in mac80211 ieee80211_send_assoc() where ieee80211_ie_split_ric() is called with after_ric[]. This can be triggered by valid data from user space nl80211 association/connect request (i.e., requiring GENL_UNS_ADMIN_PERM). The only known application having an option to include WLAN_EID_RIC_DATA in these requests is wpa_supplicant and it had a bug that prevented this specific contents from being used (and because of that, not triggering this kernel bug in an automated test case ap_ft_ric) and now that this bug is fixed, it has a workaround to avoid this kernel issue. WLAN_EID_RIC_DATA is currently used only for testing purposes, so this does not cause significant harm for production use cases. Fixes: 2512b1b18d07 ("mac80211: extend ieee80211_ie_split to support EXTENSION") Cc: [email protected] Signed-off-by: Jouni Malinen <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2018-12-05mac80211: ignore NullFunc frames in the duplicate detectionEmmanuel Grumbach1-0/+1
NullFunc packets should never be duplicate just like QoS-NullFunc packets. We saw a client that enters / exits power save with NullFunc frames (and not with QoS-NullFunc) despite the fact that the association supports HT. This specific client also re-uses a non-zero sequence number for different NullFunc frames. At some point, the client had to send a retransmission of the NullFunc frame and we dropped it, leading to a misalignment in the power save state. Fix this by never consider a NullFunc frame as duplicate, just like we do for QoS NullFunc frames. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449 CC: <[email protected]> Signed-off-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2018-12-05mac80211: fix reordering of buffered broadcast packetsFelix Fietkau1-2/+2
If the buffered broadcast queue contains packets, letting new packets bypass that queue can lead to heavy reordering, since the driver is probably throttling transmission of buffered multicast packets after beacons. Keep buffering packets until the buffer has been cleared (and no client is in powersave mode). Cc: [email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2018-12-05mac80211: ignore tx status for PS stations in ieee80211_tx_status_extFelix Fietkau1-0/+2
Make it behave like regular ieee80211_tx_status calls, except for the lack of filtered frame processing. This fixes spurious low-ack triggered disconnections with powersave clients connected to an AP. Fixes: f027c2aca0cf4 ("mac80211: add ieee80211_tx_status_noskb") Cc: [email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2018-12-05tty: serial: 8250_mtk: always resume the device in probe.Peter Shih1-9/+7
serial8250_register_8250_port calls uart_config_port, which calls config_port on the port before it tries to power on the port. So we need the port to be on before calling serial8250_register_8250_port. Change the code to always do a runtime resume in probe before registering port, and always do a runtime suspend in remove. This basically reverts the change in commit 68e5fc4a255a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling"), but still use pm_runtime callbacks. Fixes: 68e5fc4a255a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling") Signed-off-by: Peter Shih <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-12-05USB: serial: console: fix reported terminal settingsJohan Hovold3-3/+11
The USB-serial console implementation has never reported the actual terminal settings used. Despite storing the corresponding cflags in its struct console, these were never honoured on later tty open() where the tty termios would be left initialised to the driver defaults. Unlike the serial console implementation, the USB-serial code calls subdriver open() already at console setup. While calling set_termios() and write() before open() looks like it could work for some USB-serial drivers, others definitely do not expect this, so modelling this after serial core is going to be intrusive, if at all possible. Instead, use a (renamed) tty helper to save the termios data used at console setup so that the tty termios reflects the actual terminal settings after a subsequent tty open(). Note that the calls to tty_init_termios() (tty_driver_install()) and tty_save_termios() are serialised using the disconnect mutex. This specifically fixes a regression that was triggered by a recent change adding software flow control to the pl2303 driver: a getty trying to disable flow control while leaving the baud rate unchanged would now also set the baud rate to the driver default (prior to the flow-control change this had been a noop). Fixes: 7041d9c3f01b ("USB: serial: pl2303: add support for tx xon/xoff flow control") Cc: stable <[email protected]> # 4.18 Cc: Florian Zumbiehl <[email protected]> Reported-by: Jarkko Nikula <[email protected]> Tested-by: Jarkko Nikula <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2018-12-05Revert "mfd: cros_ec: Use devm_kzalloc for private data"Enric Balletbo i Serra1-1/+7
This reverts commit 3aa2177e47878f7e7616da8a2050c44f22301b6e. That commit triggered a new WARN when unloading the module (see at the end of the commit message). When a class_dev is embedded in a structure then that class_dev is the thing that controls the lifetime of that structure, for that reason device managed allocations can't be used here. See Documentation/kobject.txt. Revert the above patch, so the struct is allocated using kzalloc and we have a release function for it that frees the allocated memory, otherwise it is broken. ------------[ cut here ]------------ Device 'cros_ec' does not have a release() function, it is broken and must be fixed. WARNING: CPU: 3 PID: 3675 at drivers/base/core.c:895 device_release+0x80/0x90 Modules linked in: btusb btrtl btintel btbcm bluetooth ... CPU: 3 PID: 3675 Comm: rmmod Not tainted 4.20.0-rc4 #76 Hardware name: Google Kevin (DT) pstate: 40000005 (nZcv daif -PAN -UAO) pc : device_release+0x80/0x90 lr : device_release+0x80/0x90 sp : ffff00000c47bc70 x29: ffff00000c47bc70 x28: ffff8000e86b0d40 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000056000000 x24: 0000000000000015 x23: ffff8000f0bbf860 x22: ffff000000d320a0 x21: ffff8000ee93e100 x20: ffff8000ed931428 x19: ffff8000ed931418 x18: 0000000000000020 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000400 x14: 0000000000000143 x13: 0000000000000000 x12: 0000000000000400 x11: 0000000000000157 x10: 0000000000000960 x9 : ffff00000c47b9b0 x8 : ffff8000e86b1700 x7 : 0000000000000000 x6 : ffff8000f7d520b8 x5 : ffff8000f7d520b8 x4 : 0000000000000000 x3 : ffff8000f7d58e68 x2 : ffff8000e86b0d40 x1 : 37d859939c964800 x0 : 0000000000000000 Call trace: device_release+0x80/0x90 kobject_put+0x74/0xe8 device_unregister+0x20/0x30 ec_device_remove+0x34/0x48 [cros_ec_dev] platform_drv_remove+0x28/0x48 device_release_driver_internal+0x1a8/0x240 driver_detach+0x40/0x80 bus_remove_driver+0x54/0xa8 driver_unregister+0x2c/0x58 platform_driver_unregister+0x10/0x18 cros_ec_dev_exit+0x1c/0x2d8 [cros_ec_dev] __arm64_sys_delete_module+0x16c/0x1f8 el0_svc_common+0x84/0xd8 el0_svc_handler+0x2c/0x80 el0_svc+0x8/0xc ---[ end trace a57c4625f3c60ae8 ]--- Cc: [email protected] Fixes: 3aa2177e4787 ("mfd: cros_ec: Use devm_kzalloc for private data") Signed-off-by: Enric Balletbo i Serra <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Reviewed-by: Dmitry Torokhov <[email protected]> Signed-off-by: Lee Jones <[email protected]>
2018-12-05usb: quirk: add no-LPM quirk on SanDisk Ultra Flair deviceHarry Pan1-0/+4
Some lower volume SanDisk Ultra Flair in 16GB, which the VID:PID is in 0781:5591, will aggressively request LPM of U1/U2 during runtime, when using this thumb drive as the OS installation key we found the device will generate failure during U1 exit path making it dropped from the USB bus, this causes a corrupted installation in system at the end. i.e., [ 166.918296] hub 2-0:1.0: state 7 ports 7 chg 0000 evt 0004 [ 166.918327] usb usb2-port2: link state change [ 166.918337] usb usb2-port2: do warm reset [ 166.970039] usb usb2-port2: not warm reset yet, waiting 50ms [ 167.022040] usb usb2-port2: not warm reset yet, waiting 200ms [ 167.276043] usb usb2-port2: status 02c0, change 0041, 5.0 Gb/s [ 167.276050] usb 2-2: USB disconnect, device number 2 [ 167.276058] usb 2-2: unregistering device [ 167.276060] usb 2-2: unregistering interface 2-2:1.0 [ 167.276170] xhci_hcd 0000:00:15.0: shutdown urb ffffa3c7cc695cc0 ep1in-bulk [ 167.284055] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [ 167.284064] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 33 04 90 00 01 00 00 ... Analyzed the USB trace in the link layer we realized it is because of the 6-ms timer of tRecoveryConfigurationTimeout which documented on the USB 3.2 Revision 1.0, the section 7.5.10.4.2 of "Exit from Recovery.Configuration"; device initiates U1 exit -> Recovery.Active -> Recovery.Configuration, then the host timer timeout makes the link transits to eSS.Inactive -> Rx.Detect follows by a Warm Reset. Interestingly, the other higher volume of SanDisk Ultra Flair sharing the same VID:PID, such as 64GB, would not request LPM during runtime, it sticks at U0 always, thus disabling LPM does not affect those thumb drives at all. The same odd occures in SanDisk Ultra Fit 16GB, VID:PID in 0781:5583. Signed-off-by: Harry Pan <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-12-05USB: Fix invalid-free bug in port_over_current_notify()Alan Stern1-1/+2
Syzbot and KASAN found the following invalid-free bug in port_over_current_notify(): -------------------------------------------------------------------------- BUG: KASAN: double-free or invalid-free in port_over_current_notify drivers/usb/core/hub.c:5192 [inline] BUG: KASAN: double-free or invalid-free in port_event drivers/usb/core/hub.c:5241 [inline] BUG: KASAN: double-free or invalid-free in hub_event+0xd97/0x4140 drivers/usb/core/hub.c:5384 CPU: 1 PID: 32710 Comm: kworker/1:3 Not tainted 4.20.0-rc3+ #129 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 kasan_report_invalid_free+0x64/0xa0 mm/kasan/report.c:336 __kasan_slab_free+0x13a/0x150 mm/kasan/kasan.c:501 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kfree+0xcf/0x230 mm/slab.c:3817 port_over_current_notify drivers/usb/core/hub.c:5192 [inline] port_event drivers/usb/core/hub.c:5241 [inline] hub_event+0xd97/0x4140 drivers/usb/core/hub.c:5384 process_one_work+0xc90/0x1c40 kernel/workqueue.c:2153 worker_thread+0x17f/0x1390 kernel/workqueue.c:2296 kthread+0x35a/0x440 kernel/kthread.c:246 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 -------------------------------------------------------------------------- The problem is caused by use of a static array to store environment-string pointers. When the routine is called by multiple threads concurrently, the pointers from one thread can overwrite those from another. The solution is to use an ordinary automatic array instead of a static array. Signed-off-by: Alan Stern <[email protected]> Reported-by: [email protected] Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-12-05usb: appledisplay: Add 27" Apple Cinema DisplayAlexander Theissen1-0/+1
Add another Apple Cinema Display to the list of supported displays. Signed-off-by: Alexander Theissen <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-12-05Revert commit ef9209b642f "staging: rtl8723bs: Fix indenting errors and an ↵Young Xiao1-1/+1
off-by-one mistake in core/rtw_mlme_ext.c" pstapriv->max_num_sta is always <= NUM_STA, since max_num_sta is either set in _rtw_init_sta_priv() or rtw_set_beacon(). Fixes: ef9209b642f1 ("staging: rtl8723bs: Fix indenting errors and an off-by-one mistake in core/rtw_mlme_ext.c") Signed-off-by: Young Xiao <[email protected]> Reviewed-by: Dan Carpenter <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-12-05staging: rtl8712: Fix possible buffer overrunYoung Xiao2-2/+2
In commit 8b7a13c3f404 ("staging: r8712u: Fix possible buffer overrun") we fix a potential off by one by making the limit smaller. The better fix is to make the buffer larger. This makes it match up with the similar code in other drivers. Fixes: 8b7a13c3f404 ("staging: r8712u: Fix possible buffer overrun") Signed-off-by: Young Xiao <[email protected]> Cc: stable <[email protected]> Reviewed-by: Dan Carpenter <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-12-05dmaengine: cppi41: delete channel from pending list when stop channelBin Liu1-1/+15
The driver defines three states for a cppi channel. - idle: .chan_busy == 0 && not in .pending list - pending: .chan_busy == 0 && in .pending list - busy: .chan_busy == 1 && not in .pending list There are cases in which the cppi channel could be in the pending state when cppi41_dma_issue_pending() is called after cppi41_runtime_suspend() is called. cppi41_stop_chan() has a bug for these cases to set channels to idle state. It only checks the .chan_busy flag, but not the .pending list, then later when cppi41_runtime_resume() is called the channels in .pending list will be transitioned to busy state. Removing channels from the .pending list solves the problem. Fixes: 975faaeb9985 ("dma: cppi41: start tear down only if channel is busy") Cc: [email protected] # v3.15+ Signed-off-by: Bin Liu <[email protected]> Reviewed-by: Peter Ujfalusi <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2018-12-05dmaengine: imx-sdma: use GFP_NOWAIT for dma descriptor allocationsLucas Stach1-1/+1
DMA buffer descriptors aren't allocated from atomic context, so they can use the less heavyweigth GFP_NOWAIT. Signed-off-by: Lucas Stach <[email protected]> Signed-off-by: Robin Gong <[email protected]> Cc: stable <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2018-12-05dmaengine: imx-sdma: implement channel termination via workerLucas Stach1-13/+38
The dmaengine documentation states that device_terminate_all may be asynchronous and need not wait for the active transfers to stop. This allows us to move most of the functionality currently implemented in the sdma channel termination function to run in a worker, outside of any atomic context. Moving this out of atomic context has two benefits: we can now sleep while waiting for the channel to terminate, instead of busy waiting and the freeing of the dma descriptors happens with IRQs enabled, getting rid of a warning in the dma mapping code. As the termination is now async, we need to implement the device_synchronize dma engine function which simply waits for the worker to finish its execution. Signed-off-by: Lucas Stach <[email protected]> Signed-off-by: Robin Gong <[email protected]> Cc: stable <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.