linux-toradex.git, branch v3.4.62

Linux 3.4.62

2013-09-14T13:02:37+00:00

Revert "KVM: X86 emulator: fix source operand decoding for 8bit mov[zs]x instructions"

2013-09-14T13:02:11+00:00

This reverts commit 5b5b30580218eae22609989546bac6e44d0eda6e, which was
commit 660696d1d16a71e15549ce1bf74953be1592bcd3 upstream.

Paul Gortmaker  writes:

[this patch] introduces the following:

arch/x86/kvm/emulate.c: In function ‘decode_operand’:
arch/x86/kvm/emulate.c:3974:4: warning: passing argument 1 of ‘decode_register’ makes integer from pointer
+without a cast [enabled by default]
arch/x86/kvm/emulate.c:789:14: note: expected ‘u8’ but argument is of type ‘struct x86_emulate_ctxt *’
arch/x86/kvm/emulate.c:3974:4: warning: passing argument 2 of ‘decode_register’ makes pointer from integer
+without a cast [enabled by default]
arch/x86/kvm/emulate.c:789:14: note: expected ‘long unsigned int *’ but argument is of type ‘u8’

Based on the severity of the warnings above, I'm reasonably sure there will
be some kind of runtime regressions due to this, but I stopped to investigate
the warnings as soon as I saw them, before any run time testing.

It happens because mainline v3.7-rc1~113^2~40 (dd856efafe60) does this:

-static void *decode_register(u8 modrm_reg, unsigned long *regs,
+static void *decode_register(struct x86_emulate_ctxt *ctxt, u8 modrm_reg,

Since 660696d1d16a71e1 was only applied to stable 3.4, 3.8, and 3.9 -- and
the prerequisite above is in 3.7+, the issue should be limited to 3.4.44+

Reported-by: Paul Gortmaker 
Acked-by: Paolo Bonzini 
Cc: Gleb Natapov 
Signed-off-by: Greg Kroah-Hartman

m32r: make memset() global for CONFIG_KERNEL_BZIP2=y

2013-09-14T13:02:11+00:00

commit 9a75c6e5240f7edc5955e8da5b94bde6f96070b3 upstream.

Fix the m32r compile error:

  arch/m32r/boot/compressed/misc.c:31:14: error: static declaration of 'memset' follows non-static declaration
  make[5]: *** [arch/m32r/boot/compressed/misc.o] Error 1
  make[4]: *** [arch/m32r/boot/compressed/vmlinux] Error 2

by removing the static keyword.

Signed-off-by: Geert Uytterhoeven 
Cc: Hirokazu Takata 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

m32r: add memcpy() for CONFIG_KERNEL_GZIP=y

2013-09-14T13:02:11+00:00

commit a8abbca6617e1caa2344d2d38d0a35f3e5928b79 upstream.

Fix the m32r link error:

    LD      arch/m32r/boot/compressed/vmlinux
  arch/m32r/boot/compressed/misc.o: In function `zlib_updatewindow':
  misc.c:(.text+0x190): undefined reference to `memcpy'
  misc.c:(.text+0x190): relocation truncated to fit: R_M32R_26_PLTREL against undefined symbol `memcpy'
  make[5]: *** [arch/m32r/boot/compressed/vmlinux] Error 1

by adding our own implementation of memcpy().

Signed-off-by: Geert Uytterhoeven 
Cc: Hirokazu Takata 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

m32r: consistently use "suffix-$(...)"

2013-09-14T13:02:11+00:00

commit df12aef6a19bb2d69859a94936bda0e6ccaf3327 upstream.

Commit a556bec9955c ("m32r: fix arch/m32r/boot/compressed/Makefile")
changed "$(suffix_y)" to "$(suffix-y)", but didn't update any location
where "suffix_y" is set, causing:

  make[5]: *** No rule to make target `arch/m32r/boot/compressed/vmlinux.bin.', needed by `arch/m32r/boot/compressed/piggy.o'.  Stop.
  make[4]: *** [arch/m32r/boot/compressed/vmlinux] Error 2
  make[3]: *** [zImage] Error 2

Correct the other locations to fix this.

Signed-off-by: Geert Uytterhoeven 
Cc: Hirokazu Takata 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

tipc: fix lockdep warning during bearer initialization

2013-09-14T13:02:11+00:00

[ Upstream commit 4225a398c1352a7a5c14dc07277cb5cc4473983b ]

When the lockdep validator is enabled, it will report the below
warning when we enable a TIPC bearer:

[ INFO: possible irq lock inversion dependency detected ]
---------------------------------------------------------
Possible interrupt unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(ptype_lock);
                                local_irq_disable();
                                lock(tipc_net_lock);
                                lock(ptype_lock);
   
   lock(tipc_net_lock);

  *** DEADLOCK ***

the shortest dependencies between 2nd lock and 1st lock:
  -> (ptype_lock){+.+...} ops: 10 {
[...]
SOFTIRQ-ON-W at:
                      [] __lock_acquire+0x528/0x13e0
                      [] lock_acquire+0x90/0x100
                      [] _raw_spin_lock+0x38/0x50
                      [] dev_add_pack+0x3a/0x60
                      [] arp_init+0x1a/0x48
                      [] inet_init+0x181/0x27e
                      [] do_one_initcall+0x34/0x170
                      [] kernel_init+0x110/0x1b2
                      [] kernel_thread_helper+0x6/0x10
[...]
   ... key      at: [] ptype_lock+0x10/0x20
   ... acquired at:
    [] lock_acquire+0x90/0x100
    [] _raw_spin_lock+0x38/0x50
    [] dev_add_pack+0x3a/0x60
    [] enable_bearer+0xf2/0x140 [tipc]
    [] tipc_enable_bearer+0x1ba/0x450 [tipc]
    [] tipc_cfg_do_cmd+0x5c4/0x830 [tipc]
    [] handle_cmd+0x42/0xd0 [tipc]
    [] genl_rcv_msg+0x232/0x280
    [] netlink_rcv_skb+0x86/0xb0
    [] genl_rcv+0x1c/0x30
    [] netlink_unicast+0x174/0x1f0
    [] netlink_sendmsg+0x1eb/0x2d0
    [] sock_aio_write+0x161/0x170
    [] do_sync_write+0xac/0xf0
    [] vfs_write+0x156/0x170
    [] sys_write+0x42/0x70
    [] sysenter_do_call+0x12/0x38
[...]
}
  -> (tipc_net_lock){+..-..} ops: 4 {
[...]
    IN-SOFTIRQ-R at:
                     [] __lock_acquire+0x64a/0x13e0
                     [] lock_acquire+0x90/0x100
                     [] _raw_read_lock_bh+0x3d/0x50
                     [] tipc_recv_msg+0x1d/0x830 [tipc]
                     [] recv_msg+0x3f/0x50 [tipc]
                     [] __netif_receive_skb+0x22a/0x590
                     [] netif_receive_skb+0x2b/0xf0
                     [] pcnet32_poll+0x292/0x780
                     [] net_rx_action+0xfa/0x1e0
                     [] __do_softirq+0xae/0x1e0
[...]
}

>From the log, we can see three different call chains between
CPU0 and CPU1:

Time 0 on CPU0:

  kernel_init()->inet_init()->dev_add_pack()

At time 0, the ptype_lock is held by CPU0 in dev_add_pack();

Time 1 on CPU1:

  tipc_enable_bearer()->enable_bearer()->dev_add_pack()

At time 1, tipc_enable_bearer() first holds tipc_net_lock, and then
wants to take ptype_lock to register TIPC protocol handler into the
networking stack.  But the ptype_lock has been taken by dev_add_pack()
on CPU0, so at this time the dev_add_pack() running on CPU1 has to be
busy looping.

Time 2 on CPU0:

  netif_receive_skb()->recv_msg()->tipc_recv_msg()

At time 2, an incoming TIPC packet arrives at CPU0, hence
tipc_recv_msg() will be invoked. In tipc_recv_msg(), it first wants
to hold tipc_net_lock.  At the moment, below scenario happens:

On CPU0, below is our sequence of taking locks:

  lock(ptype_lock)->lock(tipc_net_lock)

On CPU1, our sequence of taking locks looks like:

  lock(tipc_net_lock)->lock(ptype_lock)

Obviously deadlock may happen in this case.

But please note the deadlock possibly doesn't occur at all when the
first TIPC bearer is enabled.  Before enable_bearer() -- running on
CPU1 does not hold ptype_lock, so the TIPC receive handler (i.e.
recv_msg()) is not registered successfully via dev_add_pack(), so
the tipc_recv_msg() cannot be called by recv_msg() even if a TIPC
message comes to CPU0. But when the second TIPC bearer is
registered, the deadlock can perhaps really happen.

To fix it, we will push the work of registering TIPC protocol
handler into workqueue context. After the change, both paths taking
ptype_lock are always in process contexts, thus, the deadlock should
never occur.

Signed-off-by: Ying Xue 
Signed-off-by: Jon Maloy 
Signed-off-by: Paul Gortmaker 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvtap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS

2013-09-14T13:02:11+00:00

commit ece793fcfc417b3925844be88a6a6dc82ae8f7c6 upstream.

We try to linearize part of the skb when the number of iov is greater than
MAX_SKB_FRAGS. This is not enough since each single vector may occupy more than
one pages, so zerocopy_sg_fromiovec() may still fail and may break the guest
network.

Solve this problem by calculate the pages needed for iov before trying to do
zerocopy and switch to use copy instead of zerocopy if it needs more than
MAX_SKB_FRAGS.

This is done through introducing a new helper to count the pages for iov, and
call uarg->callback() manually when switching from zerocopy to copy to notify
vhost.

We can do further optimization on top.

This bug were introduced from b92946e2919134ebe2a4083e4302236295ea2a73
(macvtap: zerocopy: validate vectors before building skb).

Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

vhost: zerocopy: poll vq in zerocopy callback

2013-09-14T13:02:10+00:00

commit c70aa540c7a9f67add11ad3161096fb95233aa2e upstream.

We add used and signal guest in worker thread but did not poll the virtqueue
during the zero copy callback. This may lead the missing of adding and
signalling during zerocopy. Solve this by polling the virtqueue and let it
wakeup the worker during callback.

Signed-off-by: Jason Wang 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Greg Kroah-Hartman

net: ipv6: tcp: fix potential use after free in tcp_v6_do_rcv

2013-09-14T13:02:10+00:00

[ Upstream commit 3a1c756590633c0e86df606e5c618c190926a0df ]

In tcp_v6_do_rcv() code, when processing pkt options, we soley work
on our skb clone opt_skb that we've created earlier before entering
tcp_rcv_established() on our way. However, only in condition ...

  if (np->rxopt.bits.rxtclass)
    np->rcv_tclass = ipv6_get_dsfield(ipv6_hdr(skb));

... we work on skb itself. As we extract every other information out
of opt_skb in ipv6_pktoptions path, this seems wrong, since skb can
already be released by tcp_rcv_established() earlier on. When we try
to access it in ipv6_hdr(), we will dereference freed skb.

[ Bug added by commit 4c507d2897bd9b ("net: implement IP_RECVTOS for
  IP_PKTOPTIONS") ]

Signed-off-by: Daniel Borkmann 
Cc: Eric Dumazet 
Acked-by: Eric Dumazet 
Acked-by: Jiri Benc 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO

2013-09-14T13:02:10+00:00

[ Upstream commit 61e76b178dbe7145e8d6afa84bb4ccea71918994 ]

RFC 4443 has defined two additional codes for ICMPv6 type 1 (destination
unreachable) messages:
        5 - Source address failed ingress/egress policy
	6 - Reject route to destination

Now they are treated as protocol error and icmpv6_err_convert() converts them
to EPROTO.

RFC 4443 says:
	"Codes 5 and 6 are more informative subsets of code 1."

Treat codes 5 and 6 as code 1 (EACCES)

Btw, connect() returning -EPROTO confuses firefox, so that fallback to
other/IPv4 addresses does not work:
https://bugzilla.mozilla.org/show_bug.cgi?id=910773

Signed-off-by: Jiri Bohac 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman