linux-stable.git/include, branch v3.16.7

kernel: add support for gcc 5

2014-10-30T16:40:16+00:00

commit 71458cfc782eafe4b27656e078d379a34e472adf upstream.

We're missing include/linux/compiler-gcc5.h which is required now
because gcc branched off to v5 in trunk.

Just copy the relevant bits out of include/linux/compiler-gcc4.h,
no new code is added as of now.

This fixes a build error when using gcc 5.

Signed-off-by: Sasha Levin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set

2014-10-30T16:40:16+00:00

commit 934f3072c17cc8886f4c043b47eeeb1b12f8de33 upstream.

commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O
during memory allocation") introduces PF_MEMALLOC_NOIO flag to avoid doing
I/O inside memory allocation, __GFP_IO is cleared when this flag is set,
but __GFP_FS implies __GFP_IO, it should also be cleared.  Or it may still
run into I/O, like in superblock shrinker.  And this will make the kernel
run into the deadlock case described in that commit.

See Dave Chinner's comment about io in superblock shrinker:

Filesystem shrinkers do indeed perform IO from the superblock shrinker and
have for years.  Even clean inodes can require IO before they can be freed
- e.g.  on an orphan list, need truncation of post-eof blocks, need to
wait for ordered operations to complete before it can be freed, etc.

IOWs, Ext4, btrfs and XFS all can issue and/or block on arbitrary amounts
of IO in the superblock shrinker context.  XFS, in particular, has been
doing transactions and IO from the VFS inode cache shrinker since it was
first introduced....

Fix this by clearing __GFP_FS in memalloc_noio_flags(), this function has
masked all the gfp_mask that will be passed into fs for the processes
setting PF_MEMALLOC_NOIO in the direct reclaim path.

v1 thread at: https://lkml.org/lkml/2014/9/3/32

Signed-off-by: Junxiao Bi 
Cc: Dave Chinner 
Cc: joyce.xue 
Cc: Ming Lei 
Cc: Trond Myklebust 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: util: Properly pack the data for file copy functionality

2014-10-30T16:40:12+00:00

commit bc5a5b02331a3175a5fca20a4beba249e573b672 upstream.

Properly pack the data for file copy functionality. Patch based on
investigation done by Matej Muzila 

Signed-off-by: K. Y. Srinivasan 
Reported-by: 
Acked-by: Jason Wang 
Signed-off-by: Greg Kroah-Hartman

pci_ids: Add support for Intel Quark ILB

2014-10-30T16:40:10+00:00

commit bb048713bba3ead39f6112910906d9fe3f88ede7 upstream.

This patch adds the PCI id for Intel Quark ILB.
It will be used for GPIO and Multifunction device driver.

Signed-off-by: Josef Ahmad 
Acked-by: Bjorn Helgaas 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Lee Jones 
Signed-off-by: Chang Rebecca Swee Fun 
Signed-off-by: Greg Kroah-Hartman

USB: Add device quirk for ASUS T100 Base Station keyboard

2014-10-15T10:05:30+00:00

commit ddbe1fca0bcb87ca8c199ea873a456ca8a948567 upstream.

This full-speed USB device generates spurious remote wakeup event
as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result,
Linux can't enter system suspend and S0ix power saving modes once
this keyboard is used.

This patch tries to introduce USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk.
With this quirk set, wakeup capability will be ignored during
device configure.

This patch could be back-ported to kernels as old as 2.6.39.

Signed-off-by: Lu Baolu 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

uas: Add no-report-opcodes quirk

2014-10-15T10:05:30+00:00

commit 734016b00b50a3c6a0e1fc1b7b217e783f5123a1 upstream.

Besides the ASM1051 (*) needing sdev->no_report_opcodes = 1, it turns out that
the JMicron JMS567 also needs it to work properly with uas (usb-storage always
sets it). Since some of the scsi devs were not to keen on the idea to
outrightly set sdev->no_report_opcodes = 1 for all uas devices, so add a quirk
for this, and set it for the JMS567.

*) Which has become a non-issue since we've completely blacklisted uas on
the ASM1051 for other reasons

Reported-and-tested-by: Claudio Bizzarri 
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

uas: Add a quirk for rejecting ATA_12 and ATA_16 commands

2014-10-15T10:05:30+00:00

commit 593078525c8b234a35a36ff551b8716464e86481 upstream.

And set this quirk for the Seagate Expansion Desk (0bc2:2312), as that one
seems to hang upon receiving an ATA_12 or ATA_16 command.

https://bugzilla.kernel.org/show_bug.cgi?id=79511
https://bbs.archlinux.org/viewtopic.php?id=183190

While at it also add missing documentation for the u value for usb-storage
quirks.

Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

sctp: handle association restarts when the socket is closed.

2014-10-15T10:05:30+00:00

[ Upstream commit bdf6fa52f01b941d4a80372d56de465bdbbd1d23 ]

Currently association restarts do not take into consideration the
state of the socket.  When a restart happens, the current assocation
simply transitions into established state.  This creates a condition
where a remote system, through a the restart procedure, may create a
local association that is no way reachable by user.  The conditions
to trigger this are as follows:
  1) Remote does not acknoledge some data causing data to remain
     outstanding.
  2) Local application calls close() on the socket.  Since data
     is still outstanding, the association is placed in SHUTDOWN_PENDING
     state.  However, the socket is closed.
  3) The remote tries to create a new association, triggering a restart
     on the local system.  The association moves from SHUTDOWN_PENDING
     to ESTABLISHED.  At this point, it is no longer reachable by
     any socket on the local system.

This patch addresses the above situation by moving the newly ESTABLISHED
association into SHUTDOWN-SENT state and bundling a SHUTDOWN after
the COOKIE-ACK chunk.  This way, the restarted associate immidiately
enters the shutdown procedure and forces the termination of the
unreachable association.

Reported-by: David Laight 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: remove rt6i_genid

2014-10-15T10:05:29+00:00

[ Upstream commit 705f1c869d577c8055736dd02501f26a2507dd5b ]

Eric Dumazet noticed that all no-nonexthop or no-gateway routes which
are already marked DST_HOST (e.g. input routes routes) will always be
invalidated during sk_dst_check. Thus per-socket dst caching absolutely
had no effect and early demuxing had no effect.

Thus this patch removes rt6i_genid: fn_sernum already gets modified during
add operations, so we only must ensure we mutate fn_sernum during ipv6
address remove operations. This is a fairly cost extensive operations,
but address removal should not happen that often. Also our mtu update
functions do the same and we heard no complains so far. xfrm policy
changes also cause a call into fib6_flush_trees. Also plug a hole in
rt6_info (no cacheline changes).

I verified via tracing that this change has effect.

Cc: Eric Dumazet 
Cc: YOSHIFUJI Hideaki 
Cc: Vlad Yasevich 
Cc: Nicolas Dichtel 
Cc: Martin Lau 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

xfrm: Generate queueing routes only from route lookup functions

2014-10-15T10:05:29+00:00

[ Upstream commit b8c203b2d2fc961bafd53b41d5396bbcdec55998 ]

Currently we genarate a queueing route if we have matching policies
but can not resolve the states and the sysctl xfrm_larval_drop is
disabled. Here we assume that dst_output() is called to kill the
queued packets. Unfortunately this assumption is not true in all
cases, so it is possible that these packets leave the system unwanted.

We fix this by generating queueing routes only from the
route lookup functions, here we can guarantee a call to
dst_output() afterwards.

Fixes: a0073fe18e71 ("xfrm: Add a state resolution packet queue")
Reported-by: Konstantinos Kolelis 
Signed-off-by: Steffen Klassert 
Signed-off-by: Greg Kroah-Hartman