- 15 Nov, 2016 10 commits
-
-
Andrew Lunn authored
[ Upstream commit 3c293f4e ] The phy_start() is used to indicate the PHY is now ready to do its work. The state is changed, normally to PHY_UP which means that both the MAC and the PHY are ready. If the phy driver is using polling, when the next poll happens, the state machine notices the PHY is now in PHY_UP, and kicks off auto-negotiation, if needed. If however, the PHY is using interrupts, there is no polling. The phy is stuck in PHY_UP until the next interrupt comes along. And there is no reason for the PHY to interrupt. Have phy_start() schedule the state machine to run, which both speeds up the polling use case, and makes the interrupt use case actually work. This problems exists whenever there is a state change which will not cause an interrupt. Trigger the state machine in these cases, e.g. phy_error(). Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Cc: Kyle Roeschley <kyle.roeschley@ni.com> Tested-by:
Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eric Dumazet authored
[ Upstream commit 8ce48623 ] Baozeng Ding reported following KASAN splat : BUG: KASAN: use-after-free in ip6_datagram_recv_specific_ctl+0x13f1/0x15c0 at addr ffff880029c84ec8 Read of size 1 by task poc/25548 Call Trace: [<ffffffff82cf43c9>] dump_stack+0x12e/0x185 /lib/dump_stack.c:15 [< inline >] print_address_description /mm/kasan/report.c:204 [<ffffffff817ced3b>] kasan_report_error+0x48b/0x4b0 /mm/kasan/report.c:283 [< inline >] kasan_report /mm/kasan/report.c:303 [<ffffffff817ced9e>] __asan_report_load1_noabort+0x3e/0x40 /mm/kasan/report.c:321 [<ffffffff85c71da1>] ip6_datagram_recv_specific_ctl+0x13f1/0x15c0 /net/ipv6/datagram.c:687 [<ffffffff85c734c3>] ip6_datagram_recv_ctl+0x33/0x40 [<ffffffff85c0b07c>] do_ipv6_getsockopt.isra.4+0xaec/0x2150 [<ffffffff85c0c7f6>] ipv6_getsockopt+0x116/0x230 [<ffffffff859b5a12>] tcp_getsockopt+0x82/0xd0 /net/ipv4/tcp.c:3035 [<ffffffff855fb385>] sock_common_getsockopt+0x95/0xd0 /net/core/sock.c:2647 [< inline >] SYSC_getsockopt /net/socket.c:1776 [<ffffffff855f8ba2>] SyS_getsockopt+0x142/0x230 /net/socket.c:1758 [<ffffffff8685cdc5>] entry_SYSCALL_64_fastpath+0x23/0xc6 Memory state around the buggy address: ffff880029c84d80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff880029c84e00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ffff880029c84e80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff880029c84f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff880029c84f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff He also provided a syzkaller reproducer. Issue is that ip6_datagram_recv_specific_ctl() expects to find IP6CB data that was moved at a different place in tcp_v6_rcv() This patch moves tcp_v6_restore_cb() up and calls it from tcp_v6_do_rcv() when np->pktoptions is set. Fixes: 971f10ec ("tcp: better TCP_SKB_CB layout to reduce cache line misses") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Baozeng Ding <sploving1@gmail.com> Signed-off-by:
-
WANG Cong authored
[ Upstream commit ab102b80 ] Krister reported a kernel NULL pointer dereference after tcf_action_init_1() invokes a_o->init(), it is a race condition where one thread calling tcf_register_action() to initialize the netns data after putting act ops in the global list and the other thread searching the list and then calling a_o->init(net, ...). Fix this by moving the pernet ops registration before making the action ops visible. This is fine because: a) we don't rely on act_base in pernet ops->init(), b) in the worst case we have a fully initialized netns but ops is still not ready so new actions still can't be created. Reported-by:
Krister Johansen <kjlx@templeofstupid.com> Tested-by:
Cong Wang <xiyou.wangcong@gmail.com> Acked-by:
Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
-
Vlad Tsyrklevich authored
[ Upstream commit 02a9079c ] The reserved field precise_offset->rsv is not cleared before being copied to user space, leaking kernel stack memory. Clear the struct before it's copied. Signed-off-by:
Vlad Tsyrklevich <vlad@tsyrklevich.net> Acked-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit d35c99ff ] Since linux-3.15, netlink_dump() can use up to 16384 bytes skb allocations. Due to struct skb_shared_info ~320 bytes overhead, we end up using order-3 (on x86) page allocations, that might trigger direct reclaim and add stress. The intent was really to attempt a large allocation but immediately fallback to a smaller one (order-1 on x86) in case of memory stress. On recent kernels (linux-4.4), we can remove __GFP_DIRECT_RECLAIM to meet the goal. Old kernels would need to remove __GFP_WAIT While we are at it, since we do an order-3 allocation, allow to use all the allocated bytes instead of 16384 to reduce syscalls during large dumps. iproute2 already uses 32KB recvmsg() buffer sizes. Alexei provided an initial patch downsizing to SKB_WITH_OVERHEAD(16384) Fixes: 9063e21f ("netlink: autosize skb lengthes") Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Cc: Greg Thelen <gthelen@google.com> Reviewed-by:
Greg Rose <grose@lightfleet.com> Acked-by:
-
Anoob Soman authored
[ Upstream commit 66644982 ] If a socket has FANOUT sockopt set, a new proto_hook is registered as part of fanout_add(). When processing a NETDEV_UNREGISTER event in af_packet, __fanout_unlink is called for all sockets, but prot_hook which was registered as part of fanout_add is not removed. Call fanout_release, on a NETDEV_UNREGISTER, which removes prot_hook and removes fanout from the fanout_list. This fixes BUG_ON(!list_empty(&dev->ptype_specific)) in netdev_run_todo() Signed-off-by:
Anoob Soman <anoob.soman@citrix.com> Signed-off-by:
-
Andrew Collins authored
[ Upstream commit 93409033 ] This is a respin of a patch to fix a relatively easily reproducible kernel panic related to the all_adj_list handling for netdevs in recent kernels. The following sequence of commands will reproduce the issue: ip link add link eth0 name eth0.100 type vlan id 100 ip link add link eth0 name eth0.200 type vlan id 200 ip link add name testbr type bridge ip link set eth0.100 master testbr ip link set eth0.200 master testbr ip link add link testbr mac0 type macvlan ip link delete dev testbr This creates an upper/lower tree of (excuse the poor ASCII art): /---eth0.100-eth0 mac0-testbr- \---eth0.200-eth0 When testbr is deleted, the all_adj_lists are walked, and eth0 is deleted twice from the mac0 list. Unfortunately, during setup in __netdev_upper_dev_link, only one reference to eth0 is added, so this results in a panic. This change adds reference count propagation so things are handled properly. Matthias Schiffer reported a similar crash in batman-adv: https://github.com/freifunk-gluon/gluon/issues/680 https://www.open-mesh.org/issues/247 which this patch also seems to resolve. Signed-off-by:
Andrew Collins <acollins@cradlepoint.com> Signed-off-by:
-
Shmulik Ladkani authored
[ Upstream commit f39acc84 ] Generic skb_vlan_push/skb_vlan_pop functions don't properly handle the case where the input skb data pointer does not point at the mac header: - They're doing push/pop, but fail to properly unwind data back to its original location. For example, in the skb_vlan_push case, any subsequent 'skb_push(skb, skb->mac_len)' calls make the skb->data point 4 bytes BEFORE start of frame, leading to bogus frames that may be transmitted. - They update rcsum per the added/removed 4 bytes tag. Alas if data is originally after the vlan/eth headers, then these bytes were already pulled out of the csum. OTOH calling skb_vlan_push/skb_vlan_pop with skb->data at mac_header present no issues. act_vlan is the only caller to skb_vlan_*() that has skb->data pointing at network header (upon ingress). Other calles (ovs, bpf) already adjust skb->data at mac_header. This patch fixes act_vlan to point to the mac_header prior calling skb_vlan_*() functions, as other callers do. Signed-off-by:
Shmulik Ladkani <shmulik.ladkani@gmail.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Pravin Shelar <pshelar@ovn.org> Cc: Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Paolo Abeni authored
[ Upstream commit 63d75463 ] The commit 879c7220 ("net: pktgen: Observe needed_headroom of the device") increased the 'pkt_overhead' field value by LL_RESERVED_SPACE. As a side effect the generated packet size, computed as: /* Eth + IPh + UDPh + mpls */ datalen = pkt_dev->cur_pkt_size - 14 - 20 - 8 - pkt_dev->pkt_overhead; is decreased by the same value. The above changed slightly the behavior of existing pktgen users, and made the procfs interface somewhat inconsistent. Fix it by restoring the previous pkt_overhead value and using LL_RESERVED_SPACE as extralen in skb allocation. Also, change pktgen_alloc_skb() to only partially reserve the headroom to allow the caller to prefetch from ll header start. v1 -> v2: - fixed some typos in the comments Fixes: 879c7220 ("net: pktgen: Observe needed_headroom of the device") Suggested-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Gavin Schenk authored
[ Upstream commit b82d44d7 ] If the mac address origin is not dt, you can only safely assign a mac address after "link up" of the device. If the link is off the clocks are disabled and because of issues assigning registers when clocks are off the new mac address cannot be written in .ndo_set_mac_address() on some soc's. This fix sets the mac address unconditionally in fec_restart(...) and ensures consistency between fec registers and the network layer. Signed-off-by:
Gavin Schenk <g.schenk@eckelmann.de> Acked-by:
Fugang Duan <fugang.duan@nxp.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Fixes: 9638d19e ("net: fec: add netif status check before set mac address") Signed-off-by:
-
- 10 Nov, 2016 30 commits
-
-
Greg Kroah-Hartman authored
-
Oliver Neukum authored
commit cf0ea4da upstream. Like many similar devices it needs a quirk to work. Issuing the request gets the device into an irrecoverable state. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Rafael J. Wysocki authored
commit a6c6ead1 upstream. After commit a4675fbc (cpufreq: intel_pstate: Replace timers with utilization update callbacks) the cpufreq governor callbacks may not be invoked on NOHZ_FULL CPUs and, in particular, switching to the "performance" policy via sysfs may not have any effect on them. That is a problem, because it usually is desirable to squeeze the last bit of performance out of those CPUs, so work around it by setting the maximum P-state (within the limits) in intel_pstate_set_policy() upfront when the policy is CPUFREQ_POLICY_PERFORMANCE. Fixes: a4675fbc (cpufreq: intel_pstate: Replace timers with utilization update callbacks) Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
-
Boris Brezillon authored
commit 40b6e61a upstream. Commit e96a8a3b ("UBI: Fastmap: Do not add vol if it already exists") introduced a bug by changing the possible error codes returned by add_vol(): - this function no longer returns NULL in case of allocation failure but return ERR_PTR(-ENOMEM) - when a duplicate entry in the volume RB tree is found it returns ERR_PTR(-EEXIST) instead of ERR_PTR(-EINVAL) Fix the tests done on add_vol() return val to match this new behavior. Fixes: e96a8a3b ("UBI: Fastmap: Do not add vol if it already exists") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by:
Sheng Yong <shengyong1@huawei.com> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Goldwyn Rodrigues authored
commit 0b34c261 upstream. While free'ing qgroup->reserved resources, we much check if the page has not been invalidated by a truncate operation by checking if the page is still dirty before reducing the qgroup resources. Resources in such a case are free'd when the entire extent is released by delayed_ref. This fixes a double accounting while releasing resources in case of truncating a file, reproduced by the following testcase. SCRATCH_DEV=/dev/vdb SCRATCH_MNT=/mnt mkfs.btrfs -f $SCRATCH_DEV mount -t btrfs $SCRATCH_DEV $SCRATCH_MNT cd $SCRATCH_MNT btrfs quota enable $SCRATCH_MNT btrfs subvolume create a btrfs qgroup limit 500m a $SCRATCH_MNT sync for c in {1..15}; do dd if=/dev/zero bs=1M count=40 of=$SCRATCH_MNT/a/file; done sleep 10 sync sleep 5 touch $SCRATCH_MNT/a/newfile echo "Removing file" rm $SCRATCH_MNT/a/file Fixes: b9d0b389 ("btrfs: Add handler for invalidate page") Signed-off-by:
Goldwyn Rodrigues <rgoldwyn@suse.com> Reviewed-by:
Qu Wenruo <quwenruo@cn.fujitsu.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Owen Hofmann authored
commit d9092f52 upstream. Commit 41061cdb ("KVM: emulate: do not initialize memopp") removes a check for non-NULL under incorrect assumptions. An undefined instruction with a ModR/M byte with Mod=0 and R/M-5 (e.g. 0xc7 0x15) will attempt to dereference a null pointer here. Fixes: 41061cdb Message-Id: <1477592752-126650-2-git-send-email-osh@google.com> Signed-off-by:
Owen Hofmann <osh@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Russell King authored
commit 04946fb6 upstream. Alexander Shiyan reports that CLPS711x fails at boot time in the data exception handler due to a NULL pointer dereference. This is caused by the late-v4t abort handler overwriting R9 (which becomes zero). Fix this by making the abort handler save and restore R9. Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = c3b58000 [00000008] *pgd=800000000, *pte=00000000, *ppte=feff4140 Internal error: Oops: 63c11817 [#1] PREEMPT ARM CPU: 0 PID: 448 Comm: ash Not tainted 4.8.1+ #1 Hardware name: Cirrus Logic CLPS711X (Device Tree Support) task: c39e03a0 ti: c3b4e000 task.ti: c3b4e000 PC is at __dabt_svc+0x4c/0x60 LR is at do_page_fault+0x144/0x2ac pc : [<c000d3ac>] lr : [<c000fcec>] psr: 60000093 sp : c3b4fe6c ip : 00000001 fp : b6f1bf88 r10: c387a5a0 r9 : 00000000 r8 : e4e0e001 r7 : bee3ef83 r6 : 00100000 r5 : 80000013 r4 : c022fcf8 r3 : 00000000 r2 : 00000008 r1 : bf000000 r0 : 00000000 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 0000217f Table: c3b58055 DAC: 00000055 Process ash (pid: 448, stack limit = 0xc3b4e190) Stack: (0xc3b4fe6c to 0xc3b50000) fe60: bee3ef83 c05168d1 ffffffff 00000000 c3adfe80 fe80: c3a03300 00000000 c3b4fed0 c3a03400 bee3ef83 c387a5a0 b6f1bf88 00000001 fea0: c3b4febc 00000076 c022fcf8 80000013 ffffffff 0000003f bf000000 bee3ef83 fec0: 00000004 00000000 c3adfe80 c00e432c 00000812 00000005 00000001 00000006 fee0: b6f1b000 00000000 00010000 0003c944 0004d000 0004d439 00010000 b6f1b000 ff00: 00000005 00000000 00015ecc c3b4fed0 0000000a 00000000 00000000 c00a1dc0 ff20: befff000 c3a03300 c3b4e000 c0507cd8 c0508024 fffffff8 c3a03300 00000000 ff40: c0516a58 c00a35bc c39e03a0 000001c0 bea84ce8 0004e008 c3b3a000 c00a3ac0 ff60: c3b40374 c3b3a000 bea84d11 00000000 c0500188 bea84d11 bea84ce8 00000001 ff80: 0000000b c000a304 c3b4e000 00000000 bea84ce4 c00a3cd0 00000000 bea84d11 ffa0: bea84ce8 c000a160 bea84d11 bea84ce8 bea84d11 bea84ce8 0004e008 0004d450 ffc0: bea84d11 bea84ce8 00000001 0000000b b6f45ee4 00000000 b6f5ff70 bea84ce4 ffe0: b6f2f130 bea84cb0 b6f2f194 b6ef29f4 a0000010 bea84d11 02c7cffa 02c7cffd [<c000d3ac>] (__dabt_svc) from [<c022fcf8>] (__copy_to_user_std+0xf8/0x330) [<c022fcf8>] (__copy_to_user_std) from [<c00e432c>] +(load_elf_binary+0x920/0x107c) [<c00e432c>] (load_elf_binary) from [<c00a35bc>] +(search_binary_handler+0x80/0x16c) [<c00a35bc>] (search_binary_handler) from [<c00a3ac0>] +(do_execveat_common+0x418/0x600) [<c00a3ac0>] (do_execveat_common) from [<c00a3cd0>] (do_execve+0x28/0x30) [<c00a3cd0>] (do_execve) from [<c000a160>] (ret_fast_syscall+0x0/0x30) Code: e1a0200d eb00136b e321f093 e59d104c (e5891008) ---[ end trace 4b4f8086ebef98c5 ]--- Fixes: e6978e4b ("ARM: save and reset the address limit when entering an exception") Reported-by:
Alexander Shiyan <shc_work@mail.ru> Tested-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Jiri Slaby authored
commit 42acfc66 upstream. In csi_J(3), the third parameter of scr_memsetw (vc_screenbuf_size) is divided by 2 inappropriatelly. But scr_memsetw expects size, not count, because it divides the size by 2 on its own before doing actual memset-by-words. So remove the bogus division. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Petr Písař <ppisar@redhat.com> Fixes: f8df13e0 (tty: Clean console safely) Signed-off-by:
-
Laurent Pinchart authored
commit e4e70a14 upstream. Pipelines can only be run if all their video nodes are streaming. Commit b4dfb9b3 ("[media] v4l: vsp1: Stop the pipeline upon the first STREAMOFF") fixed the pipeline stop sequence, but introduced a race condition that makes it possible to run a pipeline after stopping the stream on a video node by queuing a buffer on the other side of the pipeline. Fix this by clearing the buffers ready flag when stopping the stream, which will prevent the QBUF handler from running the pipeline. Fixes: b4dfb9b3 ("[media] v4l: vsp1: Stop the pipeline upon the first STREAMOFF") Reported-by:
Kieran Bingham <kieran@bingham.xyz> Tested-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Tony Lindgren authored
commit d8e5f0ec upstream. If we configure musb with 2430 glue as a peripheral, and then rmmod omap2430 module, we'll get the following error: [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] ... rmmod/413 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: (&phy->mutex){+.+.+.}, at: [<c04b9fd0>] phy_power_off+0x1c/0xb8 [ 204.678710] and this task is already holding: (&(&musb->lock)->rlock){-.-...}, at: [<bf3a482c>] musb_gadget_stop+0x24/0xec [musb_hdrc] which would create a new lock dependency: (&(&musb->lock)->rlock){-.-...} -> (&phy->mutex){+.+.+.} ... This is because some glue layers expect musb_platform_enable/disable to be called with spinlock held, and 2430 glue layer has USB PHY on the I2C bus using a mutex. We could fix the glue layers to take the spinlock, but we still have a problem of musb_plaform_enable/disable being called in an unbalanced manner. So that would still lead into USB PHY enable/disable related problems for omap2430 glue layer. While it makes sense to only enable USB PHY when needed from PM point of view, in this case we just can't do it yet without breaking things. So let's just revert phy_enable/disable related changes instead and reconsider this after we have fixed musb_platform_enable/disable to be balanced. Fixes: a83e17d0 ("usb: musb: Improve PM runtime and phy handling for 2430 glue layer") Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Bin Liu <b-liu@ti.com> Signed-off-by:
-
Stefan Wahren authored
commit 991d5add upstream. After commit b09b5224 ("usb: chipidea: implement platform shutdown callback") and commit 43a40457 ("usb: chipidea: host: set host to be null after hcd is freed") a NULL pointer dereference is caused on i.MX23 during shutdown. So ensure that role is set to CI_ROLE_END and we finish interrupt handling before the hcd is deallocated. This avoids the NULL pointer dereference. Suggested-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Fixes: b09b5224 ("usb: chipidea: implement platform shutdown callback") Signed-off-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
-
Christophe JAILLET authored
commit 51fbc7c0 upstream. In commit 2abd9d5f ("usb: dwc3: ep0: Add chained TRB support"), the size of the memory allocated with 'dma_alloc_coherent()' has been modified but the corresponding calls to 'dma_free_coherent()' have not been updated accordingly. This has been spotted with coccinelle, using the following script: //////////////////// @r@ expression x0, x1, y0, y1, z0, z1, t0, t1, ret; @@ * ret = dma_alloc_coherent(x0, y0, z0, t0); ... * dma_free_coherent(x1, y1, ret, t1); @script:python@ y0 << r.y0; y1 << r.y1; @@ if y1.find(y0) == -1: print "WARNING: sizes look different: '%s' vs '%s'" % (y0, y1) //////////////////// Fixes: 2abd9d5f ("usb: dwc3: ep0: Add chained TRB support") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
David Hsu authored
commit 0733424c upstream. Exported pwm channels aren't removed before the pwmchip and are leaked. This results in invalid sysfs files. This fix removes all exported pwm channels before chip removal. Signed-off-by:
David Hsu <davidhsu@google.com> Fixes: 76abbdde ("pwm: Add sysfs interface") Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
Wei Yongjun authored
commit 43da7575 upstream. Fix the retrn value check which testing the wrong variable in dsi_bind(). Fixes: f76ee892 ("omapfb: copy omapdss & displays for omapfb") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Dan Carpenter authored
commit e0299908 upstream. If we "goto out;" then it calls display_timings_release(timings); Since "timings" is NULL, that's going to oops. Just return directly. Fixes: 420a4882 ('video: fbdev: pxafb: initial devicetree conversion') Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Emilio López authored
commit 58f0f9f7 upstream. As part of the sync framework destaging, the sync_file.h header was moved, but an entry was not added on Kbuild to install it. This patch resolves this omission so that "make headers_install" installs this header. Fixes: 460bfc41 ("dma-buf/sync_file: de-stage sync_file headers") Reported-by:
Michael Ellerman <mpe@ellerman.id.au> Reviewed-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
Emilio López <emilio.lopez@collabora.co.uk> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20160927143142.8975-1-emilio.lopez@collabora.co.ukSigned-off-by:
-
Boris Brezillon authored
commit ecbfa8ea upstream. scan_pool() does not mark the PEB for scrubing when bitflips are detected in the EC header of a free PEB (VID header region left to 0xff). Make sure we scrub the PEB in this case. Signed-off-by:
-
Liping Zhang authored
commit 6d19375b upstream. Justin and Chris spotted that iptables NFLOG target was broken when they upgraded the kernel to 4.8: "ulogd-2.0.5- IPs are no longer logged" or "results in segfaults in ulogd-2.0.5". Because "struct nf_loginfo li;" is a local variable, and flags will be filled with garbage value, not inited to zero. So if it contains 0x1, packets will not be logged to the userspace anymore. Fixes: 7643507f ("netfilter: xt_NFLOG: nflog-range does not truncate packets") Reported-by:
Justin Piszcz <jpiszcz@lucidpixels.com> Reported-by:
Chris Caputo <ccaputo@alt.net> Tested-by:
Liping Zhang <liping.zhang@spreadtrum.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Ralf Ramsauer authored
commit 6a676fb6 upstream. Instantiated I2C device nodes are marked with OF_POPULATE. This was introduced in 4f001fd3. On unloading, loaded device nodes will of course be unmarked. The problem are nodes that fail during initialisation: If a node fails, it won't be unloaded and hence not be unmarked. If a I2C driver module is unloaded and reloaded, it will skip nodes that failed before. Skip device nodes that are already populated and mark them only in case of success. Fixes: 4f001fd3 ("i2c: Mark instantiated device nodes with OF_POPULATE") Signed-off-by:
Ralf Ramsauer <ralf@ramses-pyramidenbau.de> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Pantelis Antoniou <pantelis.antoniou@konsulko.com> [wsa: use 14-digit commit sha] Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Daniel Stone authored
commit 1fb3672e upstream. The previous code would wait for fences on the framebuffer from the old plane state to complete, rather than the new, so you would see tearing everywhere. Fix this to wait on the new state before we make it active. Signed-off-by:
Daniel Stone <daniels@collabora.com> Fixes: 94f05024 ("drm/i915: nonblocking commit") Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161021144454.6288-1-daniels@collabora.com (cherry picked from commit 2d2c5ad8) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Paulo Zanoni authored
commit e3b9e6e3 upstream. Broadwell and newer actually compress up to 2560 lines instead of 2048 (as documented in the FBC_CTL page). If we don't take this into consideration we end up reserving too little stolen memory for the CFB, so we may allocate something else (such as a ring) right after what we reserved, and the hardware will overwrite it with the contents of the CFB when FBC is active, causing GPU hangs. Another possibility is that the CFB may be allocated at the very end of the available space, so the CFB will overlap the reserved stolen area, leading to FIFO underruns. This bug has always been a problem on BDW (the only affected platform where FBC is enabled by default), but it's much easier to reproduce since the following commit: commit c58b735f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Aug 18 17:16:57 2016 +0100 drm/i915: Allocate rings from stolen Of course, you can only reproduce the bug if your screen is taller than 2048 lines. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98213 Fixes: a98ee793 ("drm/i915/fbc: enable FBC by default on HSW and BDW") Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477065346-13736-1-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit 79f2624b) Signed-off-by:
-
Ville Syrjälä authored
commit 0ce140d4 upstream. Now that we use the AUX and GMBUS assignment from VBT for all ports, let's clean up the sanitization of the port information a bit. Previosuly we only did this for port E, and only complained about a non-standard assignment for the other ports. But as we know that non-standard assignments are a fact of life, let's expand the sanitization to all the ports. v2: Include a commit message, fix up the comments a bit v3: Don't clobber other ports if the current port has no alternate aux ch/ddc pin Cc: Maarten Maathuis <madman2003@gmail.com> Tested-by:
Maarten Maathuis <madman2003@gmail.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=97877Signed-off-by:
-
Ville Syrjälä authored
commit 198c5ee3 upstream. The VBT provides the platform a way to mix and match the DDI ports vs. AUX channels. Currently we only trust the VBT for DDI E, which has no corresponding AUX channel of its own. However it is possible that some board might use some non-standard DDI vs. AUX port routing even for the other ports. Perhaps for signal routing reasons or something, So let's generalize this and trust the VBT for all ports. For now we'll limit this to DDI platforms, as we trust the VBT a bit more there anyway when it comes to the DDI ports. I've structured the code in a way that would allow us to easily expand this to other platforms as well, by simply filling in the ddi_port_info. v2: Drop whitespace changes, keep MISSING_CASE() for unknown aux ch assignment, include a commit message, include debug message during init Cc: Maarten Maathuis <madman2003@gmail.com> Tested-by:
Jim Bride <jim.bride@linux.intel.com> (cherry picked from commit 8f7ce038) Signed-off-by:
-
Felix Monninger authored
commit cac5fced upstream. drm_property_lookup_blob() returns a reference to the returned blob, and drm_atomic_replace_property_blob() takes a references to the blob it stores, so afterwards we are left owning a reference to the new_blob that we never release, and thus leak memory every time we update a property such as during drm_atomic_helper_legacy_gamma_set(). v2: update credentials, drm_property_unreference_blob() is NULL safe and NULL is passed consistently to it throughout drm_atomic.c so do so here. Reported-by:
Felix Monninger <felix.monninger@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98420Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Fixes: 5488dc16 ("drm: introduce pipe color correction properties") Reviewed-by:
-
Ville Syrjälä authored
commit 4da5caa6 upstream. Only certain types of pdts have the DDC bus registered, so check for that before we attempt the EDID read. Othwewise we risk playing around with an i2c adapter that doesn't actually exist. Cc: Carlos Santa <carlos.santa@intel.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Tested-by:
Carlos Santa <carlos.santa@intel.com> Tested-by:
Kirill A. Shutemov <kirill@shutemov.name> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666Signed-off-by:
-
Paulo Zanoni authored
commit 5e33791e upstream. Luckily, the necessary adjustments for when we're using the scaler are exactly the same as the ones needed on ILK+, so just reuse the function we already have. v2: Invert the patch order so stable backports get easier. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475872138-16194-1-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit cfd7e3a2) Signed-off-by:
-
Paulo Zanoni authored
commit 01c72d6c upstream. With the previous code we were only recomputing the DDB partitioning for the CRTCs included in the atomic commit, so any other active CRTCs would end up having their DDB registers zeroed. In this patch we make sure that the computed state starts as a copy of the current partitioning, and then we only zero the DDBs that we're actually going to recompute. How to reproduce the bug: 1 - Enable the primary plane on pipe A 2 - Enable the primary plane on pipe B 3 - Enable the cursor or sprite plane on pipe A Step 3 will zero the DDB partitioning for pipe B since it's not included in the commit that enabled the cursor or sprite for pipe A. I expect this to fix many FIFO underrun problems on gen9+. v2: - Mention the cursor on the steps to reproduce the problem (Paulo). - Add Testcase tag provided by Maarten (Maarten). Testcase: kms_cursor_legacy.cursorA-vs-flipB-atomic-transitions Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96226 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96828 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97450 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97596 Bugzilla: https://www.phoronix.com/scan.php?page=news_item&px=Intel-Skylake-Multi-Screen-WoesSigned-off-by:
Lyude <cpaul@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475602652-17326-1-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit 5a920b85) Signed-off-by:
-
Ville Syrjälä authored
commit a2889606 upstream. The fbdev helper code keeps around two lists of connectors. One is the list of all connectors it could use, and that list already holds references for all the connectors. However the other list, or rather lists, is the one actively being used. That list is tracked per-crtc and currently doesn't hold any extra references. Let's grab those extra references to avoid oopsing when the connector vanishes. The list of all possible connectors should get updated when the hpd happens, but the list of actively used connectors would not get updated until the next time the fb-helper picks through the set of possible connectors. And so we need to hang on to the connectors until that time. Since we need to clean up in drm_fb_helper_crtc_free() as well, let's pull the code to a common place. And while at it let's pull in up the modeset->mode cleanup in there as well. The case of modeset->fb is a bit less clear. I'm thinking we should probably hold a reference to it, but for now I just slapped on a FIXME. v2: Cleanup things drm_fb_helper_crtc_free() too (Chris) v3: Don't leak modeset->connectors (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Carlos Santa <carlos.santa@intel.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Tested-by: Carlos Santa <carlos.santa@intel.com> (v1) Tested-by: Kirill A. Shutemov <kirill@shutemov.name> (v1) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666Signed-off-by:
-
Ville Syrjälä authored
commit 7dfcb36a upstream. We need to drop the connector references already taken when we abort in the middle of drm_fb_helper_single_add_all_connectors() Cc: Carlos Santa <carlos.santa@intel.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Tested-by:
-
Takashi Iwai authored
commit 87d3b658 upstream. Since 4.7 kernel, we've seen the error messages like kernel: [TTM] Buffer eviction failed kernel: qxl 0000:00:02.0: object_init failed for (4026540032, 0x00000001) kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate VRAM BO on QXL when switching and accessing on VT. The culprit was the generic deferred_io code (qxl driver switched to it since 4.7). There is a race between the dirty clip update and the call of callback. In drm_fb_helper_dirty(), the dirty clip is updated in the spinlock, while it kicks off the update worker outside the spinlock. Meanwhile the update worker clears the dirty clip in the spinlock, too. Thus, when drm_fb_helper_dirty() is called concurrently, schedule_work() is called after the clip is cleared in the first worker call. This patch addresses it by validating the clip before calling the dirty fb callback. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98322 Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1003298 Fixes: eaa434de ('drm/fb-helper: Add fb_deferred_io support') Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
