Skip to content

L
linux
Switch branch/tag
  1. 15 Sep, 2014 3 commits
  3. 13 Sep, 2014 8 commits
    • David S. Miller's avatar
      Merge branch 'bridge_vlan_filtering' · 9e07a422
      David S. Miller authored 
      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: default avatarDavid S. Miller <davem@davemloft.net>
      9e07a422
    • Vlad Yasevich's avatar
      bridge: Allow clearing of pvid and untagged bitmap · 635126b7
      Vlad Yasevich authored 
      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: default avatarVlad Yasevich <vyasevic@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      635126b7
    • Vlad Yasevich's avatar
      bridge: Check if vlan filtering is enabled only once. · 20adfa1a
      Vlad Yasevich authored 
      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: default avatarVladislav Yasevich <vyasevic@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20adfa1a
    • Nikolay Aleksandrov's avatar
      bonding: fix div by zero while enslaving and transmitting · 9a72c2da
      Nikolay Aleksandrov authored 
      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: default avatarNikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9a72c2da
    • David S. Miller's avatar
      Merge branch 'r8169-net' · 638898f1
      David S. Miller authored 
      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: default avatarDavid S. Miller <davem@davemloft.net>
      638898f1
    • hayeswang's avatar
      r8169: fix setting rx vlan · 36d8e825
      hayeswang authored 
      The setting should depend on the new features not the current one.
Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      36d8e825
    • hayeswang's avatar
      r8169: fix the default setting of rx vlan · 48c20407
      hayeswang authored 
      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: default avatarHayes Wang <hayeswang@realtek.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48c20407
    • Mugunthan V N's avatar
      drivers: net: cpsw: dual_emac: in suspend/resume bring down/up all the netdev · 618073e3
      Mugunthan V N authored 
      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: default avatarMugunthan V N <mugunthanvnm@ti.com>
Tested-by: default avatarNishanth Menon <nm@ti.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      618073e3
  5. 12 Sep, 2014 7 commits
  7. 11 Sep, 2014 2 commits
    • Sujith Manoharan's avatar
      Revert "ath9k: Calculate sleep duration" · ae0fd635
      Sujith Manoharan authored 
      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: default avatarSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ae0fd635
    • David Jander's avatar
      can: flexcan: avoid calling usleep_range from interrupt context · 8badd65e
      David Jander authored 
      Apparently can_restart() runs from a (timer-) interrupt and can call
flexcan_chip_[en|dis]able(), so avoid using usleep_range()
Signed-off-by: default avatarDavid Jander <david@protonic.nl>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      8badd65e
  9. 10 Sep, 2014 11 commits
  11. 09 Sep, 2014 2 commits
  13. 08 Sep, 2014 7 commits
    • David S. Miller's avatar
      Merge branch 'oom_fixes' · 4748997e
      David S. Miller authored 
      Florian Fainelli says:

====================
net: systemport and bcmgenet OOM fixes

These two patches fix similar Out of Memory code paths in the SYSTEMPORT and
GENET drivers. Under high memory pressure, we could produce an OOPS by
passing a NULL pointer to dma_unmap_single().
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4748997e
    • Florian Fainelli's avatar
      net: bcmgenet: check harder for out of memory conditions · b629be5c
      Florian Fainelli authored 
      There is a potential case where we might be failing to refill a
control block, leaving it with both a NULL skb pointer *and* a NULL
dma_unmap_addr.

The way we process incoming packets, by first calling
dma_unmap_single(), and then only checking for a potential NULL skb can
lead to situations where do pass a NULL dma_unmap_addr() to
dma_unmap_single(), resulting in an oops.

Fix this my moving the NULL skb check earlier, since no backing skb
also means no corresponding DMA mapping for this packet.
Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b629be5c
    • Florian Fainelli's avatar
      net: systemport: check harder for out of memory conditions · fe24ba08
      Florian Fainelli authored 
      There is a potential case where we might be failing to refill a
control block, leaving it with both a NULL skb pointer *and* a NULL
dma_unmap_addr.

The way we process incoming packets, by first calling
dma_unmap_single(), and then only checking for a potential NULL skb can
lead to situations where do pass a NULL dma_unmap_addr() to
dma_unmap_single(), resulting in an oops.

Fix this my moving the NULL skb check earlier, since no backing skb
also means no corresponding DMA mapping for this packet.
Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe24ba08
    • Ivan Vecera's avatar
      net/mlx4_en: do not ignore autoneg in mlx4_en_set_pauseparam() · 278d436a
      Ivan Vecera authored 
      The driver does not support pause autonegotiation so it should return
-EINVAL when the function is called with non-zero autoneg.

Cc: Amir Vadai <amirv@mellanox.com>
Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      278d436a
    • Aaro Koskinen's avatar
      drivers: net: ethernet: octeon_mgmt: fix a compiler warning · 208f7ca4
      Aaro Koskinen authored 
      Fix the following compiler warning:

drivers/net/ethernet/octeon/octeon_mgmt.c: In function 'octeon_mgmt_clean_tx_buffers':
drivers/net/ethernet/octeon/octeon_mgmt.c:295:4: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
    u64 ns = cvmx_read_csr(CVMX_MIXX_TSTAMP(p->port));
    ^
Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nsn.com>
Acked-by: default avatarDavid Daney <david.daney@cavium.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      208f7ca4
    • Eric Dumazet's avatar
      net: fix skb_page_frag_refill() kerneldoc · 82d5e2b8
      Eric Dumazet authored 
      In commit d9b2938a ("net: attempt a single high order allocation)
I forgot to update kerneldoc, as @prio parameter was renamed to @gfp
Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      82d5e2b8
    • David L Stevens's avatar
      sunvnet - add missing rmb() for sunvnet driver · 78dcff7b
      David L Stevens authored 
      The sunvnet driver does not have an rmb() in the ring consumer corresponding
to the wmb() in the producer. According to Documentation/memory-barriers.txt:

"When dealing with CPU-CPU interactions, certain types of memory barrier should
always be paired.  A lack of appropriate pairing is almost certainly an error."

In cases where an rmb() is not a no-op and a consumer is removing data from
the ring while a producer is adding new entries, a load reorder would allow

CPU1						CPU2
----						----
						LOAD desc.size [e.g]
STORE desc.size
<wmb>
set desc.hdr.state = VIO_DESC_READY
						LOAD desc.hdr.state
						[because VIO_DESC_READY, use
						 old desc.size, already loaded
						 out of order]

[CPU2 has reordered apparently unrelated LOADs]

To ensure other desc fields are not loaded before checking VIO_DESC_READY, we
need an rmb() between the check and desc data accesses.

I've also moved the viodbg() call to after the rmb() so that it, too, has
current descriptor data even with reordering, which has the side effect that
it won't print anything for descriptors that are not VIO_DESC_READY as before.
That's a) probably a good thing, since the fields are not necessarily set and,
b) better than adding another rmb() just for viodbg().

This would not be possible if strict-ordering is enforced, but then the
memory barriers should be no-ops in that case.
Signed-off-by: default avatarDavid L Stevens <david.stevens@oracle.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      78dcff7b
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7