linux-stable.git/include/linux, branch v4.4.161

ebtables: arpreply: Add the standard target sanity check

2018-10-13T07:11:35+00:00

commit c953d63548207a085abcb12a15fefc8a11ffdf0a upstream.

The info->target comes from userspace and it would be used directly.
So we need to add the sanity check to make sure it is a valid standard
target, although the ebtables tool has already checked it. Kernel needs
to validate anything coming from userspace.

If the target is set as an evil value, it would break the ebtables
and cause a panic. Because the non-standard target is treated as one
offset.

Now add one helper function ebt_invalid_target, and we would replace
the macro INVALID_TARGET later.

Signed-off-by: Gao Feng 
Signed-off-by: Pablo Neira Ayuso 
Cc: Loic 
Signed-off-by: Greg Kroah-Hartman

tcp: use an RB tree for ooo receive queue

2018-10-13T07:11:34+00:00

[ Upstream commit 9f5afeae51526b3ad7b7cb21ee8b145ce6ea7a7a ]

Over the years, TCP BDP has increased by several orders of magnitude,
and some people are considering to reach the 2 Gbytes limit.

Even with current window scale limit of 14, ~1 Gbytes maps to ~740,000
MSS.

In presence of packet losses (or reorders), TCP stores incoming packets
into an out of order queue, and number of skbs sitting there waiting for
the missing packets to be received can be in the 10^5 range.

Most packets are appended to the tail of this queue, and when
packets can finally be transferred to receive queue, we scan the queue
from its head.

However, in presence of heavy losses, we might have to find an arbitrary
point in this queue, involving a linear scan for every incoming packet,
throwing away cpu caches.

This patch converts it to a RB tree, to get bounded latencies.

Yaogong wrote a preliminary patch about 2 years ago.
Eric did the rebase, added ofo_last_skb cache, polishing and tests.

Tested with network dropping between 1 and 10 % packets, with good
success (about 30 % increase of throughput in stress tests)

Next step would be to also use an RB tree for the write queue at sender
side ;)

Signed-off-by: Yaogong Wang 
Signed-off-by: Eric Dumazet 
Cc: Yuchung Cheng 
Cc: Neal Cardwell 
Cc: Ilpo Järvinen 
Acked-By: Ilpo Järvinen 
Signed-off-by: David S. Miller 
Signed-off-by: Mao Wenan 
Signed-off-by: Greg Kroah-Hartman

hwmon: (ina2xx) fix sysfs shunt resistor read access

2018-10-10T06:52:09+00:00

[ Upstream commit 3ad867001c91657c46dcf6656d52eb6080286fd5 ]

fix the sysfs shunt resistor read access: return the shunt resistor
value, not the calibration register contents.

update email address

Signed-off-by: Lothar Felten 
Signed-off-by: Guenter Roeck 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

slub: make ->cpu_partial unsigned int

2018-10-10T06:52:08+00:00

commit e5d9998f3e09359b372a037a6ac55ba235d95d57 upstream.

	/*
	 * cpu_partial determined the maximum number of objects
	 * kept in the per cpu partial lists of a processor.
	 */

Can't be negative.

Link: http://lkml.kernel.org/r/20180305200730.15812-15-adobriyan@gmail.com
Signed-off-by: Alexey Dobriyan 
Acked-by: Christoph Lameter 
Cc: Pekka Enberg 
Cc: David Rientjes 
Cc: Joonsoo Kim 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: zhong jiang 
Signed-off-by: Greg Kroah-Hartman

mm: get rid of vmacache_flush_all() entirely

2018-09-19T20:49:00+00:00

commit 7a9cdebdcc17e426fb5287e4a82db1dfe86339b2 upstream.

Jann Horn points out that the vmacache_flush_all() function is not only
potentially expensive, it's buggy too.  It also happens to be entirely
unnecessary, because the sequence number overflow case can be avoided by
simply making the sequence number be 64-bit.  That doesn't even grow the
data structures in question, because the other adjacent fields are
already 64-bit.

So simplify the whole thing by just making the sequence number overflow
case go away entirely, which gets rid of all the complications and makes
the code faster too.  Win-win.

[ Oleg Nesterov points out that the VMACACHE_FULL_FLUSHES statistics
  also just goes away entirely with this ]

Reported-by: Jann Horn 
Suggested-by: Will Deacon 
Acked-by: Davidlohr Bueso 
Cc: Oleg Nesterov 
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

x86/io: add interface to reserve io memtype for a resource range. (v1.1)

2018-09-09T18:04:36+00:00

commit 8ef4227615e158faa4ee85a1d6466782f7e22f2f upstream.

A recent change to the mm code in:
87744ab3832b mm: fix cache mode tracking in vm_insert_mixed()

started enforcing checking the memory type against the registered list for
amixed pfn insertion mappings. It happens that the drm drivers for a number
of gpus relied on this being broken. Currently the driver only inserted
VRAM mappings into the tracking table when they came from the kernel,
and userspace mappings never landed in the table. This led to a regression
where all the mapping end up as UC instead of WC now.

I've considered a number of solutions but since this needs to be fixed
in fixes and not next, and some of the solutions were going to introduce
overhead that hadn't been there before I didn't consider them viable at
this stage. These mainly concerned hooking into the TTM io reserve APIs,
but these API have a bunch of fast paths I didn't want to unwind to add
this to.

The solution I've decided on is to add a new API like the arch_phys_wc
APIs (these would have worked but wc_del didn't take a range), and
use them from the drivers to add a WC compatible mapping to the table
for all VRAM on those GPUs. This means we can then create userspace
mapping that won't get degraded to UC.

v1.1: use CONFIG_X86_PAT + add some comments in io.h

Cc: Toshi Kani 
Cc: Borislav Petkov 
Cc: H. Peter Anvin 
Cc: Andy Lutomirski 
Cc: Denys Vlasenko 
Cc: Brian Gerst 
Cc: x86@kernel.org
Cc: mcgrof@suse.com
Cc: Dan Williams 
Acked-by: Ingo Molnar 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Dave Airlie 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

iommu/vt-d: Fix dev iotlb pfsid use

2018-09-09T18:04:35+00:00

commit 1c48db44924298ad0cb5a6386b88017539be8822 upstream.

PFSID should be used in the invalidation descriptor for flushing
device IOTLBs on SRIOV VFs.

Signed-off-by: Jacob Pan 
Cc: stable@vger.kernel.org
Cc: "Ashok Raj" 
Cc: "Lu Baolu" 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

iommu/vt-d: Add definitions for PFSID

2018-09-09T18:04:35+00:00

commit 0f725561e168485eff7277d683405c05b192f537 upstream.

When SRIOV VF device IOTLB is invalidated, we need to provide
the PF source ID such that IOMMU hardware can gauge the depth
of invalidation queue which is shared among VFs. This is needed
when device invalidation throttle (DIT) capability is supported.

This patch adds bit definitions for checking and tracking PFSID.

Signed-off-by: Jacob Pan 
Cc: stable@vger.kernel.org
Cc: "Ashok Raj" 
Cc: "Lu Baolu" 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

scsi: sysfs: Introduce sysfs_{un,}break_active_protection()

2018-09-05T07:18:40+00:00

commit 2afc9166f79b8f6da5f347f48515215ceee4ae37 upstream.

Introduce these two functions and export them such that the next patch
can add calls to these functions from the SCSI core.

Signed-off-by: Bart Van Assche 
Acked-by: Tejun Heo 
Acked-by: Greg Kroah-Hartman 
Cc: 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

net/ethernet/freescale/fman: fix cross-build error

2018-08-24T11:27:00+00:00

[ Upstream commit c133459765fae249ba482f62e12f987aec4376f0 ]

  CC [M]  drivers/net/ethernet/freescale/fman/fman.o
In file included from ../drivers/net/ethernet/freescale/fman/fman.c:35:
../include/linux/fsl/guts.h: In function 'guts_set_dmacr':
../include/linux/fsl/guts.h:165:2: error: implicit declaration of function 'clrsetbits_be32' [-Werror=implicit-function-declaration]
  clrsetbits_be32(&guts->dmacr, 3 << shift, device << shift);
  ^~~~~~~~~~~~~~~

Signed-off-by: Randy Dunlap 
Cc: Madalin Bucur 
Cc: netdev@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman