Skip to content

L
linux
Switch branch/tag
  1. 12 Oct, 2019 2 commits
  3. 11 Oct, 2019 1 commit
  5. 10 Oct, 2019 18 commits
  7. 09 Oct, 2019 12 commits
  9. 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
  11. 07 Oct, 2019 2 commits
    • David S. Miller's avatar
      Merge branch 'dpaa2-eth-misc-cleanup' · 940f1382
      David S. Miller authored 
      Ioana Ciornei says:

====================
dpaa2-eth: misc cleanup

This patch set consists of some cleanup patches ranging from removing dead
code to fixing a minor issue in ethtool stats. Also, unbounded while loops
are removed from the driver by adding a maximum number of retries for DPIO
portal commands.

Changes in v2:
 - return -ETIMEDOUT where possible if the number of retries is hit
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      940f1382
    • Ioana Radulescu's avatar
      dpaa2-eth: Avoid unbounded while loops · ef17bd7c
      Ioana Radulescu authored 
      Throughout the driver there are several places where we wait
indefinitely for DPIO portal commands to be executed, while
the portal returns a busy response code.

Even though in theory we are guaranteed the portals become
available eventually, in practice the QBMan hardware module
may become unresponsive in various corner cases.

Make sure we can never get stuck in an infinite while loop
by adding a retry counter for all portal commands.
Signed-off-by: default avatarIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef17bd7c
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7