1. 15 Jan, 2014 23 commits
    • Linus Torvalds's avatar
      x86, fpu, amd: Clear exceptions in AMD FXSAVE workaround · a63f31f1
      Linus Torvalds authored
      commit 26bef131 upstream.
      
      Before we do an EMMS in the AMD FXSAVE information leak workaround we
      need to clear any pending exceptions, otherwise we trap with a
      floating-point exception inside this code.
      Reported-by: default avatarhalfdog <me@halfdog.net>
      Tested-by: default avatarBorislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/CA%2B55aFxQnY_PCG_n4=0w-VG=YLXL-yr7oMxyy0WU2gCBAf3ydg@mail.gmail.comSigned-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a63f31f1
    • Laurent Pinchart's avatar
      ARM: shmobile: mackerel: Fix coherent DMA mask · 925ece07
      Laurent Pinchart authored
      commit b6328a6b upstream.
      
      Commit 4dcfa600 ("ARM: DMA-API: better
      handing of DMA masks for coherent allocations") added an additional
      check to the coherent DMA mask that results in an error when the mask is
      larger than what dma_addr_t can address.
      
      Set the LCDC coherent DMA mask to DMA_BIT_MASK(32) instead of ~0 to fix
      the problem.
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      925ece07
    • Russell King's avatar
      ARM: fix "bad mode in ... handler" message for undefined instructions · 10252aa2
      Russell King authored
      commit 29c350bf upstream.
      
      The array was missing the final entry for the undefined instruction
      exception handler; this commit adds it.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      10252aa2
    • Curt Brune's avatar
      bridge: use spin_lock_bh() in br_multicast_set_hash_max · 09e333b0
      Curt Brune authored
      [ Upstream commit fe0d692b ]
      
      br_multicast_set_hash_max() is called from process context in
      net/bridge/br_sysfs_br.c by the sysfs store_hash_max() function.
      
      br_multicast_set_hash_max() calls spin_lock(&br->multicast_lock),
      which can deadlock the CPU if a softirq that also tries to take the
      same lock interrupts br_multicast_set_hash_max() while the lock is
      held .  This can happen quite easily when any of the bridge multicast
      timers expire, which try to take the same lock.
      
      The fix here is to use spin_lock_bh(), preventing other softirqs from
      executing on this CPU.
      
      Steps to reproduce:
      
      1. Create a bridge with several interfaces (I used 4).
      2. Set the "multicast query interval" to a low number, like 2.
      3. Enable the bridge as a multicast querier.
      4. Repeatedly set the bridge hash_max parameter via sysfs.
      
        # brctl addbr br0
        # brctl addif br0 eth1 eth2 eth3 eth4
        # brctl setmcqi br0 2
        # brctl setmcquerier br0 1
      
        # while true ; do echo 4096 > /sys/class/net/br0/bridge/hash_max; done
      Signed-off-by: default avatarCurt Brune <curt@cumulusnetworks.com>
      Signed-off-by: default avatarScott Feldman <sfeldma@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09e333b0
    • Daniel Borkmann's avatar
      net: llc: fix use after free in llc_ui_recvmsg · 5a5bf44e
      Daniel Borkmann authored
      [ Upstream commit 4d231b76 ]
      
      While commit 30a584d9 fixes datagram interface in LLC, a use
      after free bug has been introduced for SOCK_STREAM sockets that do
      not make use of MSG_PEEK.
      
      The flow is as follow ...
      
        if (!(flags & MSG_PEEK)) {
          ...
          sk_eat_skb(sk, skb, false);
          ...
        }
        ...
        if (used + offset < skb->len)
          continue;
      
      ... where sk_eat_skb() calls __kfree_skb(). Therefore, cache
      original length and work on skb_len to check partial reads.
      
      Fixes: 30a584d9 ("[LLX]: SOCK_DGRAM interface fixes")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5a5bf44e
    • David S. Miller's avatar
      vlan: Fix header ops passthru when doing TX VLAN offload. · 86dc6b93
      David S. Miller authored
      [ Upstream commit 2205369a ]
      
      When the vlan code detects that the real device can do TX VLAN offloads
      in hardware, it tries to arrange for the real device's header_ops to
      be invoked directly.
      
      But it does so illegally, by simply hooking the real device's
      header_ops up to the VLAN device.
      
      This doesn't work because we will end up invoking a set of header_ops
      routines which expect a device type which matches the real device, but
      will see a VLAN device instead.
      
      Fix this by providing a pass-thru set of header_ops which will arrange
      to pass the proper real device instead.
      
      To facilitate this add a dev_rebuild_header().  There are
      implementations which provide a ->cache and ->create but not a
      ->rebuild (f.e. PLIP).  So we need a helper function just like
      dev_hard_header() to avoid crashes.
      
      Use this helper in the one existing place where the
      header_ops->rebuild was being invoked, the neighbour code.
      
      With lots of help from Florian Westphal.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86dc6b93
    • Florian Westphal's avatar
      net: rose: restore old recvmsg behavior · e25027c9
      Florian Westphal authored
      [ Upstream commit f81152e3 ]
      
      recvmsg handler in net/rose/af_rose.c performs size-check ->msg_namelen.
      
      After commit f3d33426
      (net: rework recvmsg handler msg_name and msg_namelen logic), we now
      always take the else branch due to namelen being initialized to 0.
      
      Digging in netdev-vger-cvs git repo shows that msg_namelen was
      initialized with a fixed-size since at least 1995, so the else branch
      was never taken.
      
      Compile tested only.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e25027c9
    • Sasha Levin's avatar
      rds: prevent dereference of a NULL device · 7918313d
      Sasha Levin authored
      [ Upstream commit c2349758 ]
      
      Binding might result in a NULL device, which is dereferenced
      causing this BUG:
      
      [ 1317.260548] BUG: unable to handle kernel NULL pointer dereference at 000000000000097
      4
      [ 1317.261847] IP: [<ffffffff84225f52>] rds_ib_laddr_check+0x82/0x110
      [ 1317.263315] PGD 418bcb067 PUD 3ceb21067 PMD 0
      [ 1317.263502] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      [ 1317.264179] Dumping ftrace buffer:
      [ 1317.264774]    (ftrace buffer empty)
      [ 1317.265220] Modules linked in:
      [ 1317.265824] CPU: 4 PID: 836 Comm: trinity-child46 Tainted: G        W    3.13.0-rc4-
      next-20131218-sasha-00013-g2cebb9b-dirty #4159
      [ 1317.267415] task: ffff8803ddf33000 ti: ffff8803cd31a000 task.ti: ffff8803cd31a000
      [ 1317.268399] RIP: 0010:[<ffffffff84225f52>]  [<ffffffff84225f52>] rds_ib_laddr_check+
      0x82/0x110
      [ 1317.269670] RSP: 0000:ffff8803cd31bdf8  EFLAGS: 00010246
      [ 1317.270230] RAX: 0000000000000000 RBX: ffff88020b0dd388 RCX: 0000000000000000
      [ 1317.270230] RDX: ffffffff8439822e RSI: 00000000000c000a RDI: 0000000000000286
      [ 1317.270230] RBP: ffff8803cd31be38 R08: 0000000000000000 R09: 0000000000000000
      [ 1317.270230] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
      [ 1317.270230] R13: 0000000054086700 R14: 0000000000a25de0 R15: 0000000000000031
      [ 1317.270230] FS:  00007ff40251d700(0000) GS:ffff88022e200000(0000) knlGS:000000000000
      0000
      [ 1317.270230] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [ 1317.270230] CR2: 0000000000000974 CR3: 00000003cd478000 CR4: 00000000000006e0
      [ 1317.270230] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 1317.270230] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000090602
      [ 1317.270230] Stack:
      [ 1317.270230]  0000000054086700 5408670000a25de0 5408670000000002 0000000000000000
      [ 1317.270230]  ffffffff84223542 00000000ea54c767 0000000000000000 ffffffff86d26160
      [ 1317.270230]  ffff8803cd31be68 ffffffff84223556 ffff8803cd31beb8 ffff8800c6765280
      [ 1317.270230] Call Trace:
      [ 1317.270230]  [<ffffffff84223542>] ? rds_trans_get_preferred+0x42/0xa0
      [ 1317.270230]  [<ffffffff84223556>] rds_trans_get_preferred+0x56/0xa0
      [ 1317.270230]  [<ffffffff8421c9c3>] rds_bind+0x73/0xf0
      [ 1317.270230]  [<ffffffff83e4ce62>] SYSC_bind+0x92/0xf0
      [ 1317.270230]  [<ffffffff812493f8>] ? context_tracking_user_exit+0xb8/0x1d0
      [ 1317.270230]  [<ffffffff8119313d>] ? trace_hardirqs_on+0xd/0x10
      [ 1317.270230]  [<ffffffff8107a852>] ? syscall_trace_enter+0x32/0x290
      [ 1317.270230]  [<ffffffff83e4cece>] SyS_bind+0xe/0x10
      [ 1317.270230]  [<ffffffff843a6ad0>] tracesys+0xdd/0xe2
      [ 1317.270230] Code: 00 8b 45 cc 48 8d 75 d0 48 c7 45 d8 00 00 00 00 66 c7 45 d0 02 00
      89 45 d4 48 89 df e8 78 49 76 ff 41 89 c4 85 c0 75 0c 48 8b 03 <80> b8 74 09 00 00 01 7
      4 06 41 bc 9d ff ff ff f6 05 2a b6 c2 02
      [ 1317.270230] RIP  [<ffffffff84225f52>] rds_ib_laddr_check+0x82/0x110
      [ 1317.270230]  RSP <ffff8803cd31bdf8>
      [ 1317.270230] CR2: 0000000000000974
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7918313d
    • Salva Peiró's avatar
      hamradio/yam: fix info leak in ioctl · eb2da112
      Salva Peiró authored
      [ Upstream commit 8e3fbf87 ]
      
      The yam_ioctl() code fails to initialise the cmd field
      of the struct yamdrv_ioctl_cfg. Add an explicit memset(0)
      before filling the structure to avoid the 4-byte info leak.
      Signed-off-by: default avatarSalva Peiró <speiro@ai2.upv.es>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eb2da112
    • Wenliang Fan's avatar
      drivers/net/hamradio: Integer overflow in hdlcdrv_ioctl() · b7e3762c
      Wenliang Fan authored
      [ Upstream commit e9db5c21 ]
      
      The local variable 'bi' comes from userspace. If userspace passed a
      large number to 'bi.data.calibrate', there would be an integer overflow
      in the following line:
      	s->hdlctx.calibrate = bi.data.calibrate * s->par.bitrate / 16;
      Signed-off-by: default avatarWenliang Fan <fanwlexca@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b7e3762c
    • Daniel Borkmann's avatar
      net: inet_diag: zero out uninitialized idiag_{src,dst} fields · 931a701d
      Daniel Borkmann authored
      [ Upstream commit b1aac815 ]
      
      Jakub reported while working with nlmon netlink sniffer that parts of
      the inet_diag_sockid are not initialized when r->idiag_family != AF_INET6.
      That is, fields of r->id.idiag_src[1 ... 3], r->id.idiag_dst[1 ... 3].
      
      In fact, it seems that we can leak 6 * sizeof(u32) byte of kernel [slab]
      memory through this. At least, in udp_dump_one(), we allocate a skb in ...
      
        rep = nlmsg_new(sizeof(struct inet_diag_msg) + ..., GFP_KERNEL);
      
      ... and then pass that to inet_sk_diag_fill() that puts the whole struct
      inet_diag_msg into the skb, where we only fill out r->id.idiag_src[0],
      r->id.idiag_dst[0] and leave the rest untouched:
      
        r->id.idiag_src[0] = inet->inet_rcv_saddr;
        r->id.idiag_dst[0] = inet->inet_daddr;
      
      struct inet_diag_msg embeds struct inet_diag_sockid that is correctly /
      fully filled out in IPv6 case, but for IPv4 not.
      
      So just zero them out by using plain memset (for this little amount of
      bytes it's probably not worth the extra check for idiag_family == AF_INET).
      
      Similarly, fix also other places where we fill that out.
      Reported-by: default avatarJakub Zawadzki <darkjames-ws@darkjames.pl>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      931a701d
    • Sasha Levin's avatar
      net: unix: allow bind to fail on mutex lock · c0be5de1
      Sasha Levin authored
      [ Upstream commit 37ab4fa7 ]
      
      This is similar to the set_peek_off patch where calling bind while the
      socket is stuck in unix_dgram_recvmsg() will block and cause a hung task
      spew after a while.
      
      This is also the last place that did a straightforward mutex_lock(), so
      there shouldn't be any more of these patches.
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0be5de1
    • Jason Wang's avatar
      netvsc: don't flush peers notifying work during setting mtu · 0248d4b4
      Jason Wang authored
      [ Upstream commit 50dc875f ]
      
      There's a possible deadlock if we flush the peers notifying work during setting
      mtu:
      
      [   22.991149] ======================================================
      [   22.991173] [ INFO: possible circular locking dependency detected ]
      [   22.991198] 3.10.0-54.0.1.el7.x86_64.debug #1 Not tainted
      [   22.991219] -------------------------------------------------------
      [   22.991243] ip/974 is trying to acquire lock:
      [   22.991261]  ((&(&net_device_ctx->dwork)->work)){+.+.+.}, at: [<ffffffff8108af95>] flush_work+0x5/0x2e0
      [   22.991307]
      but task is already holding lock:
      [   22.991330]  (rtnl_mutex){+.+.+.}, at: [<ffffffff81539deb>] rtnetlink_rcv+0x1b/0x40
      [   22.991367]
      which lock already depends on the new lock.
      
      [   22.991398]
      the existing dependency chain (in reverse order) is:
      [   22.991426]
      -> #1 (rtnl_mutex){+.+.+.}:
      [   22.991449]        [<ffffffff810dfdd9>] __lock_acquire+0xb19/0x1260
      [   22.991477]        [<ffffffff810e0d12>] lock_acquire+0xa2/0x1f0
      [   22.991501]        [<ffffffff81673659>] mutex_lock_nested+0x89/0x4f0
      [   22.991529]        [<ffffffff815392b7>] rtnl_lock+0x17/0x20
      [   22.991552]        [<ffffffff815230b2>] netdev_notify_peers+0x12/0x30
      [   22.991579]        [<ffffffffa0340212>] netvsc_send_garp+0x22/0x30 [hv_netvsc]
      [   22.991610]        [<ffffffff8108d251>] process_one_work+0x211/0x6e0
      [   22.991637]        [<ffffffff8108d83b>] worker_thread+0x11b/0x3a0
      [   22.991663]        [<ffffffff81095e5d>] kthread+0xed/0x100
      [   22.991686]        [<ffffffff81681c6c>] ret_from_fork+0x7c/0xb0
      [   22.991715]
      -> #0 ((&(&net_device_ctx->dwork)->work)){+.+.+.}:
      [   22.991715]        [<ffffffff810de817>] check_prevs_add+0x967/0x970
      [   22.991715]        [<ffffffff810dfdd9>] __lock_acquire+0xb19/0x1260
      [   22.991715]        [<ffffffff810e0d12>] lock_acquire+0xa2/0x1f0
      [   22.991715]        [<ffffffff8108afde>] flush_work+0x4e/0x2e0
      [   22.991715]        [<ffffffff8108e1b5>] __cancel_work_timer+0x95/0x130
      [   22.991715]        [<ffffffff8108e303>] cancel_delayed_work_sync+0x13/0x20
      [   22.991715]        [<ffffffffa03404e4>] netvsc_change_mtu+0x84/0x200 [hv_netvsc]
      [   22.991715]        [<ffffffff815233d4>] dev_set_mtu+0x34/0x80
      [   22.991715]        [<ffffffff8153bc2a>] do_setlink+0x23a/0xa00
      [   22.991715]        [<ffffffff8153d054>] rtnl_newlink+0x394/0x5e0
      [   22.991715]        [<ffffffff81539eac>] rtnetlink_rcv_msg+0x9c/0x260
      [   22.991715]        [<ffffffff8155cdd9>] netlink_rcv_skb+0xa9/0xc0
      [   22.991715]        [<ffffffff81539dfa>] rtnetlink_rcv+0x2a/0x40
      [   22.991715]        [<ffffffff8155c41d>] netlink_unicast+0xdd/0x190
      [   22.991715]        [<ffffffff8155c807>] netlink_sendmsg+0x337/0x750
      [   22.991715]        [<ffffffff8150d219>] sock_sendmsg+0x99/0xd0
      [   22.991715]        [<ffffffff8150d63e>] ___sys_sendmsg+0x39e/0x3b0
      [   22.991715]        [<ffffffff8150eba2>] __sys_sendmsg+0x42/0x80
      [   22.991715]        [<ffffffff8150ebf2>] SyS_sendmsg+0x12/0x20
      [   22.991715]        [<ffffffff81681d19>] system_call_fastpath+0x16/0x1b
      
      This is because we hold the rtnl_lock() before ndo_change_mtu() and try to flush
      the work in netvsc_change_mtu(), in the mean time, netdev_notify_peers() may be
      called from worker and also trying to hold the rtnl_lock. This will lead the
      flush won't succeed forever. Solve this by not canceling and flushing the work,
      this is safe because the transmission done by NETDEV_NOTIFY_PEERS was
      synchronized with the netif_tx_disable() called by netvsc_change_mtu().
      Reported-by: default avatarYaju Cao <yacao@redhat.com>
      Tested-by: default avatarYaju Cao <yacao@redhat.com>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Acked-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0248d4b4
    • Nat Gurumoorthy's avatar
      tg3: Initialize REG_BASE_ADDR at PCI config offset 120 to 0 · e5893b25
      Nat Gurumoorthy authored
      [ Upstream commit 388d3335 ]
      
      The new tg3 driver leaves REG_BASE_ADDR (PCI config offset 120)
      uninitialized. From power on reset this register may have garbage in it. The
      Register Base Address register defines the device local address of a
      register. The data pointed to by this location is read or written using
      the Register Data register (PCI config offset 128). When REG_BASE_ADDR has
      garbage any read or write of Register Data Register (PCI 128) will cause the
      PCI bus to lock up. The TCO watchdog will fire and bring down the system.
      Signed-off-by: default avatarNat Gurumoorthy <natg@google.com>
      Acked-by: default avatarMichael Chan <mchan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e5893b25
    • Sasha Levin's avatar
      net: unix: allow set_peek_off to fail · e387172f
      Sasha Levin authored
      [ Upstream commit 12663bfc ]
      
      unix_dgram_recvmsg() will hold the readlock of the socket until recv
      is complete.
      
      In the same time, we may try to setsockopt(SO_PEEK_OFF) which will hang until
      unix_dgram_recvmsg() will complete (which can take a while) without allowing
      us to break out of it, triggering a hung task spew.
      
      Instead, allow set_peek_off to fail, this way userspace will not hang.
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Acked-by: default avatarPavel Emelyanov <xemul@parallels.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e387172f
    • Changli Gao's avatar
      net: drop_monitor: fix the value of maxattr · fcbb1132
      Changli Gao authored
      [ Upstream commit d323e92c ]
      
      maxattr in genl_family should be used to save the max attribute
      type, but not the max command type. Drop monitor doesn't support
      any attributes, so we should leave it as zero.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fcbb1132
    • Hannes Frederic Sowa's avatar
      ipv6: don't count addrconf generated routes against gc limit · 30e65cd5
      Hannes Frederic Sowa authored
      [ Upstream commit a3300ef4 ]
      
      Brett Ciphery reported that new ipv6 addresses failed to get installed
      because the addrconf generated dsts where counted against the dst gc
      limit. We don't need to count those routes like we currently don't count
      administratively added routes.
      
      Because the max_addresses check enforces a limit on unbounded address
      generation first in case someone plays with router advertisments, we
      are still safe here.
      Reported-by: default avatarBrett Ciphery <brett.ciphery@windriver.com>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      30e65cd5
    • Jason Wang's avatar
      macvtap: signal truncated packets · ae8d56de
      Jason Wang authored
      [ Upstream commit ce232ce0 ]
      
      macvtap_put_user() never return a value grater than iov length, this in fact
      bypasses the truncated checking in macvtap_recvmsg(). Fix this by always
      returning the size of packet plus the possible vlan header to let the trunca
      checking work.
      
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Cc: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ae8d56de
    • Zhi Yong Wu's avatar
      tun: update file current position · 693d5d27
      Zhi Yong Wu authored
      [ Upstream commit d0b7da8a ]
      Signed-off-by: default avatarZhi Yong Wu <wuzhy@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      693d5d27
    • Zhi Yong Wu's avatar
      macvtap: update file current position · d717ca46
      Zhi Yong Wu authored
      [ Upstream commit e6ebc7f1 ]
      Signed-off-by: default avatarZhi Yong Wu <wuzhy@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d717ca46
    • Vlad Yasevich's avatar
      macvtap: Do not double-count received packets · b4c3eac4
      Vlad Yasevich authored
      [ Upstream commit 006da7b0 ]
      
      Currently macvlan will count received packets after calling each
      vlans receive handler.   Macvtap attempts to count the packet
      yet again when the user reads the packet from the tap socket.
      This code doesn't do this consistently either.  Remove the
      counting from macvtap and let only macvlan count received
      packets.
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b4c3eac4
    • Venkat Venkatsubra's avatar
      rds: prevent BUG_ON triggered on congestion update to loopback · 468c82ca
      Venkat Venkatsubra authored
      [ Upstream commit 18fc25c9 ]
      
      After congestion update on a local connection, when rds_ib_xmit returns
      less bytes than that are there in the message, rds_send_xmit calls
      back rds_ib_xmit with an offset that causes BUG_ON(off & RDS_FRAG_SIZE)
      to trigger.
      
      For a 4Kb PAGE_SIZE rds_ib_xmit returns min(8240,4096)=4096 when actually
      the message contains 8240 bytes. rds_send_xmit thinks there is more to send
      and calls rds_ib_xmit again with a data offset "off" of 4096-48(rds header)
      =4048 bytes thus hitting the BUG_ON(off & RDS_FRAG_SIZE) [RDS_FRAG_SIZE=4k].
      
      The commit 6094628b
      "rds: prevent BUG_ON triggering on congestion map updates" introduced
      this regression. That change was addressing the triggering of a different
      BUG_ON in rds_send_xmit() on PowerPC architecture with 64Kbytes PAGE_SIZE:
       	BUG_ON(ret != 0 &&
          		 conn->c_xmit_sg == rm->data.op_nents);
      This was the sequence it was going through:
      (rds_ib_xmit)
      /* Do not send cong updates to IB loopback */
      if (conn->c_loopback
         && rm->m_inc.i_hdr.h_flags & RDS_FLAG_CONG_BITMAP) {
        	rds_cong_map_updated(conn->c_fcong, ~(u64) 0);
          	return sizeof(struct rds_header) + RDS_CONG_MAP_BYTES;
      }
      rds_ib_xmit returns 8240
      rds_send_xmit:
        c_xmit_data_off = 0 + 8240 - 48 (rds header accounted only the first time)
         		 = 8192
        c_xmit_data_off < 65536 (sg->length), so calls rds_ib_xmit again
      rds_ib_xmit returns 8240
      rds_send_xmit:
        c_xmit_data_off = 8192 + 8240 = 16432, calls rds_ib_xmit again
        and so on (c_xmit_data_off 24672,32912,41152,49392,57632)
      rds_ib_xmit returns 8240
      On this iteration this sequence causes the BUG_ON in rds_send_xmit:
          while (ret) {
          	tmp = min_t(int, ret, sg->length - conn->c_xmit_data_off);
          	[tmp = 65536 - 57632 = 7904]
          	conn->c_xmit_data_off += tmp;
          	[c_xmit_data_off = 57632 + 7904 = 65536]
          	ret -= tmp;
          	[ret = 8240 - 7904 = 336]
          	if (conn->c_xmit_data_off == sg->length) {
          		conn->c_xmit_data_off = 0;
          		sg++;
          		conn->c_xmit_sg++;
          		BUG_ON(ret != 0 &&
          			conn->c_xmit_sg == rm->data.op_nents);
          		[c_xmit_sg = 1, rm->data.op_nents = 1]
      
      What the current fix does:
      Since the congestion update over loopback is not actually transmitted
      as a message, all that rds_ib_xmit needs to do is let the caller think
      the full message has been transmitted and not return partial bytes.
      It will return 8240 (RDS_CONG_MAP_BYTES+48) when PAGE_SIZE is 4Kb.
      And 64Kb+48 when page size is 64Kb.
      Reported-by: default avatarJosh Hunt <joshhunt00@gmail.com>
      Tested-by: default avatarHonggang Li <honli@redhat.com>
      Acked-by: default avatarBang Nguyen <bang.nguyen@oracle.com>
      Signed-off-by: default avatarVenkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      468c82ca
    • Eric Dumazet's avatar
      net: do not pretend FRAGLIST support · acd4b2b8
      Eric Dumazet authored
      [ Upstream commit 28e24c62 ]
      
      Few network drivers really supports frag_list : virtual drivers.
      
      Some drivers wrongly advertise NETIF_F_FRAGLIST feature.
      
      If skb with a frag_list is given to them, packet on the wire will be
      corrupt.
      
      Remove this flag, as core networking stack will make sure to
      provide packets that can be sent without corruption.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Cc: Anirudha Sarangi <anirudh@xilinx.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      acd4b2b8
  2. 08 Jan, 2014 17 commits