05 Jan, 2012

1 commit

  • Recently Dave noticed that a test we did in ipv6_add_addr to see if we next hop
    route for the interface we're adding an addres to was wrong (see commit
    7ffbcecbeed91e5874e9a1cfc4c0cbb07dac3069). for one, it never triggers, and two,
    it was completely wrong to begin with. This test was meant to cover this
    section of RFC 4429:

    3.3 Modifications to RFC 2462 Stateless Address Autoconfiguration

    * (modifies section 5.5) A host MAY choose to configure a new address
    as an Optimistic Address. A host that does not know the SLLAO
    of its router SHOULD NOT configure a new address as Optimistic.
    A router SHOULD NOT configure an Optimistic Address.

    This patch should bring us into proper compliance with the above clause. Since
    we only add a SLAAC address after we've received a RA which may or may not
    contain a source link layer address option, we can pass a pointer to that option
    to addrconf_prefix_rcv (which may be null if the option is not present), and
    only set the optimistic flag if the option was found in the RA.

    Change notes:
    (v2) modified the new parameter to addrconf_prefix_rcv to be a bool rather than
    a pointer to make its use more clear as per request from davem.

    Signed-off-by: Neil Horman
    CC: "David S. Miller"
    CC: Hideaki YOSHIFUJI
    Signed-off-by: David S. Miller

    Neil Horman
     

29 Dec, 2011

2 commits


07 Dec, 2011

1 commit


06 Dec, 2011

1 commit


01 Dec, 2011

1 commit


27 Nov, 2011

1 commit


23 Nov, 2011

2 commits


19 Nov, 2011

1 commit

  • ipv6: Remove all uses of LL_ALLOCATED_SPACE

    The macro LL_ALLOCATED_SPACE was ill-conceived. It applies the
    alignment to the sum of needed_headroom and needed_tailroom. As
    the amount that is then reserved for head room is needed_headroom
    with alignment, this means that the tail room left may be too small.

    This patch replaces all uses of LL_ALLOCATED_SPACE in net/ipv6
    with the macro LL_RESERVED_SPACE and direct reference to
    needed_tailroom.

    This also fixes the problem with needed_headroom changing between
    allocating the skb and reserving the head room.

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

    Herbert Xu
     

14 Nov, 2011

1 commit

  • Le mercredi 09 novembre 2011 à 16:21 -0500, David Miller a écrit :
    > From: David Miller
    > Date: Wed, 09 Nov 2011 16:16:44 -0500 (EST)
    >
    > > From: Eric Dumazet
    > > Date: Wed, 09 Nov 2011 12:14:09 +0100
    > >
    > >> unres_qlen is the number of frames we are able to queue per unresolved
    > >> neighbour. Its default value (3) was never changed and is responsible
    > >> for strange drops, especially if IP fragments are used, or multiple
    > >> sessions start in parallel. Even a single tcp flow can hit this limit.
    > > ...
    > >
    > > Ok, I've applied this, let's see what happens :-)
    >
    > Early answer, build fails.
    >
    > Please test build this patch with DECNET enabled and resubmit. The
    > decnet neigh layer still refers to the removed ->queue_len member.
    >
    > Thanks.

    Ouch, this was fixed on one machine yesterday, but not the other one I
    used this morning, sorry.

    [PATCH V5 net-next] neigh: new unresolved queue limits

    unres_qlen is the number of frames we are able to queue per unresolved
    neighbour. Its default value (3) was never changed and is responsible
    for strange drops, especially if IP fragments are used, or multiple
    sessions start in parallel. Even a single tcp flow can hit this limit.

    $ arp -d 192.168.20.108 ; ping -c 2 -s 8000 192.168.20.108
    PING 192.168.20.108 (192.168.20.108) 8000(8028) bytes of data.
    8008 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.322 ms

    Signed-off-by: David S. Miller

    Eric Dumazet
     

25 Oct, 2011

1 commit

  • When hybrid mode is enabled (accept_ra == 2), the kernel also sees RAs
    generated locally. This is useful since it allows the kernel to auto-configure
    its own interface addresses.

    However, if 'accept_ra_defrtr' and/or 'accept_ra_rtr_pref' are set and the
    locally generated RAs announce the default route and/or other route information,
    the kernel happily inserts bogus routes with its own address as gateway.

    With this patch, adding routes from an RA will be skiped when the RAs source
    address matches any local address, just as if 'accept_ra_defrtr' and
    'accept_ra_rtr_pref' were set to 0.

    Signed-off-by: Andreas Hofmeister
    Signed-off-by: David S. Miller

    Andreas Hofmeister
     

18 Oct, 2011

1 commit


01 Aug, 2011

1 commit


18 Jul, 2011

3 commits


17 Jul, 2011

2 commits


30 Apr, 2011

