11 Mar, 2011

1 commit

  • When configs BRIDGE=y and IPV6=m, this build error occurs:

    br_multicast.c:(.text+0xa3341): undefined reference to `ipv6_dev_get_saddr'

    BRIDGE_IGMP_SNOOPING is boolean; if it were tristate, then adding
    depends on IPV6 || IPV6=n
    to BRIDGE_IGMP_SNOOPING would be a good fix. As it is currently,
    making BRIDGE depend on the IPV6 config works.

    Reported-by: Patrick Schaaf
    Signed-off-by: Randy Dunlap
    Signed-off-by: David S. Miller

    Randy Dunlap
     

23 Feb, 2011

6 commits

  • Currently the bridge multicast snooping feature periodically issues
    IPv6 general multicast listener queries to sense the absence of a
    listener.

    For this, it uses :: as its source address - however RFC 2710 requires:
    "To be valid, the Query message MUST come from a link-local IPv6 Source
    Address". Current Linux kernel versions seem to follow this requirement
    and ignore our bogus MLD queries.

    With this commit a link local address from the bridge interface is being
    used to issue the MLD query, resulting in other Linux devices which are
    multicast listeners in the network to respond with a MLD response (which
    was not the case before).

    Signed-off-by: Linus Lüssing
    Signed-off-by: David S. Miller

    Linus Lüssing
     
  • Map the IPv6 header's destination multicast address to an ethernet
    source address instead of the MLD queries multicast address.

    For instance for a general MLD query (multicast address in the MLD query
    set to ::), this would wrongly be mapped to 33:33:00:00:00:00, although
    an MLD queries destination MAC should always be 33:33:00:00:00:01 which
    matches the IPv6 header's multicast destination ff02::1.

    Signed-off-by: Linus Lüssing
    Signed-off-by: David S. Miller

    Linus Lüssing
     
  • Currently the multicast bridge snooping support is not active for
    link local multicast. I assume this has been done to leave
    important multicast data untouched, like IPv6 Neighborhood Discovery.

    In larger, bridged, local networks it could however be desirable to
    optimize for instance local multicast audio/video streaming too.

    With the transient flag in IPv6 multicast addresses we have an easy
    way to optimize such multimedia traffic without tempering with the
    high priority multicast data from well-known addresses.

    This patch alters the multicast bridge snooping for IPv6, to take
    effect for transient multicast addresses instead of non-link-local
    addresses.

    Signed-off-by: Linus Lüssing
    Signed-off-by: David S. Miller

    Linus Lüssing
     
  • The nsrcs number is 2 Byte wide, therefore we need to call ntohs()
    before using it.

    Signed-off-by: Linus Lüssing
    Signed-off-by: David S. Miller

    Linus Lüssing
     
  • We actually want a pointer to the grec_nsrcr and not the following
    field. Otherwise we can get very high values for *nsrcs as the first two
    bytes of the IPv6 multicast address are being used instead, leading to
    a failing pskb_may_pull() which results in MLDv2 reports not being
    parsed.

    Signed-off-by: Linus Lüssing
    Signed-off-by: David S. Miller

    Linus Lüssing
     
  • The protocol type for IPv6 entries in the hash table for multicast
    bridge snooping is falsely set to ETH_P_IP, marking it as an IPv4
    address, instead of setting it to ETH_P_IPV6, which results in negative
    look-ups in the hash table later.

    Signed-off-by: Linus Lüssing
    Signed-off-by: David S. Miller

    Linus Lüssing
     

12 Feb, 2011

3 commits

  • As it turns out we never need to walk through the list of multicast
    groups subscribed by the bridge interface itself (the only time we'd
    want to do that is when we shut down the bridge, in which case we
    simply walk through all multicast groups), we don't really need to
    keep an hlist for mp->mglist.

    This means that we can replace it with just a single bit to indicate
    whether the bridge interface is subscribed to a group.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     
  • In a couple of spots where we are supposed to modify the port
    group timer (p->timer) we instead modify the bridge interface
    group timer (mp->timer).

    The effect of this is mostly harmless. However, it can cause
    port subscriptions to be longer than they should be, thus making
    snooping less effective.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     
  • The list mp->mglist is used to indicate whether a multicast group
    is active on the bridge interface itself as opposed to one of the
    constituent interfaces in the bridge.

    Unfortunately the operation that adds the mp->mglist node to the
    list neglected to check whether it has already been added. This
    leads to list corruption in the form of nodes pointing to itself.

    Normally this would be quite obvious as it would cause an infinite
    loop when walking the list. However, as this list is never actually
    walked (which means that we don't really need it, I'll get rid of
    it in a subsequent patch), this instead is hidden until we perform
    a delete operation on the affected nodes.

    As the same node may now be pointed to by more than one node, the
    delete operations can then cause modification of freed memory.

    This was observed in practice to cause corruption in 512-byte slabs,
    most commonly leading to crashes in jbd2.

    Thanks to Josef Bacik for pointing me in the right direction.

    Reported-by: Ian Page Hands
    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     

05 Feb, 2011

1 commit


07 Jan, 2011

1 commit


05 Jan, 2011

1 commit


04 Jan, 2011

3 commits

  • net/bridge//br_stp_if.c:148:66: warning: conversion of
    net/bridge//br_stp_if.c:148:66: int to
    net/bridge//br_stp_if.c:148:66: int enum umh_wait

    net/bridge//netfilter/ebtables.c:1150:30: warning: Using plain integer as NULL pointer

    Signed-off-by: Tomas Winkler
    Signed-off-by: David S. Miller

    Tomas Winkler
     
  • commit bf9ae5386bca8836c16e69ab8fdbe46767d7452a
    (llc: use dev_hard_header) removed the
    skb_reset_mac_header call from llc_mac_hdr_init.

    This seems fine itself, but br_send_bpdu() invokes ebtables LOCAL_OUT.

    We oops in ebt_basic_match() because it assumes eth_hdr(skb) returns
    a meaningful result.

    Cc: acme@ghostprotocols.net
    References: https://bugzilla.kernel.org/show_bug.cgi?id=24532
    Signed-off-by: Florian Westphal
    Signed-off-by: David S. Miller

    Florian Westphal
     
  • use pskb_may_pull to access ipv6 header correctly for paged skbs
    It was omitted in the bridge code leading to crash in blind
    __skb_pull

    since the skb is cloned undonditionally we also simplify the
    the exit path

    this fixes bug https://bugzilla.kernel.org/show_bug.cgi?id=25202

    Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: authenticated
    Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: associated (aid 2)
    Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 RADIUS: starting accounting session 4D0608A3-00000005
    Dec 15 14:36:41 User-PC kernel: [175576.120287] ------------[ cut here ]------------
    Dec 15 14:36:41 User-PC kernel: [175576.120452] kernel BUG at include/linux/skbuff.h:1178!
    Dec 15 14:36:41 User-PC kernel: [175576.120609] invalid opcode: 0000 [#1] SMP
    Dec 15 14:36:41 User-PC kernel: [175576.120749] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
    Dec 15 14:36:41 User-PC kernel: [175576.121035] Modules linked in: approvals binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
    Dec 15 14:36:41 User-PC kernel: [175576.122712]
    Dec 15 14:36:41 User-PC kernel: [175576.122769] Pid: 0, comm: kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
    Dec 15 14:36:41 User-PC kernel: [175576.123012] EIP: 0060:[] EFLAGS: 00010283 CPU: 1
    Dec 15 14:36:41 User-PC kernel: [175576.123193] EIP is at br_multicast_rcv+0xc95/0xe1c [bridge]
    Dec 15 14:36:41 User-PC kernel: [175576.123362] EAX: 0000001c EBX: f5626318 ECX: 00000000 EDX: 00000000
    Dec 15 14:36:41 User-PC kernel: [175576.123550] ESI: ec512262 EDI: f5626180 EBP: f60b5ca0 ESP: f60b5bd8
    Dec 15 14:36:41 User-PC kernel: [175576.123737] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    Dec 15 14:36:41 User-PC kernel: [175576.123902] Process kworker/0:0 (pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
    Dec 15 14:36:41 User-PC kernel: [175576.124137] Stack:
    Dec 15 14:36:41 User-PC kernel: [175576.124181] ec556500 f6d06800 f60b5be8 c01087d8 ec512262 00000030 00000024 f5626180
    Dec 15 14:36:41 User-PC kernel: [175576.124181] f572c200 ef463440 f5626300 3affffff f6d06dd0 e60766a4 000000c4 f6d06860
    Dec 15 14:36:41 User-PC kernel: [175576.124181] ffffffff ec55652c 00000001 f6d06844 f60b5c64 c0138264 c016e451 c013e47d
    Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? sched_clock+0x8/0x10
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? enqueue_entity+0x174/0x440
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? sched_clock_cpu+0x131/0x190
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? select_task_rq_fair+0x2ad/0x730
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? nf_iterate+0x71/0x90
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? br_handle_frame_finish+0x184/0x220 [bridge]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? br_handle_frame_finish+0x0/0x220 [bridge]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? br_handle_frame+0x189/0x230 [bridge]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? br_handle_frame_finish+0x0/0x220 [bridge]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? br_handle_frame+0x0/0x230 [bridge]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? __netif_receive_skb+0x1b6/0x5b0
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? skb_copy_bits+0x110/0x210
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? netif_receive_skb+0x6f/0x80
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? ieee80211_deliver_skb+0x8c/0x1a0 [mac80211]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? ieee80211_rx_handlers+0xeb6/0x1aa0 [mac80211]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? __netif_receive_skb+0x380/0x5b0
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? sched_clock_local+0xb2/0x190
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? default_spin_lock_flags+0x8/0x10
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? _raw_spin_lock_irqsave+0x2f/0x50
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? ieee80211_prepare_and_rx_handle+0x201/0xa90 [mac80211]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? ieee80211_rx+0x2a4/0x830 [mac80211]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? iwl_update_stats+0xa6/0x2a0 [iwlcore]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? iwlagn_rx_reply_rx+0x292/0x3b0 [iwlagn]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? _raw_spin_lock_irqsave+0x2f/0x50
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? iwl_rx_handle+0xe7/0x350 [iwlagn]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? iwl_irq_tasklet+0xf7/0x5c0 [iwlagn]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? __rcu_process_callbacks+0x201/0x2d0
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? tasklet_action+0xc5/0x100
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? __do_softirq+0x97/0x1d0
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? nmi_stack_correct+0x2f/0x34
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? __do_softirq+0x0/0x1d0
    Dec 15 14:36:41 User-PC kernel: [175576.124181]
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? irq_exit+0x65/0x70
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? do_IRQ+0x52/0xc0
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? common_interrupt+0x30/0x38
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? intel_idle+0xc2/0x160
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? cpuidle_idle_call+0x6b/0x100
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? cpu_idle+0x8a/0xf0
    Dec 15 14:36:41 User-PC kernel: [175576.124181] [] ? start_secondary+0x1e8/0x1ee

    Cc: David Miller
    Cc: Johannes Berg
    Cc: Stephen Hemminger
    Signed-off-by: Tomas Winkler
    Signed-off-by: David S. Miller

    Tomas Winkler
     

18 Dec, 2010

1 commit


17 Dec, 2010

1 commit


11 Dec, 2010

2 commits

  • The nf_pre_routing functions in bridging have collected two
    distinct ways of returning NF_DROP over the years, inline and
    via goto. There is no reason for preferring either one.

    So this patch arbitrarily picks the inline variant and converts
    the all the gotos.

    Also removes a redundant comment.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     
  • If br_multicast_new_group returns NULL, we would return 0 (no error) to
    the caller of br_multicast_add_group, which is not what we want. Instead
    br_multicast_new_group should return ERR_PTR(-ENOMEM) in this case.
    Also propagate the error number returned by br_mdb_rehash properly.

    Signed-off-by: Tobias Klauser
    Signed-off-by: David S. Miller

    Tobias Klauser
     

10 Dec, 2010

1 commit

  • Use helper functions to hide all direct accesses, especially writes,
    to dst_entry metrics values.

    This will allow us to:

    1) More easily change how the metrics are stored.

    2) Implement COW for metrics.

    In particular this will help us put metrics into the inetpeer
    cache if that is what we end up doing. We can make the _metrics
    member a pointer instead of an array, initially have it point
    at the read-only metrics in the FIB, and then on the first set
    grab an inetpeer entry and point the _metrics member there.

    Signed-off-by: David S. Miller
    Acked-by: Eric Dumazet

    David S. Miller
     

18 Nov, 2010

1 commit


16 Nov, 2010

4 commits


21 Oct, 2010

5 commits


12 Oct, 2010

1 commit

  • struct dst_ops tracks number of allocated dst in an atomic_t field,
    subject to high cache line contention in stress workload.

    Switch to a percpu_counter, to reduce number of time we need to dirty a
    central location. Place it on a separate cache line to avoid dirtying
    read only fields.

    Stress test :

    (Sending 160.000.000 UDP frames,
    IP route cache disabled, dual E5540 @2.53GHz,
    32bit kernel, FIB_TRIE, SLUB/NUMA)

    Before:

    real 0m51.179s
    user 0m15.329s
    sys 10m15.942s

    After:

    real 0m45.570s
    user 0m15.525s
    sys 9m56.669s

    With a small reordering of struct neighbour fields, subject of a
    following patch, (to separate refcnt from other read mostly fields)

    real 0m41.841s
    user 0m15.261s
    sys 8m45.949s

    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Eric Dumazet
     

20 Sep, 2010

1 commit

  • Related dicussion here : http://lkml.org/lkml/2010/9/3/16

    Introduce a function br_parse_ip_options that will audit the
    skb and possibly refill IP options before a packet enters the
    IP stack. If no options are present, the function will zero out
    the skb cb area so that it is not misinterpreted as options by some
    unsuspecting IP layer routine. If packet consistency fails, drop it.

    Signed-off-by: Bandan Das
    Signed-off-by: David S. Miller

    Bandan Das
     

10 Sep, 2010

1 commit


02 Sep, 2010

1 commit


26 Aug, 2010

2 commits


24 Aug, 2010

1 commit


23 Aug, 2010

1 commit

  • While looking at using netdev_rx_handler_register for openvswitch Jesse
    Gross suggested that an unlikely() might be worthwhile in that code.
    I'm interested to see if its appropriate for the bridge code.

    Cc: Jesse Gross
    Signed-off-by: Simon Horman
    Signed-off-by: David S. Miller

    Simon Horman
     

03 Aug, 2010

1 commit