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
     

13 Jul, 2015

1 commit

  • Commit 514ac99c64b "can: fix multiple delivery of a single CAN frame for
    overlapping CAN filters" requires the skb->tstamp to be set to check for
    identical CAN skbs.

    Without timestamping to be required by user space applications this timestamp
    was not generated which lead to commit 36c01245eb8 "can: fix loss of CAN frames
    in raw_rcv" - which forces the timestamp to be set in all CAN related skbuffs
    by introducing several __net_timestamp() calls.

    This forces e.g. out of tree drivers which are not using alloc_can{,fd}_skb()
    to add __net_timestamp() after skbuff creation to prevent the frame loss fixed
    in mainline Linux.

    This patch removes the timestamp dependency and uses an atomic counter to
    create an unique identifier together with the skbuff pointer.

    Btw: the new skbcnt element introduced in struct can_skb_priv has to be
    initialized with zero in out-of-tree drivers which are not using
    alloc_can{,fd}_skb() too.

    Signed-off-by: Oliver Hartkopp
    Cc: linux-stable
    Signed-off-by: Marc Kleine-Budde

    Oliver Hartkopp
     

23 Mar, 2015

1 commit


19 May, 2014

1 commit

  • Armin pointed me to the fact that the identifier which is used to ensure the
    unique include processing in lunux/include/uapi/linux/can.h is CAN_H.
    This clashed with his own source as includes from libraries and APIs should
    use an underscore '_' at the identifier start.

    This patch fixes the protection identifiers in all CAN relavant includes.

    Reported-by: Armin Burchardt
    Signed-off-by: Oliver Hartkopp
    Signed-off-by: Marc Kleine-Budde

    Oliver Hartkopp
     

31 Jan, 2014

1 commit

  • Self generated skbuffs in net/can/bcm.c are setting a skb->sk reference but
    no explicit destructor which is enforced since Linux 3.11 with commit
    376c7311bdb6 (net: add a temporary sanity check in skb_orphan()).

    This patch adds some helper functions to make sure that a destructor is
    properly defined when a sock reference is assigned to a CAN related skb.
    To create an unshared skb owned by the original sock a common helper function
    has been introduced to replace open coded functions to create CAN echo skbs.

    Signed-off-by: Oliver Hartkopp
    Tested-by: Andre Naujoks
    Reviewed-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Oliver Hartkopp
     

29 Jan, 2013

1 commit


26 Jan, 2013

1 commit

  • The struct can_skb_priv is used to transport additional information along
    with the stored struct can(fd)_frame that can not be contained in existing
    struct sk_buff elements.

    can_skb_priv is located in the skb headroom, which does not touch the existing
    CAN sk_buff usage with skb->data and skb->len, so that even out-of-tree
    CAN drivers can be used without changes.

    Btw. out-of-tree CAN drivers without can_skb_priv in the sk_buff headroom
    would not support features based on can_skb_priv.

    The can_skb_priv->ifindex contains the first interface where the CAN frame
    appeared on the local host. Unfortunately skb->skb_iif can not be used as this
    value is overwritten in every netif_receive_skb() call.

    Signed-off-by: Oliver Hartkopp
    Signed-off-by: Marc Kleine-Budde

    Oliver Hartkopp