aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-02-21include/linux/sched/mm.h: re-inline mmdrop()Andrew Morton2-14/+14
As Peter points out, Doing a CALL+RET for just the decrement is a bit silly. Fixes: d70f2a14b72a4bc ("include/linux/sched/mm.h: uninline mmdrop_async(), etc") Acked-by: Peter Zijlstra (Intel) <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Oleg Nesterov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-02-21tools: fix cross-compile var clobberingMartin Kelly13-22/+18
Currently a number of Makefiles break when used with toolchains that pass extra flags in CC and other cross-compile related variables (such as --sysroot). Thus we get this error when we use a toolchain that puts --sysroot in the CC var: ~/src/linux/tools$ make iio [snip] iio_event_monitor.c:18:10: fatal error: unistd.h: No such file or directory #include <unistd.h> ^~~~~~~~~~ This occurs because we clobber several env vars related to cross-compiling with lines like this: CC = $(CROSS_COMPILE)gcc Although this will point to a valid cross-compiler, we lose any extra flags that might exist in the CC variable, which can break toolchains that rely on them (for example, those that use --sysroot). This easily shows up using a Yocto SDK: $ . [snip]/sdk/environment-setup-cortexa8hf-neon-poky-linux-gnueabi $ echo $CC arm-poky-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a8 --sysroot=[snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi $ echo $CROSS_COMPILE arm-poky-linux-gnueabi- $ echo ${CROSS_COMPILE}gcc krm-poky-linux-gnueabi-gcc Although arm-poky-linux-gnueabi-gcc is a cross-compiler, we've lost the --sysroot and other flags that enable us to find the right libraries to link against, so we can't find unistd.h and other libraries and headers. Normally with the --sysroot flag we would find unistd.h in the sdk directory in the sysroot: $ find [snip]/sdk/sysroots -path '*/usr/include/unistd.h' [snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi/usr/include/unistd.h The perf Makefile adds CC = $(CROSS_COMPILE)gcc if and only if CC is not already set, and it compiles correctly with the above toolchain. So, generalize the logic that perf uses in the common Makefile and remove the manual CC = $(CROSS_COMPILE)gcc lines from each Makefile. Note that this patch does not fix cross-compile for all the tools (some have other bugs), but it does fix it for all except usb and acpi, which still have other unrelated issues. I tested both with and without the patch on native and cross-build and there appear to be no regressions. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Martin Kelly <[email protected]> Acked-by: Mark Brown <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Li Zefan <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Linus Walleij <[email protected]> Cc: "K. Y. Srinivasan" <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: Stephen Hemminger <[email protected]> Cc: Jonathan Cameron <[email protected]> Cc: Pali Rohar <[email protected]> Cc: Richard Purdie <[email protected]> Cc: Jacek Anaszewski <[email protected]> Cc: Pavel Machek <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Robert Moore <[email protected]> Cc: Lv Zheng <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Valentina Manea <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Mario Limonciello <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-02-22Merge tag 'drm-misc-fixes-2018-02-21' of ↵Dave Airlie15-58/+196
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Fixes for 4.16. I contains fixes for deadlock on runtime suspend on few drivers, a memory leak on non-blocking commits, a crash on color-eviction. The is also meson and edid fixes, plus a fix for a doc warning. * tag 'drm-misc-fixes-2018-02-21' of git://anongit.freedesktop.org/drm/drm-misc: drm/tve200: fix kernel-doc documentation comment include drm/meson: fix vsync buffer update drm: Handle unexpected holes in color-eviction drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA drm/amdgpu: Fix deadlock on runtime suspend drm/radeon: Fix deadlock on runtime suspend drm/nouveau: Fix deadlock on runtime suspend drm: Allow determining if current task is output poll worker workqueue: Allow retrieval of current task's work struct drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits
2018-02-21amd-xgbe: Restore PCI interrupt enablement setting on resumeTom Lendacky1-0/+2
After resuming from suspend, the PCI device support must re-enable the interrupt setting so that interrupts are actually delivered. Signed-off-by: Tom Lendacky <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-21Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller9-22/+36
Daniel Borkmann says: ==================== pull-request: bpf 2018-02-20 The following pull-request contains BPF updates for your *net* tree. The main changes are: 1) Fix a memory leak in LPM trie's map_free() callback function, where the trie structure itself was not freed since initial implementation. Also a synchronize_rcu() was needed in order to wait for outstanding programs accessing the trie to complete, from Yonghong. 2) Fix sock_map_alloc()'s error path in order to correctly propagate the -EINVAL error in case of too large allocation requests. This was just recently introduced when fixing close hooks via ULP layer, fix from Eric. 3) Do not use GFP_ATOMIC in __cpu_map_entry_alloc(). Reason is that this will not work with the recent __ptr_ring_init_queue_alloc() conversion to kvmalloc_array(), where in case of fallback to vmalloc() that GFP flag is invalid, from Jason. 4) Fix two recent syzkaller warnings: i) fix bpf_prog_array_copy_to_user() when a prog query with a big number of ids was performed where we'd otherwise trigger a warning from allocator side, ii) fix a missing mlock precharge on arraymaps, from Daniel. 5) Two fixes for bpftool in order to avoid breaking JSON output when used in batch mode, from Quentin. 6) Move a pr_debug() in libbpf in order to avoid having an otherwise uninitialized variable in bpf_program__reloc_text(), from Jeremy. ==================== Signed-off-by: David S. Miller <[email protected]>
2018-02-21Merge branch 'virtio_net-XDP-fixes'David S. Miller1-24/+34
Jesper Dangaard Brouer says: ==================== virtio_net: several bugs in XDP code for driver virtio_net The virtio_net driver actually violates the original memory model of XDP causing hard to debug crashes. Per request of John Fastabend, instead of removing the XDP feature I'm fixing as much as possible. While testing virtio_net with XDP_REDIRECT I found 4 different bugs. Patch-1: not enough tail-room for build_skb in receive_mergeable() only option is to disable XDP_REDIRECT in receive_mergeable() Patch-2: XDP in receive_small() basically never worked (check wrong flag) Patch-3: fix memory leak for XDP_REDIRECT in error cases Patch-4: avoid crash when ndo_xdp_xmit is called on dev not ready for XDP In the longer run, we should consider introducing a separate receive function when attaching an XDP program, and also change the memory model to be compatible with XDP when attaching an XDP prog. ==================== Signed-off-by: David S. Miller <[email protected]>
2018-02-21virtio_net: fix ndo_xdp_xmit crash towards dev not ready for XDPJesper Dangaard Brouer1-1/+11
When a driver implements the ndo_xdp_xmit() function, there is (currently) no generic way to determine whether it is safe to call. It is e.g. unsafe to call the drivers ndo_xdp_xmit, if it have not allocated the needed XDP TX queues yet. This is the case for virtio_net, which first allocates the XDP TX queues once an XDP/bpf prog is attached (in virtnet_xdp_set()). Thus, a crash will occur for virtio_net when redirecting to another virtio_net device's ndo_xdp_xmit, which have not attached a XDP prog. The sample xdp_redirect_map tries to attach a dummy XDP prog to take this into account, but it can also easily fail if the virtio_net (or actually underlying vhost driver) have not allocated enough extra queues for the device. Allocating more queue this is currently a manual config. Hint for libvirt XML add: <driver name='vhost' queues='16'> <host mrg_rxbuf='off'/> <guest tso4='off' tso6='off' ecn='off' ufo='off'/> </driver> The solution in this patch is to check that the device have loaded an XDP/bpf prog before proceeding. This is similar to the check performed in driver ixgbe. Signed-off-by: Jesper Dangaard Brouer <[email protected]> Acked-by: John Fastabend <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-21virtio_net: fix memory leak in XDP_REDIRECTJesper Dangaard Brouer1-15/+22
XDP_REDIRECT calling xdp_do_redirect() can fail for multiple reasons (which can be inspected by tracepoints). The current semantics is that on failure the driver calling xdp_do_redirect() must handle freeing or recycling the page associated with this frame. This can be seen as an optimization, as drivers usually have an optimized XDP_DROP code path for frame recycling in place already. The virtio_net driver didn't handle when xdp_do_redirect() failed. This caused a memory leak as the page refcnt wasn't decremented on failures. The function __virtnet_xdp_xmit() did handle one type of failure, when the xmit queue virtqueue_add_outbuf() is full, which "hides" releasing a refcnt on the page. Instead the function __virtnet_xdp_xmit() must follow API of xdp_do_redirect(), which on errors leave it up to the caller to free the page, of the failed send operation. Fixes: 186b3c998c50 ("virtio-net: support XDP_REDIRECT") Signed-off-by: Jesper Dangaard Brouer <[email protected]> Acked-by: John Fastabend <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-21virtio_net: fix XDP code path in receive_small()Jesper Dangaard Brouer1-1/+1
When configuring virtio_net to use the code path 'receive_small()', in-order to get correct XDP_REDIRECT support, I discovered TCP packets would get silently dropped when loading an XDP program action XDP_PASS. The bug seems to be that receive_small() when XDP is loaded check that hdr->hdr.flags is zero, which seems wrong as hdr.flags contains the flags VIRTIO_NET_HDR_F_* : #define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 /* Use csum_start, csum_offset */ #define VIRTIO_NET_HDR_F_DATA_VALID 2 /* Csum is valid */ TCP got dropped as it had the VIRTIO_NET_HDR_F_DATA_VALID flag set. The flags that are relevant here are the VIRTIO_NET_HDR_GSO_* flags stored in hdr->hdr.gso_type. Thus, the fix is just check that none of the gso_type flags have been set. Fixes: bb91accf2733 ("virtio-net: XDP support for small buffers") Signed-off-by: Jesper Dangaard Brouer <[email protected]> Acked-by: John Fastabend <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-21virtio_net: disable XDP_REDIRECT in receive_mergeable() caseJesper Dangaard Brouer1-7/+0
The virtio_net code have three different RX code-paths in receive_buf(). Two of these code paths can handle XDP, but one of them is broken for at least XDP_REDIRECT. Function(1): receive_big() does not support XDP. Function(2): receive_small() support XDP fully and uses build_skb(). Function(3): receive_mergeable() broken XDP_REDIRECT uses napi_alloc_skb(). The simple explanation is that receive_mergeable() is broken because it uses napi_alloc_skb(), which violates XDP given XDP assumes packet header+data in single page and enough tail room for skb_shared_info. The longer explaination is that receive_mergeable() tries to work-around and satisfy these XDP requiresments e.g. by having a function xdp_linearize_page() that allocates and memcpy RX buffers around (in case packet is scattered across multiple rx buffers). This does currently satisfy XDP_PASS, XDP_DROP and XDP_TX (but only because we have not implemented bpf_xdp_adjust_tail yet). The XDP_REDIRECT action combined with cpumap is broken, and cause hard to debug crashes. The main issue is that the RX packet does not have the needed tail-room (SKB_DATA_ALIGN(skb_shared_info)), causing skb_shared_info to overlap the next packets head-room (in which cpumap stores info). Reproducing depend on the packet payload length and if RX-buffer size happened to have tail-room for skb_shared_info or not. But to make this even harder to troubleshoot, the RX-buffer size is runtime dynamically change based on an Exponentially Weighted Moving Average (EWMA) over the packet length, when refilling RX rings. This patch only disable XDP_REDIRECT support in receive_mergeable() case, because it can cause a real crash. IMHO we should consider NOT supporting XDP in receive_mergeable() at all, because the principles behind XDP are to gain speed by (1) code simplicity, (2) sacrificing memory and (3) where possible moving runtime checks to setup time. These principles are clearly being violated in receive_mergeable(), that e.g. runtime track average buffer size to save memory consumption. In the longer run, we should consider introducing a separate receive function when attaching an XDP program, and also change the memory model to be compatible with XDP when attaching an XDP prog. Fixes: 186b3c998c50 ("virtio-net: support XDP_REDIRECT") Signed-off-by: Jesper Dangaard Brouer <[email protected]> Acked-by: John Fastabend <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-21Merge tag 'mlx5-fixes-2018-02-20' of ↵David S. Miller10-33/+70
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== Mellanox, mlx5 fixes 2018-02-20 The following pull request includes some fixes for the mlx5 core and netdevice driver. Please pull and let me know if there's any issue. -stable 4.10.y: ('net/mlx5e: Fix loopback self test when GRO is off') -stable 4.12.y: ('net/mlx5e: Specify numa node when allocating drop rq') -stable 4.13.y: ('net/mlx5e: Verify inline header size do not exceed SKB linear size') -stable 4.15.y: ('net/mlx5e: Fix TCP checksum in LRO buffers') ('net/mlx5: Fix error handling when adding flow rules') ==================== Signed-off-by: David S. Miller <[email protected]>
2018-02-21Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller55-300/+314
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains large batch with Netfilter fixes for your net tree, mostly due to syzbot report fixups and pr_err() ratelimiting, more specifically, they are: 1) Get rid of superfluous unnecessary check in x_tables before vmalloc(), we don't hit BUG there anymore, patch from Michal Hock, suggested by Andrew Morton. 2) Race condition in proc file creation in ipt_CLUSTERIP, from Cong Wang. 3) Drop socket lock that results in circular locking dependency, patch from Paolo Abeni. 4) Drop packet if case of malformed blob that makes backpointer jump in x_tables, from Florian Westphal. 5) Fix refcount leak due to race in ipt_CLUSTERIP in clusterip_config_find_get(), from Cong Wang. 6) Several patches to ratelimit pr_err() for x_tables since this can be a problem where CAP_NET_ADMIN semantics can protect us in untrusted namespace, from Florian Westphal. 7) Missing .gitignore update for new autogenerated asn1 state machine for the SNMP NAT helper, from Zhu Lingshan. 8) Missing timer initialization in xt_LED, from Paolo Abeni. 9) Do not allow negative port range in NAT, also from Paolo. 10) Lock imbalance in the xt_hashlimit rate match mode, patch from Eric Dumazet. 11) Initialize workqueue before timer in the idletimer match, from Eric Dumazet. ==================== Signed-off-by: David S. Miller <[email protected]>
2018-02-21RDMA/uverbs: Fix kernel panic while using XRC_TGT QP typeLeon Romanovsky1-0/+3
Attempt to modify XRC_TGT QP type from the user space (ibv_xsrq_pingpong invocation) will trigger the following kernel panic. It is caused by the fact that such QPs missed uobject initialization. [ 17.408845] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 [ 17.412645] IP: rdma_lookup_put_uobject+0x9/0x50 [ 17.416567] PGD 0 P4D 0 [ 17.419262] Oops: 0000 [#1] SMP PTI [ 17.422915] CPU: 0 PID: 455 Comm: ibv_xsrq_pingpo Not tainted 4.16.0-rc1+ #86 [ 17.424765] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 [ 17.427399] RIP: 0010:rdma_lookup_put_uobject+0x9/0x50 [ 17.428445] RSP: 0018:ffffb8c7401e7c90 EFLAGS: 00010246 [ 17.429543] RAX: 0000000000000000 RBX: ffffb8c7401e7cf8 RCX: 0000000000000000 [ 17.432426] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000000 [ 17.437448] RBP: 0000000000000000 R08: 00000000000218f0 R09: ffffffff8ebc4cac [ 17.440223] R10: fffff6038052cd80 R11: ffff967694b36400 R12: ffff96769391f800 [ 17.442184] R13: ffffb8c7401e7cd8 R14: 0000000000000000 R15: ffff967699f60000 [ 17.443971] FS: 00007fc29207d700(0000) GS:ffff96769fc00000(0000) knlGS:0000000000000000 [ 17.446623] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 17.448059] CR2: 0000000000000048 CR3: 000000001397a000 CR4: 00000000000006b0 [ 17.449677] Call Trace: [ 17.450247] modify_qp.isra.20+0x219/0x2f0 [ 17.451151] ib_uverbs_modify_qp+0x90/0xe0 [ 17.452126] ib_uverbs_write+0x1d2/0x3c0 [ 17.453897] ? __handle_mm_fault+0x93c/0xe40 [ 17.454938] __vfs_write+0x36/0x180 [ 17.455875] vfs_write+0xad/0x1e0 [ 17.456766] SyS_write+0x52/0xc0 [ 17.457632] do_syscall_64+0x75/0x180 [ 17.458631] entry_SYSCALL_64_after_hwframe+0x21/0x86 [ 17.460004] RIP: 0033:0x7fc29198f5a0 [ 17.460982] RSP: 002b:00007ffccc71f018 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 17.463043] RAX: ffffffffffffffda RBX: 0000000000000078 RCX: 00007fc29198f5a0 [ 17.464581] RDX: 0000000000000078 RSI: 00007ffccc71f050 RDI: 0000000000000003 [ 17.466148] RBP: 0000000000000000 R08: 0000000000000078 R09: 00007ffccc71f050 [ 17.467750] R10: 000055b6cf87c248 R11: 0000000000000246 R12: 00007ffccc71f300 [ 17.469541] R13: 000055b6cf8733a0 R14: 0000000000000000 R15: 0000000000000000 [ 17.471151] Code: 00 00 0f 1f 44 00 00 48 8b 47 48 48 8b 00 48 8b 40 10 e9 0b 8b 68 00 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 53 89 f5 <48> 8b 47 48 48 89 fb 40 0f b6 f6 48 8b 00 48 8b 40 20 e8 e0 8a [ 17.475185] RIP: rdma_lookup_put_uobject+0x9/0x50 RSP: ffffb8c7401e7c90 [ 17.476841] CR2: 0000000000000048 [ 17.477764] ---[ end trace 1dbcc5354071a712 ]--- [ 17.478880] Kernel panic - not syncing: Fatal exception [ 17.480277] Kernel Offset: 0xd000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Fixes: 2f08ee363fe0 ("RDMA/restrack: don't use uaccess_kernel()") Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-02-21i2c: i801: Add missing documentation entries for Braswell and Kaby LakeJarkko Nikula3-0/+5
Commits adding PCI IDs for Intel Braswell and Kaby Lake PCH-H lacked the respective Kconfig and Documentation/i2c/busses/i2c-i801 change. Add them now. Signed-off-by: Jarkko Nikula <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-02-21i2c: designware: must wait for enableBen Gardner1-1/+1
One I2C bus on my Atom E3845 board has been broken since 4.9. It has two devices, both declared by ACPI and with built-in drivers. There are two back-to-back transactions originating from the kernel, one targeting each device. The first transaction works, the second one locks up the I2C controller. The controller never recovers. These kernel logs show up whenever an I2C transaction is attempted after this failure. i2c-designware-pci 0000:00:18.3: timeout in disabling adapter i2c-designware-pci 0000:00:18.3: timeout waiting for bus ready Waiting for the I2C controller status to indicate that it is enabled before programming it fixes the issue. I have tested this patch on 4.14 and 4.15. Fixes: commit 2702ea7dbec5 ("i2c: designware: wait for disable/enable only if necessary") Cc: linux-stable <[email protected]> #4.13+ Signed-off-by: Ben Gardner <[email protected]> Acked-by: Jarkko Nikula <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-02-21drm/tve200: fix kernel-doc documentation comment includeJani Nikula1-1/+1
The DOC: line acts as an identifier for the :doc: include. Fixes: ./drivers/gpu/drm/tve200/tve200_drv.c:1: warning: no structured comments found Cc: Linus Walleij <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-02-20net: sched: report if filter is too large to dumpRoman Kapl1-1/+6
So far, if the filter was too large to fit in the allocated skb, the kernel did not return any error and stopped dumping. Modify the dumper so that it returns -EMSGSIZE when a filter fails to dump and it is the first filter in the skb. If we are not first, we will get a next chance with more room. I understand this is pretty near to being an API change, but the original design (silent truncation) can be considered a bug. Note: The error case can happen pretty easily if you create a filter with 32 actions and have 4kb pages. Also recent versions of iproute try to be clever with their buffer allocation size, which in turn leads to Signed-off-by: Roman Kapl <[email protected]> Acked-by: Jiri Pirko <[email protected]> Acked-by: Cong Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-21drm/edid: quirk Sony PlayStation VR headset as non-desktopPhilipp Zabel1-0/+3
This uses the EDID info from the Sony PlayStation VR headset, when connected directly, to mark it as non-desktop. Since the connection box (product id b403) defaults to HDMI pass-through to the TV, it is not marked as non-desktop. Signed-off-by: Philipp Zabel <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2018-02-21drm/edid: quirk Windows Mixed Reality headsets as non-desktopPhilipp Zabel1-0/+10
This uses the EDID info from Lenovo Explorer (LEN-b800), Acer AH100 (ACR-7fce), and Samsung Odyssey (SEC-144a) to mark them as non-desktop. The other entries are for the HP Windows Mixed Reality Headset (HPN-3515), the Fujitsu Windows Mixed Reality headset (FUJ-1970), the Dell Visor (DEL-7fce), and the ASUS HC102 (AUS-c102). They are not tested with real hardware, but listed as HMD monitors alongside the tested headsets in the Microsoft HololensSensors driver package. Signed-off-by: Philipp Zabel <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2018-02-21drm/edid: quirk Oculus Rift headsets as non-desktopPhilipp Zabel1-0/+5
This uses the EDID info from Oculus Rift DK1 (OVR-0001), DK2 (OVR-0003), and CV1 (OVR-0004) to mark them as non-desktop. Signed-off-by: Philipp Zabel <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2018-02-21Merge tag 'drm-misc-fixes-2018-01-31' of ↵Dave Airlie1-17/+23
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes - fix lut loading for cirrus * tag 'drm-misc-fixes-2018-01-31' of git://anongit.freedesktop.org/drm/drm-misc: drm/cirrus: Load lut in crtc_commit
2018-02-21Merge tag 'exynos-drm-fixes-for-v4.16-rc3' of ↵Dave Airlie5-30/+12
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes - three fixeups . it fixes potential issues[1] by using monotonic timestamp instead of 'struct timeval' . correct HDMI_I2S_PIN_SEL_1 definition and setting value. . fix bit shift typo of FIMC register definition - two cleanups . remove unnecessary error messages . remove exynos_drm_rotator.h file [1] https://patchwork.kernel.org/patch/10170205/ * tag 'exynos-drm-fixes-for-v4.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm: exynos: Use proper macro definition for HDMI_I2S_PIN_SEL_1 drm/exynos: remove exynos_drm_rotator.h drm/exynos: g2d: Delete an error message for a failed memory allocation in two functions drm/exynos: fix comparison to bitshift when dealing with a mask drm/exynos: g2d: use monotonic timestamps
2018-02-20net/mlx5: Fix error handling when adding flow rulesVlad Buslov1-2/+8
If building match list or adding existing fg fails when node is locked, function returned without unlocking it. This happened if node version changed or adding existing fg returned with EAGAIN after jumping to search_again_locked label. Fixes: bd71b08ec2ee ("net/mlx5: Support multiple updates of steering rules in parallel") Signed-off-by: Vlad Buslov <[email protected]> Reviewed-by: Maor Gottlieb <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-02-20net/mlx5: E-Switch, Fix drop counters use before creationEugenia Emantayev1-4/+4
First use of drop counters happens in esw_apply_vport_conf function, while they are allocated later in the flow. Fix that by moving esw_vport_create_drop_counters function to be called before the first use. Fixes: b8a0dbe3a90b ("net/mlx5e: E-switch, Add steering drop counters") Signed-off-by: Eugenia Emantayev <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-02-20net/mlx5: Add header re-write to the checks for conflicting actionsOr Gerlitz1-1/+2
We can't allow only some of the rules sharing an FTE to ask for header re-write, add it to the conflicting action checks. Fixes: 0d235c3fabb7 ('net/mlx5: Add hash table to search FTEs in a flow-group') Signed-off-by: Or Gerlitz <[email protected]> Reviewed-by: Matan Barak <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-02-20net/mlx5: Use 128B cacheline size for 128B or larger cachelinesDaniel Jurgens1-1/+1
The adapter uses the cache_line_128byte setting to set the bounds for end padding. On systems where the cacheline size is greater than 128B use 128B instead of the default of 64B. This results in fewer partial cacheline writes. There's a 50% chance it will pad to the end of a 256B cache line vs only 25% when using 64B. Fixes: f32f5bd2eb7e ("net/mlx5: Configure cache line size for start and end padding") Signed-off-by: Daniel Jurgens <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-02-20net/mlx5e: Specify numa node when allocating drop rqGal Pressman1-2/+8
When allocating a drop rq, no numa node is explicitly set which means allocations are done on node zero. This is not necessarily the nearest numa node to the HCA, and even worse, might even be a memoryless numa node. Choose the numa_node given to us by the pci device in order to properly allocate the coherent dma memory instead of assuming zero is valid. Fixes: 556dd1b9c313 ("net/mlx5e: Set drop RQ's necessary parameters only") Signed-off-by: Gal Pressman <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-02-20net/mlx5e: Return error if prio is specified when offloading eswitch vlan pushOr Gerlitz1-1/+2
This isn't supported when we emulate eswitch vlan push action which is the current state of things. Fixes: 8b32580df1cb ('net/mlx5e: Add TC vlan action for SRIOV offloads') Signed-off-by: Or Gerlitz <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-02-20net/mlx5: Address static checker warnings on non-constant initializersOr Gerlitz1-4/+4
Address these sparse warnings on drivers/net/ethernet/mellanox/mlx5 [..]/core/diag/fs_tracepoint.c:99:53: warning: non-constant initializer for static object [..]/core/diag/fs_tracepoint.c:102:53: warning: non-constant initializer for static object etc Signed-off-by: Or Gerlitz <[email protected]> Reviewed-by: Matan Barak <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-02-20net/mlx5e: Eliminate build warnings on no previous prototypeOr Gerlitz2-2/+3
Fix these gcc warnings on drivers/net/ethernet/mellanox/mlx5: [..]/core/lib/clock.c:454:6: warning: no previous prototype for 'mlx5_init_clock' [-Wmissing-prototypes] [..]/core/lib/clock.c:510:6: warning: no previous prototype for 'mlx5_cleanup_clock' [-Wmissing-prototypes] [..]/core/en_main.c:3141:5: warning: no previous prototype for 'mlx5e_setup_tc' [-Wmissing-prototypes] Signed-off-by: Or Gerlitz <[email protected]> Reviewed-by: Matan Barak <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-02-20net/mlx5e: Verify inline header size do not exceed SKB linear sizeEran Ben Elisha1-1/+1
Driver tries to copy at least MLX5E_MIN_INLINE bytes into the control segment of the WQE. It assumes that the linear part contains at least MLX5E_MIN_INLINE bytes, which can be wrong. Cited commit verified that driver will not copy more bytes into the inline header part that the actual size of the packet. Re-factor this check to make sure we do not exceed the linear part as well. This fix is aligned with the current driver's assumption that the entire L2 will be present in the linear part of the SKB. Fixes: 6aace17e64f4 ("net/mlx5e: Fix inline header size for small packets") Signed-off-by: Eran Ben Elisha <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-02-20net/mlx5e: Fix loopback self test when GRO is offInbar Karmy1-1/+2
When GRO is off, the transport header pointer in sk_buff is initialized to network's header. To find the udp header, instead of using udp_hdr() which assumes skb_network_header was set, manually calculate the udp header offset. Fixes: 0952da791c97 ("net/mlx5e: Add support for loopback selftest") Signed-off-by: Inbar Karmy <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-02-20net/mlx5e: Fix TCP checksum in LRO buffersGal Pressman1-14/+35
When receiving an LRO packet, the checksum field is set by the hardware to the checksum of the first coalesced packet. Obviously, this checksum is not valid for the merged LRO packet and should be fixed. We can use the CQE checksum which covers the checksum of the entire merged packet TCP payload to help us calculate the checksum incrementally. Tested by sending IPv4/6 traffic with LRO enabled, RX checksum disabled and watching nstat checksum error counters (in addition to the obvious bandwidth drop caused by checksum errors). This bug is usually "hidden" since LRO packets would go through the CHECKSUM_UNNECESSARY flow which does not validate the packet checksum. It's important to note that previous to this patch, LRO packets provided with CHECKSUM_UNNECESSARY are indeed packets with a correct validated checksum (even though the checksum inside the TCP header is incorrect), since the hardware LRO aggregation is terminated upon receiving a packet with bad checksum. Fixes: e586b3b0baee ("net/mlx5: Ethernet Datapath files") Signed-off-by: Gal Pressman <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-02-20tools/libbpf: Avoid possibly using uninitialized variableJeremy Cline1-2/+3
Fixes a GCC maybe-uninitialized warning introduced by 48cca7e44f9f. "text" is only initialized inside the if statement so only print debug info there. Fixes: 48cca7e44f9f ("libbpf: add support for bpf_call") Signed-off-by: Jeremy Cline <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]>
2018-02-20ibmvnic: Check for NULL skb's in NAPI poll routineThomas Falcon1-0/+5
After introduction of commit d0869c0071e4, there were some instances of RX queue entries from a previous session (before the device was closed and reopened) returned to the NAPI polling routine. Since the corresponding socket buffers were freed, this resulted in a panic on reopen. Include a check for a NULL skb here to avoid this. Fixes: d0869c0071e4 ("ibmvnic: Clean RX pool buffers during device close") Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-20Rename sbi_save to parse_dtb to improve code readabilityMichael Clark2-2/+2
The sbi_ prefix would seem to indicate an SBI interface, and save is not very specific. After applying this patch, reading head.S makes more sense. Signed-off-by: Michael Clark <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2018-02-20RISC-V: Enable IRQ during exception handling[email protected]1-2/+3
Interrupt is allowed during exception handling. There are warning messages if the kernel enables the configuration 'CONFIG_DEBUG_ATOMIC_SLEEP=y'. BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:23 in_atomic(): 0, irqs_disabled(): 1, pid: 43, name: ash CPU: 0 PID: 43 Comm: ash Tainted: G W 4.15.0-rc8-00089-g89ffdae-dirty #17 Call Trace: [<000000009abb1587>] walk_stackframe+0x0/0x7a [<00000000d4f3d088>] ___might_sleep+0x102/0x11a [<00000000b1fd792a>] down_read+0x18/0x28 [<000000000289ec01>] do_page_fault+0x86/0x2f6 [<00000000012441f6>] _do_fork+0x1b4/0x1e0 [<00000000f46c3e3b>] ret_from_syscall+0xa/0xe Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Zong Li <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2018-02-20RISC-V: kconfig cleanupsPalmer Dabbelt1-3/+0
These three kconfig cleanups were found by ulfalyzer. They're all things we were selecting that were undefined, either because they'd been remove upstream or are part of a future RISC-V submission. * ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE is obselete. * RISCV_IRQ_INTC is the old name for our interrupt controller driver, it'll be changed for the final submission and doesn't exist now. * ARCH_WANT_OPTIONAL_GPIOLIB is obselete.
2018-02-20riscv: Remove ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE selectUlf Magnusson1-1/+0
The ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE symbol was removed in commit 51a021244b9d ("atomic64: no need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE"). Remove the ARCH_HAS_ATOMIC64_DEC_IS_POSITIVE select from RISCV. Discovered with the https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py script. Signed-off-by: Ulf Magnusson <[email protected]> Reviewed-by: Jonathan Neuschäfer <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2018-02-20riscv: kconfig: Remove RISCV_IRQ_INTC selectUlf Magnusson1-1/+0
The RISCV_IRQ_INTC configuration symbol is undefined, but RISCV selects it. Quoting Palmer Dabbelt: It looks like this slipped through, the symbol has been renamed RISCV_INTC. No RISCV_INTC configuration symbol has been merged either. Just remove the RISCV_IRQ_INTC select for now. Signed-off-by: Ulf Magnusson <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2018-02-20riscv: Remove ARCH_WANT_OPTIONAL_GPIOLIB selectUlf Magnusson1-1/+0
The ARCH_WANT_OPTIONAL_GPIOLIB symbol was removed in commit 65053e1a7743 ("gpio: delete ARCH_[WANTS_OPTIONAL|REQUIRE]_GPIOLIB"). GPIOLIB should just be selected explicitly if needed. Remove the ARCH_WANT_OPTIONAL_GPIOLIB select from RISCV. See commit 0145071b3314 ("x86: Do away with ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB") and commit da9a1c6767 ("arm64: do away with ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB") as well. Discovered with the https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py script. Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Ulf Magnusson <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2018-02-20Merge tag 'leds_for-4.16-rc3' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds Pull LED maintainer update: "LED update to MAINTAINERS, to admit the reality. Message from Richard: "I've been looking at some of the emails but not needed to be involved for a while now, you're doing fine without me!" [0] Many thanks to Richard for his work as a founder of the LED subsystem!" [0] https://lkml.org/lkml/2018/2/18/145 * tag 'leds_for-4.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds: MAINTAINERS: Remove Richard Purdie from LED maintainers
2018-02-20RDMA/bnxt_re: Avoid system hang during device un-regSelvin Xavier2-5/+4
BNXT_RE_FLAG_TASK_IN_PROG doesn't handle multiple work requests posted together. Track schedule of multiple workqueue items by maintaining a per device counter and proceed with IB dereg only if this counter is zero. flush_workqueue is no longer required from NETDEV_UNREGISTER path. Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-02-20RDMA/bnxt_re: Fix system crash during load/unloadSelvin Xavier1-0/+5
During driver unload, the driver proceeds with cleanup without waiting for the scheduled events. So the device pointers get freed up and driver crashes when the events are scheduled later. Flush the bnxt_re_task work queue before starting device removal. Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-02-20RDMA/bnxt_re: Synchronize destroy_qp with poll_cqSelvin Xavier4-19/+47
Avoid system crash when destroy_qp is invoked while the driver is processing the poll_cq. Synchronize these functions using the cq_lock. Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-02-20RDMA/bnxt_re: Unpin SQ and RQ memory if QP create failsDevesh Sharma1-1/+8
Driver leaves the QP memory pinned if QP create command fails from the FW. Avoids this scenario by adding a proper exit path if the FW command fails. Signed-off-by: Devesh Sharma <[email protected]> Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-02-20RDMA/bnxt_re: Disable atomic capability on bnxt_re adaptersDevesh Sharma2-17/+3
More testing needs to be done before enabling this feature. Disabling the feature temporarily Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-02-20MIPS: Drop spurious __unused in struct compat_flockJames Hogan1-1/+0
MIPS' struct compat_flock doesn't match the 32-bit struct flock, as it has an extra short __unused before pad[4], which combined with alignment increases the size to 40 bytes compared with struct flock's 36 bytes. Since commit 8c6657cb50cb ("Switch flock copyin/copyout primitives to copy_{from,to}_user()"), put_compat_flock() writes the full compat_flock struct to userland, which results in corruption of the userland word after the struct flock when running 32-bit userlands on 64-bit kernels. This was observed to cause a bus error exception when starting Firefox on Debian 8 (Jessie). Reported-by: Peter Mamonov <[email protected]> Signed-off-by: James Hogan <[email protected]> Tested-by: Peter Mamonov <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Al Viro <[email protected]> Cc: [email protected] Cc: <[email protected]> # 4.13+ Patchwork: https://patchwork.linux-mips.org/patch/18646/
2018-02-20Revert "usb: musb: host: don't start next rx urb if current one failed"Bin Liu1-7/+1
This reverts commit dbac5d07d13e330e6706813c9fde477140fb5d80. commit dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one failed") along with commit b5801212229f ("usb: musb: host: clear rxcsr error bit if set") try to solve the issue described in [1], but the latter alone is sufficient, and the former causes the issue as in [2], so now revert it. [1] https://marc.info/?l=linux-usb&m=146173995117456&w=2 [2] https://marc.info/?l=linux-usb&m=151689238420622&w=2 Cc: [email protected] # v4.7+ Signed-off-by: Bin Liu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-02-20usb: musb: fix enumeration after resumeAndreas Kemnade1-1/+2
On dm3730 there are enumeration problems after resume. Investigation led to the cause that the MUSB_POWER_SOFTCONN bit is not set. If it was set before suspend (because it was enabled via musb_pullup()), it is set in musb_restore_context() so the pullup is enabled. But then musb_start() is called which overwrites MUSB_POWER and therefore disables MUSB_POWER_SOFTCONN, so no pullup is enabled and the device is not enumerated. So let's do a subset of what musb_start() does in the same way as musb_suspend() does it. Platform-specific stuff it still called as there might be some phy-related stuff which needs to be enabled. Also interrupts are enabled, as it was the original idea of calling musb_start() in musb_resume() according to Commit 6fc6f4b87cb3 ("usb: musb: Disable interrupts on suspend, enable them on resume") Signed-off-by: Andreas Kemnade <[email protected]> Tested-by: Tony Lindgren <[email protected]> Signed-off-by: Bin Liu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.