31 Jan, 2019

1 commit

  • commit 93171ba6f1deffd82f381d36cb13177872d023f6 upstream.

    Kyungtae Kim detected a potential integer overflow in bcm_[rx|tx]_setup()
    when the conversion into ktime multiplies the given value with NSEC_PER_USEC
    (1000).

    Reference: https://marc.info/?l=linux-can&m=154732118819828&w=2

    Add a check for the given tv_usec, so that the value stays below one second.
    Additionally limit the tv_sec value to a reasonable value for CAN related
    use-cases of 400 days and ensure all values to be positive.

    Reported-by: Kyungtae Kim
    Tested-by: Oliver Hartkopp
    Signed-off-by: Oliver Hartkopp
    Cc: linux-stable # >= 2.6.26
    Tested-by: Kyungtae Kim
    Acked-by: Andre Naujoks
    Signed-off-by: Marc Kleine-Budde
    Signed-off-by: Greg Kroah-Hartman

    Oliver Hartkopp
     

23 Jan, 2019

1 commit

  • commit 0aaa81377c5a01f686bcdb8c7a6929a7bf330c68 upstream.

    Muyu Yu provided a POC where user root with CAP_NET_ADMIN can create a CAN
    frame modification rule that makes the data length code a higher value than
    the available CAN frame data size. In combination with a configured checksum
    calculation where the result is stored relatively to the end of the data
    (e.g. cgw_csum_xor_rel) the tail of the skb (e.g. frag_list pointer in
    skb_shared_info) can be rewritten which finally can cause a system crash.

    Michael Kubecek suggested to drop frames that have a DLC exceeding the
    available space after the modification process and provided a patch that can
    handle CAN FD frames too. Within this patch we also limit the length for the
    checksum calculations to the maximum of Classic CAN data length (8).

    CAN frames that are dropped by these additional checks are counted with the
    CGW_DELETED counter which indicates misconfigurations in can-gw rules.

    This fixes CVE-2019-3701.

    Reported-by: Muyu Yu
    Reported-by: Marcus Meissner
    Suggested-by: Michal Kubecek
    Tested-by: Muyu Yu
    Tested-by: Oliver Hartkopp
    Signed-off-by: Oliver Hartkopp
    Cc: linux-stable # >= v3.2
    Signed-off-by: Marc Kleine-Budde
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Oliver Hartkopp
     

01 Dec, 2018

1 commit

  • commit a43608fa77213ad5ac5f75994254b9f65d57cfa0 upstream.

    When the socket is CAN FD enabled it can handle CAN FD frame
    transmissions. Add an additional check in raw_sendmsg() as a CAN2.0 CAN
    driver (non CAN FD) should never see a CAN FD frame. Due to the commonly
    used can_dropped_invalid_skb() function the CAN 2.0 driver would drop
    that CAN FD frame anyway - but with this patch the user gets a proper
    -EINVAL return code.

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

    Oliver Hartkopp
     

24 Jan, 2018

2 commits

  • commit d4689846881d160a4d12a514e991a740bcb5d65a upstream.

    If an invalid CANFD frame is received, from a driver or from a tun
    interface, a Kernel warning is generated.

    This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
    kernel, bootet with panic_on_warn, does not panic. A printk seems to be
    more appropriate here.

    Reported-by: syzbot+e3b775f40babeff6e68b@syzkaller.appspotmail.com
    Suggested-by: Dmitry Vyukov
    Acked-by: Oliver Hartkopp
    Signed-off-by: Marc Kleine-Budde
    Signed-off-by: Greg Kroah-Hartman

    Marc Kleine-Budde
     
  • commit 8cb68751c115d176ec851ca56ecfbb411568c9e8 upstream.

    If an invalid CAN frame is received, from a driver or from a tun
    interface, a Kernel warning is generated.

    This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
    kernel, bootet with panic_on_warn, does not panic. A printk seems to be
    more appropriate here.

    Reported-by: syzbot+4386709c0c1284dca827@syzkaller.appspotmail.com
    Suggested-by: Dmitry Vyukov
    Acked-by: Oliver Hartkopp
    Signed-off-by: Marc Kleine-Budde
    Signed-off-by: Greg Kroah-Hartman

    Marc Kleine-Budde
     

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
     

19 Oct, 2017

3 commits

  • This patch adds the missing check and error handling for out-of-memory
    situations, when kzalloc cannot allocate memory.

    Fixes: cb5635a36776 ("can: complete initial namespace support")
    Acked-by: Oliver Hartkopp
    Cc: linux-stable
    Signed-off-by: Marc Kleine-Budde

    Marc Kleine-Budde
     
  • "proto_tab" is a RCU protected array, when directly accessing the array,
    sparse throws these warnings:

    CHECK /srv/work/frogger/socketcan/linux/net/can/af_can.c
    net/can/af_can.c:115:14: error: incompatible types in comparison expression (different address spaces)
    net/can/af_can.c:795:17: error: incompatible types in comparison expression (different address spaces)
    net/can/af_can.c:816:9: error: incompatible types in comparison expression (different address spaces)

    This patch fixes the problem by using rcu_access_pointer() and
    annotating "proto_tab" array as __rcu.

    Signed-off-by: Marc Kleine-Budde

    Marc Kleine-Budde
     
  • The assignment of net via call sock_net will dereference sk. This
    is performed before a sanity null check on sk, so there could be
    a potential null dereference on the sock_net call if sk is null.
    Fix this by assigning net after the sk null check. Also replace
    the sk == NULL with the more usual !sk idiom.

    Detected by CoverityScan CID#1431862 ("Dereference before null check")

    Fixes: 384317ef4187 ("can: network namespace support for CAN_BCM protocol")
    Signed-off-by: Colin Ian King
    Acked-by: Oliver Hartkopp
    Signed-off-by: Marc Kleine-Budde

    Colin Ian King
     

10 Aug, 2017

1 commit

  • This change allows us to later indicate to rtnetlink core that certain
    doit functions should be called without acquiring rtnl_mutex.

    This change should have no effect, we simply replace the last (now
    unused) calcit argument with the new flag.

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

    Florian Westphal
     

16 Jun, 2017

1 commit

  • A common pattern with skb_put() is to just want to memcpy()
    some data into the new space, introduce skb_put_data() for
    this.

    An spatch similar to the one for skb_put_zero() converts many
    of the places using it:

    @@
    identifier p, p2;
    expression len, skb, data;
    type t, t2;
    @@
    (
    -p = skb_put(skb, len);
    +p = skb_put_data(skb, data, len);
    |
    -p = (t)skb_put(skb, len);
    +p = skb_put_data(skb, data, len);
    )
    (
    p2 = (t2)p;
    -memcpy(p2, data, len);
    |
    -memcpy(p, data, len);
    )

    @@
    type t, t2;
    identifier p, p2;
    expression skb, data;
    @@
    t *p;
    ...
    (
    -p = skb_put(skb, sizeof(t));
    +p = skb_put_data(skb, data, sizeof(t));
    |
    -p = (t *)skb_put(skb, sizeof(t));
    +p = skb_put_data(skb, data, sizeof(t));
    )
    (
    p2 = (t2)p;
    -memcpy(p2, data, sizeof(*p));
    |
    -memcpy(p, data, sizeof(*p));
    )

    @@
    expression skb, len, data;
    @@
    -memcpy(skb_put(skb, len), data, len);
    +skb_put_data(skb, data, len);

    (again, manually post-processed to retain some comments)

    Reviewed-by: Stephen Hemminger
    Signed-off-by: Johannes Berg
    Signed-off-by: David S. Miller

    Johannes Berg
     

09 Jun, 2017

1 commit

  • This patch uses spin_lock_init() instead of __SPIN_LOCK_UNLOCKED() to
    initialize the per namespace net->can.can_rcvlists_lock lock to fix this
    lockdep warning:

    | INFO: trying to register non-static key.
    | the code is fine but needs lockdep annotation.
    | turning off the locking correctness validator.
    | CPU: 0 PID: 186 Comm: candump Not tainted 4.12.0-rc3+ #47
    | Hardware name: Marvell Kirkwood (Flattened Device Tree)
    | [] (unwind_backtrace) from [] (show_stack+0x18/0x1c)
    | [] (show_stack) from [] (register_lock_class+0x1e4/0x55c)
    | [] (register_lock_class) from [] (__lock_acquire+0x148/0x1990)
    | [] (__lock_acquire) from [] (lock_acquire+0x174/0x210)
    | [] (lock_acquire) from [] (_raw_spin_lock+0x50/0x88)
    | [] (_raw_spin_lock) from [] (can_rx_register+0x94/0x15c [can])
    | [] (can_rx_register [can]) from [] (raw_enable_filters+0x60/0xc0 [can_raw])
    | [] (raw_enable_filters [can_raw]) from [] (raw_enable_allfilters+0x2c/0xa0 [can_raw])
    | [] (raw_enable_allfilters [can_raw]) from [] (raw_bind+0xb0/0x250 [can_raw])
    | [] (raw_bind [can_raw]) from [] (SyS_bind+0x70/0xac)
    | [] (SyS_bind) from [] (ret_fast_syscall+0x0/0x1c)

    Cc: Mario Kicherer
    Acked-by: Oliver Hartkopp
    Signed-off-by: Marc Kleine-Budde

    Marc Kleine-Budde
     

27 Apr, 2017

1 commit

  • The introduced namespace support moved the BCM variables for procfs into a
    per-net data structure. This leads to a build failure with disabled procfs:

    on x86_64:

    when CONFIG_PROC_FS is not enabled:

    ../net/can/bcm.c:1541:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
    ../net/can/bcm.c:1601:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
    ../net/can/bcm.c:1696:11: error: 'struct netns_can' has no member named 'bcmproc_dir'
    ../net/can/bcm.c:1707:15: error: 'struct netns_can' has no member named 'bcmproc_dir'

    http://marc.info/?l=linux-can&m=149321842526524&w=2

    Reported-by: Randy Dunlap
    Signed-off-by: Oliver Hartkopp
    Signed-off-by: Marc Kleine-Budde

    Oliver Hartkopp
     

25 Apr, 2017

6 commits


18 Apr, 2017

1 commit

  • Add netlink_ext_ack arg to rtnl_doit_func. Pass extack arg to nlmsg_parse
    for doit functions that call it directly.

    This is the first step to using extended error reporting in rtnetlink.
    >From here individual subsystems can be updated to set netlink_ext_ack as
    needed.

    Signed-off-by: David Ahern
    Signed-off-by: David S. Miller

    David Ahern
     

14 Apr, 2017

1 commit


04 Apr, 2017

1 commit

  • This patch adds initial support for network namespaces. The changes only
    enable support in the CAN raw, proc and af_can code. GW and BCM still
    have their checks that ensure that they are used only from the main
    namespace.

    The patch boils down to moving the global structures, i.e. the global
    filter list and their /proc stats, into a per-namespace structure and passing
    around the corresponding "struct net" in a lot of different places.

    Changes since v1:
    - rebased on current HEAD (2bfe01e)
    - fixed overlong line

    Signed-off-by: Mario Kicherer
    Signed-off-by: Marc Kleine-Budde

    Mario Kicherer
     

30 Jan, 2017

2 commits

  • When removing a bcm tx operation either a hrtimer or a tasklet might run.
    As the hrtimer triggers its associated tasklet and vice versa we need to
    take care to mutually terminate both handlers.

    Reported-by: Michael Josenhans
    Signed-off-by: Oliver Hartkopp
    Tested-by: Michael Josenhans
    Cc: linux-stable
    Signed-off-by: Marc Kleine-Budde

    Oliver Hartkopp
     
  • Zhang Yanmin reported crashes [1] and provided a patch adding a
    synchronize_rcu() call in can_rx_unregister()

    The main problem seems that the sockets themselves are not RCU
    protected.

    If CAN uses RCU for delivery, then sockets should be freed only after
    one RCU grace period.

    Recent kernels could use sock_set_flag(sk, SOCK_RCU_FREE), but let's
    ease stable backports with the following fix instead.

    [1]
    BUG: unable to handle kernel NULL pointer dereference at (null)
    IP: [] selinux_socket_sock_rcv_skb+0x65/0x2a0

    Call Trace:

    [] security_sock_rcv_skb+0x4c/0x60
    [] sk_filter+0x41/0x210
    [] sock_queue_rcv_skb+0x53/0x3a0
    [] raw_rcv+0x2a3/0x3c0
    [] can_rcv_filter+0x12b/0x370
    [] can_receive+0xd9/0x120
    [] can_rcv+0xab/0x100
    [] __netif_receive_skb_core+0xd8c/0x11f0
    [] __netif_receive_skb+0x24/0xb0
    [] process_backlog+0x127/0x280
    [] net_rx_action+0x33b/0x4f0
    [] __do_softirq+0x184/0x440
    [] do_softirq_own_stack+0x1c/0x30

    [] do_softirq.part.18+0x3b/0x40
    [] do_softirq+0x1d/0x20
    [] netif_rx_ni+0xe5/0x110
    [] slcan_receive_buf+0x507/0x520
    [] flush_to_ldisc+0x21c/0x230
    [] process_one_work+0x24f/0x670
    [] worker_thread+0x9d/0x6f0
    [] ? rescuer_thread+0x480/0x480
    [] kthread+0x12c/0x150
    [] ret_from_fork+0x3f/0x70

    Reported-by: Zhang Yanmin
    Signed-off-by: Eric Dumazet
    Acked-by: Oliver Hartkopp
    Signed-off-by: David S. Miller

    Eric Dumazet
     

26 Dec, 2016

2 commits

  • ktime_set(S,N) was required for the timespec storage type and is still
    useful for situations where a Seconds and Nanoseconds part of a time value
    needs to be converted. For anything where the Seconds argument is 0, this
    is pointless and can be replaced with a simple assignment.

    Signed-off-by: Thomas Gleixner
    Cc: Peter Zijlstra

    Thomas Gleixner
     
  • ktime is a union because the initial implementation stored the time in
    scalar nanoseconds on 64 bit machine and in a endianess optimized timespec
    variant for 32bit machines. The Y2038 cleanup removed the timespec variant
    and switched everything to scalar nanoseconds. The union remained, but
    become completely pointless.

    Get rid of the union and just keep ktime_t as simple typedef of type s64.

    The conversion was done with coccinelle and some manual mopping up.

    Signed-off-by: Thomas Gleixner
    Cc: Peter Zijlstra

    Thomas Gleixner
     

07 Dec, 2016

1 commit


23 Nov, 2016

1 commit

  • Since commit 6f3b911d5f29b98 ("can: bcm: add support for CAN FD frames") the
    CAN broadcast manager supports CAN and CAN FD data frames.

    As these data frames are embedded in struct can[fd]_frames which have a
    different length the access to the provided array of CAN frames became
    dependend of op->cfsiz. By using a struct canfd_frame pointer for the array of
    CAN frames the new offset calculation based on op->cfsiz was accidently applied
    to CAN FD frame element lengths.

    This fix makes the pointer to the arrays of the different CAN frame types a
    void pointer so that the offset calculation in bytes accesses the correct CAN
    frame elements.

    Reference: http://marc.info/?l=linux-netdev&m=147980658909653

    Reported-by: Andrey Konovalov
    Signed-off-by: Oliver Hartkopp
    Tested-by: Andrey Konovalov
    Cc: linux-stable
    Signed-off-by: Marc Kleine-Budde

    Oliver Hartkopp
     

01 Nov, 2016

1 commit

  • Andrey Konovalov reported an issue with proc_register in bcm.c.
    As suggested by Cong Wang this patch adds a lock_sock() protection and
    a check for unsuccessful proc_create_data() in bcm_connect().

    Reference: http://marc.info/?l=linux-netdev&m=147732648731237

    Reported-by: Andrey Konovalov
    Suggested-by: Cong Wang
    Signed-off-by: Oliver Hartkopp
    Acked-by: Cong Wang
    Tested-by: Andrey Konovalov
    Cc: linux-stable
    Signed-off-by: Marc Kleine-Budde

    Oliver Hartkopp
     

23 Jun, 2016

1 commit

  • The change to leave out procfs support in CAN when CONFIG_PROC_FS
    is not set was incomplete and leads to a build error:

    net/built-in.o: In function `can_init':
    :(.init.text+0x9858): undefined reference to `can_stat_update'
    ERROR: "can_stat_update" [net/can/can.ko] undefined!

    This tries a better approach, encapsulating all of the calls
    within IS_ENABLED(), so we also leave out the timer function
    from the object file.

    Signed-off-by: Arnd Bergmann
    Fixes: a20fadf85312 ("can: build proc support only if CONFIG_PROC_FS is activated")
    Signed-off-by: Marc Kleine-Budde

    Arnd Bergmann
     

17 Jun, 2016

