1. 20 9月, 2014 5 次提交
    • F
      net: allow macvlans to move to net namespace · 0d0162e7
      Francesco Ruggeri 提交于
      I cannot move a macvlan interface created on top of a bonding interface
      to a different namespace:
      
      % ip netns add dummy0
      % ip link add link bond0 mac0 type macvlan
      % ip link set mac0 netns dummy0
      RTNETLINK answers: Invalid argument
      %
      
      The problem seems to be that commit f9399814 ("bonding: Don't allow
      bond devices to change network namespaces.") sets NETIF_F_NETNS_LOCAL
      on bonding interfaces, and commit 797f87f8 ("macvlan: fix netdev
      feature propagation from lower device") causes macvlan interfaces
      to inherit its features from the lower device.
      
      NETIF_F_NETNS_LOCAL should not be inherited from the lower device
      by a macvlan.
      Patch tested on 3.16.
      Signed-off-by: NFrancesco Ruggeri <fruggeri@arista.com>
      Acked-by: NCong Wang <cwang@twopensource.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d0162e7
    • D
      Merge tag 'master-2014-09-16' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless · 8f665f6c
      David S. Miller 提交于
      John W. Linville says:
      
      ====================
      pull request: wireless 2014-09-17
      
      Please pull this batch of fixes intended for the 3.17 stream...
      
      Arend van Spriel sends a trio of minor brcmfmac fixes, including a
      fix for a Kconfig/build issue, a fix for a crash (null reference),
      and a regression fix related to event handling on a P2P interface.
      
      Hante Meuleman follows-up with a brcmfmac fix for a memory leak.
      
      Johannes Stezenbach brings an ath9k_htc fix for a regression related
      to hardware decryption offload.
      
      Marcel Holtmann delivers a one-liner to properly mark a device ID
      table in rfkill-gpio.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8f665f6c
    • N
      3c59x: Fix bad offset spec in skb_frag_dma_map · 8400dd02
      Neil Horman 提交于
      Recently aded the use of skb_frag_dma_map to 3c59x, but didn't realize it
      automatically included the frag_offset internally, as well as provided an option
      to specify an extra offset in the parameter list.  We need to specify an offset
      of 0 in the parameter list to avoid skb corruption that results in lost
      connections.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Linux Kernel list <linux-kernel@vger.kernel.org>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Meelis Roos <mroos@linux.ee>
      Tested-by: NMeelis Roos <mroos@linux.ee>
      8400dd02
    • N
      3c59x: Add dma error checking and recovery · 6f2b6a30
      Neil Horman 提交于
      Noted that 3c59x has no checks on transmit for failed DMA mappings, and no
      ability to unmap fragments when a single map fails in the middle of a transmit.
      This patch provides error checking to ensure that dma mappings work properly,
      and unrolls an skb mapping if a fragmented skb transmission has a mapping
      failure to prevent leaks.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Linux Kernel list <linux-kernel@vger.kernel.org>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Meelis Roos <mroos@linux.ee>
      Tested-by: NMeelis Roos <mroos@linux.ee>
      6f2b6a30
    • A
      sparc: bpf_jit: fix support for ldx/stx mem and SKF_AD_VLAN_TAG · f6f2332d
      Alexei Starovoitov 提交于
      fix several issues in sparc BPF JIT compiler.
      
      ldx/stx related:
      . classic BPF instructions that access mem[] slots were not setting
        SEEN_MEM flag, so stack wasn't allocated. Fix that by advertising
        correct flags
      
      . LDX/STX instructions were missing SEEN_XREG, so register value
        could have leaked to user space. Fix it.
      
      . since stack for mem[] slots is allocated with 'sub %sp' instead
        of 'save %sp', use %sp as base register instead of %fp.
      
      . ldx mem[0] means first slot in classic BPF which should have
        -4 offset instead of 0.
      
      . sparc64 needs 2047 stack bias as per ABI to access stack
      
      . emit_stmem() was using LD32I macro instead of ST32I
      
      SKF_AD_VLAN_TAG* related:
      . SKF_AD_VLAN_TAG_PRESENT must return 1 or 0 instead of '> 0' or 0
        as per classic BPF de facto standard
      
      . SKF_AD_VLAN_TAG needs to mask the field correctly
      
      Fixes: 2809a208 ("net: filter: Just In Time compiler for sparc")
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6f2332d
  2. 17 9月, 2014 4 次提交
  3. 16 9月, 2014 13 次提交
  4. 14 9月, 2014 8 次提交
    • D
      Merge branch 'bridge_vlan_filtering' · 9e07a422
      David S. Miller 提交于
      Vladislav Yasevich says:
      
      ====================
      bridge: Two small fixes to vlan filtering code.
      
      This series corrects 2 small issues that I've ran across recently
      while doing more work with vlan filtering changes.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9e07a422
    • V
      bridge: Allow clearing of pvid and untagged bitmap · 635126b7
      Vlad Yasevich 提交于
      Currently, it is possible to modify the vlan filter
      configuration to add pvid or untagged support.
      For example:
        bridge vlan add vid 10 dev eth0
        bridge vlan add vid 10 dev eth0 untagged pvid
      
      The second statement will modify vlan 10 to
      include untagged and pvid configuration.
      However, it is currently impossible to go backwards
        bridge vlan add vid 10 dev eth0 untagged pvid
        bridge vlan add vid 10 dev eth0
      
      Here nothing happens.  This patch correct this so
      that any modifiers not supplied are removed from
      the configuration.
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      635126b7
    • V
      bridge: Check if vlan filtering is enabled only once. · 20adfa1a
      Vlad Yasevich 提交于
      The bridge code checks if vlan filtering is enabled on both
      ingress and egress.   When the state flip happens, it
      is possible for the bridge to currently be forwarding packets
      and forwarding behavior becomes non-deterministic.  Bridge
      may drop packets on some interfaces, but not others.
      
      This patch solves this by caching the filtered state of the
      packet into skb_cb on ingress.  The skb_cb is guaranteed to
      not be over-written between the time packet entres bridge
      forwarding path and the time it leaves it.  On egress, we
      can then check the cached state to see if we need to
      apply filtering information.
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      20adfa1a
    • N
      bonding: fix div by zero while enslaving and transmitting · 9a72c2da
      Nikolay Aleksandrov 提交于
      The problem is that the slave is first linked and slave_cnt is
      incremented afterwards leading to a div by zero in the modes that use it
      as a modulus. What happens is that in bond_start_xmit()
      bond_has_slaves() is used to evaluate further transmission and it becomes
      true after the slave is linked in, but when slave_cnt is used in the xmit
      path it is still 0, so fetch it once and transmit based on that. Since
      it is used only in round-robin and XOR modes, the fix is only for them.
      Thanks to Eric Dumazet for pointing out the fault in my first try to fix
      this.
      
      Call trace (took it out of net-next kernel, but it's the same with net):
      [46934.330038] divide error: 0000 [#1] SMP
      [46934.330041] Modules linked in: bonding(O) 9p fscache
      snd_hda_codec_generic crct10dif_pclmul
      [46934.330041] bond0: Enslaving eth1 as an active interface with an up
      link
      [46934.330051]  ppdev joydev crc32_pclmul crc32c_intel 9pnet_virtio
      ghash_clmulni_intel snd_hda_intel 9pnet snd_hda_controller parport_pc
      serio_raw pcspkr snd_hda_codec parport virtio_balloon virtio_console
      snd_hwdep snd_pcm pvpanic i2c_piix4 snd_timer i2ccore snd soundcore
      virtio_blk virtio_net virtio_pci virtio_ring virtio ata_generic
      pata_acpi floppy [last unloaded: bonding]
      [46934.330053] CPU: 1 PID: 3382 Comm: ping Tainted: G           O
      3.17.0-rc4+ #27
      [46934.330053] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      [46934.330054] task: ffff88005aebf2c0 ti: ffff88005b728000 task.ti:
      ffff88005b728000
      [46934.330059] RIP: 0010:[<ffffffffa0198c33>]  [<ffffffffa0198c33>]
      bond_start_xmit+0x1c3/0x450 [bonding]
      [46934.330060] RSP: 0018:ffff88005b72b7f8  EFLAGS: 00010246
      [46934.330060] RAX: 0000000000000679 RBX: ffff88004b077000 RCX:
      000000000000002a
      [46934.330061] RDX: 0000000000000000 RSI: ffff88004b3f0500 RDI:
      ffff88004b077940
      [46934.330061] RBP: ffff88005b72b830 R08: 00000000000000c0 R09:
      ffff88004a83e000
      [46934.330062] R10: 000000000000ffff R11: ffff88004b1f12c0 R12:
      ffff88004b3f0500
      [46934.330062] R13: ffff88004b3f0500 R14: 000000000000002a R15:
      ffff88004b077940
      [46934.330063] FS:  00007fbd91a4c740(0000) GS:ffff88005f080000(0000)
      knlGS:0000000000000000
      [46934.330064] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [46934.330064] CR2: 00007f803a8bb000 CR3: 000000004b2c9000 CR4:
      00000000000406e0
      [46934.330069] Stack:
      [46934.330071]  ffffffff811e6169 00000000e772fa05 ffff88004b077000
      ffff88004b3f0500
      [46934.330072]  ffffffff81d17d18 000000000000002a 0000000000000000
      ffff88005b72b8a0
      [46934.330073]  ffffffff81620108 ffffffff8161fe0e ffff88005b72b8c4
      ffff88005b302000
      [46934.330073] Call Trace:
      [46934.330077]  [<ffffffff811e6169>] ?
      __kmalloc_node_track_caller+0x119/0x300
      [46934.330084]  [<ffffffff81620108>] dev_hard_start_xmit+0x188/0x410
      [46934.330086]  [<ffffffff8161fe0e>] ? harmonize_features+0x2e/0x90
      [46934.330088]  [<ffffffff81620b06>] __dev_queue_xmit+0x456/0x590
      [46934.330089]  [<ffffffff81620c50>] dev_queue_xmit+0x10/0x20
      [46934.330090]  [<ffffffff8168f022>] arp_xmit+0x22/0x60
      [46934.330091]  [<ffffffff8168f090>] arp_send.part.16+0x30/0x40
      [46934.330092]  [<ffffffff8168f1e5>] arp_solicit+0x115/0x2b0
      [46934.330094]  [<ffffffff8160b5d7>] ? copy_skb_header+0x17/0xa0
      [46934.330096]  [<ffffffff8162875a>] neigh_probe+0x4a/0x70
      [46934.330097]  [<ffffffff8162979c>] __neigh_event_send+0xac/0x230
      [46934.330098]  [<ffffffff8162a00b>] neigh_resolve_output+0x13b/0x220
      [46934.330100]  [<ffffffff8165f120>] ? ip_forward_options+0x1c0/0x1c0
      [46934.330101]  [<ffffffff81660478>] ip_finish_output+0x1f8/0x860
      [46934.330102]  [<ffffffff81661f08>] ip_output+0x58/0x90
      [46934.330103]  [<ffffffff81661602>] ? __ip_local_out+0xa2/0xb0
      [46934.330104]  [<ffffffff81661640>] ip_local_out_sk+0x30/0x40
      [46934.330105]  [<ffffffff81662a66>] ip_send_skb+0x16/0x50
      [46934.330106]  [<ffffffff81662ad3>] ip_push_pending_frames+0x33/0x40
      [46934.330107]  [<ffffffff8168854c>] raw_sendmsg+0x88c/0xa30
      [46934.330110]  [<ffffffff81612b31>] ? skb_recv_datagram+0x41/0x60
      [46934.330111]  [<ffffffff816875a9>] ? raw_recvmsg+0xa9/0x1f0
      [46934.330113]  [<ffffffff816978d4>] inet_sendmsg+0x74/0xc0
      [46934.330114]  [<ffffffff81697a9b>] ? inet_recvmsg+0x8b/0xb0
      [46934.330115] bond0: Adding slave eth2
      [46934.330116]  [<ffffffff8160357c>] sock_sendmsg+0x9c/0xe0
      [46934.330118]  [<ffffffff81603248>] ?
      move_addr_to_kernel.part.20+0x28/0x80
      [46934.330121]  [<ffffffff811b4477>] ? might_fault+0x47/0x50
      [46934.330122]  [<ffffffff816039b9>] ___sys_sendmsg+0x3a9/0x3c0
      [46934.330125]  [<ffffffff8144a14a>] ? n_tty_write+0x3aa/0x530
      [46934.330127]  [<ffffffff810d1ae4>] ? __wake_up+0x44/0x50
      [46934.330129]  [<ffffffff81242b38>] ? fsnotify+0x238/0x310
      [46934.330130]  [<ffffffff816048a1>] __sys_sendmsg+0x51/0x90
      [46934.330131]  [<ffffffff816048f2>] SyS_sendmsg+0x12/0x20
      [46934.330134]  [<ffffffff81738b29>] system_call_fastpath+0x16/0x1b
      [46934.330144] Code: 48 8b 10 4c 89 ee 4c 89 ff e8 aa bc ff ff 31 c0 e9
      1a ff ff ff 0f 1f 00 4c 89 ee 4c 89 ff e8 65 fb ff ff 31 d2 4c 89 ee 4c
      89 ff <f7> b3 64 09 00 00 e8 02 bd ff ff 31 c0 e9 f2 fe ff ff 0f 1f 00
      [46934.330146] RIP  [<ffffffffa0198c33>] bond_start_xmit+0x1c3/0x450
      [bonding]
      [46934.330146]  RSP <ffff88005b72b7f8>
      
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      Fixes: 278b2083 ("bonding: initial RCU conversion")
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9a72c2da
    • D
      Merge branch 'r8169-net' · 638898f1
      David S. Miller 提交于
      Hayes Wang says:
      
      ====================
      r8169: fix rx vlan
      
      There are two issues for hw rx vlan. The patches are
      used to fix them.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      638898f1
    • H
      r8169: fix setting rx vlan · 36d8e825
      hayeswang 提交于
      The setting should depend on the new features not the current one.
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      36d8e825
    • H
      r8169: fix the default setting of rx vlan · 48c20407
      hayeswang 提交于
      If the parameter "features" of __rtl8169_set_features() is equal to
      dev->features, the variable "changed" is alwayes 0, and nothing would
      be changed.
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48c20407
    • M
      drivers: net: cpsw: dual_emac: in suspend/resume bring down/up all the netdev · 618073e3
      Mugunthan V N 提交于
      During suspend and resume in Dual EMAC, second port is not working as in
      suspend/resume only the first slave netdev is closed and opened. So bring
      down and up all the interfaces that are up during suspend/resume.
      Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
      Tested-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      618073e3
  5. 13 9月, 2014 7 次提交
  6. 12 9月, 2014 1 次提交
    • S
      Revert "ath9k: Calculate sleep duration" · ae0fd635
      Sujith Manoharan 提交于
      This reverts commit 09ebb810.
      
      ath9k_hw_set_sta_beacon_timers() configures AR_TIM_PERIOD with
      the beacon interval. Before this commit, the sleepduration was
      never greater than the beacon interval. But now, the behavior
      has changed. For example, with an AP that uses a beacon interval of 100:
      
      ath: phy9: next beacon 61128704
      ath: phy9: beacon period 204800
      ath: phy9: DTIM period 204800
      
      If the sleepduration is calculated based on the listen time, then
      the bmiss threshold should also be changed since the HW would
      be in sleep state for a longer time, but that is not done currently.
      
      To avoid configuring a higher beacon interval based on the sleepduration,
      revert to the original behavior. Power consumption is not a
      problem since PS is disabled in ath9k anyway.
      
      Cc: stable@vger.kernel.org
      Cc: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ae0fd635
  7. 11 9月, 2014 2 次提交