lift generic_write_checks() into callers of __generic_file_write_iter()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

__generic_file_write_iter: keep ->ki_pos and return value consistent

A side effect worth noting: in O_APPEND case we set ->ki_pos early,
so if it turns out to be an error or a zero-length write, we'll
end up with ->ki_pos modified.  Safe, since all callers never
look at the ->ki_pos after the call of __generic_file_write_iter()
returning non-positive, all the way to caller of ->write_iter() and
those discard ->ki_pos when getting that.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

cifs: fold cifs_iovec_write() into the only caller

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

ntfs: move iov_iter_truncate() closer to generic_write_checks()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

new_sync_write(): discard ->ki_pos unless the return value is positive

That allows ->write_iter() instances much more convenient life wrt
iocb->ki_pos (and fixes several filesystems with borderline POSIX
violations when zero-length write succeeds and changes the current
position).

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

direct_IO: remove rw from a_ops->direct_IO()

Now that no one is using rw, remove it completely.

Signed-off-by: Omar Sandoval <osandov@osandov.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

direct_IO: use iov_iter_rw() instead of rw everywhere

The rw parameter to direct_IO is redundant with iov_iter->type, and
treated slightly differently just about everywhere it's used: some users
do rw & WRITE, and others do rw == WRITE where they should be doing a
bitwise check. Simplify this with the new iov_iter_rw() helper, which
always returns either READ or WRITE.

Signed-off-by: Omar Sandoval <osandov@osandov.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Remove rw from dax_{do_,}io()

And use iov_iter_rw() instead.

Signed-off-by: Omar Sandoval <osandov@osandov.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Remove rw from {,__,do_}blockdev_direct_IO()

Most filesystems call through to these at some point, so we'll start
here.

Signed-off-by: Omar Sandoval <osandov@osandov.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

new helper: iov_iter_rw()

Get either READ or WRITE out of iter->type.

Signed-off-by: Omar Sandoval <osandov@osandov.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

->aio_read and ->aio_write removed

no remaining users

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

pcm: another weird API abuse

readv() and writev() should _not_ ignore all but the first ->iov_len,
among other things.  Really weird abuse of those syscalls - it
expects a vector element per channel, with identical lengths (it
actually assumes them to be identical - no checking is done).
readv() and writev() are really bad match for that.  Unfortunately,
userland API is userland API and we can't do anything about them.

Converted to ->read_iter/->write_iter.  Please, _please_ don't do
anything of that kind when designing new interfaces.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

infinibad: weird APIs switched to ->write_iter()

Things Not To Do When Writing A Driver, part 1001st:
have writev() and write() on the same file doing completely
different things.  As in, "interpret very different sets of
commands".

We _can_ handle that, but it's a bloody bad idea.
Don't do that in new drivers.  Ever.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

kill do_sync_read/do_sync_write

all remaining instances of aio_{read,write} (all 4 of them) have explicit
->read and ->write resp.; do_sync_read/do_sync_write is never called by
__vfs_read/__vfs_write anymore and no other users had been left.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

fuse: use iov_iter_get_pages() for non-splice path

store reference to iter instead of that to iovec

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

fuse: switch to ->read_iter/->write_iter

we just change the calling conventions here; more work to follow.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

switch drivers/char/mem.c to ->read_iter/->write_iter

Note that _these_ guys have ->read() and ->write() left in place - they are
eqiuvalent to what we'd get if we replaced those with NULL, but we are
talking about hot paths here.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

make new_sync_{read,write}() static

All places outside of core VFS that checked ->read and ->write for being NULL or
called the methods directly are gone now, so NULL {read,write} with non-NULL
{read,write}_iter will do the right thing in all cases.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

coredump: accept any write method

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

switch /dev/loop to vfs_iter_write()

all writable files that might be used as backing store for /dev/loop
already support ->write_iter()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

serial2002: switch to __vfs_read/__vfs_write

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

ashmem: use __vfs_read()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

export __vfs_read()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

autofs: switch to __vfs_write()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

new helper: __vfs_write()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Merge branch '9p-iov_iter' into for-next

switch hugetlbfs to ->read_iter()

... and fix the case when the area we are asked to read crosses
a hugepage boundary

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

coda: switch to ->read_iter/->write_iter

... and request the same from the local cache - all filesystems with
anything usable for that support those already.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

ncpfs: switch to ->read_iter/->write_iter

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

net/9p: remove (now-)unused helpers

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

p9_client_attach(): set fid->uid correctly

it's almost always equal to current_fsuid(), but there's an exception -
if the first writeback fid is opened by non-root *and* that happens before
root has done any lookups in /, we end up doing attach for root.  The
current code leaves the resulting FID owned by root from the server POV
and by non-root from the client one.  Unfortunately, it means that e.g.
massive dcache eviction will leave that user buggered - they'll end
up redoing walks from / *and* picking that FID every time.  As soon as
they try to create something, the things will get nasty.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

9p: we are leaking glock.client_id in v9fs_file_getlock()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

9p: switch to ->read_iter/->write_iter

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

9p: get rid of v9fs_direct_file_read()

do it in ->direct_IO()...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

9p: switch p9_client_read() to passing struct iov_iter *

... and make it loop

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

9p: get rid of v9fs_direct_file_write()

just handle it in ->direct_IO()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

9p: fold v9fs_file_write_internal() into the caller

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

9p: switch ->writepage() to direct use of p9_client_write()

Don't mess with kmap() - just use ITER_BVEC.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

9p: switch p9_client_write() to passing it struct iov_iter *

... and make it loop until it's done

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

net/9p: switch the guts of p9_client_{read,write}() to iov_iter

... and have get_user_pages_fast() mapping fewer pages than requested
to generate a short read/write.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

nommu: use __vfs_read()

... instead of open-coding the call of ->read()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

acct: check FMODE_CAN_WRITE

it's not calling ->write() directly anymore.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

aio_run_iocb(): kill dead check

We check if ->ki_pos is positive.  However, by that point we have
already done rw_verify_area(), which would have rejected such
unless the file had been one of /dev/mem, /dev/kmem and /proc/kcore.
All of which do not have vectored rw methods, so we would've bailed
out even earlier.

This check had been introduced before rw_verify_area() had been added there
- in fact, it was a subset of checks done on sync paths by rw_verify_area()
(back then the /dev/mem exception didn't exist at all).  The rest of checks
(mandatory locking, etc.) hadn't been added until later.  Unfortunately,
by the time the call of rw_verify_area() got added, the /dev/mem exception
had already appeared, so it wasn't obvious that the older explicit check
downstream had become dead code.  It *is* a dead code, though, since the few
files for which the exception applies do not have ->aio_{read,write}() or
->{read,write}_iter() and for them we won't reach that check anyway.

What's more, even if we ever introduce vectored methods for /dev/mem
and friends, they'll have to cope with negative positions anyway, since
readv(2) and writev(2) are using the same checks as read(2) and write(2) -
i.e. rw_verify_area().

Let's bury it.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

ioctx_alloc(): remove pointless check

Way, way back kiocb used to be picked from arrays, so ioctx_alloc()
checked for multiplication overflow when calculating the size of
such array.  By the time fs/aio.c went into the tree (in 2002) they
were already allocated one-by-one by kmem_cache_alloc(), so that
check had already become pointless.  Let's bury it...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

lustre: kill unused members of struct vvp_thread_info

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

expand __fuse_direct_write() in both callers

it's actually shorter that way *and* later we'll want iocb in scope
of generic_write_check() caller.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

fuse: switch fuse_direct_io_file_operations to ->{read,write}_iter()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

cuse: switch to iov_iter

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Merge branch 'for-davem' into for-next

sg_start_req(): use import_iovec()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

sg_start_req(): make sure that there's not too many elements in iovec

unfortunately, allowing an arbitrary 16bit value means a possibility of
overflow in the calculation of total number of pages in bio_map_user_iov() -
we rely on there being no more than PAGE_SIZE members of sum in the
first loop there.  If that sum wraps around, we end up allocating
too small array of pointers to pages and it's easy to overflow it in
the second loop.

X-Coverup: TINC (and there's no lumber cartel either)
Cc: stable@vger.kernel.org # way, way back
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

blk_rq_map_user(): use import_single_range()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

sg_io(): use import_iovec()

... and don't skip access_ok() validation.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

process_vm_access: switch to {compat_,}import_iovec()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

switch keyctl_instantiate_key_common() to iov_iter

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

switch {compat_,}do_readv_writev() to {compat_,}import_iovec()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

aio_setup_vectored_rw(): switch to {compat_,}import_iovec()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

vmsplice_to_user(): switch to import_iovec()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

kill aio_setup_single_vector()

identical to import_single_range()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Merge branch 'iov_iter' into for-next

aio: simplify arguments of aio_setup_..._rw()

We don't need req in either of those.  We don't need nr_segs in caller.
We don't really need len in caller either - iov_iter_count(&iter) will do.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

aio: lift iov_iter_init() into aio_setup_..._rw()

the only non-trivial detail is that we do it before rw_verify_area(),
so we'd better cap the length ourselves in aio_setup_single_rw()
case (for vectored case rw_copy_check_uvector() will do that for us).

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

lift iov_iter into {compat_,}do_readv_writev()

get it closer to matching {compat_,}rw_copy_check_uvector().

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Merge branch 'iocb' into for-next

NFS: fix BUG() crash in notify_change() with patch to chown_common()

We have observed a BUG() crash in fs/attr.c:notify_change(). The crash
occurs during an rsync into a filesystem that is exported via NFS.

1.) fs/attr.c:notify_change() modifies the caller's version of attr.
2.) 6de0ec00ba8d ("VFS: make notify_change pass ATTR_KILL_S*ID to
    setattr operations") introduced a BUG() restriction such that "no
    function will ever call notify_change() with both ATTR_MODE and
    ATTR_KILL_S*ID set". Under some circumstances though, it will have
    assisted in setting the caller's version of attr to this very
    combination.
3.) 27ac0ffeac80 ("locks: break delegations on any attribute
    modification") introduced code to handle breaking
    delegations. This can result in notify_change() being re-called. attr
    _must_ be explicitly reset to avoid triggering the BUG() established
    in #2.
4.) The path that that triggers this is via fs/open.c:chmod_common().
    The combination of attr flags set here and in the first call to
    notify_change() along with a later failed break_deleg_wait()
    results in notify_change() being called again via retry_deleg
    without resetting attr.

Solution is to move retry_deleg in chmod_common() a bit further up to
ensure attr is completely reset.

There are other places where this seemingly could occur, such as
fs/utimes.c:utimes_common(), but the attr flags are not initially
set in such a way to trigger this.

Fixes: 27ac0ffeac80 ("locks: break delegations on any attribute modification")
Reported-by: Eric Meddaugh <etmsys@rit.edu>
Tested-by: Eric Meddaugh <etmsys@rit.edu>
Signed-off-by: Andrew Elble <aweits@rit.edu>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

dcache: return -ESTALE not -EBUSY on distributed fs race

On a distributed filesystem it's possible for lookup to discover that a
directory it just found is already cached elsewhere in the directory
heirarchy.  The dcache won't let us keep the directory in both places,
so we have to move the dentry to the new location from the place we
previously had it cached.

If the parent has changed, then this requires all the same locks as we'd
need to do a cross-directory rename.  But we're already in lookup
holding one parent's i_mutex, so it's too late to acquire those locks in
the right order.

The (unreliable) solution in __d_unalias is to trylock() the required
locks and return -EBUSY if it fails.

I see no particular reason for returning -EBUSY, and -ESTALE is already
the result of some other lookup races on NFS.  I think -ESTALE is the
more helpful error return.  It also allows us to take advantage of the
logic Jeff Layton added in c6a9428401c0 "vfs: fix renameat to retry on
ESTALE errors" and ancestors, which hopefully resolves some of these
errors before they're returned to userspace.

I can reproduce these cases using NFS with:

ssh root@$client '
mount -olookupcache=pos '$server':'$export' /mnt/
mkdir /mnt/TO
mkdir /mnt/DIR
touch /mnt/DIR/test.txt
while true; do
strace -e open cat /mnt/DIR/test.txt 2>&1 | grep EBUSY
done
'
ssh root@$server '
while true; do
mv $export/DIR $export/TO/DIR
mv $export/TO/DIR $export/DIR
done
'

It also helps to add some other concurrent use of the directory on the
client (e.g., "ls /mnt/TO").  And you can replace the server-side mv's
by client-side mv's that are repeatedly killed.  (If the client is
interrupted while waiting for the RENAME response then it's left with a
dentry that has to go under one parent or the other, but it doesn't yet
know which.)

Acked-by: Jeff Layton <jlayton@primarydata.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

NTFS: Version 2.1.32 - Update file write from aio_write to write_iter.

Signed-off-by: Anton Altaparmakov <anton@tuxera.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

VFS: Add iov_iter_fault_in_multipages_readable()

simillar to iov_iter_fault_in_readable() but differs in that it is
not limited to faulting in the first iovec and instead faults in
"bytes" bytes iterating over the iovecs as necessary.

Also, instead of only faulting in the first and last page of the
range, all pages are faulted in.

This function is needed by NTFS when it does multi page file
writes.

Signed-off-by: Anton Altaparmakov <anton@tuxera.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

drop bogus check in file_open_root()

For one thing, LOOKUP_DIRECTORY will be dealt with in do_last().
For another, name can be an empty string, but not NULL - no callers
pass that and it would oops immediately if they would.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

switch security_inode_getattr() to struct path *

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

constify tomoyo_realpath_from_path()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

whack-a-mole: there's no point doing set_fs(USER_DS) in sigframe setup

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

whack-a-mole: no need to set_fs(USER_DS) in {start,flush}_thread()

flush_old_exec() has already done that.  Back on 2011 a bunch of
instances like that had been kicked out, but that hadn't taken
care of then-out-of-tree architectures, obviously, and they served
as reinfection vector...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

remove incorrect comment in lookup_one_len()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

namei.c: fold do_path_lookup() into both callers

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

kill struct filename.separate

just make const char iname[] the last member and compare name->name with
name->iname instead of checking name->separate

We need to make sure that out-of-line name doesn't end up allocated adjacent
to struct filename refering to it; fortunately, it's easy to achieve - just
allocate that struct filename with one byte in ->iname[], so that ->iname[0]
will be inside the same object and thus have an address different from that
of out-of-line name [spotted by Boqun Feng <boqun.feng@gmail.com>]

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

new helper: msg_data_left()

convert open-coded instances

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Merge remote-tracking branch 'dh/afs' into for-davem

get rid of the size argument of sock_sendmsg()

it's equal to iov_iter_count(&msg->msg_iter) in all cases

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

switch kernel_sendmsg() and kernel_recvmsg() to iov_iter_kvec()

For kernel_sendmsg() that eliminates the need to play with setfs();
for kernel_recvmsg() it does *not* - a couple of callers are using
it with non-NULL ->msg_control, which would be treated as userland
address on recvmsg side of things.

In all cases we are really setting a kvec-backed iov_iter, though.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

net: switch importing msghdr from userland to {compat_,}import_iovec()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

net: switch sendto() and recvfrom() to import_single_range()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Merge branch 'iov_iter' into for-davem

Merge branch 'iocb' into for-davem

trivial conflict in net/socket.c and non-trivial one in crypto -
that one had evaded aio_complete() removal.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Merge branch 'for-upstream' of git://git./linux/kernel/git/bluetooth/bluetooth-next

Johan Hedberg says:

====================
pull request: bluetooth-next 2015-04-04

Here's what's probably the last bluetooth-next pull request for 4.1:

 - Fixes for LE advertising data & advertising parameters
 - Fix for race condition with HCI_RESET flag
 - New BNEPGETSUPPFEAT ioctl, needed for certification
 - New HCI request callback type to get the resulting skb
 - Cleanups to use BIT() macro wherever possible
 - Consolidate Broadcom device entries in the btusb HCI driver
 - Check for valid flags in CMTP, HIDP & BNEP
 - Disallow local privacy & OOB data combo to prevent a potential race
 - Expose SMP & ECDH selftest results through debugfs
 - Expose current Device ID info through debugfs

Please let me know if there are any issues pulling. Thanks.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

Merge git://git./linux/kernel/git/davem/net

Conflicts:
drivers/net/ethernet/mellanox/mlx4/cmd.c
net/core/fib_rules.c
net/ipv4/fib_frontend.c

The fib_rules.c and fib_frontend.c conflicts were locking adjustments
in 'net' overlapping addition and removal of code in 'net-next'.

The mlx4 conflict was a bug fix in 'net' happening in the same
place a constant was being replaced with a more suitable macro.

Signed-off-by: David S. Miller <davem@davemloft.net>

Linux 4.0-rc7

Merge git://git./linux/kernel/git/davem/net

Pull networking fixes from David Miller:

 1) In TCP, don't register an FRTO for cumulatively ACK'd data that was
    previously SACK'd, from Neal Cardwell.

 2) Need to hold RNL mutex in ipv4 multicast code namespace cleanup,
    from Cong WANG.

 3) Similarly we have to hold RNL mutex for fib_rules_unregister(), also
    from Cong WANG.

 4) Revert and rework netns nsid allocation fix, from Nicolas Dichtel.

 5) When we encapsulate for a tunnel device, skb->sk still points to the
    user socket.  So this leads to cases where we retraverse the
    ipv4/ipv6 output path with skb->sk being of some other address
    family (f.e. AF_PACKET).  This can cause things to crash since the
    ipv4 output path is dereferencing an AF_PACKET socket as if it were
    an ipv4 one.

    The short term fix for 'net' and -stable is to elide these socket
    checks once we've entered an encapsulation sequence by testing
    xmit_recursion.

    Longer term we have a better solution wherein we pass the tunnel's
    socket down through the output paths, but that is way too invasive
    for 'net' and -stable.

    From Hannes Frederic Sowa.

 6) l2tp_init() failure path forgets to unregister per-net ops, from
    Cong WANG.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  net/mlx4_core: Fix error message deprecation for ConnectX-2 cards
  net: dsa: fix filling routing table from OF description
  l2tp: unregister l2tp_net_ops on failure path
  mvneta: dont call mvneta_adjust_link() manually
  ipv6: protect skb->sk accesses from recursive dereference inside the stack
  netns: don't allocate an id for dead netns
  Revert "netns: don't clear nsid too early on removal"
  ip6mr: call del_timer_sync() in ip6mr_free_table()
  net: move fib_rules_unregister() under rtnl lock
  ipv4: take rtnl_lock and mark mrt table as freed on namespace cleanup
  tcp: fix FRTO undo on cumulative ACK of SACKed range
  xen-netfront: transmit fully GSO-sized packets

net/mlx4_core: Fix error message deprecation for ConnectX-2 cards

Commit 1daa4303b4ca ("net/mlx4_core: Deprecate error message at
ConnectX-2 cards startup to debug") did the deprecation only for port 1
of the card. Need to deprecate for port 2 as well.

Fixes: 1daa4303b4ca ("net/mlx4_core: Deprecate error message at ConnectX-2 cards startup to debug")
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: dsa: fix filling routing table from OF description

According to description in 'include/net/dsa.h', in cascade switches
configurations where there are more than one interconnected devices,
'rtable' array in 'dsa_chip_data' structure is used to indicate which
port on this switch should be used to send packets to that are destined
for corresponding switch.

However, dsa_of_setup_routing_table() fills 'rtable' with port numbers
of the _target_ switch, but not current one.

This commit removes redundant devicetree parsing and adds needed port
number as a function argument. So dsa_of_setup_routing_table() now just
looks for target switch number by parsing parent of 'link' device node.

To remove possible misunderstandings with the way of determining target
switch number, a corresponding comment was added to the source code and
to the DSA device tree bindings documentation file.

This was tested on a custom board with two Marvell 88E6095 switches with
following corresponding routing tables: { -1, 10 } and { 8, -1 }.

Signed-off-by: Pavel Nakonechny <pavel.nakonechny@skitlab.ru>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'for-linus' of git://git./linux/kernel/git/dtor/input

Pull input fixes from Dmitry Torokhov:
 "Updates for the input subsystem - two more tweaks for ALPS driver to
  work out kinks after splitting the touchpad, trackstick, and potential
  external PS/2 mouse into separate input devices.

  Changes to support ALPS SS4 devices (protocol V8) will be coming in
  4.1..."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: alps - document stick behavior for protocol V2
  Input: alps - report V2 Dualpoint Stick events via the right evdev node
  Input: alps - report interleaved bare PS/2 packets via dev3

l2tp: unregister l2tp_net_ops on failure path

Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

virtio: document queue state logic

commit d631b94e7a15277858ec5f88d674d93080506999
    virtio: change comment in transmit

started clarifying the logic behind queue state management,
but introduced an inaccuracy: TX_BUSY does not cause
a BUG message.

Clean this up some more, explaining the tradeoffs in detail.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

tc: bpf: add checksum helpers

Commit 608cd71a9c7c ("tc: bpf: generalize pedit action") has added the
possibility to mangle packet data to BPF programs in the tc pipeline.
This patch adds two helpers bpf_l3_csum_replace() and bpf_l4_csum_replace()
for fixing up the protocol checksums after the packet mangling.

It also adds 'flags' argument to bpf_skb_store_bytes() helper to avoid
unnecessary checksum recomputations when BPF programs adjusting l3/l4
checksums and documents all three helpers in uapi header.

Moreover, a sample program is added to show how BPF programs can make use
of the mangle and csum helpers.

Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

mvneta: dont call mvneta_adjust_link() manually

mvneta_adjust_link() is a callback for of_phy_connect() and should
not be called directly. The result of calling it directly is as below:

Signed-off-by: David S. Miller <davem@davemloft.net>

ipv6: protect skb->sk accesses from recursive dereference inside the stack

We should not consult skb->sk for output decisions in xmit recursion
levels > 0 in the stack. Otherwise local socket settings could influence
the result of e.g. tunnel encapsulation process.

ipv6 does not conform with this in three places:

1) ip6_fragment: we do consult ipv6_npinfo for frag_size

2) sk_mc_loop in ipv6 uses skb->sk and checks if we should
   loop the packet back to the local socket

3) ip6_skb_dst_mtu could query the settings from the user socket and
   force a wrong MTU

Furthermore:
In sk_mc_loop we could potentially land in WARN_ON(1) if we use a
PF_PACKET socket ontop of an IPv6-backed vxlan device.

Reuse xmit_recursion as we are currently only interested in protecting
tunnel devices.

Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Input: alps - document stick behavior for protocol V2

Document that protocol V2 uses standard (bare) PS/2 mouse packets for the
DualPoint stick.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-By: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: alps - report V2 Dualpoint Stick events via the right evdev node

On V2 devices the DualPoint Stick reports bare packets, these should be
reported via the "AlpsPS/2 ALPS DualPoint Stick" dev2 evdev node, which also
has the INPUT_PROP_POINTING_STICK propbit set.

Note that since there is no way to distinguish these packets from an external
PS/2 mouse (insofar as these laptops have an external PS/2 port) this means
that we will be reporting PS/2 mouse events via this evdev node too, as we've
been doing in kernel 3.19 and older.

This has been tested on a Dell Latitude D620 and a Dell Latitude E6400,
which both have a V2 touchpad + a DualPoint Stick which reports bare packets.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: alps - report interleaved bare PS/2 packets via dev3

Bare packets should be reported via the same evdev device independent on
whether they are detected on the beginning of a packet or in the middle
of a packet.

This has been tested on a Dell Latitude E6400, where the DualPoint Stick
reports bare packets, which get reported via dev3 when the touchpad is
idle, and via dev2 when the touchpad and stick are used simultaneously.

This commit fixes this inconsistency by always reporting bare packets via
dev3. Note that since the come from a DualPoint Stick they really should be
reported via dev2, this gets fixed in a later commit.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge tag 'usb-4.0-rc6' of git://git./linux/kernel/git/gregkh/usb

Pull USB fixes from Greg KH:
 "Here are some small USB fixes and new device ids for 4.0-rc6.  Nothing
  major, some xhci fixes for reported problems, and some usb-serial
  device ids.

  All have been in linux-next for a while"

* tag 'usb-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  USB: ftdi_sio: Use jtag quirk for SNAP Connect E10
  usb: isp1760: fix spin unlock in the error path of isp1760_udc_start
  usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers
  usb: xhci: handle Config Error Change (CEC) in xhci driver
  USB: keyspan_pda: add new device id
  USB: ftdi_sio: Added custom PID for Synapse Wireless product