1 commit

  • For backward compatibility, we should retain the module parameters and
    sysfs attributes to control the number of peer notifications
    (gratuitous ARPs and unsolicited NAs) sent after bonding failover.
    Also, it is possible for failover to take place even though the new
    active slave does not have link up, and in that case the peer
    notification should be deferred until it does.

    Change ipv4 and ipv6 so they do not automatically send peer
    notifications on bonding failover.

    Change the bonding driver to send separate NETDEV_NOTIFY_PEERS
    notifications when the link is up, as many times as requested. Since
    it does not directly control which protocols send notifications, make
    num_grat_arp and num_unsol_na aliases for a single parameter. Bump
    the bonding version number and update its documentation.

    Signed-off-by: Ben Hutchings
    Signed-off-by: Jay Vosburgh
    Acked-by: Brian Haley
    Signed-off-by: David S. Miller

    Ben Hutchings
     

23 Apr, 2011

1 commit


18 Apr, 2011

2 commits


16 Apr, 2011

1 commit

  • [ipv6] Ignore looped-back NAs while in Duplicate Address Detection

    If we send an unsolicited NA shortly after bringing up an
    IPv6 address, the duplicate address detection algorithm
    fails and the ip stays in tentative mode forever.
    This is due a missing check if the NA is looped-back to us.

    Signed-off-by: Daniel Walter
    Signed-off-by: David S. Miller

    Daniel Walter
     

30 Mar, 2011

1 commit

  • My commit 6d55cb91a0020ac0 (gre: fix hard header destination
    address checking) broke multicast.

    The reason is that ip_gre used to get ipgre_header() calls with
    zero destination if we have NOARP or multicast destination. Instead
    the actual target was decided at ipgre_tunnel_xmit() time based on
    per-protocol dissection.

    Instead of allowing the "abuse" of ->header() calls with invalid
    destination, this creates multicast mappings for ip_gre. This also
    fixes "ip neigh show nud noarp" to display the proper multicast
    mappings used by the gre device.

    Reported-by: Doug Kehn
    Signed-off-by: Timo Teräs
    Acked-by: Doug Kehn
    Signed-off-by: David S. Miller

    Timo Teräs
     

13 Mar, 2011

1 commit


03 Mar, 2011

1 commit


05 Feb, 2011

1 commit


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
     

03 Dec, 2010

1 commit


06 Oct, 2010

1 commit

  • David

    This is the first step for RCU conversion of neigh code.

    Next patches will convert hash_buckets[] and "struct neighbour" to RCU
    protected objects.

    Thanks

    [PATCH net-next] net neigh: RCU conversion of neigh hash table

    Instead of storing hash_buckets, hash_mask and hash_rnd in "struct
    neigh_table", a new structure is defined :

    struct neigh_hash_table {
    struct neighbour **hash_buckets;
    unsigned int hash_mask;
    __u32 hash_rnd;
    struct rcu_head rcu;
    };

    And "struct neigh_table" has an RCU protected pointer to such a
    neigh_hash_table.

    This means the signature of (*hash)() function changed: We need to add a
    third parameter with the actual hash_rnd value, since this is not
    anymore a neigh_table field.

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

    Eric Dumazet
     

24 Sep, 2010

1 commit


04 Sep, 2010

1 commit

  • The current IPv6 behavior is to not accept router advertisements while
    forwarding, i.e. configured as router.

    This does make sense, a router is typically not supposed to be auto
    configured. However there are exceptions and we should allow the
    current behavior to be overwritten.

    Therefore this patch enables the user to overrule the "if forwarding
    enabled then don't listen to RAs" rule by setting accept_ra to the
    special value of 2.

    An alternative would be to ignore the forwarding switch alltogether
    and solely accept RAs based on the value of accept_ra. However, I
    found that if not intended, accepting RAs as a router can lead to
    strange unwanted behavior therefore we it seems wise to only do so
    if the user explicitely asks for this behavior.

    Signed-off-by: Thomas Graf
    Signed-off-by: David S. Miller

    Thomas Graf
     

08 Jul, 2010

1 commit


26 Jun, 2010

1 commit

  • The addition of TLLAO option created a kernel OOPS regression
    for the case where neighbor advertisement is being sent via
    proxy path. When using proxy, ipv6_get_ifaddr() returns NULL
    causing the NULL dereference.

    Change causing the bug was:
    commit f7734fdf61ec6bb848e0bafc1fb8bad2c124bb50
    Author: Octavian Purdila
    Date: Fri Oct 2 11:39:15 2009 +0000

    make TLLAO option for NA packets configurable

    Signed-off-by: Stephen Hemminger
    Acked-by: YOSHIFUJI Hideaki
    Signed-off-by: David S. Miller

    stephen hemminger
     

11 Jun, 2010

1 commit


18 May, 2010

1 commit

  • This patch removes from net/ (but not any netfilter files)
    all the unnecessary return; statements that precede the
    last closing brace of void functions.

    It does not remove the returns that are immediately
    preceded by a label as gcc doesn't like that.

    Done via:
    $ grep -rP --include=*.[ch] -l "return;\n}" net/ | \
    xargs perl -i -e 'local $/ ; while (<>) { s/\n[ \t\n]+return;\n}/\n}/g; print; }'

    Signed-off-by: Joe Perches
    Signed-off-by: David S. Miller

    Joe Perches
     

20 Apr, 2010

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

25 Mar, 2010

1 commit