Eric Lee / smarc-ti-linux-kernel

30 Aug, 2014

1 commit

01 Aug, 2014

1 commit

  • 7304fe468   net: fix the counter ICMP_MIB_INERRORS/ICMP6_MIB_INERRORS ... Browse Code »

    When dealing with ICMPv[46] Error Message, function icmp_socket_deliver()
    and icmpv6_notify() do some valid checks on packet's length, but then some
    protocols check packet's length redaudantly. So remove those duplicated
    statements, and increase counter ICMP_MIB_INERRORS/ICMP6_MIB_INERRORS in
    function icmp_socket_deliver() and icmpv6_notify() respectively.

    In addition, add missed counter in udp6/udplite6 when socket is NULL.

    Signed-off-by: Duan Jiong
    Acked-by: Hannes Frederic Sowa
    Signed-off-by: David S. Miller

    Duan Jiong
     

22 Jan, 2014

3 commits

27 Dec, 2013

3 commits

23 Dec, 2013

1 commit

22 Dec, 2013

2 commits

21 Dec, 2013

1 commit

19 Dec, 2013

1 commit

  • 93b36cf34   ipv6: support IPV6_PMTU_INTERFACE on sockets ... Browse Code »

    IPV6_PMTU_INTERFACE is the same as IPV6_PMTU_PROBE for ipv6. Add it
    nontheless for symmetry with IPv4 sockets. Also drop incoming MTU
    information if this mode is enabled.

    The additional bit in ipv6_pinfo just eats in the padding behind the
    bitfield. There are no changes to the layout of the struct at all.

    Signed-off-by: Hannes Frederic Sowa
    Signed-off-by: David S. Miller

    Hannes Frederic Sowa
     

12 Dec, 2013

1 commit

  • e47726683   sctp: remove redundant null check on asoc ... Browse Code »

    In sctp_err_lookup, goto out while the asoc is not NULL, so remove the
    check NULL. Also, in sctp_err_finish which called by sctp_v4_err and
    sctp_v6_err, they pass asoc to sctp_err_finish while the asoc is not
    NULL, so remove the check.

    Signed-off-by: Wang Weidong
    Acked-by: Neil Horman
    Acked-by: Vlad Yasevich
    Signed-off-by: David S. Miller

    wangweidong
     

07 Dec, 2013

1 commit

  • 4b2f13a25   sctp: Fix FSF address in file headers ... Browse Code »

    Several files refer to an old address for the Free Software Foundation
    in the file header comment. Resolve by replacing the address with
    the URL so that we do not have to keep
    updating the header comments anytime the address changes.

    CC: Vlad Yasevich
    CC: Neil Horman
    Signed-off-by: Jeff Kirsher
    Signed-off-by: David S. Miller

    Jeff Kirsher
     

17 Sep, 2013

1 commit

  • 3f96a5321   net: sctp: rfc4443: do not report ICMP redirects to user space ... Browse Code »

    Adapt the same behaviour for SCTP as present in TCP for ICMP redirect
    messages. For IPv6, RFC4443, section 2.4. says:

    ...
    (e) An ICMPv6 error message MUST NOT be originated as a result of
    receiving the following:
    ...
    (e.2) An ICMPv6 redirect message [IPv6-DISC].
    ...

    Therefore, do not report an error to user space, just invoke dst's redirect
    callback and leave, same for IPv4 as done in TCP as well. The implication
    w/o having this patch could be that the reception of such packets would
    generate a poll notification and in worst case it could even tear down the
    whole connection. Therefore, stop updating sk_err on redirects.

    Reported-by: Duan Jiong
    Reported-by: Hannes Frederic Sowa
    Suggested-by: Vlad Yasevich
    Signed-off-by: Daniel Borkmann
    Signed-off-by: David S. Miller

    Daniel Borkmann
     

10 Aug, 2013

3 commits

28 Jul, 2013

1 commit

25 Jul, 2013

1 commit

  • 91705c61b   net: sctp: trivial: update mailing list address ... Browse Code »

    The SCTP mailing list address to send patches or questions
    to is linux-sctp@vger.kernel.org and not
    lksctp-developers@lists.sourceforge.net anymore. Therefore,
    update all occurences.

    Signed-off-by: Daniel Borkmann
    Acked-by: Neil Horman
    Acked-by: Vlad Yasevich
    Signed-off-by: David S. Miller

    Daniel Borkmann
     

02 Jul, 2013

1 commit

  • bb33381d0   net: sctp: rework debugging framework to use pr_debug and friends ... Browse Code »

    We should get rid of all own SCTP debug printk macros and use the ones
    that the kernel offers anyway instead. This makes the code more readable
    and conform to the kernel code, and offers all the features of dynamic
    debbuging that pr_debug() et al has, such as only turning on/off portions
    of debug messages at runtime through debugfs. The runtime cost of having
    CONFIG_DYNAMIC_DEBUG enabled, but none of the debug statements printing,
    is negligible [1]. If kernel debugging is completly turned off, then these
    statements will also compile into "empty" functions.

    While we're at it, we also need to change the Kconfig option as it /now/
    only refers to the ifdef'ed code portions in outqueue.c that enable further
    debugging/tracing of SCTP transaction fields. Also, since SCTP_ASSERT code
    was enabled with this Kconfig option and has now been removed, we
    transform those code parts into WARNs resp. where appropriate BUG_ONs so
    that those bugs can be more easily detected as probably not many people
    have SCTP debugging permanently turned on.

    To turn on all SCTP debugging, the following steps are needed:

    # mount -t debugfs none /sys/kernel/debug
    # echo -n 'module sctp +p' > /sys/kernel/debug/dynamic_debug/control

    This can be done more fine-grained on a per file, per line basis and others
    as described in [2].

    [1] https://www.kernel.org/doc/ols/2009/ols2009-pages-39-46.pdf
    [2] Documentation/dynamic-debug-howto.txt

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

    Daniel Borkmann
     

18 Jun, 2013

1 commit

  • dda919285   net: sctp: remove SCTP_STATIC macro ... Browse Code »

    SCTP_STATIC is just another define for the static keyword. It's use
    is inconsistent in the SCTP code anyway and it was introduced in the
    initial implementation of SCTP in 2.5. We have a regression suite in
    lksctp-tools, but this is for user space only, so noone makes use of
    this macro anymore. The kernel test suite for 2.5 is incompatible with
    the current SCTP code anyway.

    So simply Remove it, to be more consistent with the rest of the kernel
    code.

    Signed-off-by: Daniel Borkmann
    Acked-by: Vlad Yasevich
    Signed-off-by: David S. Miller

    Daniel Borkmann
     

31 May, 2013

1 commit

29 May, 2013

1 commit

28 Feb, 2013

1 commit

  • b67bfe0d4   hlist: drop the node parameter from iterators ... Browse Code »
    26

    I'm not sure why, but the hlist for each entry iterators were conceived

    list_for_each_entry(pos, head, member)

    The hlist ones were greedy and wanted an extra parameter:

    hlist_for_each_entry(tpos, pos, head, member)

    Why did they need an extra pos parameter? I'm not quite sure. Not only
    they don't really need it, it also prevents the iterator from looking
    exactly like the list iterator, which is unfortunate.

    Besides the semantic patch, there was some manual work required:

    - Fix up the actual hlist iterators in linux/list.h
    - Fix up the declaration of other iterators based on the hlist ones.
    - A very small amount of places were using the 'node' parameter, this
    was modified to use 'obj->member' instead.
    - Coccinelle didn't handle the hlist_for_each_entry_safe iterator
    properly, so those had to be fixed up manually.

    The semantic patch which is mostly the work of Peter Senna Tschudin is here:

    @@
    iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;

    type T;
    expression a,c,d,e;
    identifier b;
    statement S;
    @@

    -T b;

    [akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
    [akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
    [akpm@linux-foundation.org: checkpatch fixes]
    [akpm@linux-foundation.org: fix warnings]
    [akpm@linux-foudnation.org: redo intrusive kvm changes]
    Tested-by: Peter Senna Tschudin
    Acked-by: Paul E. McKenney
    Signed-off-by: Sasha Levin
    Cc: Wu Fengguang
    Cc: Marcelo Tosatti
    Cc: Gleb Natapov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sasha Levin
     

05 Feb, 2013

1 commit

05 Oct, 2012

1 commit

15 Aug, 2012

6 commits

20 Jul, 2012

1 commit

17 Jul, 2012

2 commits

  • 6700c2709   net: Pass optional SKB and SK arguments to dst_ops->{update_pmtu,redirect}() ... Browse Code »

    This will be used so that we can compose a full flow key.

    Even though we have a route in this context, we need more. In the
    future the routes will be without destination address, source address,
    etc. keying. One ipv4 route will cover entire subnets, etc.

    In this environment we have to have a way to possess persistent storage
    for redirects and PMTU information. This persistent storage will exist
    in the FIB tables, and that's why we'll need to be able to rebuild a
    full lookup flow key here. Using that flow key will do a fib_lookup()
    and create/update the persistent entry.

    Signed-off-by: David S. Miller

    David S. Miller
     
  • 2eebc1e18   sctp: Fix list corruption resulting from freeing an association on a list ... Browse Code »

    A few days ago Dave Jones reported this oops:

    [22766.294255] general protection fault: 0000 [#1] PREEMPT SMP
    [22766.295376] CPU 0
    [22766.295384] Modules linked in:
    [22766.387137] ffffffffa169f292 6b6b6b6b6b6b6b6b ffff880147c03a90
    ffff880147c03a74
    [22766.387135] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000
    [22766.387136] Process trinity-watchdo (pid: 10896, threadinfo ffff88013e7d2000,
    [22766.387137] Stack:
    [22766.387140] ffff880147c03a10
    [22766.387140] ffffffffa169f2b6
    [22766.387140] ffff88013ed95728
    [22766.387143] 0000000000000002
    [22766.387143] 0000000000000000
    [22766.387143] ffff880003fad062
    [22766.387144] ffff88013c120000
    [22766.387144]
    [22766.387145] Call Trace:
    [22766.387145]
    [22766.387150] [] ? __sctp_lookup_association+0x62/0xd0
    [sctp]
    [22766.387154] [] __sctp_lookup_association+0x86/0xd0 [sctp]
    [22766.387157] [] sctp_rcv+0x207/0xbb0 [sctp]
    [22766.387161] [] ? trace_hardirqs_off_caller+0x28/0xd0
    [22766.387163] [] ? nf_hook_slow+0x133/0x210
    [22766.387166] [] ? ip_local_deliver_finish+0x4c/0x4c0
    [22766.387168] [] ip_local_deliver_finish+0x18d/0x4c0
    [22766.387169] [] ? ip_local_deliver_finish+0x4c/0x4c0
    [22766.387171] [] ip_local_deliver+0x47/0x80
    [22766.387172] [] ip_rcv_finish+0x150/0x680
    [22766.387174] [] ip_rcv+0x214/0x320
    [22766.387176] [] __netif_receive_skb+0x7b7/0x910
    [22766.387178] [] ? __netif_receive_skb+0x11c/0x910
    [22766.387180] [] ? put_lock_stats.isra.25+0xe/0x40
    [22766.387182] [] netif_receive_skb+0x23/0x1f0
    [22766.387183] [] ? dev_gro_receive+0x139/0x440
    [22766.387185] [] napi_skb_finish+0x70/0xa0
    [22766.387187] [] napi_gro_receive+0xf5/0x130
    [22766.387218] [] e1000_receive_skb+0x59/0x70 [e1000e]
    [22766.387242] [] e1000_clean_rx_irq+0x28b/0x460 [e1000e]
    [22766.387266] [] e1000e_poll+0x78/0x430 [e1000e]
    [22766.387268] [] net_rx_action+0x1aa/0x3d0
    [22766.387270] [] ? account_system_vtime+0x10f/0x130
    [22766.387273] [] __do_softirq+0xe0/0x420
    [22766.387275] [] call_softirq+0x1c/0x30
    [22766.387278] [] do_softirq+0xd5/0x110
    [22766.387279] [] irq_exit+0xd5/0xe0
    [22766.387281] [] do_IRQ+0x63/0xd0
    [22766.387283] [] common_interrupt+0x6f/0x6f
    [22766.387283]
    [22766.387284]
    [22766.387285] [] ? retint_swapgs+0x13/0x1b
    [22766.387285] Code: c0 90 5d c3 66 0f 1f 44 00 00 4c 89 c8 5d c3 0f 1f 00 55 48
    89 e5 48 83
    ec 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 b7 87 98 00 00 00
    48 89 fb
    49 89 f5 66 c1 c0 08 66 39 46 02
    [22766.387307]
    [22766.387307] RIP
    [22766.387311] [] sctp_assoc_is_match+0x19/0x90 [sctp]
    [22766.387311] RSP
    [22766.387142] ffffffffa16ab120
    [22766.599537] ---[ end trace 3f6dae82e37b17f5 ]---
    [22766.601221] Kernel panic - not syncing: Fatal exception in interrupt

    It appears from his analysis and some staring at the code that this is likely
    occuring because an association is getting freed while still on the
    sctp_assoc_hashtable. As a result, we get a gpf when traversing the hashtable
    while a freed node corrupts part of the list.

    Nominally I would think that an mibalanced refcount was responsible for this,
    but I can't seem to find any obvious imbalance. What I did note however was
    that the two places where we create an association using
    sctp_primitive_ASSOCIATE (__sctp_connect and sctp_sendmsg), have failure paths
    which free a newly created association after calling sctp_primitive_ASSOCIATE.
    sctp_primitive_ASSOCIATE brings us into the sctp_sf_do_prm_asoc path, which
    issues a SCTP_CMD_NEW_ASOC side effect, which in turn adds a new association to
    the aforementioned hash table. the sctp command interpreter that process side
    effects has not way to unwind previously processed commands, so freeing the
    association from the __sctp_connect or sctp_sendmsg error path would lead to a
    freed association remaining on this hash table.

    I've fixed this but modifying sctp_[un]hash_established to use hlist_del_init,
    which allows us to proerly use hlist_unhashed to check if the node is on a
    hashlist safely during a delete. That in turn alows us to safely call
    sctp_unhash_established in the __sctp_connect and sctp_sendmsg error paths
    before freeing them, regardles of what the associations state is on the hash
    list.

    I noted, while I was doing this, that the __sctp_unhash_endpoint was using
    hlist_unhsashed in a simmilar fashion, but never nullified any removed nodes
    pointers to make that function work properly, so I fixed that up in a simmilar
    fashion.

    I attempted to test this using a virtual guest running the SCTP_RR test from
    netperf in a loop while running the trinity fuzzer, both in a loop. I wasn't
    able to recreate the problem prior to this fix, nor was I able to trigger the
    failure after (neither of which I suppose is suprising). Given the trace above
    however, I think its likely that this is what we hit.

    Signed-off-by: Neil Horman
    Reported-by: davej@redhat.com
    CC: davej@redhat.com
    CC: "David S. Miller"
    CC: Vlad Yasevich
    CC: Sridhar Samudrala
    CC: linux-sctp@vger.kernel.org
    Signed-off-by: David S. Miller

    Neil Horman
     

16 Jul, 2012

1 commit

12 Jul, 2012

2 commits