1. 26 7月, 2018 1 次提交
    • L
      Merge tag 'fscache-fixes-20180725' of... · 5c61ef1b
      Linus Torvalds 提交于
      Merge tag 'fscache-fixes-20180725' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
      
      Pull fscache/cachefiles fixes from David Howells:
      
       - Allow cancelled operations to be queued so they can be cleaned up.
      
       - Fix a refcounting bug in the monitoring of reads on backend files
         whereby a race can occur between monitor objects being listed for
         work, the work processing being queued and the work processor running
         and destroying the monitor objects.
      
       - Fix a ref overput in object attachment, whereby a tentatively
         considered object is put in error handling without first being 'got'.
      
       - Fix a missing clear of the CACHEFILES_OBJECT_ACTIVE flag whereby an
         assertion occurs when we retry because it seems the object is now
         active.
      
       - Wait rather BUG'ing on an object collision in the depths of
         cachefiles as the active object should be being cleaned up - also
         depends on the one above.
      
      * tag 'fscache-fixes-20180725' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
        cachefiles: Wait rather than BUG'ing on "Unexpected object collision"
        cachefiles: Fix missing clear of the CACHEFILES_OBJECT_ACTIVE flag
        fscache: Fix reference overput in fscache_attach_object() error handling
        cachefiles: Fix refcounting bug in backing-file read monitoring
        fscache: Allow cancelled operations to be enqueued
      5c61ef1b
  2. 25 7月, 2018 17 次提交
    • K
      cachefiles: Wait rather than BUG'ing on "Unexpected object collision" · c2412ac4
      Kiran Kumar Modukuri 提交于
      If we meet a conflicting object that is marked FSCACHE_OBJECT_IS_LIVE in
      the active object tree, we have been emitting a BUG after logging
      information about it and the new object.
      
      Instead, we should wait for the CACHEFILES_OBJECT_ACTIVE flag to be cleared
      on the old object (or return an error).  The ACTIVE flag should be cleared
      after it has been removed from the active object tree.  A timeout of 60s is
      used in the wait, so we shouldn't be able to get stuck there.
      
      Fixes: 9ae326a6 ("CacheFiles: A cache that backs onto a mounted filesystem")
      Signed-off-by: NKiran Kumar Modukuri <kiran.modukuri@gmail.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      c2412ac4
    • K
      cachefiles: Fix missing clear of the CACHEFILES_OBJECT_ACTIVE flag · 5ce83d4b
      Kiran Kumar Modukuri 提交于
      In cachefiles_mark_object_active(), the new object is marked active and
      then we try to add it to the active object tree.  If a conflicting object
      is already present, we want to wait for that to go away.  After the wait,
      we go round again and try to re-mark the object as being active - but it's
      already marked active from the first time we went through and a BUG is
      issued.
      
      Fix this by clearing the CACHEFILES_OBJECT_ACTIVE flag before we try again.
      
      Analysis from Kiran Kumar Modukuri:
      
      [Impact]
      Oops during heavy NFS + FSCache + Cachefiles
      
      CacheFiles: Error: Overlong wait for old active object to go away.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000002
      
      CacheFiles: Error: Object already active kernel BUG at
      fs/cachefiles/namei.c:163!
      
      [Cause]
      In a heavily loaded system with big files being read and truncated, an
      fscache object for a cookie is being dropped and a new object being
      looked. The new object being looked for has to wait for the old object
      to go away before the new object is moved to active state.
      
      [Fix]
      Clear the flag 'CACHEFILES_OBJECT_ACTIVE' for the new object when
      retrying the object lookup.
      
      [Testcase]
      Have run ~100 hours of NFS stress tests and have not seen this bug recur.
      
      [Regression Potential]
       - Limited to fscache/cachefiles.
      
      Fixes: 9ae326a6 ("CacheFiles: A cache that backs onto a mounted filesystem")
      Signed-off-by: NKiran Kumar Modukuri <kiran.modukuri@gmail.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      5ce83d4b
    • K
      fscache: Fix reference overput in fscache_attach_object() error handling · f29507ce
      Kiran Kumar Modukuri 提交于
      When a cookie is allocated that causes fscache_object structs to be
      allocated, those objects are initialised with the cookie pointer, but
      aren't blessed with a ref on that cookie unless the attachment is
      successfully completed in fscache_attach_object().
      
      If attachment fails because the parent object was dying or there was a
      collision, fscache_attach_object() returns without incrementing the cookie
      counter - but upon failure of this function, the object is released which
      then puts the cookie, whether or not a ref was taken on the cookie.
      
      Fix this by taking a ref on the cookie when it is assigned in
      fscache_object_init(), even when we're creating a root object.
      
      
      Analysis from Kiran Kumar:
      
      This bug has been seen in 4.4.0-124-generic #148-Ubuntu kernel
      
      BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1776277
      
      fscache cookie ref count updated incorrectly during fscache object
      allocation resulting in following Oops.
      
      kernel BUG at /build/linux-Y09MKI/linux-4.4.0/fs/fscache/internal.h:321!
      kernel BUG at /build/linux-Y09MKI/linux-4.4.0/fs/fscache/cookie.c:639!
      
      [Cause]
      Two threads are trying to do operate on a cookie and two objects.
      
      (1) One thread tries to unmount the filesystem and in process goes over a
          huge list of objects marking them dead and deleting the objects.
          cookie->usage is also decremented in following path:
      
            nfs_fscache_release_super_cookie
             -> __fscache_relinquish_cookie
              ->__fscache_cookie_put
              ->BUG_ON(atomic_read(&cookie->usage) <= 0);
      
      (2) A second thread tries to lookup an object for reading data in following
          path:
      
          fscache_alloc_object
          1) cachefiles_alloc_object
              -> fscache_object_init
                 -> assign cookie, but usage not bumped.
          2) fscache_attach_object -> fails in cant_attach_object because the
               cookie's backing object or cookie's->parent object are going away
          3) fscache_put_object
              -> cachefiles_put_object
                ->fscache_object_destroy
                  ->fscache_cookie_put
                     ->BUG_ON(atomic_read(&cookie->usage) <= 0);
      
      [NOTE from dhowells] It's unclear as to the circumstances in which (2) can
      take place, given that thread (1) is in nfs_kill_super(), however a
      conflicting NFS mount with slightly different parameters that creates a
      different superblock would do it.  A backtrace from Kiran seems to show
      that this is a possibility:
      
          kernel BUG at/build/linux-Y09MKI/linux-4.4.0/fs/fscache/cookie.c:639!
          ...
          RIP: __fscache_cookie_put+0x3a/0x40 [fscache]
          Call Trace:
           __fscache_relinquish_cookie+0x87/0x120 [fscache]
           nfs_fscache_release_super_cookie+0x2d/0xb0 [nfs]
           nfs_kill_super+0x29/0x40 [nfs]
           deactivate_locked_super+0x48/0x80
           deactivate_super+0x5c/0x60
           cleanup_mnt+0x3f/0x90
           __cleanup_mnt+0x12/0x20
           task_work_run+0x86/0xb0
           exit_to_usermode_loop+0xc2/0xd0
           syscall_return_slowpath+0x4e/0x60
           int_ret_from_sys_call+0x25/0x9f
      
      [Fix] Bump up the cookie usage in fscache_object_init, when it is first
      being assigned a cookie atomically such that the cookie is added and bumped
      up if its refcount is not zero.  Remove the assignment in
      fscache_attach_object().
      
      [Testcase]
      I have run ~100 hours of NFS stress tests and not seen this bug recur.
      
      [Regression Potential]
       - Limited to fscache/cachefiles.
      
      Fixes: ccc4fc3d ("FS-Cache: Implement the cookie management part of the netfs API")
      Signed-off-by: NKiran Kumar Modukuri <kiran.modukuri@gmail.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      f29507ce
    • K
      cachefiles: Fix refcounting bug in backing-file read monitoring · 934140ab
      Kiran Kumar Modukuri 提交于
      cachefiles_read_waiter() has the right to access a 'monitor' object by
      virtue of being called under the waitqueue lock for one of the pages in its
      purview.  However, it has no ref on that monitor object or on the
      associated operation.
      
      What it is allowed to do is to move the monitor object to the operation's
      to_do list, but once it drops the work_lock, it's actually no longer
      permitted to access that object.  However, it is trying to enqueue the
      retrieval operation for processing - but it can only do this via a pointer
      in the monitor object, something it shouldn't be doing.
      
      If it doesn't enqueue the operation, the operation may not get processed.
      If the order is flipped so that the enqueue is first, then it's possible
      for the work processor to look at the to_do list before the monitor is
      enqueued upon it.
      
      Fix this by getting a ref on the operation so that we can trust that it
      will still be there once we've added the monitor to the to_do list and
      dropped the work_lock.  The op can then be enqueued after the lock is
      dropped.
      
      The bug can manifest in one of a couple of ways.  The first manifestation
      looks like:
      
       FS-Cache:
       FS-Cache: Assertion failed
       FS-Cache: 6 == 5 is false
       ------------[ cut here ]------------
       kernel BUG at fs/fscache/operation.c:494!
       RIP: 0010:fscache_put_operation+0x1e3/0x1f0
       ...
       fscache_op_work_func+0x26/0x50
       process_one_work+0x131/0x290
       worker_thread+0x45/0x360
       kthread+0xf8/0x130
       ? create_worker+0x190/0x190
       ? kthread_cancel_work_sync+0x10/0x10
       ret_from_fork+0x1f/0x30
      
      This is due to the operation being in the DEAD state (6) rather than
      INITIALISED, COMPLETE or CANCELLED (5) because it's already passed through
      fscache_put_operation().
      
      The bug can also manifest like the following:
      
       kernel BUG at fs/fscache/operation.c:69!
       ...
          [exception RIP: fscache_enqueue_operation+246]
       ...
       #7 [ffff883fff083c10] fscache_enqueue_operation at ffffffffa0b793c6
       #8 [ffff883fff083c28] cachefiles_read_waiter at ffffffffa0b15a48
       #9 [ffff883fff083c48] __wake_up_common at ffffffff810af028
      
      I'm not entirely certain as to which is line 69 in Lei's kernel, so I'm not
      entirely clear which assertion failed.
      
      Fixes: 9ae326a6 ("CacheFiles: A cache that backs onto a mounted filesystem")
      Reported-by: NLei Xue <carmark.dlut@gmail.com>
      Reported-by: NVegard Nossum <vegard.nossum@gmail.com>
      Reported-by: NAnthony DeRobertis <aderobertis@metrics.net>
      Reported-by: NNeilBrown <neilb@suse.com>
      Reported-by: NDaniel Axtens <dja@axtens.net>
      Reported-by: NKiran Kumar Modukuri <kiran.modukuri@gmail.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NDaniel Axtens <dja@axtens.net>
      934140ab
    • K
      fscache: Allow cancelled operations to be enqueued · d0eb06af
      Kiran Kumar Modukuri 提交于
      Alter the state-check assertion in fscache_enqueue_operation() to allow
      cancelled operations to be given processing time so they can be cleaned up.
      
      Also fix a debugging statement that was requiring such operations to have
      an object assigned.
      
      Fixes: 9ae326a6 ("CacheFiles: A cache that backs onto a mounted filesystem")
      Reported-by: NKiran Kumar Modukuri <kiran.modukuri@gmail.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      d0eb06af
    • L
      Merge tag 'mips_fixes_4.18_4' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux · 9981b4fb
      Linus Torvalds 提交于
      Pull MIPS fixes from Paul Burton:
       "A couple more MIPS fixes for 4.18:
      
         - Fix an off-by-one in reporting PCI resource sizes to userland which
           regressed in v3.12.
      
         - Fix writes to DDR controller registers used to flush write buffers,
           which regressed with some refactoring in v4.2"
      
      * tag 'mips_fixes_4.18_4' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
        MIPS: ath79: fix register address in ath79_ddr_wb_flush()
        MIPS: Fix off-by-one in pci_resource_to_user()
      9981b4fb
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 07230906
      Linus Torvalds 提交于
      Pull networking fixes from David Miller:
      
       1) Handle stations tied to AP_VLANs properly during mac80211 hw
          reconfig. From Manikanta Pubbisetty.
      
       2) Fix jump stack depth validation in nf_tables, from Taehee Yoo.
      
       3) Fix quota handling in aRFS flow expiration of mlx5 driver, from Eran
          Ben Elisha.
      
       4) Exit path handling fix in powerpc64 BPF JIT, from Daniel Borkmann.
      
       5) Use ptr_ring_consume_bh() in page pool code, from Tariq Toukan.
      
       6) Fix cached netdev name leak in nf_tables, from Florian Westphal.
      
       7) Fix memory leaks on chain rename, also from Florian Westphal.
      
       8) Several fixes to DCTCP congestion control ACK handling, from Yuchunk
          Cheng.
      
       9) Missing rcu_read_unlock() in CAIF protocol code, from Yue Haibing.
      
      10) Fix link local address handling with VRF, from David Ahern.
      
      11) Don't clobber 'err' on a successful call to __skb_linearize() in
          skb_segment(). From Eric Dumazet.
      
      12) Fix vxlan fdb notification races, from Roopa Prabhu.
      
      13) Hash UDP fragments consistently, from Paolo Abeni.
      
      14) If TCP receives lots of out of order tiny packets, we do really
          silly stuff. Make the out-of-order queue ending more robust to this
          kind of behavior, from Eric Dumazet.
      
      15) Don't leak netlink dump state in nf_tables, from Florian Westphal.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (76 commits)
        net: axienet: Fix double deregister of mdio
        qmi_wwan: fix interface number for DW5821e production firmware
        ip: in cmsg IP(V6)_ORIGDSTADDR call pskb_may_pull
        bnx2x: Fix invalid memory access in rss hash config path.
        net/mlx4_core: Save the qpn from the input modifier in RST2INIT wrapper
        r8169: restore previous behavior to accept BIOS WoL settings
        cfg80211: never ignore user regulatory hint
        sock: fix sg page frag coalescing in sk_alloc_sg
        netfilter: nf_tables: move dumper state allocation into ->start
        tcp: add tcp_ooo_try_coalesce() helper
        tcp: call tcp_drop() from tcp_data_queue_ofo()
        tcp: detect malicious patterns in tcp_collapse_ofo_queue()
        tcp: avoid collapses in tcp_prune_queue() if possible
        tcp: free batches of packets in tcp_prune_ofo_queue()
        ip: hash fragments consistently
        ipv6: use fib6_info_hold_safe() when necessary
        can: xilinx_can: fix power management handling
        can: xilinx_can: fix incorrect clear of non-processed interrupts
        can: xilinx_can: fix RX overflow interrupt not being enabled
        can: xilinx_can: keep only 1-2 frames in TX FIFO to fix TX accounting
        ...
      07230906
    • S
      net: axienet: Fix double deregister of mdio · 03bc7cab
      Shubhrajyoti Datta 提交于
      If the registration fails then mdio_unregister is called.
      However at unbind the unregister ia attempted again resulting
      in the below crash
      
      [   73.544038] kernel BUG at drivers/net/phy/mdio_bus.c:415!
      [   73.549362] Internal error: Oops - BUG: 0 [#1] SMP
      [   73.554127] Modules linked in:
      [   73.557168] CPU: 0 PID: 2249 Comm: sh Not tainted 4.14.0 #183
      [   73.562895] Hardware name: xlnx,zynqmp (DT)
      [   73.567062] task: ffffffc879e41180 task.stack: ffffff800cbe0000
      [   73.572973] PC is at mdiobus_unregister+0x84/0x88
      [   73.577656] LR is at axienet_mdio_teardown+0x18/0x30
      [   73.582601] pc : [<ffffff80085fa4cc>] lr : [<ffffff8008616858>]
      pstate: 20000145
      [   73.589981] sp : ffffff800cbe3c30
      [   73.593277] x29: ffffff800cbe3c30 x28: ffffffc879e41180
      [   73.598573] x27: ffffff8008a21000 x26: 0000000000000040
      [   73.603868] x25: 0000000000000124 x24: ffffffc879efe920
      [   73.609164] x23: 0000000000000060 x22: ffffffc879e02000
      [   73.614459] x21: ffffffc879e02800 x20: ffffffc87b0b8870
      [   73.619754] x19: ffffffc879e02800 x18: 000000000000025d
      [   73.625050] x17: 0000007f9a719ad0 x16: ffffff8008195bd8
      [   73.630345] x15: 0000007f9a6b3d00 x14: 0000000000000010
      [   73.635640] x13: 74656e7265687465 x12: 0000000000000030
      [   73.640935] x11: 0000000000000030 x10: 0101010101010101
      [   73.646231] x9 : 241f394f42533300 x8 : ffffffc8799f6e98
      [   73.651526] x7 : ffffffc8799f6f18 x6 : ffffffc87b0ba318
      [   73.656822] x5 : ffffffc87b0ba498 x4 : 0000000000000000
      [   73.662117] x3 : 0000000000000000 x2 : 0000000000000008
      [   73.667412] x1 : 0000000000000004 x0 : ffffffc8799f4000
      [   73.672708] Process sh (pid: 2249, stack limit = 0xffffff800cbe0000)
      
      Fix the same by making the bus NULL on unregister.
      Signed-off-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      03bc7cab
    • A
      qmi_wwan: fix interface number for DW5821e production firmware · f25e1392
      Aleksander Morgado 提交于
      The original mapping for the DW5821e was done using a development
      version of the firmware. Confirmed with the vendor that the final
      USB layout ends up exposing the QMI control/data ports in USB
      config #1, interface #0, not in interface #1 (which is now a HID
      interface).
      
      T:  Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 16 Spd=480 MxCh= 0
      D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  2
      P:  Vendor=413c ProdID=81d7 Rev=03.18
      S:  Manufacturer=DELL
      S:  Product=DW5821e Snapdragon X20 LTE
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      
      Fixes: e7e197ed ("qmi_wwan: add support for the Dell Wireless 5821e module")
      Signed-off-by: NAleksander Morgado <aleksander@aleksander.es>
      Acked-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f25e1392
    • W
      ip: in cmsg IP(V6)_ORIGDSTADDR call pskb_may_pull · 2efd4fca
      Willem de Bruijn 提交于
      Syzbot reported a read beyond the end of the skb head when returning
      IPV6_ORIGDSTADDR:
      
        BUG: KMSAN: kernel-infoleak in put_cmsg+0x5ef/0x860 net/core/scm.c:242
        CPU: 0 PID: 4501 Comm: syz-executor128 Not tainted 4.17.0+ #9
        Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
        Google 01/01/2011
        Call Trace:
          __dump_stack lib/dump_stack.c:77 [inline]
          dump_stack+0x185/0x1d0 lib/dump_stack.c:113
          kmsan_report+0x188/0x2a0 mm/kmsan/kmsan.c:1125
          kmsan_internal_check_memory+0x138/0x1f0 mm/kmsan/kmsan.c:1219
          kmsan_copy_to_user+0x7a/0x160 mm/kmsan/kmsan.c:1261
          copy_to_user include/linux/uaccess.h:184 [inline]
          put_cmsg+0x5ef/0x860 net/core/scm.c:242
          ip6_datagram_recv_specific_ctl+0x1cf3/0x1eb0 net/ipv6/datagram.c:719
          ip6_datagram_recv_ctl+0x41c/0x450 net/ipv6/datagram.c:733
          rawv6_recvmsg+0x10fb/0x1460 net/ipv6/raw.c:521
          [..]
      
      This logic and its ipv4 counterpart read the destination port from
      the packet at skb_transport_offset(skb) + 4.
      
      With MSG_MORE and a local SOCK_RAW sender, syzbot was able to cook a
      packet that stores headers exactly up to skb_transport_offset(skb) in
      the head and the remainder in a frag.
      
      Call pskb_may_pull before accessing the pointer to ensure that it lies
      in skb head.
      
      Link: http://lkml.kernel.org/r/CAF=yD-LEJwZj5a1-bAAj2Oy_hKmGygV6rsJ_WOrAYnv-fnayiQ@mail.gmail.com
      Reported-by: syzbot+9adb4b567003cac781f0@syzkaller.appspotmail.com
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2efd4fca
    • S
      bnx2x: Fix invalid memory access in rss hash config path. · ae2dcb28
      Sudarsana Reddy Kalluru 提交于
      Rx hash/filter table configuration uses rss_conf_obj to configure filters
      in the hardware. This object is initialized only when the interface is
      brought up.
      This patch adds driver changes to configure rss params only when the device
      is in opened state. In port disabled case, the config will be cached in the
      driver structure which will be applied in the successive load path.
      
      Please consider applying it to 'net' branch.
      Signed-off-by: NSudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae2dcb28
    • J
      net/mlx4_core: Save the qpn from the input modifier in RST2INIT wrapper · 958c696f
      Jack Morgenstein 提交于
      Function mlx4_RST2INIT_QP_wrapper saved the qp number passed in the qp
      context, rather than the one passed in the input modifier.
      
      However, the qp number in the qp context is not defined as a
      required parameter by the FW. Therefore, drivers may choose to not
      specify the qp number in the qp context for the reset-to-init transition.
      
      Thus, we must save the qp number passed in the command input modifier --
      which is always present. (This saved qp number is used as the input
      modifier for command 2RST_QP when a slave's qp's are destroyed).
      
      Fixes: c82e9aa0 ("mlx4_core: resource tracking for HCA resources used by guests")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      958c696f
    • H
      r8169: restore previous behavior to accept BIOS WoL settings · 18041b52
      Heiner Kallweit 提交于
      Commit 7edf6d31 tried to resolve an inconsistency (BIOS WoL
      settings are accepted, but device isn't wakeup-enabled) resulting
      from a previous broken-BIOS workaround by making disabled WoL the
      default.
      This however had some side effects, most likely due to a broken BIOS
      some systems don't properly resume from suspend when the MagicPacket
      WoL bit isn't set in the chip, see
      https://bugzilla.kernel.org/show_bug.cgi?id=200195
      Therefore restore the WoL behavior from 4.16.
      Reported-by: NAlbert Astals Cid <aacid@kde.org>
      Fixes: 7edf6d31 ("r8169: disable WOL per default")
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      18041b52
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · f89ed2f8
      Linus Torvalds 提交于
      Pull s390 fix from Martin Schwidefsky.
      
      Guenter Roeck reports that the s390 allmodconfig build fails because of
      a gcc plugin problem.  The fix won't be in-tree until 4.19, so for now
      disable the gcc plugins on s390.
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
        s390: disable gcc plugins
      f89ed2f8
    • G
      media: staging: omap4iss: Include asm/cacheflush.h after generic includes · 0894da84
      Guenter Roeck 提交于
      Including asm/cacheflush.h first results in the following build error
      when trying to build sparc32:allmodconfig, because 'struct page' has not
      been declared, and the function declaration ends up creating a separate
      (private) declaration of struct page (as a result of function arguments
      being in the scope of the function declaration and definition, not in
      global scope).
      
      The C scoping rules do not just affect variable visibility, they also
      affect type declaration visibility.
      
      The end result is that when the actual call site is seen in
      <linux/highmem.h>, the 'struct page' type in the caller is not the same
      'struct page' that the function was declared with, resulting in:
      
        In file included from arch/sparc/include/asm/page.h:10:0,
                         ...
                         from drivers/staging/media/omap4iss/iss_video.c:15:
        include/linux/highmem.h: In function 'clear_user_highpage':
        include/linux/highmem.h:137:31: error:
      	passing argument 1 of 'sparc_flush_page_to_ram' from incompatible
      	pointer type
      
      Include generic includes files first to fix the problem.
      
      Fixes: fc96d58c ("[media] v4l: omap4iss: Add support for OMAP4 camera interface - Video devices")
      Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      [ Added explanation of C scope rules - Linus ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0894da84
    • D
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 049f5604
      David S. Miller 提交于
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter fixes for net
      
      The following patchset contains Netfilter fixes for net:
      
      1) Make sure we don't go over the maximum jump stack boundary,
         from Taehee Yoo.
      
      2) Missing rcu_barrier() in hash and rbtree sets, also from Taehee.
      
      3) Missing check to nul-node in rbtree timeout routine, from Taehee.
      
      4) Use dev->name from flowtable to fix a memleak, from Florian.
      
      5) Oneliner to free flowtable object on removal, from Florian.
      
      6) Memleak in chain rename transaction, again from Florian.
      
      7) Don't allow two chains to use the same name in the same
         transaction, from Florian.
      
      8) handle DCCP SYNC/SYNCACK as invalid, this triggers an
         uninitialized timer in conntrack reported by syzbot, from Florian.
      
      9) Fix leak in case netlink_dump_start() fails, from Florian.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      049f5604
    • D
      Merge tag 'mac80211-for-davem-2018-07-24' of... · e1adf314
      David S. Miller 提交于
      Merge tag 'mac80211-for-davem-2018-07-24' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      Only a few fixes:
       * always keep regulatory user hint
       * add missing break statement in station flags parsing
       * fix non-linear SKBs in port-control-over-nl80211
       * reconfigure VLAN stations during HW restart
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e1adf314
  3. 24 7月, 2018 13 次提交
    • A
      cfg80211: never ignore user regulatory hint · e31f6456
      Amar Singhal 提交于
      Currently user regulatory hint is ignored if all wiphys
      in the system are self managed. But the hint is not ignored
      if there is no wiphy in the system. This affects the global
      regulatory setting. Global regulatory setting needs to be
      maintained so that it can be applied to a new wiphy entering
      the system. Therefore, do not ignore user regulatory setting
      even if all wiphys in the system are self managed.
      Signed-off-by: NAmar Singhal <asinghal@codeaurora.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e31f6456
    • M
      s390: disable gcc plugins · 2fba3573
      Martin Schwidefsky 提交于
      The s390 build currently fails with the latent entropy plugin:
      
      arch/s390/kernel/als.o: In function `verify_facilities':
      als.c:(.init.text+0x24): undefined reference to `latent_entropy'
      als.c:(.init.text+0xae): undefined reference to `latent_entropy'
      make[3]: *** [arch/s390/boot/compressed/vmlinux] Error 1
      make[2]: *** [arch/s390/boot/compressed/vmlinux] Error 2
      make[1]: *** [bzImage] Error 2
      
      This will be fixed with the early boot rework from Vasily, which
      is planned for the 4.19 merge window.
      
      For 4.18 the simplest solution is to disable the gcc plugins and
      reenable them after the early boot rework is upstream.
      Reported-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      2fba3573
    • D
      sock: fix sg page frag coalescing in sk_alloc_sg · 144fe2bf
      Daniel Borkmann 提交于
      Current sg coalescing logic in sk_alloc_sg() (latter is used by tls and
      sockmap) is not quite correct in that we do fetch the previous sg entry,
      however the subsequent check whether the refilled page frag from the
      socket is still the same as from the last entry with prior offset and
      length matching the start of the current buffer is comparing always the
      first sg list entry instead of the prior one.
      
      Fixes: 3c4d7559 ("tls: kernel TLS support")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NDave Watson <davejwatson@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      144fe2bf
    • F
      netfilter: nf_tables: move dumper state allocation into ->start · 90fd131a
      Florian Westphal 提交于
      Shaochun Chen points out we leak dumper filter state allocations
      stored in dump_control->data in case there is an error before netlink sets
      cb_running (after which ->done will be called at some point).
      
      In order to fix this, add .start functions and do the allocations
      there.
      
      ->done is going to clean up, and in case error occurs before
      ->start invocation no cleanups need to be done anymore.
      Reported-by: Nshaochun chen <cscnull@gmail.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      90fd131a
    • D
      Merge branch 'tcp-robust-ooo' · 1a4f14ba
      David S. Miller 提交于
      Eric Dumazet says:
      
      ====================
      Juha-Matti Tilli reported that malicious peers could inject tiny
      packets in out_of_order_queue, forcing very expensive calls
      to tcp_collapse_ofo_queue() and tcp_prune_ofo_queue() for
      every incoming packet.
      
      With tcp_rmem[2] default of 6MB, the ooo queue could
      contain ~7000 nodes.
      
      This patch series makes sure we cut cpu cycles enough to
      render the attack not critical.
      
      We might in the future go further, like disconnecting
      or black-holing proven malicious flows.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1a4f14ba
    • E
      tcp: add tcp_ooo_try_coalesce() helper · 58152ecb
      Eric Dumazet 提交于
      In case skb in out_or_order_queue is the result of
      multiple skbs coalescing, we would like to get a proper gso_segs
      counter tracking, so that future tcp_drop() can report an accurate
      number.
      
      I chose to not implement this tracking for skbs in receive queue,
      since they are not dropped, unless socket is disconnected.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
      Acked-by: NYuchung Cheng <ycheng@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      58152ecb
    • E
      tcp: call tcp_drop() from tcp_data_queue_ofo() · 8541b21e
      Eric Dumazet 提交于
      In order to be able to give better diagnostics and detect
      malicious traffic, we need to have better sk->sk_drops tracking.
      
      Fixes: 9f5afeae ("tcp: use an RB tree for ooo receive queue")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
      Acked-by: NYuchung Cheng <ycheng@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8541b21e
    • E
      tcp: detect malicious patterns in tcp_collapse_ofo_queue() · 3d4bf93a
      Eric Dumazet 提交于
      In case an attacker feeds tiny packets completely out of order,
      tcp_collapse_ofo_queue() might scan the whole rb-tree, performing
      expensive copies, but not changing socket memory usage at all.
      
      1) Do not attempt to collapse tiny skbs.
      2) Add logic to exit early when too many tiny skbs are detected.
      
      We prefer not doing aggressive collapsing (which copies packets)
      for pathological flows, and revert to tcp_prune_ofo_queue() which
      will be less expensive.
      
      In the future, we might add the possibility of terminating flows
      that are proven to be malicious.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d4bf93a
    • E
      tcp: avoid collapses in tcp_prune_queue() if possible · f4a3313d
      Eric Dumazet 提交于
      Right after a TCP flow is created, receiving tiny out of order
      packets allways hit the condition :
      
      if (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf)
      	tcp_clamp_window(sk);
      
      tcp_clamp_window() increases sk_rcvbuf to match sk_rmem_alloc
      (guarded by tcp_rmem[2])
      
      Calling tcp_collapse_ofo_queue() in this case is not useful,
      and offers a O(N^2) surface attack to malicious peers.
      
      Better not attempt anything before full queue capacity is reached,
      forcing attacker to spend lots of resource and allow us to more
      easily detect the abuse.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
      Acked-by: NYuchung Cheng <ycheng@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f4a3313d
    • E
      tcp: free batches of packets in tcp_prune_ofo_queue() · 72cd43ba
      Eric Dumazet 提交于
      Juha-Matti Tilli reported that malicious peers could inject tiny
      packets in out_of_order_queue, forcing very expensive calls
      to tcp_collapse_ofo_queue() and tcp_prune_ofo_queue() for
      every incoming packet. out_of_order_queue rb-tree can contain
      thousands of nodes, iterating over all of them is not nice.
      
      Before linux-4.9, we would have pruned all packets in ofo_queue
      in one go, every XXXX packets. XXXX depends on sk_rcvbuf and skbs
      truesize, but is about 7000 packets with tcp_rmem[2] default of 6 MB.
      
      Since we plan to increase tcp_rmem[2] in the future to cope with
      modern BDP, can not revert to the old behavior, without great pain.
      
      Strategy taken in this patch is to purge ~12.5 % of the queue capacity.
      
      Fixes: 36a6503f ("tcp: refine tcp_prune_ofo_queue() to not drop all packets")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NJuha-Matti Tilli <juha-matti.tilli@iki.fi>
      Acked-by: NYuchung Cheng <ycheng@google.com>
      Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      72cd43ba
    • P
      ip: hash fragments consistently · 3dd1c9a1
      Paolo Abeni 提交于
      The skb hash for locally generated ip[v6] fragments belonging
      to the same datagram can vary in several circumstances:
      * for connected UDP[v6] sockets, the first fragment get its hash
        via set_owner_w()/skb_set_hash_from_sk()
      * for unconnected IPv6 UDPv6 sockets, the first fragment can get
        its hash via ip6_make_flowlabel()/skb_get_hash_flowi6(), if
        auto_flowlabel is enabled
      
      For the following frags the hash is usually computed via
      skb_get_hash().
      The above can cause OoO for unconnected IPv6 UDPv6 socket: in that
      scenario the egress tx queue can be selected on a per packet basis
      via the skb hash.
      It may also fool flow-oriented schedulers to place fragments belonging
      to the same datagram in different flows.
      
      Fix the issue by copying the skb hash from the head frag into
      the others at fragmentation time.
      
      Before this commit:
      perf probe -a "dev_queue_xmit skb skb->hash skb->l4_hash:b1@0/8 skb->sw_hash:b1@1/8"
      netperf -H $IPV4 -t UDP_STREAM -l 5 -- -m 2000 -n &
      perf record -e probe:dev_queue_xmit -e probe:skb_set_owner_w -a sleep 0.1
      perf script
      probe:dev_queue_xmit: (ffffffff8c6b1b20) hash=3713014309 l4_hash=1 sw_hash=0
      probe:dev_queue_xmit: (ffffffff8c6b1b20) hash=0 l4_hash=0 sw_hash=0
      
      After this commit:
      probe:dev_queue_xmit: (ffffffff8c6b1b20) hash=2171763177 l4_hash=1 sw_hash=0
      probe:dev_queue_xmit: (ffffffff8c6b1b20) hash=2171763177 l4_hash=1 sw_hash=0
      
      Fixes: b73c3d0e ("net: Save TX flow hash in sock and set in skbuf on xmit")
      Fixes: 67800f9b ("ipv6: Call skb_get_hash_flowi6 to get skb->hash in ip6_make_flowlabel")
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3dd1c9a1
    • W
      ipv6: use fib6_info_hold_safe() when necessary · e873e4b9
      Wei Wang 提交于
      In the code path where only rcu read lock is held, e.g. in the route
      lookup code path, it is not safe to directly call fib6_info_hold()
      because the fib6_info may already have been deleted but still exists
      in the rcu grace period. Holding reference to it could cause double
      free and crash the kernel.
      
      This patch adds a new function fib6_info_hold_safe() and replace
      fib6_info_hold() in all necessary places.
      
      Syzbot reported 3 crash traces because of this. One of them is:
      8021q: adding VLAN 0 to HW filter on device team0
      IPv6: ADDRCONF(NETDEV_CHANGE): team0: link becomes ready
      dst_release: dst:(____ptrval____) refcnt:-1
      dst_release: dst:(____ptrval____) refcnt:-2
      WARNING: CPU: 1 PID: 4845 at include/net/dst.h:239 dst_hold include/net/dst.h:239 [inline]
      WARNING: CPU: 1 PID: 4845 at include/net/dst.h:239 ip6_setup_cork+0xd66/0x1830 net/ipv6/ip6_output.c:1204
      dst_release: dst:(____ptrval____) refcnt:-1
      Kernel panic - not syncing: panic_on_warn set ...
      
      CPU: 1 PID: 4845 Comm: syz-executor493 Not tainted 4.18.0-rc3+ #10
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
       panic+0x238/0x4e7 kernel/panic.c:184
      dst_release: dst:(____ptrval____) refcnt:-2
      dst_release: dst:(____ptrval____) refcnt:-3
       __warn.cold.8+0x163/0x1ba kernel/panic.c:536
      dst_release: dst:(____ptrval____) refcnt:-4
       report_bug+0x252/0x2d0 lib/bug.c:186
       fixup_bug arch/x86/kernel/traps.c:178 [inline]
       do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
      dst_release: dst:(____ptrval____) refcnt:-5
       do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
       invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
      RIP: 0010:dst_hold include/net/dst.h:239 [inline]
      RIP: 0010:ip6_setup_cork+0xd66/0x1830 net/ipv6/ip6_output.c:1204
      Code: c1 ed 03 89 9d 18 ff ff ff 48 b8 00 00 00 00 00 fc ff df 41 c6 44 05 00 f8 e9 2d 01 00 00 4c 8b a5 c8 fe ff ff e8 1a f6 e6 fa <0f> 0b e9 6a fc ff ff e8 0e f6 e6 fa 48 8b 85 d0 fe ff ff 48 8d 78
      RSP: 0018:ffff8801a8fcf178 EFLAGS: 00010293
      RAX: ffff8801a8eba5c0 RBX: 0000000000000000 RCX: ffffffff869511e6
      RDX: 0000000000000000 RSI: ffffffff869515b6 RDI: 0000000000000005
      RBP: ffff8801a8fcf2c8 R08: ffff8801a8eba5c0 R09: ffffed0035ac8338
      R10: ffffed0035ac8338 R11: ffff8801ad6419c3 R12: ffff8801a8fcf720
      R13: ffff8801a8fcf6a0 R14: ffff8801ad6419c0 R15: ffff8801ad641980
       ip6_make_skb+0x2c8/0x600 net/ipv6/ip6_output.c:1768
       udpv6_sendmsg+0x2c90/0x35f0 net/ipv6/udp.c:1376
       inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
       sock_sendmsg_nosec net/socket.c:641 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:651
       ___sys_sendmsg+0x51d/0x930 net/socket.c:2125
       __sys_sendmmsg+0x240/0x6f0 net/socket.c:2220
       __do_sys_sendmmsg net/socket.c:2249 [inline]
       __se_sys_sendmmsg net/socket.c:2246 [inline]
       __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2246
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x446ba9
      Code: e8 cc bb 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fb39a469da8 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
      RAX: ffffffffffffffda RBX: 00000000006dcc54 RCX: 0000000000446ba9
      RDX: 00000000000000b8 RSI: 0000000020001b00 RDI: 0000000000000003
      RBP: 00000000006dcc50 R08: 00007fb39a46a700 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 45c828efc7a64843
      R13: e6eeb815b9d8a477 R14: 5068caf6f713c6fc R15: 0000000000000001
      Dumping ftrace buffer:
         (ftrace buffer empty)
      Kernel Offset: disabled
      Rebooting in 86400 seconds..
      
      Fixes: 93531c67 ("net/ipv6: separate handling of FIB entries from dst based routes")
      Reported-by: syzbot+902e2a1bcd4f7808cef5@syzkaller.appspotmail.com
      Reported-by: syzbot+8ae62d67f647abeeceb9@syzkaller.appspotmail.com
      Reported-by: syzbot+3f08feb14086930677d0@syzkaller.appspotmail.com
      Signed-off-by: NWei Wang <weiwan@google.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e873e4b9
    • D
      Merge tag 'linux-can-fixes-for-4.18-20180723' of... · 5302a84e
      David S. Miller 提交于
      Merge tag 'linux-can-fixes-for-4.18-20180723' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
      
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can 2018-07-23
      
      this is a pull request of 12 patches for net/master.
      
      The patch by Stephane Grosjean for the peak_canfd CAN driver fixes a problem
      with older firmware. The next patch is by Roman Fietze and fixes the setup of
      the CCCR register in the m_can driver. Nicholas Mc Guire's patch for the
      mpc5xxx_can driver adds missing error checking. The two patches by Faiz Abbas
      fix the runtime resume and clean up the probe function in the m_can driver. The
      last 7 patches by Anssi Hannula fix several problem in the xilinx_can driver.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5302a84e
  4. 23 7月, 2018 9 次提交
    • A
      can: xilinx_can: fix power management handling · 8ebd83bd
      Anssi Hannula 提交于
      There are several issues with the suspend/resume handling code of the
      driver:
      
      - The device is attached and detached in the runtime_suspend() and
        runtime_resume() callbacks if the interface is running. However,
        during xcan_chip_start() the interface is considered running,
        causing the resume handler to incorrectly call netif_start_queue()
        at the beginning of xcan_chip_start(), and on xcan_chip_start() error
        return the suspend handler detaches the device leaving the user
        unable to bring-up the device anymore.
      
      - The device is not brought properly up on system resume. A reset is
        done and the code tries to determine the bus state after that.
        However, after reset the device is always in Configuration mode
        (down), so the state checking code does not make sense and
        communication will also not work.
      
      - The suspend callback tries to set the device to sleep mode (low-power
        mode which monitors the bus and brings the device back to normal mode
        on activity), but then immediately disables the clocks (possibly
        before the device reaches the sleep mode), which does not make sense
        to me. If a clean shutdown is wanted before disabling clocks, we can
        just bring it down completely instead of only sleep mode.
      
      Reorganize the PM code so that only the clock logic remains in the
      runtime PM callbacks and the system PM callbacks contain the device
      bring-up/down logic. This makes calling the runtime PM callbacks during
      e.g. xcan_chip_start() safe.
      
      The system PM callbacks now simply call common code to start/stop the
      HW if the interface was running, replacing the broken code from before.
      
      xcan_chip_stop() is updated to use the common reset code so that it will
      wait for the reset to complete. Reset also disables all interrupts so do
      not do that separately.
      
      Also, the device_may_wakeup() checks are removed as the driver does not
      have wakeup support.
      
      Tested on Zynq-7000 integrated CAN.
      Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      8ebd83bd
    • A
      can: xilinx_can: fix incorrect clear of non-processed interrupts · 2f4f0f33
      Anssi Hannula 提交于
      xcan_interrupt() clears ERROR|RXOFLV|BSOFF|ARBLST interrupts if any of
      them is asserted. This does not take into account that some of them
      could have been asserted between interrupt status read and interrupt
      clear, therefore clearing them without handling them.
      
      Fix the code to only clear those interrupts that it knows are asserted
      and therefore going to be processed in xcan_err_interrupt().
      
      Fixes: b1201e44 ("can: xilinx CAN controller support")
      Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      2f4f0f33
    • A
      can: xilinx_can: fix RX overflow interrupt not being enabled · 83997997
      Anssi Hannula 提交于
      RX overflow interrupt (RXOFLW) is disabled even though xcan_interrupt()
      processes it. This means that an RX overflow interrupt will only be
      processed when another interrupt gets asserted (e.g. for RX/TX).
      
      Fix that by enabling the RXOFLW interrupt.
      
      Fixes: b1201e44 ("can: xilinx CAN controller support")
      Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      83997997
    • A
      can: xilinx_can: keep only 1-2 frames in TX FIFO to fix TX accounting · 620050d9
      Anssi Hannula 提交于
      The xilinx_can driver assumes that the TXOK interrupt only clears after
      it has been acknowledged as many times as there have been successfully
      sent frames.
      
      However, the documentation does not mention such behavior, instead
      saying just that the interrupt is cleared when the clear bit is set.
      
      Similarly, testing seems to also suggest that it is immediately cleared
      regardless of the amount of frames having been sent. Performing some
      heavy TX load and then going back to idle has the tx_head drifting
      further away from tx_tail over time, steadily reducing the amount of
      frames the driver keeps in the TX FIFO (but not to zero, as the TXOK
      interrupt always frees up space for 1 frame from the driver's
      perspective, so frames continue to be sent) and delaying the local echo
      frames.
      
      The TX FIFO tracking is also otherwise buggy as it does not account for
      TX FIFO being cleared after software resets, causing
        BUG!, TX FIFO full when queue awake!
      messages to be output.
      
      There does not seem to be any way to accurately track the state of the
      TX FIFO for local echo support while using the full TX FIFO.
      
      The Zynq version of the HW (but not the soft-AXI version) has watermark
      programming support and with it an additional TX-FIFO-empty interrupt
      bit.
      
      Modify the driver to only put 1 frame into TX FIFO at a time on soft-AXI
      and 2 frames at a time on Zynq. On Zynq the TXFEMP interrupt bit is used
      to detect whether 1 or 2 frames have been sent at interrupt processing
      time.
      
      Tested with the integrated CAN on Zynq-7000 SoC. The 1-frame-FIFO mode
      was also tested.
      
      An alternative way to solve this would be to drop local echo support but
      keep using the full TX FIFO.
      
      v2: Add FIFO space check before TX queue wake with locking to
      synchronize with queue stop. This avoids waking the queue when xmit()
      had just filled it.
      
      v3: Keep local echo support and reduce the amount of frames in FIFO
      instead as suggested by Marc Kleine-Budde.
      
      Fixes: b1201e44 ("can: xilinx CAN controller support")
      Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      620050d9
    • A
      can: xilinx_can: fix recovery from error states not being propagated · 877e0b75
      Anssi Hannula 提交于
      The xilinx_can driver contains no mechanism for propagating recovery
      from CAN_STATE_ERROR_WARNING and CAN_STATE_ERROR_PASSIVE.
      
      Add such a mechanism by factoring the handling of
      XCAN_STATE_ERROR_PASSIVE and XCAN_STATE_ERROR_WARNING out of
      xcan_err_interrupt and checking for recovery after RX and TX if the
      interface is in one of those states.
      
      Tested with the integrated CAN on Zynq-7000 SoC.
      
      Fixes: b1201e44 ("can: xilinx CAN controller support")
      Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      877e0b75
    • A
      can: xilinx_can: fix RX loop if RXNEMP is asserted without RXOK · 32852c56
      Anssi Hannula 提交于
      If the device gets into a state where RXNEMP (RX FIFO not empty)
      interrupt is asserted without RXOK (new frame received successfully)
      interrupt being asserted, xcan_rx_poll() will continue to try to clear
      RXNEMP without actually reading frames from RX FIFO. If the RX FIFO is
      not empty, the interrupt will not be cleared and napi_schedule() will
      just be called again.
      
      This situation can occur when:
      
      (a) xcan_rx() returns without reading RX FIFO due to an error condition.
      The code tries to clear both RXOK and RXNEMP but RXNEMP will not clear
      due to a frame still being in the FIFO. The frame will never be read
      from the FIFO as RXOK is no longer set.
      
      (b) A frame is received between xcan_rx_poll() reading interrupt status
      and clearing RXOK. RXOK will be cleared, but RXNEMP will again remain
      set as the new message is still in the FIFO.
      
      I'm able to trigger case (b) by flooding the bus with frames under load.
      
      There does not seem to be any benefit in using both RXNEMP and RXOK in
      the way the driver does, and the polling example in the reference manual
      (UG585 v1.10 18.3.7 Read Messages from RxFIFO) also says that either
      RXOK or RXNEMP can be used for detecting incoming messages.
      
      Fix the issue and simplify the RX processing by only using RXNEMP
      without RXOK.
      
      Tested with the integrated CAN on Zynq-7000 SoC.
      
      Fixes: b1201e44 ("can: xilinx CAN controller support")
      Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      32852c56
    • A
      can: xilinx_can: fix device dropping off bus on RX overrun · 2574fe54
      Anssi Hannula 提交于
      The xilinx_can driver performs a software reset when an RX overrun is
      detected. This causes the device to enter Configuration mode where no
      messages are received or transmitted.
      
      The documentation does not mention any need to perform a reset on an RX
      overrun, and testing by inducing an RX overflow also indicated that the
      device continues to work just fine without a reset.
      
      Remove the software reset.
      
      Tested with the integrated CAN on Zynq-7000 SoC.
      
      Fixes: b1201e44 ("can: xilinx CAN controller support")
      Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      2574fe54
    • F
      can: m_can: Move accessing of message ram to after clocks are enabled · 54e4a0c4
      Faiz Abbas 提交于
      MCAN message ram should only be accessed once clocks are enabled.
      Therefore, move the call to parse/init the message ram to after
      clocks are enabled.
      Signed-off-by: NFaiz Abbas <faiz_abbas@ti.com>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      54e4a0c4
    • F
      can: m_can: Fix runtime resume call · 1675bee3
      Faiz Abbas 提交于
      pm_runtime_get_sync() returns a 1 if the state of the device is already
      'active'. This is not a failure case and should return a success.
      
      Therefore fix error handling for pm_runtime_get_sync() call such that
      it returns success when the value is 1.
      
      Also cleanup the TODO for using runtime PM for sleep mode as that is
      implemented.
      Signed-off-by: NFaiz Abbas <faiz_abbas@ti.com>
      Cc: <stable@vger.kernel.org
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      1675bee3