1. 09 Oct, 2019 12 commits
  2. 08 Oct, 2019 5 commits
    • Eric Dumazet's avatar
      tun: fix memory leak in error path · 11fc7d5a
      Eric Dumazet authored
      syzbot reported a warning [1] that triggered after recent Jiri patch.
      
      This exposes a bug that we hit already in the past (see commit
      ff244c6b ("tun: handle register_netdevice() failures properly")
      for details)
      
      tun uses priv->destructor without an ndo_init() method.
      
      register_netdevice() can return an error, but will
      not call priv->destructor() in some cases. Jiri recent
      patch added one more.
      
      A long term fix would be to transfer the initialization
      of what we destroy in ->destructor() in the ndo_init()
      
      This looks a bit risky given the complexity of tun driver.
      
      A simpler fix is to detect after the failed register_netdevice()
      if the tun_free_netdev() function was called already.
      
      [1]
      ODEBUG: free active (active state 0) object type: timer_list hint: tun_flow_cleanup+0x0/0x280 drivers/net/tun.c:457
      WARNING: CPU: 0 PID: 8653 at lib/debugobjects.c:481 debug_print_object+0x168/0x250 lib/debugobjects.c:481
      Kernel panic - not syncing: panic_on_warn set ...
      CPU: 0 PID: 8653 Comm: syz-executor976 Not tainted 5.4.0-rc1-next-20191004 #0
      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+0x172/0x1f0 lib/dump_stack.c:113
       panic+0x2dc/0x755 kernel/panic.c:220
       __warn.cold+0x2f/0x3c kernel/panic.c:581
       report_bug+0x289/0x300 lib/bug.c:195
       fixup_bug arch/x86/kernel/traps.c:174 [inline]
       fixup_bug arch/x86/kernel/traps.c:169 [inline]
       do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:267
       do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286
       invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028
      RIP: 0010:debug_print_object+0x168/0x250 lib/debugobjects.c:481
      Code: dd 80 b9 e6 87 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 b5 00 00 00 48 8b 14 dd 80 b9 e6 87 48 c7 c7 e0 ae e6 87 e8 80 84 ff fd <0f> 0b 83 05 e3 ee 80 06 01 48 83 c4 20 5b 41 5c 41 5d 41 5e 5d c3
      RSP: 0018:ffff888095997a28 EFLAGS: 00010082
      RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: ffffffff815cb526 RDI: ffffed1012b32f37
      RBP: ffff888095997a68 R08: ffff8880a92ac580 R09: ffffed1015d04101
      R10: ffffed1015d04100 R11: ffff8880ae820807 R12: 0000000000000001
      R13: ffffffff88fb5340 R14: ffffffff81627110 R15: ffff8880aa41eab8
       __debug_check_no_obj_freed lib/debugobjects.c:963 [inline]
       debug_check_no_obj_freed+0x2d4/0x43f lib/debugobjects.c:994
       kfree+0xf8/0x2c0 mm/slab.c:3755
       kvfree+0x61/0x70 mm/util.c:593
       netdev_freemem net/core/dev.c:9384 [inline]
       free_netdev+0x39d/0x450 net/core/dev.c:9533
       tun_set_iff drivers/net/tun.c:2871 [inline]
       __tun_chr_ioctl+0x317b/0x3f30 drivers/net/tun.c:3075
       tun_chr_ioctl+0x2b/0x40 drivers/net/tun.c:3355
       vfs_ioctl fs/ioctl.c:47 [inline]
       file_ioctl fs/ioctl.c:539 [inline]
       do_vfs_ioctl+0xdb6/0x13e0 fs/ioctl.c:726
       ksys_ioctl+0xab/0xd0 fs/ioctl.c:743
       __do_sys_ioctl fs/ioctl.c:750 [inline]
       __se_sys_ioctl fs/ioctl.c:748 [inline]
       __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:748
       do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x441439
      Code: e8 9c ae 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 3b 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fff61c37438 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000441439
      RDX: 0000000020000400 RSI: 00000000400454ca RDI: 0000000000000004
      RBP: 00007fff61c37470 R08: 0000000000000001 R09: 0000000100000000
      R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff
      R13: 0000000000000005 R14: 0000000000000000 R15: 0000000000000000
      Kernel Offset: disabled
      Rebooting in 86400 seconds..
      
      Fixes: ff927412 ("net: introduce name_node struct to be used in hashlist")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      11fc7d5a
    • Colin Ian King's avatar
      netdevsim: fix spelling mistake "forbidded" -> "forbid" · f9867b51
      Colin Ian King authored
      There is a spelling mistake in a NL_SET_ERR_MSG_MOD message. Fix it.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      f9867b51
    • Colin Ian King's avatar
      net: phy: mscc: make arrays static, makes object smaller · c4256794
      Colin Ian King authored
      Don't populate const arrays on the stack but instead make them
      static. Makes the object code smaller by 1058 bytes.
      
      Before:
         text	   data	    bss	    dec	    hex	filename
        29879	   6144	      0	  36023	   8cb7	drivers/net/phy/mscc.o
      
      After:
         text	   data	    bss	    dec	    hex	filename
        28437	   6528	      0	  34965	   8895	drivers/net/phy/mscc.o
      
      (gcc version 9.2.1, amd64)
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      c4256794
    • Colin Ian King's avatar
      nfp: bpf: make array exp_mask static, makes object smaller · 155283c3
      Colin Ian King authored
      Don't populate the array exp_mask on the stack but instead make it
      static. Makes the object code smaller by 224 bytes.
      
      Before:
         text	   data	    bss	    dec	    hex	filename
        77832	   2290	      0	  80122	  138fa	ethernet/netronome/nfp/bpf/jit.o
      
      After:
         text	   data	    bss	    dec	    hex	filename
        77544	   2354	      0	  79898	  1381a	ethernet/netronome/nfp/bpf/jit.o
      
      (gcc version 9.2.1, amd64)
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Acked-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      155283c3
    • Vladimir Oltean's avatar
      spi: Add a PTP system timestamp to the transfer structure · 79591b7d
      Vladimir Oltean authored
      SPI is one of the interfaces used to access devices which have a POSIX
      clock driver (real time clocks, 1588 timers etc). The fact that the SPI
      bus is slow is not what the main problem is, but rather the fact that
      drivers don't take a constant amount of time in transferring data over
      SPI. When there is a high delay in the readout of time, there will be
      uncertainty in the value that has been read out of the peripheral.
      When that delay is constant, the uncertainty can at least be
      approximated with a certain accuracy which is fine more often than not.
      
      Timing jitter occurs all over in the kernel code, and is mainly caused
      by having to let go of the CPU for various reasons such as preemption,
      servicing interrupts, going to sleep, etc. Another major reason is CPU
      dynamic frequency scaling.
      
      It turns out that the problem of retrieving time from a SPI peripheral
      with high accuracy can be solved by the use of "PTP system
      timestamping" - a mechanism to correlate the time when the device has
      snapshotted its internal time counter with the Linux system time at that
      same moment. This is sufficient for having a precise time measurement -
      it is not necessary for the whole SPI transfer to be transmitted "as
      fast as possible", or "as low-jitter as possible". The system has to be
      low-jitter for a very short amount of time to be effective.
      
      This patch introduces a PTP system timestamping mechanism in struct
      spi_transfer. This is to be used by SPI device drivers when they need to
      know the exact time at which the underlying device's time was
      snapshotted. More often than not, SPI peripherals have a very exact
      timing for when their SPI-to-interconnect bridge issues a transaction
      for snapshotting and reading the time register, and that will be
      dependent on when the SPI-to-interconnect bridge figures out that this
      is what it should do, aka as soon as it sees byte N of the SPI transfer.
      Since spi_device drivers are the ones who'd know best how the peripheral
      behaves in this regard, expose a mechanism in spi_transfer which allows
      them to specify which word (or word range) from the transfer should be
      timestamped.
      
      Add a default implementation of the PTP system timestamping in the SPI
      core. This is not going to be satisfactory performance-wise, but should
      at least increase the likelihood that SPI device drivers will use PTP
      system timestamping in the future.
      There are 3 entry points from the core towards the SPI controller
      drivers:
      
      - transfer_one: The driver is passed individual spi_transfers to
        execute. This is the easiest to timestamp.
      
      - transfer_one_message: The core passes the driver an entire spi_message
        (a potential batch of spi_transfers). The core puts the same pre and
        post timestamp to all transfers within a message. This is not ideal,
        but nothing better can be done by default anyway, since the core has
        no insight into how the driver batches the transfers.
      
      - transfer: Like transfer_one_message, but for unqueued drivers (i.e.
        the driver implements its own queue scheduling).
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Link: https://lore.kernel.org/r/20190905010114.26718-3-olteanv@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      79591b7d
  3. 07 Oct, 2019 23 commits