linux-toradex.git/include, branch v4.4.16

drm/ttm: Make ttm_bo_mem_compat available

2016-07-27T16:47:35+00:00

commit 94477bff390aa4612d2332c8abafaae0a13d6923 upstream.

There are cases where it is desired to see if a proposed placement
is compatible with a buffer object before calling ttm_bo_validate().

Signed-off-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Greg Kroah-Hartman

vfs: add d_real_inode() helper

2016-07-27T16:47:33+00:00

commit a118084432d642eeccb961c7c8cc61525a941fcb upstream.

Needed by the following fix.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

net_sched: fix mirrored packets checksum

2016-07-27T16:47:31+00:00

[ Upstream commit 82a31b9231f02d9c1b7b290a46999d517b0d312a ]

Similar to commit 9b368814b336 ("net: fix bridge multicast packet checksum validation")
we need to fixup the checksum for CHECKSUM_COMPLETE when
pushing skb on RX path. Otherwise we get similar splats.

Cc: Jamal Hadi Salim 
Cc: Tom Herbert 
Signed-off-by: Cong Wang 
Acked-by: Jamal Hadi Salim 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

packet: Use symmetric hash for PACKET_FANOUT_HASH.

2016-07-27T16:47:31+00:00

[ Upstream commit eb70db8756717b90c01ccc765fdefc4dd969fc74 ]

People who use PACKET_FANOUT_HASH want a symmetric hash, meaning that
they want packets going in both directions on a flow to hash to the
same bucket.

The core kernel SKB hash became non-symmetric when the ipv6 flow label
and other entities were incorporated into the standard flow hash order
to increase entropy.

But there are no users of PACKET_FANOUT_HASH who want an assymetric
hash, they all want a symmetric one.

Therefore, use the flow dissector to compute a flat symmetric hash
over only the protocol, addresses and ports.  This hash does not get
installed into and override the normal skb hash, so this change has
no effect whatsoever on the rest of the stack.

Reported-by: Eric Leblond 
Tested-by: Eric Leblond 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

nfsd4/rpc: move backchannel create logic into rpc code

2016-07-27T16:47:30+00:00

commit d50039ea5ee63c589b0434baa5ecf6e5075bb6f9 upstream.

Also simplify the logic a bit.

Signed-off-by: J. Bruce Fields 
Acked-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

locking/static_key: Fix concurrent static_key_slow_inc()

2016-07-27T16:47:29+00:00

commit 4c5ea0a9cd02d6aa8adc86e100b2a4cff8d614ff upstream.

The following scenario is possible:

    CPU 1                                   CPU 2
    static_key_slow_inc()
     atomic_inc_not_zero()
      -> key.enabled == 0, no increment
     jump_label_lock()
     atomic_inc_return()
      -> key.enabled == 1 now
                                            static_key_slow_inc()
                                             atomic_inc_not_zero()
                                              -> key.enabled == 1, inc to 2
                                             return
                                            ** static key is wrong!
     jump_label_update()
     jump_label_unlock()

Testing the static key at the point marked by (**) will follow the
wrong path for jumps that have not been patched yet.  This can
actually happen when creating many KVM virtual machines with userspace
LAPIC emulation; just run several copies of the following program:

    #include 
    #include 
    #include 
    #include 

    int main(void)
    {
        for (;;) {
            int kvmfd = open("/dev/kvm", O_RDONLY);
            int vmfd = ioctl(kvmfd, KVM_CREATE_VM, 0);
            close(ioctl(vmfd, KVM_CREATE_VCPU, 1));
            close(vmfd);
            close(kvmfd);
        }
        return 0;
    }

Every KVM_CREATE_VCPU ioctl will attempt a static_key_slow_inc() call.
The static key's purpose is to skip NULL pointer checks and indeed one
of the processes eventually dereferences NULL.

As explained in the commit that introduced the bug:

  706249c222f6 ("locking/static_keys: Rework update logic")

jump_label_update() needs key.enabled to be true.  The solution adopted
here is to temporarily make key.enabled == -1, and use go down the
slow path when key.enabled <= 0.

Reported-by: Dmitry Vyukov 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: 706249c222f6 ("locking/static_keys: Rework update logic")
Link: http://lkml.kernel.org/r/1466527937-69798-1-git-send-email-pbonzini@redhat.com
[ Small stylistic edits to the changelog and the code. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

locking/qspinlock: Fix spin_unlock_wait() some more

2016-07-27T16:47:29+00:00

commit 2c610022711675ee908b903d242f0b90e1db661f upstream.

While this prior commit:

  54cf809b9512 ("locking,qspinlock: Fix spin_is_locked() and spin_unlock_wait()")

... fixes spin_is_locked() and spin_unlock_wait() for the usage
in ipc/sem and netfilter, it does not in fact work right for the
usage in task_work and futex.

So while the 2 locks crossed problem:

	spin_lock(A)		spin_lock(B)
	if (!spin_is_locked(B)) spin_unlock_wait(A)
	  foo()			foo();

... works with the smp_mb() injected by both spin_is_locked() and
spin_unlock_wait(), this is not sufficient for:

	flag = 1;
	smp_mb();		spin_lock()
	spin_unlock_wait()	if (!flag)
				  // add to lockless list
	// iterate lockless list

... because in this scenario, the store from spin_lock() can be delayed
past the load of flag, uncrossing the variables and loosing the
guarantee.

This patch reworks spin_is_locked() and spin_unlock_wait() to work in
both cases by exploiting the observation that while the lock byte
store can be delayed, the contender must have registered itself
visibly in other state contained in the word.

It also allows for architectures to override both functions, as PPC
and ARM64 have an additional issue for which we currently have no
generic solution.

Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andrew Morton 
Cc: Boqun Feng 
Cc: Davidlohr Bueso 
Cc: Giovanni Gherdovich 
Cc: Linus Torvalds 
Cc: Pan Xinhui 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Waiman Long 
Cc: Will Deacon 
Fixes: 54cf809b9512 ("locking,qspinlock: Fix spin_is_locked() and spin_unlock_wait()")
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

USB: EHCI: declare hostpc register as zero-length array

2016-07-27T16:47:28+00:00

commit 7e8b3dfef16375dbfeb1f36a83eb9f27117c51fd upstream.

The HOSTPC extension registers found in some EHCI implementations form
a variable-length array, with one element for each port.  Therefore
the hostpc field in struct ehci_regs should be declared as a
zero-length array, not a single-element array.

This fixes a problem reported by UBSAN.

Signed-off-by: Alan Stern 
Reported-by: Wilfried Klaebe 
Tested-by: Wilfried Klaebe 
Signed-off-by: Greg Kroah-Hartman

bpf: try harder on clones when writing into skb

2016-07-11T16:31:12+00:00

[ Upstream commit 3697649ff29e0f647565eed04b27a7779c646a22 ]

When we're dealing with clones and the area is not writeable, try
harder and get a copy via pskb_expand_head(). Replace also other
occurences in tc actions with the new skb_try_make_writable().

Reported-by: Ashhad Sheikh 
Signed-off-by: Daniel Borkmann 
Acked-by: Alexei Starovoitov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bpf, perf: delay release of BPF prog after grace period

2016-07-11T16:31:11+00:00

[ Upstream commit ceb56070359b7329b5678b5d95a376fcb24767be ]

Commit dead9f29ddcc ("perf: Fix race in BPF program unregister") moved
destruction of BPF program from free_event_rcu() callback to __free_event(),
which is problematic if used with tail calls: if prog A is attached as
trace event directly, but at the same time present in a tail call map used
by another trace event program elsewhere, then we need to delay destruction
via RCU grace period since it can still be in use by the program doing the
tail call (the prog first needs to be dropped from the tail call map, then
trace event with prog A attached destroyed, so we get immediate destruction).

Fixes: dead9f29ddcc ("perf: Fix race in BPF program unregister")
Signed-off-by: Daniel Borkmann 
Acked-by: Alexei Starovoitov 
Cc: Jann Horn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman