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

ipc,mqueue: remove limits for the amount of system-wide queues

2014-03-07T06:06:28+00:00

commit f3713fd9cff733d9df83116422d8e4af6e86b2bb upstream.

Commit 93e6f119c0ce ("ipc/mqueue: cleanup definition names and
locations") added global hardcoded limits to the amount of message
queues that can be created.  While these limits are per-namespace,
reality is that it ends up breaking userspace applications.
Historically users have, at least in theory, been able to create up to
INT_MAX queues, and limiting it to just 1024 is way too low and dramatic
for some workloads and use cases.  For instance, Madars reports:

 "This update imposes bad limits on our multi-process application.  As
  our app uses approaches that each process opens its own set of queues
  (usually something about 3-5 queues per process).  In some scenarios
  we might run up to 3000 processes or more (which of-course for linux
  is not a problem).  Thus we might need up to 9000 queues or more.  All
  processes run under one user."

Other affected users can be found in launchpad bug #1155695:
  https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1155695

Instead of increasing this limit, revert it entirely and fallback to the
original way of dealing queue limits -- where once a user's resource
limit is reached, and all memory is used, new queues cannot be created.

Signed-off-by: Davidlohr Bueso 
Reported-by: Madars Vitolins 
Acked-by: Doug Ledford 
Cc: Manfred Spraul 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Revert "writeback: do not sync data dirtied after sync start"

2014-03-07T06:06:22+00:00

commit 0dc83bd30b0bf5410c0933cfbbf8853248eff0a9 upstream.

This reverts commit c4a391b53a72d2df4ee97f96f78c1d5971b47489. Dave
Chinner  has reported the commit may cause some
inodes to be left out from sync(2). This is because we can call
redirty_tail() for some inode (which sets i_dirtied_when to current time)
after sync(2) has started or similarly requeue_inode() can set
i_dirtied_when to current time if writeback had to skip some pages. The
real problem is in the functions clobbering i_dirtied_when but fixing
that isn't trivial so revert is a safer choice for now.

Signed-off-by: Jan Kara 
Signed-off-by: Greg Kroah-Hartman

export: declare ksymtab symbols

2014-03-07T06:06:18+00:00

commit 7b4ec8dd7d4ac467e9eee4d49f2c9574d773efbb upstream.

sparse complains about any __ksymtab symbols with the following:

 warning: symbol '__ksymtab_...' was not declared. Should it be static?

due to Andi's patch making it non-static.

Mollify sparse by declaring the symbol extern, otherwise we get
drowned in sparse warnings for anything that uses EXPORT_SYMBOL
in the sources, making it easy to miss real warnings.

Fixes: e0f244c63fc9 ("asmlinkage, module: Make ksymtab [...] __visible")
Signed-off-by: Johannes Berg 
Acked-by: Andi Kleen 
Signed-off-by: Rusty Russell 
Signed-off-by: Greg Kroah-Hartman

net: ip, ipv6: handle gso skbs in forwarding path

2014-03-07T06:06:14+00:00

commit fe6cc55f3a9a053482a76f5a6b2257cee51b4663 upstream.

Marcelo Ricardo Leitner reported problems when the forwarding link path
has a lower mtu than the incoming one if the inbound interface supports GRO.

Given:
Host  R1  R2

Host sends tcp stream which is routed via R1 and R2.  R1 performs GRO.

In this case, the kernel will fail to send ICMP fragmentation needed
messages (or pkt too big for ipv6), as GSO packets currently bypass dstmtu
checks in forward path. Instead, Linux tries to send out packets exceeding
the mtu.

When locking route MTU on Host (i.e., no ipv4 DF bit set), R1 does
not fragment the packets when forwarding, and again tries to send out
packets exceeding R1-R2 link mtu.

This alters the forwarding dstmtu checks to take the individual gso
segment lengths into account.

For ipv6, we send out pkt too big error for gso if the individual
segments are too big.

For ipv4, we either send icmp fragmentation needed, or, if the DF bit
is not set, perform software segmentation and let the output path
create fragments when the packet is leaving the machine.
It is not 100% correct as the error message will contain the headers of
the GRO skb instead of the original/segmented one, but it seems to
work fine in my (limited) tests.

Eric Dumazet suggested to simply shrink mss via ->gso_size to avoid
sofware segmentation.

However it turns out that skb_segment() assumes skb nr_frags is related
to mss size so we would BUG there.  I don't want to mess with it considering
Herbert and Eric disagree on what the correct behavior should be.

Hannes Frederic Sowa notes that when we would shrink gso_size
skb_segment would then also need to deal with the case where
SKB_MAX_FRAGS would be exceeded.

This uses sofware segmentation in the forward path when we hit ipv4
non-DF packets and the outgoing link mtu is too small.  Its not perfect,
but given the lack of bug reports wrt. GRO fwd being broken this is a
rare case anyway.  Also its not like this could not be improved later
once the dust settles.

Acked-by: Herbert Xu 
Reported-by: Marcelo Ricardo Leitner 
Signed-off-by: Florian Westphal 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: core: introduce netif_skb_dev_features

2014-03-07T06:06:14+00:00

commit d206940319c41df4299db75ed56142177bb2e5f6 upstream.

Will be used by upcoming ipv4 forward path change that needs to
determine feature mask using skb->dst->dev instead of skb->dev.

Signed-off-by: Florian Westphal 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: add and use skb_gso_transport_seglen()

2014-03-07T06:06:14+00:00

commit de960aa9ab4decc3304959f69533eef64d05d8e8 upstream.

This moves part of Eric Dumazets skb_gso_seglen helper from tbf sched to
skbuff core so it may be reused by upcoming ip forwarding path patch.

Signed-off-by: Florian Westphal 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

can: add destructor for self generated skbs

2014-03-07T06:06:11+00:00

[ Upstream commit 0ae89beb283a0db5980d1d4781c7d7be2f2810d6 ]

Self generated skbuffs in net/can/bcm.c are setting a skb->sk reference but
no explicit destructor which is enforced since Linux 3.11 with commit
376c7311bdb6 (net: add a temporary sanity check in skb_orphan()).

This patch adds some helper functions to make sure that a destructor is
properly defined when a sock reference is assigned to a CAN related skb.
To create an unshared skb owned by the original sock a common helper function
has been introduced to replace open coded functions to create CAN echo skbs.

Signed-off-by: Oliver Hartkopp 
Tested-by: Andre Naujoks 
Reviewed-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

compiler/gcc4: Make quirk for asm_volatile_goto() unconditional

2014-02-22T21:34:57+00:00

commit a9f180345f5378ac87d80ed0bea55ba421d83859 upstream.

I started noticing problems with KVM guest destruction on Linux
3.12+, where guest memory wasn't being cleaned up. I bisected it
down to the commit introducing the new 'asm goto'-based atomics,
and found this quirk was later applied to those.

Unfortunately, even with GCC 4.8.2 (which ostensibly fixed the
known 'asm goto' bug) I am still getting some kind of
miscompilation. If I enable the asm_volatile_goto quirk for my
compiler, KVM guests are destroyed correctly and the memory is
cleaned up.

So make the quirk unconditional for now, until bug is found
and fixed.

Suggested-by: Linus Torvalds 
Signed-off-by: Steven Noonan 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Cc: Jakub Jelinek 
Cc: Richard Henderson 
Cc: Andrew Morton 
Cc: Oleg Nesterov 
Link: http://lkml.kernel.org/r/1392274867-15236-1-git-send-email-steven@uplinklabs.net
Link: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

Revert "usb: xhci: Link TRB must not occur within a USB payload burst"

2014-02-22T21:34:56+00:00

commit 3d4b81eda2211f32886e2978daf6f39885042fc4 upstream.

This reverts commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e.  It's a
hack that caused regressions in the usb-storage and userspace USB
drivers that use usbfs and libusb.  Commit 70cabb7d992f "xhci 1.0: Limit
arbitrarily-aligned scatter gather." should fix the issues seen with the
ax88179_178a driver on xHCI 1.0 hosts, without causing regressions.

Signed-off-by: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Specify the target CPU that should receive notification

2014-02-22T21:34:53+00:00

commit e28bab4828354583bb66ac09021ca69b341a7db4 upstream.

During the initial VMBUS connect phase, starting with WS2012 R2, we should
specify the VPCU in the guest that should receive the notification. Fix this
issue. This fix is required to properly connect to the host in the kexeced
kernel.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman