02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

28 Apr, 2017

1 commit


15 Apr, 2017

2 commits

  • This function is now obsolete and always returns false.
    This change has no effect on generated code.

    Signed-off-by: Florian Westphal
    Signed-off-by: Pablo Neira Ayuso

    Florian Westphal
     
  • resurrect an old patch from Pablo Neira to remove the untracked objects.

    Currently, there are four possible states of an skb wrt. conntrack.

    1. No conntrack attached, ct is NULL.
    2. Normal (kmem cache allocated) ct attached.
    3. a template (kmalloc'd), not in any hash tables at any point in time
    4. the 'untracked' conntrack, a percpu nf_conn object, tagged via
    IPS_UNTRACKED_BIT in ct->status.

    Untracked is supposed to be identical to case 1. It exists only
    so users can check

    -m conntrack --ctstate UNTRACKED vs.
    -m conntrack --ctstate INVALID

    e.g. attempts to set connmark on INVALID or UNTRACKED conntracks is
    supposed to be a no-op.

    Thus currently we need to check
    ct == NULL || nf_ct_is_untracked(ct)

    in a lot of places in order to avoid altering untracked objects.

    The other consequence of the percpu untracked object is that all
    -j NOTRACK (and, later, kfree_skb of such skbs) result in an atomic op
    (inc/dec the untracked conntracks refcount).

    This adds a new kernel-private ctinfo state, IP_CT_UNTRACKED, to
    make the distinction instead.

    The (few) places that care about packet invalid (ct is NULL) vs.
    packet untracked now need to test ct == NULL vs. ctinfo == IP_CT_UNTRACKED,
    but all other places can omit the nf_ct_is_untracked() check.

    Signed-off-by: Florian Westphal
    Signed-off-by: Pablo Neira Ayuso

    Florian Westphal
     

17 Mar, 2017

1 commit

  • refcount_t type and corresponding API (see include/linux/refcount.h)
    should be used instead of atomic_t when the variable is used as
    a reference counter. This allows to avoid accidental
    refcounter overflows that might lead to use-after-free
    situations.

    Signed-off-by: Elena Reshetova
    Signed-off-by: Hans Liljestrand
    Signed-off-by: Kees Cook
    Signed-off-by: David Windsor
    Signed-off-by: Pablo Neira Ayuso

    Reshetova, Elena
     

02 Feb, 2017

3 commits

  • Currently, the ip_vs_dest cache frees ip_vs_dest objects when their
    reference count becomes < 0. Aside from not being semantically sound,
    this is problematic for the new type refcount_t, which will be introduced
    shortly in a separate patch. refcount_t is the new kernel type for
    holding reference counts, and provides overflow protection and a
    constrained interface relative to atomic_t (the type currently being
    used for kernel reference counts).

    Per Julian Anastasov: "The problem is that dest_trash currently holds
    deleted dests (unlinked from RCU lists) with refcnt=0." Changing
    dest_trash to hold dest with refcnt=1 will allow us to free ip_vs_dest
    structs when their refcnt=0, in ip_vs_dest_put_and_free().

    Signed-off-by: David Windsor
    Signed-off-by: Julian Anastasov
    Signed-off-by: Simon Horman
    Signed-off-by: Pablo Neira Ayuso

    David Windsor
     
  • Add a helper to assign a nf_conn entry and the ctinfo bits to an sk_buff.
    This avoids changing code in followup patch that merges skb->nfct and
    skb->nfctinfo into skb->_nfct.

    Signed-off-by: Florian Westphal
    Signed-off-by: Pablo Neira Ayuso

    Florian Westphal
     
  • Next patch makes direct skb->nfct access illegal, reduce noise
    in next patch by using accessors we already have.

    Signed-off-by: Florian Westphal
    Signed-off-by: Pablo Neira Ayuso

    Florian Westphal
     

06 Jun, 2016

1 commit

  • Previous patch that introduced handling of outgoing packets in SIP
    persistent-engine did not call ip_vs_check_template() in case packet was
    matching a connection template. Assumption was that real-server was
    healthy, since it was sending a packet just in that moment.

    There are however real-server fault conditions requiring that association
    between call-id and real-server (represented by connection template)
    gets updated. Here is an example of the sequence of events:
    1) RS1 is a back2back user agent that handled call-id1 and call-id2
    2) RS1 is down and was marked as unavailable
    3) new message from outside comes to IPVS with call-id1
    4) IPVS reschedules the message to RS2, which becomes new call handler
    5) RS2 forwards the message outside, translating call-id1 to call-id2
    6) inside pe->conn_out() IPVS matches call-id2 with existing template
    7) IPVS does not change association call-id2 RS1
    8) new message comes from client with call-id2
    9) IPVS reschedules the message to a real-server potentially different
    from RS2, which is now the correct destination

    This patch introduces ip_vs_check_template() call in the handling of
    outgoing packets for SIP-pe. And also introduces a second optional
    argument for ip_vs_check_template() that allows to check if dest
    associated to a connection template is the same dest that was identified
    as the source of the packet. This is to change the real-server bound to a
    particular call-id independently from its availability status: the idea
    is that it's more reliable, for in->out direction (where internal
    network can be considered trusted), to always associate a call-id with
    the last real-server that used it in one of its messages. Think about
    above sequence of events where, just after step 5, RS1 returns instead
    to be available.

    Comparison of dests is done by simply comparing pointers to struct
    ip_vs_dest; there should be no cases where struct ip_vs_dest keeps its
    memory address, but represent a different real-server in terms of
    ip-address / port.

    Fixes: 39b972231536 ("ipvs: handle connections started by real-servers")
    Signed-off-by: Marco Angaroni
    Acked-by: Julian Anastasov
    Signed-off-by: Simon Horman

    Marco Angaroni
     

20 Apr, 2016

1 commit

  • When using LVS-NAT and SIP persistence-egine over UDP, the following
    limitations are present with current implementation:

    1) To actually have load-balancing based on Call-ID header, you need to
    use one-packet-scheduling mode. But with one-packet-scheduling the
    connection is deleted just after packet is forwarded, so SIP responses
    coming from real-servers do not match any connection and SNAT is
    not applied.

    2) If you do not use "-o" option, IPVS behaves as normal UDP load
    balancer, so different SIP calls (each one identified by a different
    Call-ID) coming from the same ip-address/port go to the same
    real-server. So basically you don’t have load-balancing based on
    Call-ID as intended.

    3) Call-ID is not learned when a new SIP call is started by a real-server
    (inside-to-outside direction), but only in the outside-to-inside
    direction. This would be a general problem for all SIP servers acting
    as Back2BackUserAgent.

    This patch aims to solve problems 1) and 3) while keeping OPS mode
    mandatory for SIP-UDP, so that 2) is not a problem anymore.

    The basic mechanism implemented is to make packets, that do not match any
    existent connection but come from real-servers, create new connections
    instead of let them pass without any effect.
    When such packets pass through ip_vs_out(), if their source ip address and
    source port match a configured real-server, a new connection is
    automatically created in the same way as it would have happened if the
    packet had come from outside-to-inside direction. A new connection template
    is created too if the virtual-service is persistent and there is no
    matching connection template found. The new connection automatically
    created, if the service had "-o" option, is an OPS connection that lasts
    only the time to forward the packet, just like it happens on the
    ingress side.

    The main part of this mechanism is implemented inside a persistent-engine
    specific callback (at the moment only SIP persistent engine exists) and
    is triggered only for UDP packets, since connection oriented protocols, by
    using different set of ports (typically ephemeral ports) to open new
    outgoing connections, should not need this feature.

    The following requisites are needed for automatic connection creation; if
    any is missing the packet simply goes the same way as before.
    a) virtual-service is not fwmark based (this is because fwmark services
    do not store address and port of the virtual-service, required to
    build the connection data).
    b) virtual-service and real-servers must not have been configured with
    omitted port (this is again to have all data to create the connection).

    Signed-off-by: Marco Angaroni
    Acked-by: Julian Anastasov
    Signed-off-by: Simon Horman

    Marco Angaroni
     

07 Mar, 2016

1 commit

  • Jiri Bohac is reporting for a problem where the attempt
    to reschedule existing connection to another real server
    needs proper redirect for the conntrack used by the IPVS
    connection. For example, when IPVS connection is created
    to NAT-ed real server we alter the reply direction of
    conntrack. If we later decide to select different real
    server we can not alter again the conntrack. And if we
    expire the old connection, the new connection is left
    without conntrack.

    So, the only way to redirect both the IPVS connection and
    the Netfilter's conntrack is to drop the SYN packet that
    hits existing connection, to wait for the next jiffie
    to expire the old connection and its conntrack and to rely
    on client's retransmission to create new connection as
    usually.

    Jiri Bohac provided a fix that drops all SYNs on rescheduling,
    I extended his patch to do such drops only for connections
    that use conntrack. Here is the original report from Jiri Bohac:

    Since commit dc7b3eb900aa ("ipvs: Fix reuse connection if real server
    is dead"), new connections to dead servers are redistributed
    immediately to new servers. The old connection is expired using
    ip_vs_conn_expire_now() which sets the connection timer to expire
    immediately.

    However, before the timer callback, ip_vs_conn_expire(), is run
    to clean the connection's conntrack entry, the new redistributed
    connection may already be established and its conntrack removed
    instead.

    Fix this by dropping the first packet of the new connection
    instead, like we do when the destination server is not available.
    The timer will have deleted the old conntrack entry long before
    the first packet of the new connection is retransmitted.

    Fixes: dc7b3eb900aa ("ipvs: Fix reuse connection if real server is dead")
    Signed-off-by: Jiri Bohac
    Signed-off-by: Julian Anastasov
    Signed-off-by: Simon Horman

    Julian Anastasov
     

24 Sep, 2015

29 commits