summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-02-27net: ipv4: don't allow setting net.ipv4.route.min_pmtu below 68Sabrina Dubroca
According to RFC 1191 sections 3 and 4, ICMP frag-needed messages indicating an MTU below 68 should be rejected: A host MUST never reduce its estimate of the Path MTU below 68 octets. and (talking about ICMP frag-needed's Next-Hop MTU field): This field will never contain a value less than 68, since every router "must be able to forward a datagram of 68 octets without fragmentation". Furthermore, by letting net.ipv4.route.min_pmtu be set to negative values, we can end up with a very large PMTU when (-1) is cast into u32. Let's also make ip_rt_min_pmtu a u32, since it's only ever compared to unsigned ints. Reported-by: Jianlin Shi <jishi@redhat.com> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27Merge branch 'for-upstream' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Johan Hedberg says: ==================== pull request: bluetooth 2018-02-26 Here are a two Bluetooth driver fixes for the 4.16 kernel. Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27devlink: Compare to size_new in case of resource child validationArkadi Sharshevsky
The current implementation checks the combined size of the children with the 'size' of the parent. The correct behavior is to check the combined size vs the pending change and to compare vs the 'size_new'. Fixes: d9f9b9a4d05f ("devlink: Add support for resource abstraction") Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Tested-by: Yuval Mintz <yuvalm@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27dmaengine: rcar-dmac: fix max_chunk_size for R-Car Gen3Yoshihiro Shimoda
According to R-Car Gen3 Rev.0.80 manual, the DMATCR can be set to 16,777,215 as maximum. So, this patch fixes the max_chunk_size for safety on all of SoCs. Otherwise, a system may hang if the DMATCR is set to 0 on R-Car Gen3. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2018-02-27mmc: core: Avoid hanging to claim host for mmc via some nested callsUlf Hansson
As the block layer, since the conversion to blkmq, claims the host using a context, a following nested call to mmc_claim_host(), which isn't using a context, may hang. Calling mmc_interrupt_hpi() and mmc_read_bkops_status() via the mmc block layer, may suffer from this problem, as these functions are calling mmc_claim|release_host(). Let's fix the problem by removing the calls to mmc_claim|release_host() from the above mentioned functions and instead make the callers responsible of claiming/releasing the host. As a matter of fact, the existing callers already deals with it. Fixes: 81196976ed94 ("mmc: block: Add blk-mq support") Reported-by: Dmitry Osipenko <digetx@gmail.com> Suggested-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
2018-02-27mmc: dw_mmc: Avoid accessing registers in runtime suspended stateShawn Lin
cat /sys/kernel/debug/mmc0/regs will hang up the system since it's in runtime suspended state, so the genpd and biu_clk is off. This patch fixes this problem by calling pm_runtime_get_sync to wake it up before reading the registers. Fixes: e9ed8835e990 ("mmc: dw_mmc: add runtime PM callback") Cc: <stable@vger.kernel.org> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-02-27mmc: dw_mmc: Fix out-of-bounds access for slot's capsShawn Lin
Add num_caps field for dw_mci_drv_data to validate the controller id from DT alias and non-DT ways. Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Fixes: 800d78bfccb3 ("mmc: dw_mmc: add support for implementation specific callbacks") Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-02-27mmc: dw_mmc: Factor out dw_mci_init_slot_capsShawn Lin
Factor out dw_mci_init_slot_caps to consolidate parsing all differents types of capabilities from host contrllers. No functional change intended. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Fixes: 800d78bfccb3 ("mmc: dw_mmc: add support for implementation specific callbacks") Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-02-27mmc: dw_mmc-k3: Fix out-of-bounds access through DT aliasGeert Uytterhoeven
The hs_timing_cfg[] array is indexed using a value derived from the "mshcN" alias in DT, which may lead to an out-of-bounds access. Fix this by adding a range check. Fixes: 361c7fe9b02eee7e ("mmc: dw_mmc-k3: add sd support for hi3660") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-02-27cfg80211: add missing dependency to CFG80211 suboptionsRomain Naour
New options introduced by the patch this fixes are still enabled even if CFG80211 is disabled. .config: # CONFIG_CFG80211 is not set CONFIG_CFG80211_REQUIRE_SIGNED_REGDB=y CONFIG_CFG80211_USE_KERNEL_REGDB_KEYS=y # CONFIG_LIB80211 is not set When CFG80211_REQUIRE_SIGNED_REGDB is enabled, it selects SYSTEM_DATA_VERIFICATION which selects SYSTEM_TRUSTED_KEYRING that need extract-cert tool. extract-cert needs some openssl headers to be installed on the build machine. Instead of adding missing "depends on CFG80211", it's easier to use a 'if' block around all options related to CFG80211, so do that. Fixes: 90a53e4432b1 ("cfg80211: implement regdb signature checking") Signed-off-by: Romain Naour <romain.naour@gmail.com> [touch up commit message a bit] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2018-02-27printk: Wake klogd when passing console_lock ownerPetr Mladek
wake_klogd is a local variable in console_unlock(). The information is lost when the console_lock owner using the busy wait added by the commit dbdda842fe96f8932 ("printk: Add console owner and waiter logic to load balance console writes"). The following race is possible: CPU0 CPU1 console_unlock() for (;;) /* calling console for last message */ printk() log_store() log_next_seq++; /* see new message */ if (seen_seq != log_next_seq) { wake_klogd = true; seen_seq = log_next_seq; } console_lock_spinning_enable(); if (console_trylock_spinning()) /* spinning */ if (console_lock_spinning_disable_and_check()) { printk_safe_exit_irqrestore(flags); return; console_unlock() if (seen_seq != log_next_seq) { /* already seen */ /* nothing to do */ Result: Nobody would wakeup klogd. One solution would be to make a global variable from wake_klogd. But then we would need to manipulate it under a lock or so. This patch wakes klogd also when console_lock is passed to the spinning waiter. It looks like the right way to go. Also userspace should have a chance to see and store any "flood" of messages. Note that the very late klogd wake up was a historic solution. It made sense on single CPU systems or when sys_syslog() operations were synchronized using the big kernel lock like in v2.1.113. But it is questionable these days. Fixes: dbdda842fe96f8932 ("printk: Add console owner and waiter logic to load balance console writes") Link: http://lkml.kernel.org/r/20180226155734.dzwg3aovqnwtvkoy@pathway.suse.cz Cc: Steven Rostedt <rostedt@goodmis.org> Cc: linux-kernel@vger.kernel.org Cc: Tejun Heo <tj@kernel.org> Suggested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Petr Mladek <pmladek@suse.com>
2018-02-27mmc: sdhci-pci: Fix S0i3 for Intel BYT-based controllersAdrian Hunter
Tuning can leave the IP in an active state (Buffer Read Enable bit set) which prevents the entry to low power states (i.e. S0i3). Data reset will clear it. Generally tuning is followed by a data transfer which will anyway sort out the state, so it is rare that S0i3 is actually prevented. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-02-27gpio: Handle deferred probing in of_find_gpio() properlyChen-Yu Tsai
of_get_named_gpiod_flags() used directly in of_find_gpio() or indirectly through of_find_spi_gpio() or of_find_regulator_gpio() can return -EPROBE_DEFER. This gets overwritten by the subsequent of_find_*_gpio() calls. This patch fixes this by trying of_find_spi_gpio() or of_find_regulator_gpio() only if deferred probing was not requested by the previous of_get_named_gpiod_flags() call. Fixes: 6a537d48461d ("gpio: of: Support regulator nonstandard GPIO properties") Fixes: c85823390215 ("gpio: of: Support SPI nonstandard GPIO properties") Signed-off-by: Chen-Yu Tsai <wens@csie.org> [Augmented to fit with Maxime's patch] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-02-27gpiolib: Keep returning EPROBE_DEFER when we shouldMaxime Ripard
Commits c85823390215 ("gpio: of: Support SPI nonstandard GPIO properties") and 6a537d48461d ("gpio: of: Support regulator nonstandard GPIO properties") have introduced a regression in the way error codes from of_get_named_gpiod_flags are handled. Previously, those errors codes were returned immediately, but the two commits mentioned above are now overwriting the error pointer, meaning that whatever value has been returned will be dropped in favor of whatever the two new functions will return. This might not be a big deal except for EPROBE_DEFER, on which GPIOlib customers will depend on, and that will now be returned as an hard error which means that they will not probe anymore, instead of gently deferring their probe. Since EPROBE_DEFER basically means that we have found a valid property but there was no GPIO controller registered to handle it, fix this issues by returning it as soon as we encounter it. Fixes: c85823390215 ("gpio: of: Support SPI nonstandard GPIO properties") Fixes: 6a537d48461d ("gpio: of: Support regulator nonstandard GPIO properties") Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> [Fold in fix to the fix] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-02-27virtio-gpu: fix ioctl and expose the fixed status to userspace.Dave Airlie
This exposes to mesa that it can use the fixed ioctl for querying later cap sets, cap set 1 is forever frozen in time. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180221015003.22884-1-airlied@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-02-27netfilter: nf_tables: missing attribute validation in nf_tables_delflowtable()Pablo Neira Ayuso
Return -EINVAL is mandatory attributes are missing. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2018-02-27netfilter: nf_tables: return EBUSY if device already belongs to flowtablePablo Neira Ayuso
If the netdevice is already part of a flowtable, return EBUSY. I cannot find a valid usecase for having two flowtables bound to the same netdevice. We can still have two flowtable where the device set is disjoint. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2018-02-26bpf, ppc64: fix out of bounds access in tail callDaniel Borkmann
While working on 16338a9b3ac3 ("bpf, arm64: fix out of bounds access in tail call") I noticed that ppc64 JIT is partially affected as well. While the bound checking is correctly performed as unsigned comparison, the register with the index value however, is never truncated into 32 bit space, so e.g. a index value of 0x100000000ULL with a map of 1 element would pass with PPC_CMPLW() whereas we later on continue with the full 64 bit register value. Therefore, as we do in interpreter and other JITs truncate the value to 32 bit initially in order to fix access. Fixes: ce0761419fae ("powerpc/bpf: Implement support for tail calls") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-02-26r8152: fix tx packets accountingEric Dumazet
r8152 driver handles TSO packets (limited to ~16KB) quite well, but pretends each TSO logical packet is a single packet on the wire. There is also some error since headers are accounted once, but error rate is small enough that we do not care. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-26tpm: fix potential buffer overruns caused by bit glitches on the busJeremy Boone
Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. If a bit does flip it could cause an overrun if it's in one of the size parameters, so sanity check that we're not overrunning the provided buffer when doing a memcpy(). Signed-off-by: Jeremy Boone <jeremy.boone@nccgroup.trust> Cc: stable@vger.kernel.org Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: James Morris <james.morris@microsoft.com>
2018-02-26tpm: st33zp24: fix potential buffer overruns caused by bit glitches on the busJeremy Boone
Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. In all the driver _recv() functions, we need to use a u32 to unmarshal the response size, otherwise a bit flip of the 31st bit would cause the expected variable to go negative, which would then try to read a huge amount of data. Also sanity check that the expected amount of data is large enough for the TPM header. Signed-off-by: Jeremy Boone <jeremy.boone@nccgroup.trust> Cc: stable@vger.kernel.org Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: James Morris <james.morris@microsoft.com>
2018-02-26tpm_i2c_infineon: fix potential buffer overruns caused by bit glitches on ↵Jeremy Boone
the bus Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. In all the driver _recv() functions, we need to use a u32 to unmarshal the response size, otherwise a bit flip of the 31st bit would cause the expected variable to go negative, which would then try to read a huge amount of data. Also sanity check that the expected amount of data is large enough for the TPM header. Signed-off-by: Jeremy Boone <jeremy.boone@nccgroup.trust> Cc: stable@vger.kernel.org Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: James Morris <james.morris@microsoft.com>
2018-02-26tpm_i2c_nuvoton: fix potential buffer overruns caused by bit glitches on the busJeremy Boone
Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. In all the driver _recv() functions, we need to use a u32 to unmarshal the response size, otherwise a bit flip of the 31st bit would cause the expected variable to go negative, which would then try to read a huge amount of data. Also sanity check that the expected amount of data is large enough for the TPM header. Signed-off-by: Jeremy Boone <jeremy.boone@nccgroup.trust> Cc: stable@vger.kernel.org Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: James Morris <james.morris@microsoft.com>
2018-02-26tpm_tis: fix potential buffer overruns caused by bit glitches on the busJeremy Boone
Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. In all the driver _recv() functions, we need to use a u32 to unmarshal the response size, otherwise a bit flip of the 31st bit would cause the expected variable to go negative, which would then try to read a huge amount of data. Also sanity check that the expected amount of data is large enough for the TPM header. Signed-off-by: Jeremy Boone <jeremy.boone@nccgroup.trust> Cc: stable@vger.kernel.org Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: James Morris <james.morris@microsoft.com>
2018-02-26selftests: vm: update .gitignore with new testShuah Khan
Update .gitignore with new test. Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
2018-02-26selftests: memory-hotplug: silence test command echoShuah Khan
Silence the following command being printed while running test. ./mem-on-off-test.sh -r 2 && echo "selftests: memory-hotplug [PASS]" || echo "selftests: memory-hotplug [FAIL]" Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
2018-02-26selftests/futex: Fix line continuation in MakefileDaniel Díaz
The Makefile lacks a couple of line continuation backslashes in an `if' clause, which produces an error when make versions prior to 4.x are used for building the tests. $ make make[1]: Entering directory `/[...]/linux/tools/testing/selftests/futex' /bin/sh: -c: line 5: syntax error: unexpected end of file make[1]: *** [all] Error 1 make[1]: Leaving directory `/[...]/linux/tools/testing/selftests/futex' make: *** [all] Error 2 Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
2018-02-26cpufreq: scpi: Fix incorrect arm_big_little config dependencySudeep Holla
Commit 343a8d17fa8d (cpufreq: scpi: remove arm_big_little dependency) removed the SCPI cpufreq dependency on arm_big_little cpufreq driver. However the Kconfig entry still depends on ARM_BIG_LITTLE_CPUFREQ which is clearly wrong. This patch removes that unnecessary Kconfig dependency. Fixes: 343a8d17fa8d (cpufreq: scpi: remove arm_big_little dependency) Reported-by: Quentin Perret <quentin.perret@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-26cpufreq: scpi: invoke frequency-invariance setter functionDietmar Eggemann
Commit 343a8d17fa8d (cpufreq: scpi: remove arm_big_little dependency) changed the cpufreq driver on juno from arm_big_little to scpi. The scpi set_target function does not call the frequency-invariance setter function arch_set_freq_scale() like the arm_big_little set_target function does. As a result the task scheduler load and utilization signals are not frequency-invariant on this platform anymore. Fix this by adding a call to arch_set_freq_scale() into scpi_cpufreq_set_target(). Fixes: 343a8d17fa8d (cpufreq: scpi: remove arm_big_little dependency) Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-26Merge branch 'idr-2018-02-06' of git://git.infradead.org/users/willy/linux-daxLinus Torvalds
Pull idr fixes from Matthew Wilcox: "One test-suite build fix for you and one run-time regression fix. The regression fix includes new tests to make sure they don't pop back up." * 'idr-2018-02-06' of git://git.infradead.org/users/willy/linux-dax: idr: Fix handling of IDs above INT_MAX radix tree test suite: Fix build
2018-02-26PCI: Allow release of resources that were never assignedChristian König
It is entirely possible that the BIOS wasn't able to assign resources to a device. In this case don't crash in pci_release_resource() when we try to resize the resource. Fixes: 8bb705e3e79d ("PCI: Add pci_resize_resource() for resizing BARs") Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> CC: stable@vger.kernel.org # v4.15+
2018-02-26ARM: dts: Set D-Link DNS-313 SATA to muxmode 0Linus Walleij
This stops the driver from trying to probe the ATA slave interface. The vendor code enables the slave interface but the driver in the vendor tree does not make use of it. Setting it to muxmode 0 disables the slave interface: the hardware only has the master interface connected to the one harddrive slot anyways. Without this change booting takes excessive time, so it is very annoying to end users. Fixes: dd5c0561db75 ("ARM: dts: Add basic devicetree for D-Link DNS-313") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-02-26ARM: omap2: set CONFIG_LIRC=y in defconfigArnd Bergmann
The CONFIG_LIRC symbol has changed from 'tristate' to 'bool, so we now get a warning for omap2plus_defconfig: arch/arm/configs/omap2plus_defconfig:322:warning: symbol value 'm' invalid for LIRC This changes the file to mark the symbol as built-in to get rid of the warning. Fixes: a60d64b15c20 ("media: lirc: lirc interface should not be a raw decoder") Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-02-26dax: fix vma_is_fsdax() helperDan Williams
Gerd reports that ->i_mode may contain other bits besides S_IFCHR. Use S_ISCHR() instead. Otherwise, get_user_pages_longterm() may fail on device-dax instances when those are meant to be explicitly allowed. Fixes: 2bb6d2837083 ("mm: introduce get_user_pages_longterm") Cc: <stable@vger.kernel.org> Reported-by: Gerd Rausch <gerd.rausch@oracle.com> Acked-by: Jane Chu <jane.chu@oracle.com> Reported-by: Haozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-02-26dax: ->direct_access does not sleep anymoreBoaz Harrosh
In Patch: [7a862fb] brd: remove dax support Dan Williams has removed the only might_sleep implementation of ->direct_access. So we no longer need to check for it. CC: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Boaz Harrosh <boazh@netapp.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-02-26ip_tunnel: Do not use mark in skb by defaultThomas Winter
This reverts commit 5c38bd1b82e1f76f9fa96c1e61c9897cabf1ce45. skb->mark contains the mark the encapsulated traffic which can result in incorrect routing decisions being made such as routing loops if the route chosen is via tunnel itself. The correct method should be to use tunnel->fwmark. Signed-off-by: Thomas Winter <thomas.winter@alliedtelesis.co.nz> Cc: "David S. Miller" <davem@davemloft.net> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-26bridge: Fix VLAN reference count problemIdo Schimmel
When a VLAN is added on a port, a reference is taken on the corresponding master VLAN entry. If it does not already exist, then it is created and a reference taken. However, in the second case a reference is not really taken when CONFIG_REFCOUNT_FULL is enabled as refcount_inc() is replaced by refcount_inc_not_zero(). Fix this by using refcount_set() on a newly created master VLAN entry. Fixes: 251277598596 ("net, bridge: convert net_bridge_vlan.refcnt from atomic_t to refcount_t") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-26DT: net: renesas,ravb: document R8A77980 bindingsSergei Shtylyov
Renesas R-Car V3H (R8A77980) SoC has the R-Car gen3 compatible EtherAVB device, so document the SoC specific bindings. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-26qrtr: add MODULE_ALIAS macro to smdRamon Fried
Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load when IPCRTR channel is detected. Signed-off-by: Ramon Fried <rfried@codeaurora.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-26test_bpf: add a schedule pointEric Dumazet
test_bpf() is taking 1.6 seconds nowadays, it is time to add a schedule point in it. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-02-26idr: Fix handling of IDs above INT_MAXMatthew Wilcox
Khalid reported that the kernel selftests are currently failing: selftests: test_bpf.sh ======================================== test_bpf: [FAIL] not ok 1..8 selftests: test_bpf.sh [FAIL] He bisected it to 6ce711f2750031d12cec91384ac5cfa0a485b60a ("idr: Make 1-based IDRs more efficient"). The root cause is doing a signed comparison in idr_alloc_u32() instead of an unsigned comparison. I went looking for any similar problems and found a couple (which would each result in the failure to warn in two situations that aren't supposed to happen). I knocked up a few test-cases to prove that I was right and added them to the test-suite. Reported-by: Khalid Aziz <khalid.aziz@oracle.com> Tested-by: Khalid Aziz <khalid.aziz@oracle.com> Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
2018-02-26hdlc_ppp: carrier detect ok, don't turn off negotiationDenis Du
Sometimes when physical lines have a just good noise to make the protocol handshaking fail, but the carrier detect still good. Then after remove of the noise, nobody will trigger this protocol to be start again to cause the link to never come back. The fix is when the carrier is still on, not terminate the protocol handshaking. Signed-off-by: Denis Du <dudenis2000@yahoo.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-26blktrace_api.h: fix comment for struct blk_user_trace_setupEric Biggers
'struct blk_user_trace_setup' is passed to BLKTRACESETUP, not BLKTRACESTART. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2018-02-26tuntap: correctly add the missing XDP flushJason Wang
We don't flush batched XDP packets through xdp_do_flush_map(), this will cause packets stall at TX queue. Consider we don't do XDP on NAPI poll(), the only possible fix is to call xdp_do_flush_map() immediately after xdp_do_redirect(). Note, this in fact won't try to batch packets through devmap, we could address in the future. Reported-by: Christoffer Dall <christoffer.dall@linaro.org> Fixes: 761876c857cb ("tap: XDP support") Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-26tuntap: disable preemption during XDP processingJason Wang
Except for tuntap, all other drivers' XDP was implemented at NAPI poll() routine in a bh. This guarantees all XDP operation were done at the same CPU which is required by e.g BFP_MAP_TYPE_PERCPU_ARRAY. But for tuntap, we do it in process context and we try to protect XDP processing by RCU reader lock. This is insufficient since CONFIG_PREEMPT_RCU can preempt the RCU reader critical section which breaks the assumption that all XDP were processed in the same CPU. Fixing this by simply disabling preemption during XDP processing. Fixes: 761876c857cb ("tap: XDP support") Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-26Revert "tuntap: add missing xdp flush"Jason Wang
This reverts commit 762c330d670e3d4b795cf7a8d761866fdd1eef49. The reason is we try to batch packets for devmap which causes calling xdp_do_flush() in the process context. Simply disabling preemption may not work since process may move among processors which lead xdp_do_flush() to miss some flushes on some processors. So simply revert the patch, a follow-up patch will add the xdp flush correctly. Reported-by: Christoffer Dall <christoffer.dall@linaro.org> Fixes: 762c330d670e ("tuntap: add missing xdp flush") Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-26ixgbe: fix crash in build_skb Rx code pathEmil Tantilov
Add check for build_skb enabled ring in ixgbe_dma_sync_frag(). In that case &skb_shinfo(skb)->frags[0] may not always be set which can lead to a crash. Instead we derive the page offset from skb->data. Fixes: 42073d91a214 ("ixgbe: Have the CPU take ownership of the buffers sooner") CC: stable <stable@vger.kernel.org> Reported-by: Ambarish Soman <asoman@redhat.com> Suggested-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-26ARM: orion5x: Revert commit 4904dbda41c8.David S. Miller
It is not valid for orion5x to use mac_pton(). First of all, the orion5x buffer is not NULL terminated. mac_pton() has no business operating on non-NULL terminated buffers because only the caller can know that this is valid and in what manner it is ok to parse this NULL'less buffer. Second of all, orion5x operates on an __iomem pointer, which cannot be dereferenced using normal C pointer operations. Accesses to such areas much be performed with the proper iomem accessors. Fixes: 4904dbda41c8 ("ARM: orion5x: use mac_pton() helper") Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-26Merge tag 'edac_fixes_for_4.16' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp Pull EDAC fix from Borislav Petkov: "sb_edac: Prevent memory corruption on KNL (from Anna Karbownik)" * tag 'edac_fixes_for_4.16' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp: EDAC, sb_edac: Fix out of bound writes during DIMM configuration on KNL
2018-02-26xfs: fix potential memory leak in mount option parsingChengguang Xu
When specifying string type mount option (e.g., logdev) several times in a mount, current option parsing may cause memory leak. Hence, call kfree for previous one in this case. Signed-off-by: Chengguang Xu <cgxu519@icloud.com> Reviewed-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>