5 commits

  • The programming API of the CAN_BCM depends on struct can_frame which is
    given as array directly behind the bcm_msg_head structure. To follow this
    schema for the CAN FD frames a new flag 'CAN_FD_FRAME' in the bcm_msg_head
    flags indicates that the concatenated CAN frame structures behind the
    bcm_msg_head are defined as struct canfd_frame.

    This patch adds the support to handle CAN and CAN FD frames on a per BCM-op
    base. Main changes:

    - generally use struct canfd_frames instead if struct can_frames
    - use canfd_frame.flags instead of can_frame.can_dlc for private BCM flags
    - make all CAN frame sizes depending on the new CAN_FD_FRAME flags
    - separate between CAN and CAN FD when sending/receiving frames

    Due to the dependence of the CAN_FD_FRAME flag the former binary interface
    for classic CAN frames remains stable.

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

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

    Oliver Hartkopp
     
  • can_frame is the name of the struct can_frame which is not meant in
    the corrected comments.

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

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

    Oliver Hartkopp
     
  • When building can subsystem with CONFIG_PROC_FS=n I detected some unused
    variables warning by using proc functions. In CAN the proc handling is
    nicely placed in one object file. This patch adds simple add a
    dependency on CONFIG_PROC_FS for CAN's proc.o file and corresponding
    static inline no-op functions.

    Signed-off-by: Alexander Aring
    Acked-by: Oliver Hartkopp
    [mkl: provide static inline noops instead of using #ifdefs]
    Signed-off-by: Marc Kleine-Budde

    Alexander Aring
     

05 Apr, 2016

1 commit

  • Currently, SOL_TIMESTAMPING can only be enabled using setsockopt.
    This is very costly when users want to sample writes to gather
    tx timestamps.

    Add support for enabling SO_TIMESTAMPING via control messages by
    using tsflags added in `struct sockcm_cookie` (added in the previous
    patches in this series) to set the tx_flags of the last skb created in
    a sendmsg. With this patch, the timestamp recording bits in tx_flags
    of the skbuff is overridden if SO_TIMESTAMPING is passed in a cmsg.

    Please note that this is only effective for overriding the recording
    timestamps flags. Users should enable timestamp reporting (e.g.,
    SOF_TIMESTAMPING_SOFTWARE | SOF_TIMESTAMPING_OPT_ID) using
    socket options and then should ask for SOF_TIMESTAMPING_TX_*
    using control messages per sendmsg to sample timestamps for each
    write.

    Signed-off-by: Soheil Hassas Yeganeh
    Acked-by: Willem de Bruijn
    Signed-off-by: David S. Miller

    Soheil Hassas Yeganeh
     

13 Oct, 2015

1 commit

  • The can subsystem communicates with user space using a bcm_msg_head
    header, which contains two timestamps. This is problematic for
    multiple reasons:

    a) The structure layout is currently incompatible between 64-bit
    user space and 32-bit user space, and cannot work in compat
    mode (other than x32).

    b) The timeval structure layout will change in 32-bit user
    space when we fix the y2038 overflow problem by redefining
    time_t to 64-bit, making new 32-bit user space incompatible
    with the current kernel interface.
    Cars last a long time and often use old kernels, so the actual
    users of this code are the most likely ones to migrate to y2038
    safe user space.

    This tries to work around part of the problem by changing the
    publicly visible user interface in the header, but not the binary
    interface. Fortunately, the values passed around in the structure
    are relative times and do not actually suffer from the y2038
    overflow, so 32-bit is enough here.

    We replace the use of 'struct timeval' with a newly defined
    'struct bcm_timeval' that uses the exact same binary layout
    as before and that still suffers from problem a) but not problem
    b).

    The downside of this approach is that any user space program
    that currently assigns a timeval structure to these members
    rather than writing the tv_sec/tv_usec portions individually
    will suffer a compile-time error when built with an updated
    kernel header. Fixing this error makes it work fine with old
    and new headers though.

    We could address problem a) by using '__u32' or 'int' members
    rather than 'long', but that would have a more significant
    downside in also breaking support for all existing 64-bit user
    binaries that might be using this interface, which is likely
    not acceptable.

    Signed-off-by: Arnd Bergmann
    Acked-by: Oliver Hartkopp
    Cc: linux-can@vger.kernel.org
    Cc: linux-api@vger.kernel.org
    Signed-off-by: Marc Kleine-Budde

    Arnd Bergmann
     

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
     

24 Jun, 2015

1 commit


22 Jun, 2015

1 commit

  • As reported by Manfred Schlaegl here

    http://marc.info/?l=linux-netdev&m=143482089824232&w=2

    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.

    As net timestamping is influenced by several players (netstamp_needed and
    netdev_tstamp_prequeue) Manfred missed a proper timestamp which leads to
    CAN frame loss.

    As skb timestamping became now mandatory for CAN related skbs this patch
    makes sure that received CAN skbs always have a proper timestamp set.
    Maybe there's a better solution in the future but this patch fixes the
    CAN frame loss so far.

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

    Oliver Hartkopp