1. 05 Feb, 2013 6 commits
    • Tom Parkin's avatar
      l2tp: prevent tunnel creation on netns mismatch · cbb95e0c
      Tom Parkin authored
      l2tp_tunnel_create is passed a pointer to the network namespace for the
      tunnel, along with an optional file descriptor for the tunnel which may
      be passed in from userspace via. netlink.
      In the case where the file descriptor is defined, ensure that the namespace
      associated with that socket matches the namespace explicitly passed to
      Signed-off-by: default avatarTom Parkin <tparkin@katalix.com>
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Tom Parkin's avatar
      l2tp: set netnsok flag for netlink messages · b6fdfdfa
      Tom Parkin authored
      The L2TP netlink code can run in namespaces.  Set the netnsok flag in
      genl_family to true to reflect that fact.
      Signed-off-by: default avatarTom Parkin <tparkin@katalix.com>
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Tom Parkin's avatar
      l2tp: put tunnel socket release on a workqueue · f8ccac0e
      Tom Parkin authored
      To allow l2tp_tunnel_delete to be called from an atomic context, place the
      tunnel socket release calls on a workqueue for asynchronous execution.
      Tunnel memory is eventually freed in the tunnel socket destructor.
      Signed-off-by: default avatarTom Parkin <tparkin@katalix.com>
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 188d1f76
      David S. Miller authored
      The ipv6 route.c conflict is simple, just ignore the 'net' side change
      as we fixed the same problem in 'net-next' by eliminating cached
      neighbours from ipv6 routes.
      The e1000e conflict is an addition of a new statistic in the ethtool
      code, trivial.
      The vmxnet3 conflict is about one change in 'net' removing a guarding
      conditional, whilst in 'net-next' we had a netdev_info() conversion.
      The iwlwifi conflict is dealing with a WARN_ON() conversion in
      'net-next' vs. a revert happening in 'net'.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Jitendra Kalsaria's avatar
      qlcnic: Updating copyright information. · 577ae39d
      Jitendra Kalsaria authored
      We recently refactored the driver source, this patch will take care of
      updating copyright date and adding it to newly added files.
      Signed-off-by: default avatarJitendra Kalsaria <jitendra.kalsaria@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Paul Gortmaker's avatar
      gianfar: dont conditionally alloc Rx/Err irq structs · 7c1e7e99
      Paul Gortmaker authored
      Commit ee873fda
          "gianfar: Pack struct gfar_priv_grp into three cachelines"
      causes the following null dereference at driver init on sbc8548:
         libphy: Freescale PowerQUICC MII Bus: probed
         Unable to handle kernel paging request for data at address 0x00000000
         Faulting instruction address: 0xc01d6a38
         Oops: Kernel access of bad area, sig: 11 [#1]
         NIP [c01d6a38] gfar_parse_group+0x228/0x280
         LR [c01d6a34] gfar_parse_group+0x224/0x280
         Call Trace:
         [ef82dd60] [c01d6a34] gfar_parse_group+0x224/0x280 (unreliable)
         [ef82dd90] [c01d73a4] gfar_probe+0x284/0xfe0
      The reason is that the commit also changed the allocation of the
      Rx and error handling irq structs to be skipped for !MQ_MG_MODE.
      In the !MQ_MG_MODE case, only the Tx irq struct is allocated.
      Digging further, we see that MQ_MG_MODE is set only if we find
      the OF compatible string "fsl,etsec2".
      A quick grep in the dts directory shows lots of boards that support
      Rx/Tx/Err, but without this specific compat string.  And hence they
      go after the unallocated Rx/Error structs and cause the above oops.
      Hence such a change can not be deployed until all the dts files
      are updated and sufficiently deployed.  Further, the optimization
      is of limited value, since the kmalloc'd struct in question has only
      a single unsigned int, and an (IFNAMSIZ + 6) sized string.
      Note that no changes to the freeing code are needed here, as it
      already did an unconditional free of Rx/Tx/Error gfar_irqinfo.
      Cc: Claudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  2. 04 Feb, 2013 28 commits
  3. 03 Feb, 2013 6 commits
    • Phil Sutter's avatar
      packet: fix leakage of tx_ring memory · 9665d5d6
      Phil Sutter authored
      When releasing a packet socket, the routine packet_set_ring() is reused
      to free rings instead of allocating them. But when calling it for the
      first time, it fills req->tp_block_nr with the value of rb->pg_vec_len
      which in the second invocation makes it bail out since req->tp_block_nr
      is greater zero but req->tp_block_size is zero.
      This patch solves the problem by passing a zeroed auto-variable to
      packet_set_ring() upon each invocation from packet_release().
      As far as I can tell, this issue exists even since 69e3c75f
       (net: TX_RING
      and packet mmap), i.e. the original inclusion of TX ring support into
      af_packet, but applies only to sockets with both RX and TX ring
      allocated, which is probably why this was unnoticed all the time.
      Signed-off-by: default avatarPhil Sutter <phil.sutter@viprinet.com>
      Cc: Johann Baudy <johann.baudy@gnu-log.net>
      Cc: Daniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Alexey Khoroshilov's avatar
      stmmac: don't return zero on failure path in stmmac_pci_probe() · 4f463855
      Alexey Khoroshilov authored
      If stmmac_dvr_probe() fails in stmmac_pci_probe(), it breaks off initialization,
      deallocates all resources, but returns zero.
      The patch adds -ENODEV as return value in this case.
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: default avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Pravin B Shelar's avatar
      net: Fix inner_network_header assignment in skb-copy. · 92df9b21
      Pravin B Shelar authored
      Use correct inner offset to set inner_network_offset.
      Found by inspection.
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Eric Dumazet's avatar
      tcp: frto should not set snd_cwnd to 0 · 2e5f4212
      Eric Dumazet authored
      Commit 9dc27415
       (tcp: fix ABC in tcp_slow_start())
      uncovered a bug in FRTO code :
      tcp_process_frto() is setting snd_cwnd to 0 if the number
      of in flight packets is 0.
      As Neal pointed out, if no packet is in flight we lost our
      chance to disambiguate whether a loss timeout was spurious.
      We should assume it was a proper loss.
      Reported-by: default avatarPasi Kärkkäinen <pasik@iki.fi>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Cc: Yuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Eric Dumazet's avatar
      tcp: fix an infinite loop in tcp_slow_start() · 973ec449
      Eric Dumazet authored
      Since commit 9dc27415
       (tcp: fix ABC in tcp_slow_start()),
      a nul snd_cwnd triggers an infinite loop in tcp_slow_start()
      Avoid this infinite loop and log a one time error for further
      analysis. FRTO code is suspected to cause this bug.
      Reported-by: default avatarPasi Kärkkäinen <pasik@iki.fi>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • David S. Miller's avatar
      Merge branch 'delete-wanrouter' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux · 33397a71
      David S. Miller authored
      Paul Gortmaker says:
      The removal of wanrouter code was originally listed in the (now
      gone) feature removal file since May 2012, and an RFC of the
      deletion was posted[1] in late 2012.  The overall concept was given
      an OK, but defconfig contamination, build failures, etc. meant that
      it didn't quite make it into mainline for 3.8.
      Since that time, Dan discovered (via code audit) a runtime bug that
      proves nobody has been using this for over four years[2].  With that
      new information, I think it makes sense for someone to follow through
      on Joe's original RFC and get this done for the 3.9 release.
      In addition to resolving the build failures of the RFC by keeping
      stub headers, this also splits the change into two parts, just like
      the token ring removal did.  Part #1 decouples the mainline kernel
      from the expired subsystem, and part #2 does the large scale
      deletion of the subsystem content.
      The advantage of the above, is that a "git blame" will never lead
      you to a 4000+ line deletion commit.  The large scale deletion will
      never show up in a "git blame" and hence the same advantages that we
      get from the "--irreversible-delete" in the review stage of "git
      format-patch" are also embedded into the git history itself.  This
      may seem like a moot point to some, but for those who spend a
      considerable amount of time data mining in the git history, this is
      probably worth doing.
      I have done build tests of all[mod/yes]config for both the stage 1
      (Makefile and Kconfig) and stage 2 (full driver delete) as a sanity
      check, and the issues with the previously posted RFC should be gone.
      Speaking of "--irreversible-delete" -- these patches were created
      with that option, so if you want to use them locally, you are going
      to have to pull (location below) the content instead of doing a
      "git am" of the mailed out content.
      [1] http://patchwork.ozlabs.org/patch/198794/
      [2] http://www.spinics.net/lists/netdev/msg218670.html
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>