user/sven/linux.git/Documentation, branch v5.1.15

tcp: add tcp_min_snd_mss sysctl

2019-06-17T17:50:37Z

commit 5f3e2bf008c2221478101ee72f5cb4654b9fc363 upstream. Some TCP peers announce a very small MSS option in their SYN and/or SYN/ACK messages. This forces the stack to send packets with a very high network/cpu overhead. Linux has enforced a minimal value of 48. Since this value includes the size of TCP options, and that the options can consume up to 40 bytes, this means that each segment can include only 8 bytes of payload. In some cases, it can be useful to increase the minimal value to a saner value. We still let the default to 48 (TCP_MIN_SND_MSS), for compatibility reasons. Note that TCP_MAXSEG socket option enforces a minimal value of (TCP_MIN_MSS). David Miller increased this minimal value in commit c39508d6f118 ("tcp: Make TCP_MAXSEG minimum more correct.") from 64 to 88. We might in the future merge TCP_MIN_SND_MSS and TCP_MIN_MSS. CVE-2019-11479 -- tcp mss hardcoded to 48 Signed-off-by: Eric Dumazet Suggested-by: Jonathan Looney Acked-by: Neal Cardwell Cc: Yuchung Cheng Cc: Tyler Hicks Cc: Bruce Curtis Cc: Jonathan Lemon Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Input: goodix - add GT5663 CTP support

2019-06-15T09:53:03Z

[ Upstream commit a5f50c501321249d67611353dde6d68d48c5b959 ] GT5663 is capacitive touch controller with customized smart wakeup gestures. Add support for it by adding compatible and supported chip data. The chip data on GT5663 is similar to GT1151, like - config data register has 0x8050 address - config data register max len is 240 - config data checksum has 16-bit Signed-off-by: Jagan Teki Reviewed-by: Rob Herring Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

doc: Cope with Sphinx logging deprecations

2019-06-09T07:16:14Z

commit 096ea522e84ea68f8e6c41e5e7294731a81e29bc upstream. Recent versions of sphinx will emit messages like: Documentation/sphinx/kerneldoc.py:103: RemovedInSphinx20Warning: app.warning() is now deprecated. Use sphinx.util.logging instead. Switch to sphinx.util.logging to make this unsightly message go away. Alas, that interface was only added in version 1.6, so we have to add a version check to keep things working with older sphinxes. Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman

doc: Cope with the deprecation of AutoReporter

2019-06-09T07:16:14Z

commit 2404dad1f67f8917e30fc22a85e0dbcc85b99955 upstream. AutoReporter is going away; recent versions of sphinx emit a warning like: Documentation/sphinx/kerneldoc.py:125: RemovedInSphinx20Warning: AutodocReporter is now deprecated. Use sphinx.util.docutils.switch_source_input() instead. Make the switch. But switch_source_input() only showed up in 1.7, so we have to do ugly version checks to keep things working in older versions. Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman

docs: Fix conf.py for Sphinx 2.0

2019-06-09T07:16:14Z

commit 3bc8088464712fdcb078eefb68837ccfcc413c88 upstream. Our version check in Documentation/conf.py never envisioned a world where Sphinx moved beyond 1.x. Now that the unthinkable has happened, fix our version check to handle higher version numbers correctly. Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman

mm, memcg: consider subtrees in memory.events

2019-06-09T07:16:13Z

commit 9852ae3fe5293264f01c49f2571ef7688f7823ce upstream. memory.stat and other files already consider subtrees in their output, and we should too in order to not present an inconsistent interface. The current situation is fairly confusing, because people interacting with cgroups expect hierarchical behaviour in the vein of memory.stat, cgroup.events, and other files. For example, this causes confusion when debugging reclaim events under low, as currently these always read "0" at non-leaf memcg nodes, which frequently causes people to misdiagnose breach behaviour. The same confusion applies to other counters in this file when debugging issues. Aggregation is done at write time instead of at read-time since these counters aren't hot (unlike memory.stat which is per-page, so it does it at read time), and it makes sense to bundle this with the file notifications. After this patch, events are propagated up the hierarchy: [root@ktst ~]# cat /sys/fs/cgroup/system.slice/memory.events low 0 high 0 max 0 oom 0 oom_kill 0 [root@ktst ~]# systemd-run -p MemoryMax=1 true Running as unit: run-r251162a189fb4562b9dabfdc9b0422f5.service [root@ktst ~]# cat /sys/fs/cgroup/system.slice/memory.events low 0 high 0 max 7 oom 1 oom_kill 1 As this is a change in behaviour, this can be reverted to the old behaviour by mounting with the `memory_localevents' flag set. However, we use the new behaviour by default as there's a lack of evidence that there are any current users of memory.events that would find this change undesirable. akpm: this is a behaviour change, so Cc:stable. THis is so that forthcoming distros which use cgroup v2 are more likely to pick up the revised behaviour. Link: http://lkml.kernel.org/r/20190208224419.GA24772@chrisdown.name Signed-off-by: Chris Down Acked-by: Johannes Weiner Reviewed-by: Shakeel Butt Cc: Michal Hocko Cc: Tejun Heo Cc: Roman Gushchin Cc: Dennis Zhou Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

