1. 02 Dec, 2013 6 commits
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 5fc92de3
      Linus Torvalds authored
      Pull networking updates from David Miller:
       "Here is a pile of bug fixes that accumulated while I was in Europe"
      
       1) In fixing kernel leaks to userspace during copying of socket
          addresses, we broke a case that used to work, namely the user
          providing a buffer larger than the in-kernel generic socket address
          structure.  This broke Ruby amongst other things.  Fix from Dan
          Carpenter.
      
       2) Fix regression added by byte queue limit support in 8139cp driver,
          from Yang Yingliang.
      
       3) The addition of MSG_SENDPAGE_NOTLAST buggered up a few sendpage
          implementations, they should just treat it the same as MSG_MORE.
          Fix from Richard Weinberger and Shawn Landden.
      
       4) Handle icmpv4 errors received on ipv6 SIT tunnels correctly, from
          Oussama Ghorbel.  In particular we should send an ICMPv6 unreachable
          in such situations.
      
       5) Fix some regressions in the recent genetlink fixes, in particular
          get the pmcraid driver to use the new safer interfaces correctly.
          From Johannes Berg.
      
       6) macvtap was converted to use a per-cpu set of statistics, but some
          code was still bumping tx_dropped elsewhere.  From Jason Wang.
      
       7) Fix build failure of xen-netback due to missing include on some
          architectures, from Andy Whitecroft.
      
       8) macvtap double counts received packets in statistics, fix from Vlad
          Yasevich.
      
       9) Fix various cases of using *_STATS_BH() when *_STATS() is more
          appropriate.  From Eric Dumazet and Hannes Frederic Sowa.
      
      10) Pktgen ipsec mode doesn't update the ipv4 header length and checksum
          properly after encapsulation.  Fix from Fan Du.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (61 commits)
        net/mlx4_en: Remove selftest TX queues empty condition
        {pktgen, xfrm} Update IPv4 header total len and checksum after tranformation
        virtio_net: make all RX paths handle erors consistently
        virtio_net: fix error handling for mergeable buffers
        virtio_net: Fixed a trivial typo (fitler --> filter)
        netem: fix gemodel loss generator
        netem: fix loss 4 state model
        netem: missing break in ge loss generator
        net/hsr: Support iproute print_opt ('ip -details ...')
        net/hsr: Very small fix of comment style.
        MAINTAINERS: Added net/hsr/ maintainer
        ipv6: fix possible seqlock deadlock in ip6_finish_output2
        ixgbe: Make ixgbe_identify_qsfp_module_generic static
        ixgbe: turn NETIF_F_HW_L2FW_DOFFLOAD off by default
        ixgbe: ixgbe_fwd_ring_down needs to be static
        e1000: fix possible reset_task running after adapter down
        e1000: fix lockdep warning in e1000_reset_task
        e1000: prevent oops when adapter is being closed and reset simultaneously
        igb: Fixed Wake On LAN support
        inet: fix possible seqlock deadlocks
        ...
      5fc92de3
    • Linus Torvalds's avatar
      vfs: fix subtle use-after-free of pipe_inode_info · b0d8d229
      Linus Torvalds authored
      The pipe code was trying (and failing) to be very careful about freeing
      the pipe info only after the last access, with a pattern like:
      
              spin_lock(&inode->i_lock);
              if (!--pipe->files) {
                      inode->i_pipe = NULL;
                      kill = 1;
              }
              spin_unlock(&inode->i_lock);
              __pipe_unlock(pipe);
              if (kill)
                      free_pipe_info(pipe);
      
      where the final freeing is done last.
      
      HOWEVER.  The above is actually broken, because while the freeing is
      done at the end, if we have two racing processes releasing the pipe
      inode info, the one that *doesn't* free it will decrement the ->files
      count, and unlock the inode i_lock, but then still use the
      "pipe_inode_info" afterwards when it does the "__pipe_unlock(pipe)".
      
      This is *very* hard to trigger in practice, since the race window is
      very small, and adding debug options seems to just hide it by slowing
      things down.
      
      Simon originally reported this way back in July as an Oops in
      kmem_cache_allocate due to a single bit corruption (due to the final
      "spin_unlock(pipe->mutex.wait_lock)" incrementing a field in a different
      allocation that had re-used the free'd pipe-info), it's taken this long
      to figure out.
      
      Since the 'pipe->files' accesses aren't even protected by the pipe lock
      (we very much use the inode lock for that), the simple solution is to
      just drop the pipe lock early.  And since there were two users of this
      pattern, create a helper function for it.
      
      Introduced commit ba5bb147 ("pipe: take allocation and freeing of
      pipe_inode_info out of ->i_mutex").
      Reported-by: default avatarSimon Kirby <sim@hostway.ca>
      Reported-by: default avatarIan Applegate <ia@cloudflare.com>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: stable@kernel.org   # v3.10+
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b0d8d229
    • Eugenia Emantayev's avatar
      net/mlx4_en: Remove selftest TX queues empty condition · 833846e8
      Eugenia Emantayev authored
      Remove waiting for TX queues to become empty during selftest.
      This check is not necessary for any purpose, and might put
      the driver into an infinite loop.
      Signed-off-by: default avatarEugenia Emantayev <eugenia@mellanox.com>
      Signed-off-by: default avatarAmir Vadai <amirv@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      833846e8
    • fan.du's avatar
      {pktgen, xfrm} Update IPv4 header total len and checksum after tranformation · 3868204d
      fan.du authored
      commit a553e4a6 ("[PKTGEN]: IPSEC support")
      tried to support IPsec ESP transport transformation for pktgen, but acctually
      this doesn't work at all for two reasons(The orignal transformed packet has
      bad IPv4 checksum value, as well as wrong auth value, reported by wireshark)
      
      - After transpormation, IPv4 header total length needs update,
        because encrypted payload's length is NOT same as that of plain text.
      
      - After transformation, IPv4 checksum needs re-caculate because of payload
        has been changed.
      
      With this patch, armmed pktgen with below cofiguration, Wireshark is able to
      decrypted ESP packet generated by pktgen without any IPv4 checksum error or
      auth value error.
      
      pgset "flag IPSEC"
      pgset "flows 1"
      Signed-off-by: default avatarFan Du <fan.du@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3868204d
    • Michael S. Tsirkin's avatar
      virtio_net: make all RX paths handle erors consistently · f121159d
      Michael S. Tsirkin authored
      receive mergeable now handles errors internally.
      Do same for big and small packet paths, otherwise
      the logic is too hard to follow.
      Signed-off-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>
      f121159d
    • Michael S. Tsirkin's avatar
      virtio_net: fix error handling for mergeable buffers · 8fc3b9e9
      Michael S. Tsirkin authored
      Eric Dumazet noticed that if we encounter an error
      when processing a mergeable buffer, we don't
      dequeue all of the buffers from this packet,
      the result is almost sure to be loss of networking.
      
      Jason Wang noticed that we also leak a page and that we don't decrement
      the rq buf count, so we won't repost buffers (a resource leak).
      
      Fix both issues.
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Michael Dalton <mwdalton@google.com>
      Reported-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-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>
      8fc3b9e9
  2. 01 Dec, 2013 4 commits
  3. 30 Nov, 2013 24 commits
    • Fabio Estevam's avatar
      ARM: 7907/1: lib: delay-loop: Add align directive to fix BogoMIPS calculation · 11d4bb1b
      Fabio Estevam authored
      Currently mx53 (CortexA8) running at 1GHz reports:
      Calibrating delay loop... 663.55 BogoMIPS (lpj=3317760)
      
      Tom Evans verified that alignments of 0x0 and 0x8 run the two instructions of __loop_delay in one clock cycle (1 clock/loop), while alignments of 0x4 and 0xc take 3 clocks to run the loop twice. (1.5 clock/loop)
      
      The original object code looks like this:
      
      00000010 <__loop_const_udelay>:
        10:	e3e01000 	mvn	r1, #0
        14:	e51f201c 	ldr	r2, [pc, #-28]	; 0 <__loop_udelay-0x8>
        18:	e5922000 	ldr	r2, [r2]
        1c:	e0800921 	add	r0, r0, r1, lsr #18
        20:	e1a00720 	lsr	r0, r0, #14
        24:	e0822b21 	add	r2, r2, r1, lsr #22
        28:	e1a02522 	lsr	r2, r2, #10
        2c:	e0000092 	mul	r0, r2, r0
        30:	e0800d21 	add	r0, r0, r1, lsr #26
        34:	e1b00320 	lsrs	r0, r0, #6
        38:	01a0f00e 	moveq	pc, lr
      
      0000003c <__loop_delay>:
        3c:	e2500001 	subs	r0, r0, #1
        40:	8afffffe 	bhi	3c <__loop_delay>
        44:	e1a0f00e 	mov	pc, lr
      
      After adding the 'align 3' directive to __loop_delay (align to 8 bytes):
      
      00000010 <__loop_const_udelay>:
        10:	e3e01000 	mvn	r1, #0
        14:	e51f201c 	ldr	r2, [pc, #-28]	; 0 <__loop_udelay-0x8>
        18:	e5922000 	ldr	r2, [r2]
        1c:	e0800921 	add	r0, r0, r1, lsr #18
        20:	e1a00720 	lsr	r0, r0, #14
        24:	e0822b21 	add	r2, r2, r1, lsr #22
        28:	e1a02522 	lsr	r2, r2, #10
        2c:	e0000092 	mul	r0, r2, r0
        30:	e0800d21 	add	r0, r0, r1, lsr #26
        34:	e1b00320 	lsrs	r0, r0, #6
        38:	01a0f00e 	moveq	pc, lr
        3c:	e320f000 	nop	{0}
      
      00000040 <__loop_delay>:
        40:	e2500001 	subs	r0, r0, #1
        44:	8afffffe 	bhi	40 <__loop_delay>
        48:	e1a0f00e 	mov	pc, lr
        4c:	e320f000 	nop	{0}
      
      , which now reports:
      Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)
      
      Some more test results:
      
      On mx31 (ARM1136) running at 532 MHz, before the patch:
      Calibrating delay loop... 351.43 BogoMIPS (lpj=1757184)
      
      On mx31 (ARM1136) running at 532 MHz after the patch:
      Calibrating delay loop... 528.79 BogoMIPS (lpj=2643968)
      
      Also tested on mx6 (CortexA9) and on mx27 (ARM926), which shows the same
      BogoMIPS value before and after this patch.
      Reported-by: default avatarTom Evans <tom_usenet@optusnet.com.au>
      Suggested-by: default avatarTom Evans <tom_usenet@optusnet.com.au>
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      11d4bb1b
    • Dave Martin's avatar
      ARM: 7897/1: kexec: Use the right ISA for relocate_new_kernel · e2ccba49
      Dave Martin authored
      Copying a function with memcpy() and then trying to execute the
      result isn't trivially portable to Thumb.
      
      This patch modifies the kexec soft restart code to copy its
      assembler trampoline relocate_new_kernel() using fncpy() instead,
      so that relocate_new_kernel can be in the same ISA as the rest of
      the kernel without problems.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Reported-by: default avatarTaras Kondratiuk <taras.kondratiuk@linaro.org>
      Tested-by: default avatarTaras Kondratiuk <taras.kondratiuk@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      e2ccba49
    • Victor Kamensky's avatar
      ARM: 7895/1: signal: fix armv7-m build issue in sigreturn_codes.S · 50913336
      Victor Kamensky authored
      After "ARM: signal: sigreturn_codes should be endian neutral to
      work in BE8" commit, thumb only platforms, like armv7m, fails to
      compile sigreturn_codes.S. The reason is that for such arch
      values '.arm' directive and arm opcodes are not allowed.
      
      Fix conditionally enables arm opcodes only if no CONFIG_CPU_THUMBONLY
      defined and it uses .org instructions to keep sigreturn_codes
      layout.
      Suggested-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarVictor Kamensky <victor.kamensky@linaro.org>
      Tested-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Reviewed-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      50913336
    • Russell King's avatar
      ARM: footbridge: fix EBSA285 LEDs · 67130c54
      Russell King authored
      - The LEDs register is write-only: it can't be read-modify-written.
      - The LEDs are write-1-for-off not 0.
      - The check for the platform was inverted.
      
      Fixes: cf6856d6 ("ARM: mach-footbridge: retire custom LED code")
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: stable@vger.kernel.org
      67130c54
    • Thomas Huth's avatar
      virtio_net: Fixed a trivial typo (fitler --> filter) · 99e872ae
      Thomas Huth authored
      "MAC filter" sounds more reasonable than "MAC fitler".
      Signed-off-by: default avatarThomas Huth <thuth@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      99e872ae
    • stephen hemminger's avatar
      netem: fix gemodel loss generator · eff7979f
      stephen hemminger authored
      Patch from developers of the alternative loss models, downloaded from:
         http://netgroup.uniroma2.it/twiki/bin/view.cgi/Main/NetemCLG
      
       "in case 2, of the switch we change the direction of the inequality to
        net_random()>clg->a3, because clg->a3 is h in the GE model and when h
        is 0 all packets will be lost."
      Signed-off-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eff7979f
    • stephen hemminger's avatar
      netem: fix loss 4 state model · ab6c27be
      stephen hemminger authored
      Patch from developers of the alternative loss models, downloaded from:
         http://netgroup.uniroma2.it/twiki/bin/view.cgi/Main/NetemCLG
      
       "In the case 1 of the switch statement in the if conditions we
         need to add clg->a4 to clg->a1, according to the model."
      Signed-off-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ab6c27be
    • stephen hemminger's avatar
      netem: missing break in ge loss generator · 7c2781fa
      stephen hemminger authored
      There is a missing break statement in the Gilbert Elliot loss model
      generator which makes state machine behave incorrectly.
      
      Reported-by: Martin Burri <martin.burri@ch.abb.com
      Signed-off-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7c2781fa
    • Arvid Brodin's avatar
      net/hsr: Support iproute print_opt ('ip -details ...') · 98bf8362
      Arvid Brodin authored
      This implements the rtnl_link_ops fill_info routine for HSR.
      Signed-off-by: default avatarArvid Brodin <arvid.brodin@alten.se>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      98bf8362
    • Arvid Brodin's avatar
      213e3bc7
    • Arvid Brodin's avatar
      19990e29
    • Hannes Frederic Sowa's avatar
      ipv6: fix possible seqlock deadlock in ip6_finish_output2 · 7f88c6b2
      Hannes Frederic Sowa authored
      IPv6 stats are 64 bits and thus are protected with a seqlock. By not
      disabling bottom-half we could deadlock here if we don't disable bh and
      a softirq reentrantly updates the same mib.
      
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f88c6b2
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net · 696701b8
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      Intel Wired LAN Driver Updates
      
      This series contains updates to igb, e1000 and ixgbe.
      
      Akeem provides a igb fix where WOL was being reported as supported on
      some ethernet devices which did not have that capability.
      
      Yanjun provides a fix for e1000 which is similar to a previous fix
      for e1000e commit bb9e44d0 ("e1000e: prevent oops when adapter is
      being closed and reset simultaneously"), where the same issue was
      observed on the older e1000 cards.
      
      Vladimir Davydov provides 2 e1000 fixes.  The first fixes a lockdep
      warning e1000_down() tries to synchronously cancel e1000 auxiliary
      works (reset_task, watchdog_task, phy_info_task and fifo_stall_task)
      which take adapter->mutex in their handlers.  The second patch is to
      fix a possible race condition where reset_task() would be running
      after adapter down.
      
      John provides 2 fixes for ixgbe.  First turns ixgbe_fwd_ring_down
      to static and the second disables NETIF_F_HW_L2FW_DOFFLOAD by default
      because it allows upper layer net devices to use queues in the hardware
      to directly submit and receive skbs.
      
      Mark Rustad provides a single patch for ixgbe to make
      ixgbe_identify_qsfp_module_generic static to resolve compile
      warnings.
      
      v2: Drop igb patch "igb: Update queue reinit function to call dev_close
          when init of queues fails" from Carolyn, so that the solution can
          be re-worked based on feedback from David Miller.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      696701b8
    • Russell King's avatar
      ARM: footbridge: fix VGA initialisation · 43659222
      Russell King authored
      It's no good setting vga_base after the VGA console has been
      initialised, because if we do that we get this:
      
      Unable to handle kernel paging request at virtual address 000b8000
      pgd = c0004000
      [000b8000] *pgd=07ffc831, *pte=00000000, *ppte=00000000
      0Internal error: Oops: 5017 [#1] ARM
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0+ #49
      task: c03e2974 ti: c03d8000 task.ti: c03d8000
      PC is at vgacon_startup+0x258/0x39c
      LR is at request_resource+0x10/0x1c
      pc : [<c01725d0>]    lr : [<c0022b50>]    psr: 60000053
      sp : c03d9f68  ip : 000b8000  fp : c03d9f8c
      r10: 000055aa  r9 : 4401a103  r8 : ffffaa55
      r7 : c03e357c  r6 : c051b460  r5 : 000000ff  r4 : 000c0000
      r3 : 000b8000  r2 : c03e0514  r1 : 00000000  r0 : c0304971
      Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
      
      which is an access to the 0xb8000 without the PCI offset required to
      make it work.
      
      Fixes: cc22b4c1 ("ARM: set vga memory base at run-time")
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: <stable@vger.kernel.org>
      43659222
    • Russell King's avatar
      ARM: fix booting low-vectors machines · d8aa712c
      Russell King authored
      Commit f6f91b0d (ARM: allow kuser helpers to be removed from the
      vector page) required two pages for the vectors code.  Although the
      code setting up the initial page tables was updated, the code which
      allocates page tables for new processes wasn't, neither was the code
      which tears down the mappings.  Fix this.
      
      Fixes: f6f91b0d ("ARM: allow kuser helpers to be removed from the vector page")
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: <stable@vger.kernel.org>
      d8aa712c
    • Russell King's avatar
      ARM: dma-mapping: check DMA mask against available memory · 11a5aa32
      Russell King authored
      Some buses have negative offsets, which causes the DMA mask checks to
      falsely fail.  Fix this by using the actual amount of memory fitted in
      the system.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      11a5aa32
    • Mark Rustad's avatar
      ixgbe: Make ixgbe_identify_qsfp_module_generic static · 88217547
      Mark Rustad authored
      Correct a namespace complaint by making the function static
      and moving the prototype into the .c file.
      Signed-off-by: default avatarMark Rustad <mark.d.rustad@intel.com>
      Tested-by: default avatarPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      88217547
    • John Fastabend's avatar
      ixgbe: turn NETIF_F_HW_L2FW_DOFFLOAD off by default · 8bf1264d
      John Fastabend authored
      NETIF_F_HW_L2FW_DOFFLOAD allows upper layer net devices such
      as macvlan to use queues in the hardware to directly submit and
      receive skbs.
      
      This creates a subtle change in the datapath though. One change
      being the skb may no longer use the root devices qdisc.
      
      Because users may not expect this we can't enable the feature
      by default unless the hardware can offload all the software
      functionality above it. So for now disable it by default and
      let users opt in.
      Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: default avatarPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      8bf1264d
    • John Fastabend's avatar
      ixgbe: ixgbe_fwd_ring_down needs to be static · ae72c8d0
      John Fastabend authored
      When compiling with -Wstrict-prototypes gcc catches a static
      I missed.
      
      ./ixgbe_main.c:4254: warning: no previous prototype for 'ixgbe_fwd_ring_down'
      Reported-by: default avatarPhillip Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: default avatarPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      ae72c8d0
    • Vladimir Davydov's avatar
      e1000: fix possible reset_task running after adapter down · 74a1b1ea
      Vladimir Davydov authored
      On e1000_down(), we should ensure every asynchronous work is canceled
      before proceeding. Since the watchdog_task can schedule other works
      apart from itself, it should be stopped first, but currently it is
      stopped after the reset_task. This can result in the following race
      leading to the reset_task running after the module unload:
      
      e1000_down_and_stop():			e1000_watchdog():
      ----------------------			-----------------
      
      cancel_work_sync(reset_task)
      					schedule_work(reset_task)
      cancel_delayed_work_sync(watchdog_task)
      
      The patch moves cancel_delayed_work_sync(watchdog_task) at the beginning
      of e1000_down_and_stop() thus ensuring the race is impossible.
      
      Cc: Tushar Dave <tushar.n.dave@intel.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarVladimir Davydov <vdavydov@parallels.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      74a1b1ea
    • Vladimir Davydov's avatar
      e1000: fix lockdep warning in e1000_reset_task · b2f963bf
      Vladimir Davydov authored
      The patch fixes the following lockdep warning, which is 100%
      reproducible on network restart:
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.12.0+ #47 Tainted: GF
      -------------------------------------------------------
      kworker/1:1/27 is trying to acquire lock:
       ((&(&adapter->watchdog_task)->work)){+.+...}, at: [<ffffffff8108a5b0>] flush_work+0x0/0x70
      
      but task is already holding lock:
       (&adapter->mutex){+.+...}, at: [<ffffffffa0177c0a>] e1000_reset_task+0x4a/0xa0 [e1000]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&adapter->mutex){+.+...}:
             [<ffffffff810bdb5d>] lock_acquire+0x9d/0x120
             [<ffffffff816b8cbc>] mutex_lock_nested+0x4c/0x390
             [<ffffffffa017233d>] e1000_watchdog+0x7d/0x5b0 [e1000]
             [<ffffffff8108b972>] process_one_work+0x1d2/0x510
             [<ffffffff8108ca80>] worker_thread+0x120/0x3a0
             [<ffffffff81092c1e>] kthread+0xee/0x110
             [<ffffffff816c3d7c>] ret_from_fork+0x7c/0xb0
      
      -> #0 ((&(&adapter->watchdog_task)->work)){+.+...}:
             [<ffffffff810bd9c0>] __lock_acquire+0x1710/0x1810
             [<ffffffff810bdb5d>] lock_acquire+0x9d/0x120
             [<ffffffff8108a5eb>] flush_work+0x3b/0x70
             [<ffffffff8108b5d8>] __cancel_work_timer+0x98/0x140
             [<ffffffff8108b693>] cancel_delayed_work_sync+0x13/0x20
             [<ffffffffa0170cec>] e1000_down_and_stop+0x3c/0x60 [e1000]
             [<ffffffffa01775b1>] e1000_down+0x131/0x220 [e1000]
             [<ffffffffa0177c12>] e1000_reset_task+0x52/0xa0 [e1000]
             [<ffffffff8108b972>] process_one_work+0x1d2/0x510
             [<ffffffff8108ca80>] worker_thread+0x120/0x3a0
             [<ffffffff81092c1e>] kthread+0xee/0x110
             [<ffffffff816c3d7c>] ret_from_fork+0x7c/0xb0
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&adapter->mutex);
                                     lock((&(&adapter->watchdog_task)->work));
                                     lock(&adapter->mutex);
        lock((&(&adapter->watchdog_task)->work));
      
       *** DEADLOCK ***
      
      3 locks held by kworker/1:1/27:
       #0:  (events){.+.+.+}, at: [<ffffffff8108b906>] process_one_work+0x166/0x510
       #1:  ((&adapter->reset_task)){+.+...}, at: [<ffffffff8108b906>] process_one_work+0x166/0x510
       #2:  (&adapter->mutex){+.+...}, at: [<ffffffffa0177c0a>] e1000_reset_task+0x4a/0xa0 [e1000]
      
      stack backtrace:
      CPU: 1 PID: 27 Comm: kworker/1:1 Tainted: GF            3.12.0+ #47
      Hardware name: System manufacturer System Product Name/P5B-VM SE, BIOS 0501    05/31/2007
      Workqueue: events e1000_reset_task [e1000]
       ffffffff820f6000 ffff88007b9dba98 ffffffff816b54a2 0000000000000002
       ffffffff820f5e50 ffff88007b9dbae8 ffffffff810ba936 ffff88007b9dbac8
       ffff88007b9dbb48 ffff88007b9d8f00 ffff88007b9d8780 ffff88007b9d8f00
      Call Trace:
       [<ffffffff816b54a2>] dump_stack+0x49/0x5f
       [<ffffffff810ba936>] print_circular_bug+0x216/0x310
       [<ffffffff810bd9c0>] __lock_acquire+0x1710/0x1810
       [<ffffffff8108a5b0>] ? __flush_work+0x250/0x250
       [<ffffffff810bdb5d>] lock_acquire+0x9d/0x120
       [<ffffffff8108a5b0>] ? __flush_work+0x250/0x250
       [<ffffffff8108a5eb>] flush_work+0x3b/0x70
       [<ffffffff8108a5b0>] ? __flush_work+0x250/0x250
       [<ffffffff8108b5d8>] __cancel_work_timer+0x98/0x140
       [<ffffffff8108b693>] cancel_delayed_work_sync+0x13/0x20
       [<ffffffffa0170cec>] e1000_down_and_stop+0x3c/0x60 [e1000]
       [<ffffffffa01775b1>] e1000_down+0x131/0x220 [e1000]
       [<ffffffffa0177c12>] e1000_reset_task+0x52/0xa0 [e1000]
       [<ffffffff8108b972>] process_one_work+0x1d2/0x510
       [<ffffffff8108b906>] ? process_one_work+0x166/0x510
       [<ffffffff8108ca80>] worker_thread+0x120/0x3a0
       [<ffffffff8108c960>] ? manage_workers+0x2c0/0x2c0
       [<ffffffff81092c1e>] kthread+0xee/0x110
       [<ffffffff81092b30>] ? __init_kthread_worker+0x70/0x70
       [<ffffffff816c3d7c>] ret_from_fork+0x7c/0xb0
       [<ffffffff81092b30>] ? __init_kthread_worker+0x70/0x70
      
      == The issue background ==
      
      The problem occurs, because e1000_down(), which is called under
      adapter->mutex by e1000_reset_task(), tries to synchronously cancel
      e1000 auxiliary works (reset_task, watchdog_task, phy_info_task,
      fifo_stall_task), which take adapter->mutex in their handlers. So the
      question is what does adapter->mutex protect there?
      
      The adapter->mutex was introduced by commit 0ef4ee ("e1000: convert to
      private mutex from rtnl") as a replacement for rtnl_lock() taken in the
      asynchronous handlers. It targeted on fixing a similar lockdep warning
      issued when e1000_down() was called under rtnl_lock(), and it fixed it,
      but unfortunately it introduced the lockdep warning described above.
      Anyway, that said the source of this bug is that the asynchronous works
      were made to take rtnl_lock() some time ago, so let's look deeper and
      find why it was added there.
      
      The rtnl_lock() was added to asynchronous handlers by commit 338c15
      ("e1000: fix occasional panic on unload") in order to prevent
      asynchronous handlers from execution after the module is unloaded
      (e1000_down() is called) as it follows from the comment to the commit:
      
      > Net drivers in general have an issue where timers fired
      > by mod_timer or work threads with schedule_work are running
      > outside of the rtnl_lock.
      >
      > With no other lock protection these routines are vulnerable
      > to races with driver unload or reset paths.
      >
      > The longer term solution to this might be a redesign with
      > safer locks being taken in the driver to guarantee no
      > reentrance, but for now a safe and effective fix is
      > to take the rtnl_lock in these routines.
      
      I'm not sure if this locking scheme fixed the problem or just made it
      unlikely, although I incline to the latter. Anyway, this was long time
      ago when e1000 auxiliary works were implemented as timers scheduling
      real work handlers in their routines. The e1000_down() function only
      canceled the timers, but left the real handlers running if they were
      running, which could result in work execution after module unload.
      Today, the e1000 driver uses sane delayed works instead of the pair
      timer+work to implement its delayed asynchronous handlers, and the
      e1000_down() synchronously cancels all the works so that the problem
      that commit 338c15 tried to cope with disappeared, and we don't need any
      locks in the handlers any more. Moreover, any locking there can
      potentially result in a deadlock.
      
      So, this patch reverts commits 0ef4ee and 338c15.
      
      Fixes: 0ef4eedc ("e1000: convert to private mutex from rtnl")
      Fixes: 338c15e4 ("e1000: fix occasional panic on unload")
      Cc: Tushar Dave <tushar.n.dave@intel.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarVladimir Davydov <vdavydov@parallels.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      b2f963bf
    • yzhu1's avatar
      e1000: prevent oops when adapter is being closed and reset simultaneously · 6a7d64e3
      yzhu1 authored
      This change is based on a similar change made to e1000e support in
      commit bb9e44d0 ("e1000e: prevent oops when adapter is being closed
      and reset simultaneously").  The same issue has also been observed
      on the older e1000 cards.
      
      Here, we have increased the RESET_COUNT value to 50 because there are too
      many accesses to e1000 nic on stress tests to e1000 nic, it is not enough
      to set RESET_COUT 25. Experimentation has shown that it is enough to set
      RESET_COUNT 50.
      Signed-off-by: default avataryzhu1 <yanjun.zhu@windriver.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      6a7d64e3
    • Akeem G Abodunrin's avatar
      igb: Fixed Wake On LAN support · 42ce4126
      Akeem G Abodunrin authored
      This patch fixes Wake on LAN being reported as supported on some Ethernet
      ports, in contrary to Hardware capability.
      Signed-off-by: default avatarAkeem G Abodunrin <akeem.g.abodunrin@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      42ce4126
    • Roberto Sassu's avatar
      ima: store address of template_fmt_copy in a pointer before calling strsep · af91706d
      Roberto Sassu authored
      This patch stores the address of the 'template_fmt_copy' variable in a new
      variable, called 'template_fmt_ptr', so that the latter is passed as an
      argument of strsep() instead of the former. This modification is needed
      in order to correctly free the memory area referenced by
      'template_fmt_copy' (strsep() modifies the pointer of the passed string).
      Signed-off-by: default avatarRoberto Sassu <roberto.sassu@polito.it>
      Reported-by: default avatarSebastian Ott <sebott@linux.vnet.ibm.com>
      Signed-off-by: default avatarMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      af91706d
  4. 29 Nov, 2013 6 commits
    • Eric Dumazet's avatar
      inet: fix possible seqlock deadlocks · f1d8cba6
      Eric Dumazet authored
      In commit c9e90429 ("ipv4: fix possible seqlock deadlock") I left
      another places where IP_INC_STATS_BH() were improperly used.
      
      udp_sendmsg(), ping_v4_sendmsg() and tcp_v4_connect() are called from
      process context, not from softirq context.
      
      This was detected by lockdep seqlock support.
      Reported-by: default avatarjongman heo <jongman.heo@samsung.com>
      Fixes: 584bdf8c ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP")
      Fixes: c319b4d7 ("net: ipv4: add IPPROTO_ICMP socket kind")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1d8cba6
    • Jiri Pirko's avatar
      team: fix master carrier set when user linkup is enabled · f5e0d343
      Jiri Pirko authored
      When user linkup is enabled and user sets linkup of individual port,
      we need to recompute linkup (carrier) of master interface so the change
      is reflected. Fix this by calling __team_carrier_check() which does the
      needed work.
      
      Please apply to all stable kernels as well. Thanks.
      Reported-by: default avatarJan Tluka <jtluka@redhat.com>
      Signed-off-by: default avatarJiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f5e0d343
    • Shawn Landden's avatar
      net: update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST · d3f7d56a
      Shawn Landden authored
      Commit 35f9c09f (tcp: tcp_sendpages() should call tcp_push() once)
      added an internal flag MSG_SENDPAGE_NOTLAST, similar to
      MSG_MORE.
      
      algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages()
      and need to see the new flag as identical to MSG_MORE.
      
      This fixes sendfile() on AF_ALG.
      
      v3: also fix udp
      
      Cc: Tom Herbert <therbert@google.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: <stable@vger.kernel.org> # 3.4.x + 3.2.x
      Reported-and-tested-by: default avatarShawn Landden <shawnlandden@gmail.com>
      Original-patch: Richard Weinberger <richard@nod.at>
      Signed-off-by: default avatarShawn Landden <shawn@churchofgit.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d3f7d56a
    • Guenter Roeck's avatar
      sfc: Convert to use hwmon_device_register_with_groups · 85493e6d
      Guenter Roeck authored
      Simplify the code. Avoid race conditions caused by attributes
      being created after hwmon device registration. Implicitly
      (through hwmon API) add mandatory 'name' sysfs attribute.
      Reviewed-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      85493e6d
    • Linus Walleij's avatar
      net: smc91: fix crash regression on the versatile · a0c20fb0
      Linus Walleij authored
      After commit e9e4ea74
      "net: smc91x: dont't use SMC_outw for fixing up halfword-aligned data"
      The Versatile SMSC LAN91C111 is crashing like this:
      
      ------------[ cut here ]------------
      kernel BUG at /home/linus/linux/drivers/net/ethernet/smsc/smc91x.c:599!
      Internal error: Oops - BUG: 0 [#1] ARM
      Modules linked in:
      CPU: 0 PID: 43 Comm: udhcpc Not tainted 3.13.0-rc1+ #24
      task: c6ccfaa0 ti: c6cd0000 task.ti: c6cd0000
      PC is at smc_hardware_send_pkt+0x198/0x22c
      LR is at smc_hardware_send_pkt+0x24/0x22c
      pc : [<c01be324>]    lr : [<c01be1b0>]    psr: 20000013
      sp : c6cd1d08  ip : 00000001  fp : 00000000
      r10: c02adb08  r9 : 00000000  r8 : c6ced802
      r7 : c786fba0  r6 : 00000146  r5 : c8800000  r4 : c78d6000
      r3 : 0000000f  r2 : 00000146  r1 : 00000000  r0 : 00000031
      Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 0005317f  Table: 06cf4000  DAC: 00000015
      Process udhcpc (pid: 43, stack limit = 0xc6cd01c0)
      Stack: (0xc6cd1d08 to 0xc6cd2000)
      1d00:                   00000010 c8800000 c78d6000 c786fba0 c78d6000 c01be868
      1d20: c01be7a4 00004000 00000000 c786fba0 c6c12b80 c0208554 000004d0 c780fc60
      1d40: 00000220 c01fb734 00000000 00000000 00000000 c6c9a440 c6c12b80 c78d6000
      1d60: c786fba0 c6c9a440 00000000 c021d1d8 00000000 00000000 c6c12b80 c78d6000
      1d80: c786fba0 00000001 c6c9a440 c02087f8 c6c9a4a0 00080008 00000000 00000000
      1da0: c78d6000 c786fba0 c78d6000 00000138 00000000 00000000 00000000 00000000
      1dc0: 00000000 c027ba74 00000138 00000138 00000001 00000010 c6cedc00 00000000
      1de0: 00000008 c7404400 c6cd1eec c6cd1f14 c067a73c c065c0b8 00000000 c067a740
      1e00: 01ffffff 002040d0 00000000 00000000 00000000 00000000 00000000 ffffffff
      1e20: 43004400 00110022 c6cdef20 c027ae8c c6ccfaa0 be82d65c 00000014 be82d3cc
      1e40: 00000000 00000000 00000000 c01f2870 00000000 00000000 00000000 c6cd1e88
      1e60: c6ccfaa0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      1e80: 00000000 00000000 00000031 c7802310 c7802300 00000138 c7404400 c0771da0
      1ea0: 00000000 c6cd1eec c7800340 00000138 be82d65c 00000014 be82d3cc c6cd1f08
      1ec0: 00000014 00000000 c7404400 c7404400 00000138 c01f4628 c78d6000 00000000
      1ee0: 00000000 be82d3cc 00000138 c6cd1f08 00000014 c6cd1ee4 00000001 00000000
      1f00: 00000000 00000000 00080011 00000002 06000000 ffffffff 0000ffff 00000002
      1f20: 06000000 ffffffff 0000ffff c00928c8 c065c520 c6cd1f58 00000003 c009299c
      1f40: 00000003 c065c520 c7404400 00000000 c7404400 c01f2218 c78106b0 c7441cb0
      1f60: 00000000 00000006 c06799fc 00000000 00000000 00000006 00000000 c01f3ee0
      1f80: 00000000 00000000 be82d678 be82d65c 00000014 00000001 00000122 c00139c8
      1fa0: c6cd0000 c0013840 be82d65c 00000014 00000006 be82d3cc 00000138 00000000
      1fc0: be82d65c 00000014 00000001 00000122 00000000 00000000 00018cb1 00000000
      1fe0: 00003801 be82d3a8 0003a0c7 b6e9af08 60000010 00000006 00000000 00000000
      [<c01be324>] (smc_hardware_send_pkt+0x198/0x22c) from [<c01be868>] (smc_hard_start_xmit+0xc4/0x1e8)
      [<c01be868>] (smc_hard_start_xmit+0xc4/0x1e8) from [<c0208554>] (dev_hard_start_xmit+0x460/0x4cc)
      [<c0208554>] (dev_hard_start_xmit+0x460/0x4cc) from [<c021d1d8>] (sch_direct_xmit+0x94/0x18c)
      [<c021d1d8>] (sch_direct_xmit+0x94/0x18c) from [<c02087f8>] (dev_queue_xmit+0x238/0x42c)
      [<c02087f8>] (dev_queue_xmit+0x238/0x42c) from [<c027ba74>] (packet_sendmsg+0xbe8/0xd28)
      [<c027ba74>] (packet_sendmsg+0xbe8/0xd28) from [<c01f2870>] (sock_sendmsg+0x84/0xa8)
      [<c01f2870>] (sock_sendmsg+0x84/0xa8) from [<c01f4628>] (SyS_sendto+0xb8/0xdc)
      [<c01f4628>] (SyS_sendto+0xb8/0xdc) from [<c0013840>] (ret_fast_syscall+0x0/0x2c)
      Code: e3130002 1a000001 e3130001 0affffcd (e7f001f2)
      ---[ end trace 81104fe70e8da7fe ]---
      Kernel panic - not syncing: Fatal exception in interrupt
      
      This is because the macro operations in smc91x.h defined
      for Versatile are missing SMC_outsw() as used in this
      commit.
      
      The Versatile needs and uses the same accessors as the other
      platforms in the first if(...) clause, just switch it to using
      that and we have one problem less to worry about.
      
      This includes a hunk of a patch from Will Deacon fixin
      the other 32bit platforms as well: Innokom, Ramses, PXA,
      PCM027.
      
      Checkpatch complains about spacing, but I have opted to
      follow the style of this .h-file.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Nicolas Pitre <nico@fluxnic.net>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Cc: Jonathan Cameron <jic23@cam.ac.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a0c20fb0
    • David S. Miller's avatar
      Revert "net: smc91: fix crash regression on the versatile" · 9d38d28b
      David S. Miller authored
      This reverts commit b268daff.
      
      I applied the wrong version of this patch, the proper version
      is coming up next.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d38d28b