aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-12-13tcp: refresh tcp_mstamp from timers callbacksEric Dumazet1-0/+2
Only the retransmit timer currently refreshes tcp_mstamp We should do the same for delayed acks and keepalives. Even if RFC 7323 does not request it, this is consistent to what linux did in the past, when TS values were based on jiffies. Fixes: 385e20706fac ("tcp: use tp->tcp_mstamp in output path") Signed-off-by: Eric Dumazet <[email protected]> Cc: Soheil Hassas Yeganeh <[email protected]> Cc: Mike Maloney <[email protected]> Cc: Neal Cardwell <[email protected]> Acked-by: Neal Cardwell <[email protected]> Acked-by: Soheil Hassas Yeganeh <[email protected]> Acked-by: Mike Maloney <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13tcp: fix potential underestimation on rcv_rttWei Wang1-4/+6
When ms timestamp is used, current logic uses 1us in tcp_rcv_rtt_update() when the real rcv_rtt is within 1 - 999us. This could cause rcv_rtt underestimation. Fix it by always using a min value of 1ms if ms timestamp is used. Fixes: 645f4c6f2ebd ("tcp: switch rcv_rtt_est and rcvq_space to high resolution timestamps") Signed-off-by: Wei Wang <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Neal Cardwell <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13skge: remove redundunt free_irq under spinlockStephen Hemminger1-1/+0
The code to handle multi-port SKGE boards was freeing IRQ twice. The first one was under lock and might sleep. Signed-off-by: Stephen Hemminger <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13net: phy: meson-gxl: make function meson_gxl_read_status staticColin Ian King1-1/+1
The function meson_gxl_read_status is local to the source and does not need to be in global scope, so make it static. Cleans up sparse warning: symbol 'meson_gxl_read_status' was not declared. Should it be static? Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Jerome Brunet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13of_mdio / mdiobus: ensure mdio devices have fwnode correctly populatedRussell King2-0/+4
Ensure that all mdio devices populate the struct device fwnode pointer as well as the of_node pointer to allow drivers that wish to use fwnode APIs to work. Signed-off-by: Russell King <[email protected]> Reviewed-by: Rob Herring <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13net: phy: fix resume handlingRussell King3-14/+9
When a PHY has the BMCR_PDOWN bit set, it may decide to ignore writes to other registers, or reset the registers to power-on defaults. Micrel PHYs do this for their interrupt registers. The current structure of phylib tries to enable interrupts before resuming (and releasing) the BMCR_PDOWN bit. This fails, causing Micrel PHYs to stop working after a suspend/resume sequence if they are using interrupts. Fix this by ensuring that the PHY driver resume methods do not take the phydev->lock mutex themselves, but the callers of phy_resume() take that lock. This then allows us to move the call to phy_resume() before we enable interrupts in phy_start(). Signed-off-by: Russell King <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13ARM: dts: vf610-zii-dev: use XAUI for DSA link portsRussell King1-2/+2
Use XAUI rather than XGMII for DSA link ports, as this is the interface mode that the switches actually use. XAUI is the 4 lane bus with clock per direction, whereas XGMII is a 32 bit bus with clock. Signed-off-by: Russell King <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13net: dsa: allow XAUI phy interface modeRussell King1-0/+1
XGMII is a 32-bit bus plus two clock signals per direction. XAUI is four serial lanes per direction. The 88e6190 supports XAUI but not XGMII as it doesn't have enough pins. The same is true of 88e6176. Match on PHY_INTERFACE_MODE_XAUI for the XAUI port type, but keep accepting XGMII for backwards compatibility. Signed-off-by: Russell King <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13hippi: Fix a Fix a possible sleep-in-atomic bug in rr_closeJia-Ju Bai1-1/+1
The driver may sleep under a spinlock. The function call path is: rr_close (acquire the spinlock) free_irq --> may sleep To fix it, free_irq is moved to the place without holding the spinlock. This bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller16-38/+170
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The follow patchset contains Netfilter fixes for your net tree, they are: 1) Fix compilation warning in x_tables with clang due to useless redundant reassignment, from Colin Ian King. 2) Add bugtrap to net_exit to catch uninitialized lists, patch from Vasily Averin. 3) Fix out of bounds memory reads in H323 conntrack helper, this comes with an initial patch to remove replace the obscure CHECK_BOUND macro as a dependency. From Eric Sesterhenn. 4) Reduce retransmission timeout when window is 0 in TCP conntrack, from Florian Westphal. 6) ctnetlink clamp timeout to INT_MAX if timeout is too large, otherwise timeout wraps around and it results in killing the entry that is being added immediately. 7) Missing CAP_NET_ADMIN checks in cthelper and xt_osf, due to no netns support. From Kevin Cernekee. 8) Missing maximum number of instructions checks in xt_bpf, patch from Jann Horn. 9) With no CONFIG_PROC_FS ipt_CLUSTERIP compilation breaks, patch from Arnd Bergmann. 10) Missing netlink attribute policy in nftables exthdr, from Florian Westphal. 11) Enable conntrack with IPv6 MASQUERADE rules, as a357b3f80bc8 should have done in first place, from Konstantin Khlebnikov. ==================== Signed-off-by: David S. Miller <[email protected]>
2017-12-13net: ethernet: arc: fix error handling in emac_rockchip_probeBranislav Radocaj1-3/+7
If clk_set_rate() fails, we should disable clk before return. Found by Linux Driver Verification project (linuxtesting.org). Changes since v2 [1]: * Merged with latest code changes Changes since v1: Update made thanks to David's review, much appreciated David. * Improved inconsistent failure handling of clock rate setting * For completeness of usecase, added arc_emac_probe error handling Signed-off-by: Branislav Radocaj <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13net: qmi_wwan: add Sierra EM7565 1199:9091Sebastian Sjoholm1-0/+1
Sierra Wireless EM7565 is an Qualcomm MDM9x50 based M.2 modem. The USB id is added to qmi_wwan.c to allow QMI communication with the EM7565. Signed-off-by: Sebastian Sjoholm <[email protected]> Acked-by: Bjørn Mork <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13net: igmp: Use correct source address on IGMPv3 reportsKevin Cernekee1-1/+19
Closing a multicast socket after the final IPv4 address is deleted from an interface can generate a membership report that uses the source IP from a different interface. The following test script, run from an isolated netns, reproduces the issue: #!/bin/bash ip link add dummy0 type dummy ip link add dummy1 type dummy ip link set dummy0 up ip link set dummy1 up ip addr add 10.1.1.1/24 dev dummy0 ip addr add 192.168.99.99/24 dev dummy1 tcpdump -U -i dummy0 & socat EXEC:"sleep 2" \ UDP4-DATAGRAM:239.101.1.68:8889,ip-add-membership=239.0.1.68:10.1.1.1 & sleep 1 ip addr del 10.1.1.1/24 dev dummy0 sleep 5 kill %tcpdump RFC 3376 specifies that the report must be sent with a valid IP source address from the destination subnet, or from address 0.0.0.0. Add an extra check to make sure this is the case. Signed-off-by: Kevin Cernekee <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13tipc: eliminate potential memory leakJon Maloy1-1/+1
In the function tipc_sk_mcast_rcv() we call refcount_dec(&skb->users) on received sk_buffers. Since the reference counter might hit zero at this point, we have a potential memory leak. We fix this by replacing refcount_dec() with kfree_skb(). Signed-off-by: Jon Maloy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13net: remove duplicate includesPravin Shedge7-7/+0
These duplicate includes have been found with scripts/checkincludes.pl but they have been removed manually to avoid removing false positives. Signed-off-by: Pravin Shedge <[email protected]> Acked-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13ipv4: igmp: guard against silly MTU valuesEric Dumazet4-12/+19
IPv4 stack reacts to changes to small MTU, by disabling itself under RTNL. But there is a window where threads not using RTNL can see a wrong device mtu. This can lead to surprises, in igmp code where it is assumed the mtu is suitable. Fix this by reading device mtu once and checking IPv4 minimal MTU. This patch adds missing IPV4_MIN_MTU define, to not abuse ETH_MIN_MTU anymore. Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13ipv6: mcast: better catch silly mtu valuesEric Dumazet1-10/+15
syzkaller reported crashes in IPv6 stack [1] Xin Long found that lo MTU was set to silly values. IPv6 stack reacts to changes to small MTU, by disabling itself under RTNL. But there is a window where threads not using RTNL can see a wrong device mtu. This can lead to surprises, in mld code where it is assumed the mtu is suitable. Fix this by reading device mtu once and checking IPv6 minimal MTU. [1] skbuff: skb_over_panic: text:0000000010b86b8d len:196 put:20 head:000000003b477e60 data:000000000e85441e tail:0xd4 end:0xc0 dev:lo ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:104! invalid opcode: 0000 [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.15.0-rc2-mm1+ #39 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:skb_panic+0x15c/0x1f0 net/core/skbuff.c:100 RSP: 0018:ffff8801db307508 EFLAGS: 00010286 RAX: 0000000000000082 RBX: ffff8801c517e840 RCX: 0000000000000000 RDX: 0000000000000082 RSI: 1ffff1003b660e61 RDI: ffffed003b660e95 RBP: ffff8801db307570 R08: 1ffff1003b660e23 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff85bd4020 R13: ffffffff84754ed2 R14: 0000000000000014 R15: ffff8801c4e26540 FS: 0000000000000000(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000463610 CR3: 00000001c6698000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> skb_over_panic net/core/skbuff.c:109 [inline] skb_put+0x181/0x1c0 net/core/skbuff.c:1694 add_grhead.isra.24+0x42/0x3b0 net/ipv6/mcast.c:1695 add_grec+0xa55/0x1060 net/ipv6/mcast.c:1817 mld_send_cr net/ipv6/mcast.c:1903 [inline] mld_ifc_timer_expire+0x4d2/0x770 net/ipv6/mcast.c:2448 call_timer_fn+0x23b/0x840 kernel/time/timer.c:1320 expire_timers kernel/time/timer.c:1357 [inline] __run_timers+0x7e1/0xb60 kernel/time/timer.c:1660 run_timer_softirq+0x4c/0xb0 kernel/time/timer.c:1686 __do_softirq+0x29d/0xbb2 kernel/softirq.c:285 invoke_softirq kernel/softirq.c:365 [inline] irq_exit+0x1d3/0x210 kernel/softirq.c:405 exiting_irq arch/x86/include/asm/apic.h:540 [inline] smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052 apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920 Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Tested-by: Xin Long <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13IB/ipoib: Restore MM behavior in case of tx_ring allocation failureYuval Shaia1-0/+1
memalloc_noio_save modifies the behavior of MM, we must restore it after we are done. Fixes: d83187dda9b9 ("IB/IPoIB: Convert IPoIB to memalloc_noio_* calls") Signed-off-by: Yuval Shaia <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2017-12-13Revert "ravb: add workaround for clock when resuming with WoL enabled"Geert Uytterhoeven1-25/+2
This reverts commit fbf3d034f2ff6264183cfa6845770e8cc2a986c8. As of commit 560869100b99a3da ("clk: renesas: cpg-mssr: Restore module clocks during resume"), the workaround is no longer needed. Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Acked-by: Sergei Shtylyov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-13drm: Update edid-derived drm_display_info fields at edid property set [v2]Keith Packard3-14/+53
There are a set of values in the drm_display_info structure for each connector which hold information derived from EDID. These are computed in drm_add_display_info. Before this patch, that was only called in drm_add_edid_modes. This meant that they were only set when EDID was present and never reset when EDID was not, as happened when the display was disconnected. One of these fields, non_desktop, is used from drm_mode_connector_update_edid_property, the function responsible for assigning the new edid value to the application-visible property. Various drivers call these two functions (drm_add_edid_modes and drm_mode_connector_update_edid_property) in different orders. This means that even when EDID is present, the drm_display_info fields may not have been computed at the time that drm_mode_connector_update_edid_property used the non_desktop value to set the non_desktop property. I've added a public function (drm_reset_display_info) that resets the drm_display_info field values to default values and then made the drm_add_display_info function public. These two functions are now called directly from drm_mode_connector_update_edid_property so that the drm_display_info fields are always computed from the current EDID information before being used in that function. This means that the drm_display_info values are often computed twice, once when the EDID property it set and a second time when EDID is used to compute modes for the device. The alternative would be to uniformly ensure that the values were computed once before being used, which would require that all drivers reliably invoke the two paths in the same order. The computation is inexpensive enough that it seems more maintainable in the long term to simply compute them in both paths. The API to drm_add_display_info has been changed so that it no longer takes the set of edid-based quirks as a parameter. Rather, it now computes those quirks itself and returns them for further use by drm_add_edid_modes. This patch also includes a number of 'const' additions caused by drm_mode_connector_update_edid_property taking a 'const struct edid *' parameter and wanting to pass that along to drm_add_display_info. v2: after review by Daniel Vetter <[email protected]> Removed EXPORT_SYMBOL_GPL for drm_reset_display_info and drm_add_display_info. Added FIXME in drm_mode_connector_update_edid_property about potentially merging that with drm_add_edid_modes to avoid the need for two driver calls. Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (danvet: cherry picked from commit 12a889bf4bca ("drm: rework delayed connector cleanup in connector_iter") from drm-misc-next since functional conflict with changes in -next and we need to make sure both have the right version and nothing gets lost.) Signed-off-by: Daniel Vetter <[email protected]>
2017-12-13USB: core: prevent malicious bNumInterfaces overflowAlan Stern1-1/+3
A malicious USB device with crafted descriptors can cause the kernel to access unallocated memory by setting the bNumInterfaces value too high in a configuration descriptor. Although the value is adjusted during parsing, this adjustment is skipped in one of the error return paths. This patch prevents the problem by setting bNumInterfaces to 0 initially. The existing code already sets it to the proper value after parsing is complete. Signed-off-by: Alan Stern <[email protected]> Reported-by: Andrey Konovalov <[email protected]> CC: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-13Revert "USB: core: only clean up what we allocated"Greg Kroah-Hartman1-6/+3
This reverts commit 32fd87b3bbf5f7a045546401dfe2894dbbf4d8c3. Alan wrote a better fix for this... Cc: Andrey Konovalov <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-13tools/lib/lockdep: Add missing declaration of 'pr_cont()'Mengting Zhang1-0/+1
Commit: 681fbec881de ("lockdep: Use consistent printing primitives") has moved lockdep away from using printk() for printing. The commit added usage of pr_cont() which wasn't wrapped in the userspace headers, causing the following warning for the liblockdep build: ../../../kernel/locking/lockdep.c:3544:2: warning: implicit declaration of function 'pr_cont' [-Wimplicit-function-declaration] Adding an empty declaration of 'pr_cont' fixes the problem. Signed-off-by: Mengting Zhang <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Reviewed-by: Alexander Sverdlin <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-12-13arm64: fault: avoid send SIGBUS two timesDongjiu Geng1-3/+2
do_sea() calls arm64_notify_die() which will always signal user-space. It also returns whether APEI claimed the external abort as a RAS notification. If it returns failure do_mem_abort() will signal user-space too. do_mem_abort() wants to know if we handled the error, we always call arm64_notify_die() so can always return success. Signed-off-by: Dongjiu Geng <[email protected]> Reviewed-by: James Morse <[email protected]> Reviewed-by: Xie XiuQi <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2017-12-12Merge tag 'platform-drivers-x86-v4.15-3' of ↵Linus Torvalds3-0/+20
git://git.infradead.org/linux-platform-drivers-x86 Pull x86 platform driver fixes from Darren Hart: - Correct an error in the evdev protocol in asus-wireless which results in dropped key events in recent versions of libinput - Add a quirk for keyboard lighting for a specific Dell laptop - Silence a static analysis warning regarding unchecked return values of small kmalloc() allocations in dell-wmi * tag 'platform-drivers-x86-v4.15-3' of git://git.infradead.org/linux-platform-drivers-x86: platform/x86: dell-wmi: check for kmalloc() errors platform/x86: asus-wireless: send an EV_SYN/SYN_REPORT between state changes platform/x86: dell-laptop: Fix keyboard max lighting for Dell Latitude E6410
2017-12-12bpf: add schedule points to map alloc/freeEric Dumazet1-0/+2
While using large percpu maps, htab_map_alloc() can hold cpu for hundreds of ms. This patch adds cond_resched() calls to percpu alloc/free call sites, all running in process context. Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]>
2017-12-12i2c: piix4: Fix port number check on releaseJean Delvare1-1/+1
The port number shift is still hard-coded to 1 while it now depends on the hardware. Thankfully 0 is always 0 no matter how you shift it, so this was a bug without consequences. Signed-off-by: Jean Delvare <[email protected]> Fixes: 0fe16195f891 ("i2c: piix4: Fix SMBus port selection for AMD Family 17h chips") Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2017-12-12i2c: stm32: Fix copyrightsBenjamin Gaignard3-3/+6
Uniformize STMicroelectronics copyrights headers and add SPDX identifier. Signed-off-by: Benjamin Gaignard <[email protected]> Acked-by: Alexandre TORGUE <[email protected]> Acked-by: Pierre-Yves MORDRET <[email protected]> Acked-by: M'boumba Cedric Madianga <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2017-12-12Merge tag 'at24-4.15-rc3-fixes-for-wolfram' of ↵Wolfram Sang1-15/+11
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into i2c/for-current Sakari fixed a regression introduced during the 4.15 merge window and David submitted a fix for an issue that has existed in at24 since introducing nvmem.
2017-12-12Revert "dt-bindings: mtd: add sst25wf040b and en25s64 to sip-nor list"Cyrille Pitchen1-2/+0
This reverts commit b07815d4eaf658b683c345d6e643895a20d92f29. The reverted commit was merged into v4-15-rc1 by mistake: it was taken from the IMX tree but the patch has never been sent to linux-mtd nor reviewed by any spi-nor maintainers. Actually, it would have been rejected since we add new values for the 'compatible' DT property only for SPI NOR memories that don't support the JEDEC READ ID op code (0x9F). Both en25s64 and sst25wf040b support the JEDEC READ ID op code, hence should use the "jedec,spi-nor" string alone as 'compatible' value. See the following link for more details: http://lists.infradead.org/pipermail/linux-mtd/2017-November/077425.html Signed-off-by: Cyrille Pitchen <[email protected]> Acked-by: Marek Vasut <[email protected]>
2017-12-12Merge branch 'bpf-misc-fixes'Alexei Starovoitov4-19/+21
Daniel Borkmann says: ==================== Couple of outstanding fixes for BPF tree: 1) fixes a perf RB corruption, 2) and 3) fixes a few build issues from the recent bpf_perf_event.h uapi corrections. Thanks! ==================== Signed-off-by: Alexei Starovoitov <[email protected]>
2017-12-12bpf: fix broken BPF selftest buildDaniel Borkmann2-12/+8
At least on x86_64, the kernel's BPF selftests seemed to have stopped to build due to 618e165b2a8e ("selftests/bpf: sync kernel headers and introduce arch support in Makefile"): [...] In file included from test_verifier.c:29:0: ../../../include/uapi/linux/bpf_perf_event.h:11:32: fatal error: asm/bpf_perf_event.h: No such file or directory #include <asm/bpf_perf_event.h> ^ compilation terminated. [...] While pulling in tools/arch/*/include/uapi/asm/bpf_perf_event.h seems to work fine, there's no automated fall-back logic right now that would do the same out of tools/include/uapi/asm-generic/bpf_perf_event.h. The usual convention today is to add a include/[uapi/]asm/ equivalent that would pull in the correct arch header or generic one as fall-back, all ifdef'ed based on compiler target definition. It's similarly done also in other cases such as tools/include/asm/barrier.h, thus adapt the same here. Fixes: 618e165b2a8e ("selftests/bpf: sync kernel headers and introduce arch support in Makefile") Signed-off-by: Daniel Borkmann <[email protected]> Cc: Hendrik Brueckner <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Acked-by: Alexei Starovoitov <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]>
2017-12-12bpf: fix build issues on um due to mising bpf_perf_event.hDaniel Borkmann1-0/+1
Since c895f6f703ad ("bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT program type") um (uml) won't build on i386 or x86_64: [...] CC init/main.o In file included from ../include/linux/perf_event.h:18:0, from ../include/linux/trace_events.h:10, from ../include/trace/syscall.h:7, from ../include/linux/syscalls.h:82, from ../init/main.c:20: ../include/uapi/linux/bpf_perf_event.h:11:32: fatal error: asm/bpf_perf_event.h: No such file or directory #include <asm/bpf_perf_event.h> [...] Lets add missing bpf_perf_event.h also to um arch. This seems to be the only one still missing. Fixes: c895f6f703ad ("bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT program type") Reported-by: Randy Dunlap <[email protected]> Suggested-by: Richard Weinberger <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Tested-by: Randy Dunlap <[email protected]> Cc: Hendrik Brueckner <[email protected]> Cc: Richard Weinberger <[email protected]> Acked-by: Alexei Starovoitov <[email protected]> Acked-by: Richard Weinberger <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]>
2017-12-12bpf: fix corruption on concurrent perf_event_output callsDaniel Borkmann1-7/+12
When tracing and networking programs are both attached in the system and both use event-output helpers that eventually call into perf_event_output(), then we could end up in a situation where the tracing attached program runs in user context while a cls_bpf program is triggered on that same CPU out of softirq context. Since both rely on the same per-cpu perf_sample_data, we could potentially corrupt it. This can only ever happen in a combination of the two types; all tracing programs use a bpf_prog_active counter to bail out in case a program is already running on that CPU out of a different context. XDP and cls_bpf programs by themselves don't have this issue as they run in the same context only. Therefore, split both perf_sample_data so they cannot be accessed from each other. Fixes: 20b9d7ac4852 ("bpf: avoid excessive stack usage for perf_sample_data") Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Tested-by: Song Liu <[email protected]> Acked-by: Alexei Starovoitov <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]>
2017-12-12PCI: rcar: Fix use-after-free in probe error pathGeert Uytterhoeven1-4/+4
If CONFIG_DEBUG_SLAB=y, and no PCIe card is inserted, the kernel crashes during probe on r8a7791/koelsch: rcar-pcie fe000000.pcie: PCIe link down Unable to handle kernel paging request at virtual address 6b6b6b6b (seeing this message requires earlycon and keep_bootcon). Indeed, pci_free_host_bridge() frees the PCI host bridge, including the embedded rcar_pcie object, so pci_free_resource_list() must not be called afterwards. To fix this, move the call to pci_free_resource_list() up, and update the label name accordingly. Fixes: ddd535f1ea3eb27e ("PCI: rcar: Fix memory leak when no PCIe card is inserted") Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Simon Horman <[email protected]> Acked-by: Lorenzo Pieralisi <[email protected]>
2017-12-12tcp md5sig: Use skb's saddr when replying to an incoming segmentChristoph Paasch2-2/+2
The MD5-key that belongs to a connection is identified by the peer's IP-address. When we are in tcp_v4(6)_reqsk_send_ack(), we are replying to an incoming segment from tcp_check_req() that failed the seq-number checks. Thus, to find the correct key, we need to use the skb's saddr and not the daddr. This bug seems to have been there since quite a while, but probably got unnoticed because the consequences are not catastrophic. We will call tcp_v4_reqsk_send_ack only to send a challenge-ACK back to the peer, thus the connection doesn't really fail. Fixes: 9501f9722922 ("tcp md5sig: Let the caller pass appropriate key for tcp_v{4,6}_do_calc_md5_hash().") Signed-off-by: Christoph Paasch <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-12xen: XEN_ACPI_PROCESSOR is Dom0-onlyJan Beulich1-1/+1
Add a respective dependency. Signed-off-by: Jan Beulich <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Boris Ostrovsky <[email protected]>
2017-12-12x86/Xen: don't report ancient LAPIC versionJan Beulich1-1/+1
Unconditionally reporting a value seen on the P4 or older invokes functionality like io_apic_get_unique_id() on 32-bit builds, resulting in a panic() with sufficiently many CPUs and/or IO-APICs. Doing what that function does would be the hypervisor's responsibility anyway, so makes no sense to be used when running on Xen. Uniformly report a more modern version; this shouldn't matter much as both LAPIC and IO-APIC are being managed entirely / mostly by the hypervisor. Signed-off-by: Jan Beulich <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Boris Ostrovsky <[email protected]>
2017-12-12checkpatch: Remove ACCESS_ONCE() warningMark Rutland1-22/+0
Now that ACCESS_ONCE() has been excised from the kernel, any uses will result in a build error, and we no longer need to whine about it in checkpatch. This patch removes the newly redundant warning. Tested-by: Paul E. McKenney <[email protected]> Signed-off-by: Mark Rutland <[email protected]> Acked-by: Joe Perches <[email protected]> Cc: Andy Whitcroft <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-12-12compiler.h: Remove ACCESS_ONCE()Mark Rutland1-36/+11
There are no longer any kernelspace uses of ACCESS_ONCE(), so we can remove the definition from <linux/compiler.h>. This patch removes the ACCESS_ONCE() definition, and updates comments which referred to it. At the same time, some inconsistent and redundant whitespace is removed from comments. Tested-by: Paul E. McKenney <[email protected]> Signed-off-by: Mark Rutland <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Joe Perches <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-12-12tools/include: Remove ACCESS_ONCE()Mark Rutland1-12/+9
There are no longer any usersapce uses of ACCESS_ONCE(), so we can remove the definition from our userspace <linux/compiler.h>, which is only used by tools in the kernel directory (i.e. it isn't a uapi header). This patch removes the ACCESS_ONCE() definition, and updates comments which referred to it. At the same time, some inconsistent and redundant whitespace is removed from comments. Tested-by: Paul E. McKenney <[email protected]> Signed-off-by: Mark Rutland <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Joe Perches <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-12-12tools/perf: Convert ACCESS_ONCE() to READ_ONCE()Mark Rutland1-1/+1
Recently there was a treewide conversion of ACCESS_ONCE() to {READ,WRITE}_ONCE(), but a new use was introduced concurrently by commit: 1695849735752d2a ("perf mmap: Move perf_mmap and methods to separate mmap.[ch] files") Let's convert this over to READ_ONCE() so that we can remove the ACCESS_ONCE() definitions in subsequent patches. Tested-by: Paul E. McKenney <[email protected]> Signed-off-by: Mark Rutland <[email protected]> Reviewed-by: Paul E. McKenney <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Joe Perches <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-12-12USB: core: only clean up what we allocatedAndrey Konovalov1-3/+6
When cleaning up the configurations, make sure we only free the number of configurations and interfaces that we could have allocated. Reported-by: Andrey Konovalov <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-12arm64: hw_breakpoint: Use linux/uaccess.h instead of asm/uaccess.hWill Deacon1-1/+1
The only inclusion of asm/uaccess.h should be by linux/uaccess.h. All other headers should use the latter. Reported-by: Al Viro <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2017-12-12Merge tag 'fixes-for-v4.15-rc4' of ↵Greg Kroah-Hartman844-5067/+7687
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus Felipe writes: usb: fixes for v4.15-rc4 We have a few fixes on dwc3: - one fix which only happens with some implementations where we need to wait longer for some commands to finish. - Another fix for high-bandwidth isochronous endpoint programming making sure that we send the correct DATA tokens in the correct sequence - A couple PM fixes on dwc3-of-simple The other synopsys controller driver (dwc2) got a fix for FIFO size programming. Other than these, we have a couple Kconfig fixes making sure that dependencies are properly setup.
2017-12-12arm64: Add software workaround for Falkor erratum 1041Shanker Donthineni8-1/+28
The ARM architecture defines the memory locations that are permitted to be accessed as the result of a speculative instruction fetch from an exception level for which all stages of translation are disabled. Specifically, the core is permitted to speculatively fetch from the 4KB region containing the current program counter 4K and next 4K. When translation is changed from enabled to disabled for the running exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the Falkor core may errantly speculatively access memory locations outside of the 4KB region permitted by the architecture. The errant memory access may lead to one of the following unexpected behaviors. 1) A System Error Interrupt (SEI) being raised by the Falkor core due to the errant memory access attempting to access a region of memory that is protected by a slave-side memory protection unit. 2) Unpredictable device behavior due to a speculative read from device memory. This behavior may only occur if the instruction cache is disabled prior to or coincident with translation being changed from enabled to disabled. The conditions leading to this erratum will not occur when either of the following occur: 1) A higher exception level disables translation of a lower exception level (e.g. EL2 changing SCTLR_EL1[M] from a value of 1 to 0). 2) An exception level disabling its stage-1 translation if its stage-2 translation is enabled (e.g. EL1 changing SCTLR_EL1[M] from a value of 1 to 0 when HCR_EL2[VM] has a value of 1). To avoid the errant behavior, software must execute an ISB immediately prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0. Signed-off-by: Shanker Donthineni <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2017-12-12arm64: Define cputype macros for Falkor CPUShanker Donthineni1-0/+2
Add cputype definition macros for Qualcomm Datacenter Technologies Falkor CPU in cputype.h. It's unfortunate that the first revision of the Falkor CPU used the wrong part number 0x800, got fixed in v2 chip with part number 0xC00, and would be used the same value for future revisions. Signed-off-by: Shanker Donthineni <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2017-12-12arm64: mm: Fix false positives in set_pte_at access/dirty race detectionWill Deacon1-4/+4
Jiankang reports that our race detection in set_pte_at is firing when copying the page tables in dup_mmap as a result of a fork(). In this situation, the page table isn't actually live and so there is no way that we can race with a concurrent update from the hardware page table walker. This patch reworks the race detection so that we require either the mm to match the current active_mm (i.e. currently installed in our TTBR0) or the mm_users count to be greater than 1, implying that the page table could be live in another CPU. The mm_users check might still be racy, but we'll avoid false positives and it's not realistic to validate that all the necessary locks are held as part of this assertion. Cc: Yisheng Xie <[email protected]> Reported-by: Jiankang Chen <[email protected]> Tested-by: Jiankang Chen <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2017-12-12locking/lockdep: Remove the cross-release locking checksIngo Molnar6-1705/+35
This code (CONFIG_LOCKDEP_CROSSRELEASE=y and CONFIG_LOCKDEP_COMPLETIONS=y), while it found a number of old bugs initially, was also causing too many false positives that caused people to disable lockdep - which is arguably a worse overall outcome. If we disable cross-release by default but keep the code upstream then in practice the most likely outcome is that we'll allow the situation to degrade gradually, by allowing entropy to introduce more and more false positives, until it overwhelms maintenance capacity. Another bad side effect was that people were trying to work around the false positives by uglifying/complicating unrelated code. There's a marked difference between annotating locking operations and uglifying good code just due to bad lock debugging code ... This gradual decrease in quality happened to a number of debugging facilities in the kernel, and lockdep is pretty complex already, so we cannot risk this outcome. Either cross-release checking can be done right with no false positives, or it should not be included in the upstream kernel. ( Note that it might make sense to maintain it out of tree and go through the false positives every now and then and see whether new bugs were introduced. ) Cc: Byungchul Park <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-12-12Revert "usb: gadget: allow to enable legacy drivers without USB_ETH"Felipe Balbi2-12/+2
This reverts commit 7a9618a22aadffb55027d665491adf466bced61a. Romain Izard recently reported that commit 7a9618a22aad ended up allowing every legacy gadget driver to statically linked to the kernel, however that doesn't work, since only one legacy gadget can be bound to a controller. Because of that, let's revert the original commit and fix the problem. Reported-by: Romain Izard <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.