dt-bindings: phy-qcom-qmp: Add UFS PHY reset

2019-05-31T13:43:31Z

[ Upstream commit 95cee0b4e30a09a411a17e9a3bc6b72ed92063da ] Add a required reset to the SDM845 UFS phy to express the PHY reset bit inside the UFS controller register space. Before this change, this reset was not expressed in the DT, and the driver utilized two different callbacks (phy_init and phy_poweron) to implement a two-phase initialization procedure that involved deasserting this reset between init and poweron. This abused the two callbacks and diluted their purpose. That scheme does not work as regulators cannot be turned off in phy_poweroff because they were turned on in init, rather than poweron. The net result is that regulators are left on in suspend that shouldn't be. This new scheme gives the UFS reset to the PHY, so that it can fully initialize itself in a single callback. We can then turn regulators on during poweron and off during poweroff. Signed-off-by: Evan Green Reviewed-by: Rob Herring Reviewed-by: Stephen Boyd Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin

arm64: errata: Add workaround for Cortex-A76 erratum #1463225

2019-05-31T13:43:11Z

commit 969f5ea627570e91c9d54403287ee3ed657f58fe upstream. Revisions of the Cortex-A76 CPU prior to r4p0 are affected by an erratum that can prevent interrupts from being taken when single-stepping. This patch implements a software workaround to prevent userspace from effectively being able to disable interrupts. Cc: Cc: Marc Zyngier Cc: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman

dcache: sort the freeing-without-RCU-delay mess for good.

2019-05-25T16:16:24Z

commit 5467a68cbf6884c9a9d91e2a89140afb1839c835 upstream. For lockless accesses to dentries we don't have pinned we rely (among other things) upon having an RCU delay between dropping the last reference and actually freeing the memory. On the other hand, for things like pipes and sockets we neither do that kind of lockless access, nor want to deal with the overhead of an RCU delay every time a socket gets closed. So delay was made optional - setting DCACHE_RCUACCESS in ->d_flags made sure it would happen. We tried to avoid setting it unless we knew we need it. Unfortunately, that had led to recurring class of bugs, in which we missed the need to set it. We only really need it for dentries that are created by d_alloc_pseudo(), so let's not bother with trying to be smart - just make having an RCU delay the default. The ones that do *not* get it set the replacement flag (DCACHE_NORCU) and we'd better use that sparingly. d_alloc_pseudo() is the only such user right now. FWIW, the race that finally prompted that switch had been between __lock_parent() of immediate subdirectory of what's currently the root of a disconnected tree (e.g. from open-by-handle in progress) racing with d_splice_alias() elsewhere picking another alias for the same inode, either on outright corrupted fs image, or (in case of open-by-handle on NFS) that subdirectory having been just moved on server. It's not easy to hit, so the sky is not falling, but that's not the first race on similar missed cases and the logics for settinf DCACHE_RCUACCESS has gotten ridiculously convoluted. Cc: stable@vger.kernel.org Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman

dt-bindings: mmc: Add disable-cqe-dcmd property.

2019-05-22T05:39:46Z

commit 28f22fb755ecf9f933f045bc0afdb8140641b01c upstream. Add disable-cqe-dcmd as optional property for MMC hosts. This property allows to disable or not enable the direct command features of the command queue engine. Signed-off-by: Christoph Muellner Signed-off-by: Philipp Tomsich Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman