1. 26 Jan, 2019 40 commits
    • Florian Fainelli's avatar
      perf tests ARM: Disable breakpoint tests 32-bit · 389cde57
      Florian Fainelli authored
      [ Upstream commit 24f96733 ]
      
      The breakpoint tests on the ARM 32-bit kernel are broken in several
      ways.
      
      The breakpoint length requested does not necessarily match whether the
      function address has the Thumb bit (bit 0) set or not, and this does
      matter to the ARM kernel hw_breakpoint infrastructure. See [1] for
      background.
      
      [1]: https://lkml.org/lkml/2018/11/15/205
      
      As Will indicated, the overflow handling would require single-stepping
      which is not supported at the moment. Just disable those tests for the
      ARM 32-bit platforms and update the comment above to explain these
      limitations.
      Co-developed-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Acked-by: Jiri Olsa's avatarJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20181203191138.2419-1-f.fainelli@gmail.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      389cde57
    • Adrian Hunter's avatar
      perf intel-pt: Fix error with config term "pt=0" · 7eb6443f
      Adrian Hunter authored
      [ Upstream commit 1c6f709b ]
      
      Users should never use 'pt=0', but if they do it may give a meaningless
      error:
      
      	$ perf record -e intel_pt/pt=0/u uname
      	Error:
      	The sys_perf_event_open() syscall returned with 22 (Invalid argument) for
      	event (intel_pt/pt=0/u).
      
      Fix that by forcing 'pt=1'.
      
      Committer testing:
      
        # perf record -e intel_pt/pt=0/u uname
        Error:
        The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (intel_pt/pt=0/u).
        /bin/dmesg | grep -i perf may provide additional information.
      
        # perf record -e intel_pt/pt=0/u uname
        pt=0 doesn't make sense, forcing pt=1
        Linux
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.020 MB perf.data ]
        #
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Link: http://lkml.kernel.org/r/b7c5b4e5-9497-10e5-fd43-5f3e4a0fe51d@intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7eb6443f
    • Adrian Hunter's avatar
      tools lib traceevent: Fix compile warnings in tools/lib/traceevent/event-parse.c · 7dd70b09
      Adrian Hunter authored
      [ Upstream commit 0631ca3a ]
      
      Fix following warnings:
      
        event-parse.c: In function ‘tep_find_event_by_name’:
        event-parse.c:3521:21: warning: ‘event’ may be used uninitialized in this function [-Wmaybe-uninitialized]
          pevent->last_event = event;
          ~~~~~~~~~~~~~~~~~~~^~~~~~~
          CC       ui/gtk/hists.o
          LINK     plugin_mac80211.so
          CC       nlattr.o
        event-parse.c: In function ‘tep_data_lat_fmt’:
        event-parse.c:5200:4: warning: ‘migrate_disable’ may be used uninitialized in this function [-Wmaybe-uninitialized]
            trace_seq_printf(s, "%d", migrate_disable);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        event-parse.c:5207:4: warning: ‘lock_depth’ may be used uninitialized in this function [-Wmaybe-uninitialized]
            trace_seq_printf(s, "%d", lock_depth);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          LINK     plugin_sched_switch.so
          LINK     plugin_function.so
          LINK     plugin_xen.so
        event-parse.c: In function ‘tep_event_info’:
        event-parse.c:5047:7: warning: ‘len_arg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
               trace_seq_printf(s, format, len_arg, (char)val);
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        event-parse.c:4884:6: note: ‘len_arg’ was declared here
          int len_arg;
              ^~~~~~~
        event-parse.c:4338:11: warning: ‘vsize’ may be used uninitialized in this function [-Wmaybe-uninitialized]
             val = tep_read_number(pevent, bptr, vsize);
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        event-parse.c:4224:6: note: ‘vsize’ was declared here
          int vsize;
              ^~~~~
      
      $ gcc --version
        gcc (Clear Linux OS for Intel Architecture) 8.2.1 20180502
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
      Link: http://lkml.kernel.org/r/20181122112937.10582-1-adrian.hunter@intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7dd70b09
    • Sergey Senozhatsky's avatar
      tty/serial: do not free trasnmit buffer page under port lock · 9c59b4c8
      Sergey Senozhatsky authored
      [ Upstream commit d7240214 ]
      
      LKP has hit yet another circular locking dependency between uart
      console drivers and debugobjects [1]:
      
           CPU0                                    CPU1
      
                                                  rhltable_init()
                                                   __init_work()
                                                    debug_object_init
           uart_shutdown()                          /* db->lock */
            /* uart_port->lock */                    debug_print_object()
             free_page()                              printk()
                                                       call_console_drivers()
              debug_check_no_obj_freed()                /* uart_port->lock */
               /* db->lock */
                debug_print_object()
      
      So there are two dependency chains:
      	uart_port->lock -> db->lock
      And
      	db->lock -> uart_port->lock
      
      This particular circular locking dependency can be addressed in several
      ways:
      
      a) One way would be to move debug_print_object() out of db->lock scope
         and, thus, break the db->lock -> uart_port->lock chain.
      b) Another one would be to free() transmit buffer page out of db->lock
         in UART code; which is what this patch does.
      
      It makes sense to apply a) and b) independently: there are too many things
      going on behind free(), none of which depend on uart_port->lock.
      
      The patch fixes transmit buffer page free() in uart_shutdown() and,
      additionally, in uart_port_startup() (as was suggested by Dmitry Safonov).
      
      [1] https://lore.kernel.org/lkml/20181211091154.GL23332@shao2-debian/T/#uSigned-off-by: sergey-senozhatsky's avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Waiman Long <longman@redhat.com>
      Cc: Dmitry Safonov <dima@arista.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9c59b4c8
    • Johannes Thumshirn's avatar
      btrfs: improve error handling of btrfs_add_link · e18db412
      Johannes Thumshirn authored
      [ Upstream commit 1690dd41 ]
      
      In the error handling block, err holds the return value of either
      btrfs_del_root_ref() or btrfs_del_inode_ref() but it hasn't been checked
      since it's introduction with commit fe66a05a (Btrfs: improve error
      handling for btrfs_insert_dir_item callers) in 2012.
      
      If the error handling in the error handling fails, there's not much left
      to do and the abort either happened earlier in the callees or is
      necessary here.
      
      So if one of btrfs_del_root_ref() or btrfs_del_inode_ref() failed, abort
      the transaction, but still return the original code of the failure
      stored in 'ret' as this will be reported to the user.
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e18db412
    • Anand Jain's avatar
      btrfs: fix use-after-free due to race between replace start and cancel · d9ef1519
      Anand Jain authored
      [ Upstream commit d189dd70 ]
      
      The device replace cancel thread can race with the replace start thread
      and if fs_info::scrubs_running is not yet set, btrfs_scrub_cancel() will
      fail to stop the scrub thread.
      
      The scrub thread continues with the scrub for replace which then will
      try to write to the target device and which is already freed by the
      cancel thread.
      
      scrub_setup_ctx() warns as tgtdev is NULL.
      
        struct scrub_ctx *scrub_setup_ctx(struct btrfs_device *dev, int is_dev_replace)
        {
        ...
      	  if (is_dev_replace) {
      		  WARN_ON(!fs_info->dev_replace.tgtdev);  <===
      		  sctx->pages_per_wr_bio = SCRUB_PAGES_PER_WR_BIO;
      		  sctx->wr_tgtdev = fs_info->dev_replace.tgtdev;
      		  sctx->flush_all_writes = false;
      	  }
      
        [ 6724.497655] BTRFS info (device sdb): dev_replace from /dev/sdb (devid 1) to /dev/sdc started
        [ 6753.945017] BTRFS info (device sdb): dev_replace from /dev/sdb (devid 1) to /dev/sdc canceled
        [ 6852.426700] WARNING: CPU: 0 PID: 4494 at fs/btrfs/scrub.c:622 scrub_setup_ctx.isra.19+0x220/0x230 [btrfs]
        ...
        [ 6852.428928] RIP: 0010:scrub_setup_ctx.isra.19+0x220/0x230 [btrfs]
        ...
        [ 6852.432970] Call Trace:
        [ 6852.433202]  btrfs_scrub_dev+0x19b/0x5c0 [btrfs]
        [ 6852.433471]  btrfs_dev_replace_start+0x48c/0x6a0 [btrfs]
        [ 6852.433800]  btrfs_dev_replace_by_ioctl+0x3a/0x60 [btrfs]
        [ 6852.434097]  btrfs_ioctl+0x2476/0x2d20 [btrfs]
        [ 6852.434365]  ? do_sigaction+0x7d/0x1e0
        [ 6852.434623]  do_vfs_ioctl+0xa9/0x6c0
        [ 6852.434865]  ? syscall_trace_enter+0x1c8/0x310
        [ 6852.435124]  ? syscall_trace_enter+0x1c8/0x310
        [ 6852.435387]  ksys_ioctl+0x60/0x90
        [ 6852.435663]  __x64_sys_ioctl+0x16/0x20
        [ 6852.435907]  do_syscall_64+0x50/0x180
        [ 6852.436150]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Further, as the replace thread enters scrub_write_page_to_dev_replace()
      without the target device it panics:
      
        static int scrub_add_page_to_wr_bio(struct scrub_ctx *sctx,
      				      struct scrub_page *spage)
        {
        ...
      	bio_set_dev(bio, sbio->dev->bdev); <======
      
        [ 6929.715145] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
        ..
        [ 6929.717106] Workqueue: btrfs-scrub btrfs_scrub_helper [btrfs]
        [ 6929.717420] RIP: 0010:scrub_write_page_to_dev_replace+0xb4/0x260
        [btrfs]
        ..
        [ 6929.721430] Call Trace:
        [ 6929.721663]  scrub_write_block_to_dev_replace+0x3f/0x60 [btrfs]
        [ 6929.721975]  scrub_bio_end_io_worker+0x1af/0x490 [btrfs]
        [ 6929.722277]  normal_work_helper+0xf0/0x4c0 [btrfs]
        [ 6929.722552]  process_one_work+0x1f4/0x520
        [ 6929.722805]  ? process_one_work+0x16e/0x520
        [ 6929.723063]  worker_thread+0x46/0x3d0
        [ 6929.723313]  kthread+0xf8/0x130
        [ 6929.723544]  ? process_one_work+0x520/0x520
        [ 6929.723800]  ? kthread_delayed_work_timer_fn+0x80/0x80
        [ 6929.724081]  ret_from_fork+0x3a/0x50
      
      Fix this by letting the btrfs_dev_replace_finishing() to do the job of
      cleaning after the cancel, including freeing of the target device.
      btrfs_dev_replace_finishing() is called when btrfs_scub_dev() returns
      along with the scrub return status.
      Signed-off-by: Anand Jain's avatarAnand Jain <anand.jain@oracle.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d9ef1519
    • Hans van Kranenburg's avatar
      btrfs: alloc_chunk: fix more DUP stripe size handling · ec08bfea
      Hans van Kranenburg authored
      [ Upstream commit baf92114 ]
      
      Commit 92e222df "btrfs: alloc_chunk: fix DUP stripe size handling"
      fixed calculating the stripe_size for a new DUP chunk.
      
      However, the same calculation reappears a bit later, and that one was
      not changed yet. The resulting bug that is exposed is that the newly
      allocated device extents ('stripes') can have a few MiB overlap with the
      next thing stored after them, which is another device extent or the end
      of the disk.
      
      The scenario in which this can happen is:
      * The block device for the filesystem is less than 10GiB in size.
      * The amount of contiguous free unallocated disk space chosen to use for
        chunk allocation is 20% of the total device size, or a few MiB more or
        less.
      
      An example:
      - The filesystem device is 7880MiB (max_chunk_size gets set to 788MiB)
      - There's 1578MiB unallocated raw disk space left in one contiguous
        piece.
      
      In this case stripe_size is first calculated as 789MiB, (half of
      1578MiB).
      
      Since 789MiB (stripe_size * data_stripes) > 788MiB (max_chunk_size), we
      enter the if block. Now stripe_size value is immediately overwritten
      while calculating an adjusted value based on max_chunk_size, which ends
      up as 788MiB.
      
      Next, the value is rounded up to a 16MiB boundary, 800MiB, which is
      actually more than the value we had before. However, the last comparison
      fails to detect this, because it's comparing the value with the total
      amount of free space, which is about twice the size of stripe_size.
      
      In the example above, this means that the resulting raw disk space being
      allocated is 1600MiB, while only a gap of 1578MiB has been found. The
      second device extent object for this DUP chunk will overlap for 22MiB
      with whatever comes next.
      
      The underlying problem here is that the stripe_size is reused all the
      time for different things. So, when entering the code in the if block,
      stripe_size is immediately overwritten with something else. If later we
      decide we want to have the previous value back, then the logic to
      compute it was copy pasted in again.
      
      With this change, the value in stripe_size is not unnecessarily
      destroyed, so the duplicated calculation is not needed any more.
      Signed-off-by: default avatarHans van Kranenburg <hans.van.kranenburg@mendix.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ec08bfea
    • Qu Wenruo's avatar
      btrfs: volumes: Make sure there is no overlap of dev extents at mount time · ebc9efb9
      Qu Wenruo authored
      [ Upstream commit 5eb19381 ]
      
      Enhance btrfs_verify_dev_extents() to remember previous checked dev
      extents, so it can verify no dev extents can overlap.
      
      Analysis from Hans:
      
      "Imagine allocating a DATA|DUP chunk.
      
       In the chunk allocator, we first set...
         max_stripe_size = SZ_1G;
         max_chunk_size = BTRFS_MAX_DATA_CHUNK_SIZE
       ... which is 10GiB.
      
       Then...
         /* we don't want a chunk larger than 10% of writeable space */
         max_chunk_size = min(div_factor(fs_devices->total_rw_bytes, 1),
             		 max_chunk_size);
      
       Imagine we only have one 7880MiB block device in this filesystem. Now
       max_chunk_size is down to 788MiB.
      
       The next step in the code is to search for max_stripe_size * dev_stripes
       amount of free space on the device, which is in our example 1GiB * 2 =
       2GiB. Imagine the device has exactly 1578MiB free in one contiguous
       piece. This amount of bytes will be put in devices_info[ndevs - 1].max_avail
      
       Next we recalculate the stripe_size (which is actually the device extent
       length), based on the actual maximum amount of available raw disk space:
         stripe_size = div_u64(devices_info[ndevs - 1].max_avail, dev_stripes);
      
       stripe_size is now 789MiB
      
       Next we do...
         data_stripes = num_stripes / ncopies
       ...where data_stripes ends up as 1, because num_stripes is 2 (the amount
       of device extents we're going to have), and DUP has ncopies 2.
      
       Next there's a check...
         if (stripe_size * data_stripes > max_chunk_size)
       ...which matches because 789MiB * 1 > 788MiB.
      
       We go into the if code, and next is...
         stripe_size = div_u64(max_chunk_size, data_stripes);
       ...which resets stripe_size to max_chunk_size: 788MiB
      
       Next is a fun one...
         /* bump the answer up to a 16MB boundary */
         stripe_size = round_up(stripe_size, SZ_16M);
       ...which changes stripe_size from 788MiB to 800MiB.
      
       We're not done changing stripe_size yet...
         /* But don't go higher than the limits we found while searching
          * for free extents
          */
         stripe_size = min(devices_info[ndevs - 1].max_avail,
             	      stripe_size);
      
       This is bad. max_avail is twice the stripe_size (we need to fit 2 device
       extents on the same device for DUP).
      
       The result here is that 800MiB < 1578MiB, so it's unchanged. However,
       the resulting DUP chunk will need 1600MiB disk space, which isn't there,
       and the second dev_extent might extend into the next thing (next
       dev_extent? end of device?) for 22MiB.
      
       The last shown line of code relies on a situation where there's twice
       the value of stripe_size present as value for the variable stripe_size
       when it's DUP. This was actually the case before commit 92e222df
       "btrfs: alloc_chunk: fix DUP stripe size handling", from which I quote:
         "[...] in the meantime there's a check to see if the stripe_size does
       not exceed max_chunk_size. Since during this check stripe_size is twice
       the amount as intended, the check will reduce the stripe_size to
       max_chunk_size if the actual correct to be used stripe_size is more than
       half the amount of max_chunk_size."
      
       In the previous version of the code, the 16MiB alignment (why is this
       done, by the way?) would result in a 50% chance that it would actually
       do an 8MiB alignment for the individual dev_extents, since it was
       operating on double the size. Does this matter?
      
       Does it matter that stripe_size can be set to anything which is not
       16MiB aligned because of the amount of remaining available disk space
       which is just taken?
      
       What is the main purpose of this round_up?
      
       The most straightforward thing to do seems something like...
         stripe_size = min(
             div_u64(devices_info[ndevs - 1].max_avail, dev_stripes),
             stripe_size
         )
       ..just putting half of the max_avail into stripe_size."
      
      Link: https://lore.kernel.org/linux-btrfs/b3461a38-e5f8-f41d-c67c-2efac8129054@mendix.com/Reported-by: default avatarHans van Kranenburg <hans.van.kranenburg@mendix.com>
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      [ add analysis from report ]
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ebc9efb9
    • Jonas Danielsson's avatar
      mmc: atmel-mci: do not assume idle after atmci_request_end · aa0703b7
      Jonas Danielsson authored
      [ Upstream commit ae460c11 ]
      
      On our AT91SAM9260 board we use the same sdio bus for wifi and for the
      sd card slot. This caused the atmel-mci to give the following splat on
      the serial console:
      
        ------------[ cut here ]------------
        WARNING: CPU: 0 PID: 538 at drivers/mmc/host/atmel-mci.c:859 atmci_send_command+0x24/0x44
        Modules linked in:
        CPU: 0 PID: 538 Comm: mmcqd/0 Not tainted 4.14.76 #14
        Hardware name: Atmel AT91SAM9
        [<c000fccc>] (unwind_backtrace) from [<c000d3dc>] (show_stack+0x10/0x14)
        [<c000d3dc>] (show_stack) from [<c0017644>] (__warn+0xd8/0xf4)
        [<c0017644>] (__warn) from [<c0017704>] (warn_slowpath_null+0x1c/0x24)
        [<c0017704>] (warn_slowpath_null) from [<c033bb9c>] (atmci_send_command+0x24/0x44)
        [<c033bb9c>] (atmci_send_command) from [<c033e984>] (atmci_start_request+0x1f4/0x2dc)
        [<c033e984>] (atmci_start_request) from [<c033f3b4>] (atmci_request+0xf0/0x164)
        [<c033f3b4>] (atmci_request) from [<c0327108>] (mmc_start_request+0x280/0x2d0)
        [<c0327108>] (mmc_start_request) from [<c032800c>] (mmc_start_areq+0x230/0x330)
        [<c032800c>] (mmc_start_areq) from [<c03366f8>] (mmc_blk_issue_rw_rq+0xc4/0x310)
        [<c03366f8>] (mmc_blk_issue_rw_rq) from [<c03372c4>] (mmc_blk_issue_rq+0x118/0x5ac)
        [<c03372c4>] (mmc_blk_issue_rq) from [<c033781c>] (mmc_queue_thread+0xc4/0x118)
        [<c033781c>] (mmc_queue_thread) from [<c002daf8>] (kthread+0x100/0x118)
        [<c002daf8>] (kthread) from [<c000a580>] (ret_from_fork+0x14/0x34)
        ---[ end trace 594371ddfa284bd6 ]---
      
      This is:
        WARN_ON(host->cmd);
      
      This was fixed on our board by letting atmci_request_end determine what
      state we are in. Instead of unconditionally setting it to STATE_IDLE on
      STATE_END_REQUEST.
      Signed-off-by: default avatarJonas Danielsson <jonas@orbital-systems.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      aa0703b7
    • Masahiro Yamada's avatar
      kconfig: fix memory leak when EOF is encountered in quotation · 507a004e
      Masahiro Yamada authored
      [ Upstream commit fbac5977 ]
      
      An unterminated string literal followed by new line is passed to the
      parser (with "multi-line strings not supported" warning shown), then
      handled properly there.
      
      On the other hand, an unterminated string literal at end of file is
      never passed to the parser, then results in memory leak.
      
      [Test Code]
      
        ----------(Kconfig begin)----------
        source "Kconfig.inc"
      
        config A
                bool "a"
        -----------(Kconfig end)-----------
      
        --------(Kconfig.inc begin)--------
        config B
                bool "b\No new line at end of file
        ---------(Kconfig.inc end)---------
      
      [Summary from Valgrind]
      
        Before the fix:
      
          LEAK SUMMARY:
             definitely lost: 16 bytes in 1 blocks
             ...
      
        After the fix:
      
          LEAK SUMMARY:
             definitely lost: 0 bytes in 0 blocks
             ...
      
      Eliminate the memory leak path by handling this case. Of course, such
      a Kconfig file is wrong already, so I will add an error message later.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      507a004e
    • Masahiro Yamada's avatar
      kconfig: fix file name and line number of warn_ignored_character() · c0a4b0c7
      Masahiro Yamada authored
      [ Upstream commit 77c1c0fa ]
      
      Currently, warn_ignore_character() displays invalid file name and
      line number.
      
      The lexer should use current_file->name and yylineno, while the parser
      should use zconf_curname() and zconf_lineno().
      
      This difference comes from that the lexer is always going ahead
      of the parser. The parser needs to look ahead one token to make a
      shift/reduce decision, so the lexer is requested to scan more text
      from the input file.
      
      This commit fixes the warning message from warn_ignored_character().
      
      [Test Code]
      
        ----(Kconfig begin)----
        /
        -----(Kconfig end)-----
      
      [Output]
      
        Before the fix:
      
        <none>:0:warning: ignoring unsupported character '/'
      
        After the fix:
      
        Kconfig:1:warning: ignoring unsupported character '/'
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c0a4b0c7
    • Reinette Chatre's avatar
      x86/resctrl: Fix rdt_find_domain() return value and checks · 8edd32a1
      Reinette Chatre authored
      [ Upstream commit 52eb7433 ]
      
      rdt_find_domain() returns an ERR_PTR() that is generated from a provided
      domain id when the value is negative.
      
      Care needs to be taken when creating an ERR_PTR() from this value
      because a subsequent check using IS_ERR() expects the error to
      be within the MAX_ERRNO range. Using an invalid domain id as an
      ERR_PTR() does work at this time since this is currently always -1.
      Using this undocumented assumption is fragile since future users of
      rdt_find_domain() may not be aware of thus assumption.
      
      Two related issues are addressed:
      
      - Ensure that rdt_find_domain() always returns a valid error value by
      forcing the error to be -ENODEV when a negative domain id is provided.
      
      - In a few instances the return value of rdt_find_domain() is just
      checked for NULL - fix these to include a check of ERR_PTR.
      
      Fixes: d89b7379 ("x86/intel_rdt/cqm: Add mon_data")
      Fixes: 521348b0 ("x86/intel_rdt: Introduce utility to obtain CDP peer")
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: fenghua.yu@intel.com
      Cc: gavin.hindman@intel.com
      Cc: jithu.joseph@intel.com
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/b88cd4ff6a75995bf8db9b0ea546908fe50f69f3.1544479852.git.reinette.chatre@intel.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      8edd32a1
    • Minas Harutyunyan's avatar
      usb: dwc2: Fix disable all EP's on disconnect · c92de95a
      Minas Harutyunyan authored
      [ Upstream commit 4fe4f9fe ]
      
      Disabling all EP's allow to reset EP's to initial state.
      Introduced new function dwc2_hsotg_ep_disable_lock() which
      before calling dwc2_hsotg_ep_disable() function acquire
      hsotg->lock and release on exiting.
      From dwc2_hsotg_ep_disable() function removed acquiring
      hsotg->lock.
      In dwc2_hsotg_core_init_disconnected() function when USB
      reset interrupt asserted disabling all ep’s by
      dwc2_hsotg_ep_disable() function.
      This updates eliminating sparse imbalance warnings.
      
      Reverted changes in dwc2_hostg_disconnect() function.
      Introduced new function dwc2_hsotg_ep_disable_lock().
      Changed dwc2_hsotg_ep_ops. Now disable point to
      dwc2_hsotg_ep_disable_lock() function.
      In functions dwc2_hsotg_udc_stop() and dwc2_hsotg_suspend()
      dwc2_hsotg_ep_disable() function replaced by
      dwc2_hsotg_ep_disable_lock() function.
      In dwc2_hsotg_ep_disable() function removed acquiring
      of hsotg->lock.
      
      Fixes: dccf1bad ("usb: dwc2: Disable all EP's on disconnect")
      Signed-off-by: default avatarMinas Harutyunyan <hminas@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c92de95a
    • Jiong Wang's avatar
      bpf: relax verifier restriction on BPF_MOV | BPF_ALU · 525cd39f
      Jiong Wang authored
      [ Upstream commit e434b8cd ]
      
      Currently, the destination register is marked as unknown for 32-bit
      sub-register move (BPF_MOV | BPF_ALU) whenever the source register type is
      SCALAR_VALUE.
      
      This is too conservative that some valid cases will be rejected.
      Especially, this may turn a constant scalar value into unknown value that
      could break some assumptions of verifier.
      
      For example, test_l4lb_noinline.c has the following C code:
      
          struct real_definition *dst
      
      1:  if (!get_packet_dst(&dst, &pckt, vip_info, is_ipv6))
      2:    return TC_ACT_SHOT;
      3:
      4:  if (dst->flags & F_IPV6) {
      
      get_packet_dst is responsible for initializing "dst" into valid pointer and
      return true (1), otherwise return false (0). The compiled instruction
      sequence using alu32 will be:
      
        412: (54) (u32) r7 &= (u32) 1
        413: (bc) (u32) r0 = (u32) r7
        414: (95) exit
      
      insn 413, a BPF_MOV | BPF_ALU, however will turn r0 into unknown value even
      r7 contains SCALAR_VALUE 1.
      
      This causes trouble when verifier is walking the code path that hasn't
      initialized "dst" inside get_packet_dst, for which case 0 is returned and
      we would then expect verifier concluding line 1 in the above C code pass
      the "if" check, therefore would skip fall through path starting at line 4.
      Now, because r0 returned from callee has became unknown value, so verifier
      won't skip analyzing path starting at line 4 and "dst->flags" requires
      dereferencing the pointer "dst" which actually hasn't be initialized for
      this path.
      
      This patch relaxed the code marking sub-register move destination. For a
      SCALAR_VALUE, it is safe to just copy the value from source then truncate
      it into 32-bit.
      
      A unit test also included to demonstrate this issue. This test will fail
      before this patch.
      
      This relaxation could let verifier skipping more paths for conditional
      comparison against immediate. It also let verifier recording a more
      accurate/strict value for one register at one state, if this state end up
      with going through exit without rejection and it is used for state
      comparison later, then it is possible an inaccurate/permissive value is
      better. So the real impact on verifier processed insn number is complex.
      But in all, without this fix, valid program could be rejected.
      
      >From real benchmarking on kernel selftests and Cilium bpf tests, there is
      no impact on processed instruction number when tests ares compiled with
      default compilation options. There is slightly improvements when they are
      compiled with -mattr=+alu32 after this patch.
      
      Also, test_xdp_noinline/-mattr=+alu32 now passed verification. It is
      rejected before this fix.
      
      Insn processed before/after this patch:
      
                              default     -mattr=+alu32
      
      Kernel selftest
      
      ===
      test_xdp.o              371/371      369/369
      test_l4lb.o             6345/6345    5623/5623
      test_xdp_noinline.o     2971/2971    rejected/2727
      test_tcp_estates.o      429/429      430/430
      
      Cilium bpf
      ===
      bpf_lb-DLB_L3.o:        2085/2085     1685/1687
      bpf_lb-DLB_L4.o:        2287/2287     1986/1982
      bpf_lb-DUNKNOWN.o:      690/690       622/622
      bpf_lxc.o:              95033/95033   N/A
      bpf_netdev.o:           7245/7245     N/A
      bpf_overlay.o:          2898/2898     3085/2947
      
      NOTE:
        - bpf_lxc.o and bpf_netdev.o compiled by -mattr=+alu32 are rejected by
          verifier due to another issue inside verifier on supporting alu32
          binary.
        - Each cilium bpf program could generate several processed insn number,
          above number is sum of them.
      
      v1->v2:
       - Restrict the change on SCALAR_VALUE.
       - Update benchmark numbers on Cilium bpf tests.
      Signed-off-by: default avatarJiong Wang <jiong.wang@netronome.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      525cd39f
    • Will Deacon's avatar
      arm64: Fix minor issues with the dcache_by_line_op macro · 26463188
      Will Deacon authored
      [ Upstream commit 33309ecd ]
      
      The dcache_by_line_op macro suffers from a couple of small problems:
      
      First, the GAS directives that are currently being used rely on
      assembler behavior that is not documented, and probably not guaranteed
      to produce the correct behavior going forward. As a result, we end up
      with some undefined symbols in cache.o:
      
      $ nm arch/arm64/mm/cache.o
               ...
               U civac
               ...
               U cvac
               U cvap
               U cvau
      
      This is due to the fact that the comparisons used to select the
      operation type in the dcache_by_line_op macro are comparing symbols
      not strings, and even though it seems that GAS is doing the right
      thing here (undefined symbols by the same name are equal to each
      other), it seems unwise to rely on this.
      
      Second, when patching in a DC CVAP instruction on CPUs that support it,
      the fallback path consists of a DC CVAU instruction which may be
      affected by CPU errata that require ARM64_WORKAROUND_CLEAN_CACHE.
      
      Solve these issues by unrolling the various maintenance routines and
      using the conditional directives that are documented as operating on
      strings. To avoid the complexity of nested alternatives, we move the
      DC CVAP patching to __clean_dcache_area_pop, falling back to a branch
      to __clean_dcache_area_poc if DCPOP is not supported by the CPU.
      Reported-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Suggested-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      26463188
    • Lucas Stach's avatar
      clk: imx6q: reset exclusive gates on init · cc3620b8
      Lucas Stach authored
      [ Upstream commit f7542d81 ]
      
      The exclusive gates may be set up in the wrong way by software running
      before the clock driver comes up. In that case the exclusive setup is
      locked in its initial state, as the complementary function can't be
      activated without disabling the initial setup first.
      
      To avoid this lock situation, reset the exclusive gates to the off
      state and allow the kernel to provide the proper setup.
      Signed-off-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Reviewed-by: default avatarDong Aisheng <Aisheng.dong@nxp.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cc3620b8
    • Qian Cai's avatar
      arm64: kasan: Increase stack size for KASAN_EXTRA · 4694db1b
      Qian Cai authored
      [ Upstream commit 6e883067 ]
      
      If the kernel is configured with KASAN_EXTRA, the stack size is
      increased significantly due to setting the GCC -fstack-reuse option to
      "none" [1]. As a result, it can trigger a stack overrun quite often with
      32k stack size compiled using GCC 8. For example, this reproducer
      
        https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise06.c
      
      can trigger a "corrupted stack end detected inside scheduler" very
      reliably with CONFIG_SCHED_STACK_END_CHECK enabled. There are other
      reports at:
      
        https://lore.kernel.org/lkml/1542144497.12945.29.camel@gmx.us/
        https://lore.kernel.org/lkml/721E7B42-2D55-4866-9C1A-3E8D64F33F9C@gmx.us/
      
      There are just too many functions that could have a large stack with
      KASAN_EXTRA due to large local variables that have been called over and
      over again without being able to reuse the stacks. Some noticiable ones
      are,
      
      size
      7536 shrink_inactive_list
      7440 shrink_page_list
      6560 fscache_stats_show
      3920 jbd2_journal_commit_transaction
      3216 try_to_unmap_one
      3072 migrate_page_move_mapping
      3584 migrate_misplaced_transhuge_page
      3920 ip_vs_lblcr_schedule
      4304 lpfc_nvme_info_show
      3888 lpfc_debugfs_nvmestat_data.constprop
      
      There are other 49 functions over 2k in size while compiling kernel with
      "-Wframe-larger-than=" on this machine. Hence, it is too much work to
      change Makefiles for each object to compile without
      -fsanitize-address-use-after-scope individually.
      
      [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715#c23Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4694db1b
    • Dmitry V. Levin's avatar
      selftests: do not macro-expand failed assertion expressions · 3fef5905
      Dmitry V. Levin authored
      [ Upstream commit b708a3cc ]
      
      I've stumbled over the current macro-expand behaviour of the test
      harness:
      
      $ gcc -Wall -xc - <<'__EOF__'
      TEST(macro) {
      	int status = 0;
      	ASSERT_TRUE(WIFSIGNALED(status));
      }
      TEST_HARNESS_MAIN
      __EOF__
      $ ./a.out
      [==========] Running 1 tests from 1 test cases.
      [ RUN      ] global.macro
      <stdin>:4:global.macro:Expected 0 (0) != (((signed char) (((status) & 0x7f) + 1) >> 1) > 0) (0)
      global.macro: Test terminated by assertion
      [     FAIL ] global.macro
      [==========] 0 / 1 tests passed.
      [  FAILED  ]
      
      With this change the output of the same test looks much more
      comprehensible:
      
      [==========] Running 1 tests from 1 test cases.
      [ RUN      ] global.macro
      <stdin>:4:global.macro:Expected 0 (0) != WIFSIGNALED(status) (0)
      global.macro: Test terminated by assertion
      [     FAIL ] global.macro
      [==========] 0 / 1 tests passed.
      [  FAILED  ]
      
      The issue is very similar to the bug fixed in glibc assert(3)
      three years ago:
      https://sourceware.org/bugzilla/show_bug.cgi?id=18604
      
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Will Drewry <wad@chromium.org>
      Cc: linux-kselftest@vger.kernel.org
      Signed-off-by: default avatarDmitry V. Levin <ldv@altlinux.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarShuah Khan <shuah@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3fef5905
    • Bart Van Assche's avatar
      scsi: target/core: Make sure that target_wait_for_sess_cmds() waits long enough · 6c05aea6
      Bart Van Assche authored
      [ Upstream commit ad669505 ]
      
      A session must only be released after all code that accesses the session
      structure has finished. Make sure that this is the case by introducing a
      new command counter per session that is only decremented after the
      .release_cmd() callback has finished. This patch fixes the following crash:
      
      BUG: KASAN: use-after-free in do_raw_spin_lock+0x1c/0x130
      Read of size 4 at addr ffff8801534b16e4 by task rmdir/14805
      CPU: 16 PID: 14805 Comm: rmdir Not tainted 4.18.0-rc2-dbg+ #5
      Call Trace:
      dump_stack+0xa4/0xf5
      print_address_description+0x6f/0x270
      kasan_report+0x241/0x360
      __asan_load4+0x78/0x80
      do_raw_spin_lock+0x1c/0x130
      _raw_spin_lock_irqsave+0x52/0x60
      srpt_set_ch_state+0x27/0x70 [ib_srpt]
      srpt_disconnect_ch+0x1b/0xc0 [ib_srpt]
      srpt_close_session+0xa8/0x260 [ib_srpt]
      target_shutdown_sessions+0x170/0x180 [target_core_mod]
      core_tpg_del_initiator_node_acl+0xf3/0x200 [target_core_mod]
      target_fabric_nacl_base_release+0x25/0x30 [target_core_mod]
      config_item_release+0x9c/0x110 [configfs]
      config_item_put+0x26/0x30 [configfs]
      configfs_rmdir+0x3b8/0x510 [configfs]
      vfs_rmdir+0xb3/0x1e0
      do_rmdir+0x262/0x2c0
      do_syscall_64+0x77/0x230
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Cc: Nicholas Bellinger <nab@linux-iscsi.org>
      Cc: Mike Christie <mchristi@redhat.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: David Disseldorp <ddiss@suse.de>
      Cc: Hannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: Martin K. Petersen's avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6c05aea6
    • David Disseldorp's avatar
      scsi: target: use consistent left-aligned ASCII INQUIRY data · 074a5fa4
      David Disseldorp authored
      [ Upstream commit 0de26357 ]
      
      spc5r17.pdf specifies:
      
        4.3.1 ASCII data field requirements
        ASCII data fields shall contain only ASCII printable characters (i.e.,
        code values 20h to 7Eh) and may be terminated with one or more ASCII null
        (00h) characters.  ASCII data fields described as being left-aligned
        shall have any unused bytes at the end of the field (i.e., highest
        offset) and the unused bytes shall be filled with ASCII space characters
        (20h).
      
      LIO currently space-pads the T10 VENDOR IDENTIFICATION and PRODUCT
      IDENTIFICATION fields in the standard INQUIRY data. However, the PRODUCT
      REVISION LEVEL field in the standard INQUIRY data as well as the T10 VENDOR
      IDENTIFICATION field in the INQUIRY Device Identification VPD Page are
      zero-terminated/zero-padded.
      
      Fix this inconsistency by using space-padding for all of the above fields.
      Signed-off-by: default avatarDavid Disseldorp <ddiss@suse.de>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarBryant G. Ly <bly@catalogicsoftware.com>
      Reviewed-by: default avatarLee Duncan <lduncan@suse.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarRoman Bolshakov <r.bolshakov@yadro.com>
      Signed-off-by: Martin K. Petersen's avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      074a5fa4
    • yupeng820921's avatar
      net: call sk_dst_reset when set SO_DONTROUTE · 221fed3a
      yupeng820921 authored
      [ Upstream commit 0fbe82e6 ]
      
      after set SO_DONTROUTE to 1, the IP layer should not route packets if
      the dest IP address is not in link scope. But if the socket has cached
      the dst_entry, such packets would be routed until the sk_dst_cache
      expires. So we should clean the sk_dst_cache when a user set
      SO_DONTROUTE option. Below are server/client python scripts which
      could reprodue this issue:
      
      server side code:
      
      ==========================================================================
      import socket
      import struct
      import time
      
      s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
      s.bind(('0.0.0.0', 9000))
      s.listen(1)
      sock, addr = s.accept()
      sock.setsockopt(socket.SOL_SOCKET, socket.SO_DONTROUTE, struct.pack('i', 1))
      while True:
          sock.send(b'foo')
          time.sleep(1)
      ==========================================================================
      
      client side code:
      ==========================================================================
      import socket
      import time
      
      s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
      s.connect(('server_address', 9000))
      while True:
          data = s.recv(1024)
          print(data)
      ==========================================================================
      Signed-off-by: yupeng820921's avataryupeng <yupeng0921@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      221fed3a
    • Gao Xiang's avatar
      staging: erofs: fix use-after-free of on-stack `z_erofs_vle_unzip_io' · 54d0b69a
      Gao Xiang authored
      [ Upstream commit 848bd9ac ]
      
      The root cause is the race as follows:
       Thread #0                         Thread #1
      
       z_erofs_vle_unzip_kickoff         z_erofs_submit_and_unzip
      
                                          struct z_erofs_vle_unzip_io io[]
         atomic_add_return()
                                          wait_event()
                                          [end of function]
         wake_up()
      
      Fix it by taking the waitqueue lock between atomic_add_return and
      wake_up to close such the race.
      
      kernel message:
      
      Unable to handle kernel paging request at virtual address 97f7052caa1303dc
      ...
      Workqueue: kverityd verity_work
      task: ffffffe32bcb8000 task.stack: ffffffe3298a0000
      PC is at __wake_up_common+0x48/0xa8
      LR is at __wake_up+0x3c/0x58
      ...
      Call trace:
      ...
      [<ffffff94a08ff648>] __wake_up_common+0x48/0xa8
      [<ffffff94a08ff8b8>] __wake_up+0x3c/0x58
      [<ffffff94a0c11b60>] z_erofs_vle_unzip_kickoff+0x40/0x64
      [<ffffff94a0c118e4>] z_erofs_vle_read_endio+0x94/0x134
      [<ffffff94a0c83c9c>] bio_endio+0xe4/0xf8
      [<ffffff94a1076540>] dec_pending+0x134/0x32c
      [<ffffff94a1076f28>] clone_endio+0x90/0xf4
      [<ffffff94a0c83c9c>] bio_endio+0xe4/0xf8
      [<ffffff94a1095024>] verity_work+0x210/0x368
      [<ffffff94a08c4150>] process_one_work+0x188/0x4b4
      [<ffffff94a08c45bc>] worker_thread+0x140/0x458
      [<ffffff94a08cad48>] kthread+0xec/0x108
      [<ffffff94a0883ab4>] ret_from_fork+0x10/0x1c
      Code: d1006273 54000260 f9400804 b9400019 (b85fc081)
      ---[ end trace be9dde154f677cd1 ]---
      Reviewed-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarGao Xiang <gaoxiang25@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      54d0b69a
    • Vivek Gautam's avatar
      media: venus: core: Set dma maximum segment size · 181aa135
      Vivek Gautam authored
      [ Upstream commit de2563bc ]
      
      Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:
      
      [  460.308650] ------------[ cut here ]------------
      [  460.313490] qcom-venus aa00000.video-codec: DMA-API: mapping sg segment longer than device claims to support [len=4194304] [max=65536]
      [  460.326017] WARNING: CPU: 3 PID: 3555 at src/kernel/dma/debug.c:1301 debug_dma_map_sg+0x174/0x254
      [  460.338888] Modules linked in: venus_dec venus_enc videobuf2_dma_sg videobuf2_memops hci_uart btqca bluetooth venus_core v4l2_mem2mem videobuf2_v4l2 videobuf2_common ath10k_snoc ath10k_core ath lzo lzo_compress zramjoydev
      [  460.375811] CPU: 3 PID: 3555 Comm: V4L2DecoderThre Tainted: G        W         4.19.1 #82
      [  460.384223] Hardware name: Google Cheza (rev1) (DT)
      [  460.389251] pstate: 60400009 (nZCv daif +PAN -UAO)
      [  460.394191] pc : debug_dma_map_sg+0x174/0x254
      [  460.398680] lr : debug_dma_map_sg+0x174/0x254
      [  460.403162] sp : ffffff80200c37d0
      [  460.406583] x29: ffffff80200c3830 x28: 0000000000010000
      [  460.412056] x27: 00000000ffffffff x26: ffffffc0f785ea80
      [  460.417532] x25: 0000000000000000 x24: ffffffc0f4ea1290
      [  460.423001] x23: ffffffc09e700300 x22: ffffffc0f4ea1290
      [  460.428470] x21: ffffff8009037000 x20: 0000000000000001
      [  460.433936] x19: ffffff80091b0000 x18: 0000000000000000
      [  460.439411] x17: 0000000000000000 x16: 000000000000f251
      [  460.444885] x15: 0000000000000006 x14: 0720072007200720
      [  460.450354] x13: ffffff800af536e0 x12: 0000000000000000
      [  460.455822] x11: 0000000000000000 x10: 0000000000000000
      [  460.461288] x9 : 537944d9c6c48d00 x8 : 537944d9c6c48d00
      [  460.466758] x7 : 0000000000000000 x6 : ffffffc0f8d98f80
      [  460.472230] x5 : 0000000000000000 x4 : 0000000000000000
      [  460.477703] x3 : 000000000000008a x2 : ffffffc0fdb13948
      [  460.483170] x1 : ffffffc0fdb0b0b0 x0 : 000000000000007a
      [  460.488640] Call trace:
      [  460.491165]  debug_dma_map_sg+0x174/0x254
      [  460.495307]  vb2_dma_sg_alloc+0x260/0x2dc [videobuf2_dma_sg]
      [  460.501150]  __vb2_queue_alloc+0x164/0x374 [videobuf2_common]
      [  460.507076]  vb2_core_reqbufs+0xfc/0x23c [videobuf2_common]
      [  460.512815]  vb2_reqbufs+0x44/0x5c [videobuf2_v4l2]
      [  460.517853]  v4l2_m2m_reqbufs+0x44/0x78 [v4l2_mem2mem]
      [  460.523144]  v4l2_m2m_ioctl_reqbufs+0x1c/0x28 [v4l2_mem2mem]
      [  460.528976]  v4l_reqbufs+0x30/0x40
      [  460.532480]  __video_do_ioctl+0x36c/0x454
      [  460.536610]  video_usercopy+0x25c/0x51c
      [  460.540572]  video_ioctl2+0x38/0x48
      [  460.544176]  v4l2_ioctl+0x60/0x74
      [  460.547602]  do_video_ioctl+0x948/0x3520
      [  460.551648]  v4l2_compat_ioctl32+0x60/0x98
      [  460.555872]  __arm64_compat_sys_ioctl+0x134/0x20c
      [  460.560718]  el0_svc_common+0x9c/0xe4
      [  460.564498]  el0_svc_compat_handler+0x2c/0x38
      [  460.568982]  el0_svc_compat+0x8/0x18
      [  460.572672] ---[ end trace ce209b87b2f3af88 ]---
      
      >From above warning one would deduce that the sg segment will overflow
      the device's capacity. In reality, the hardware can accommodate larger
      sg segments.
      So, initialize the max segment size properly to weed out this warning.
      
      Based on a similar patch sent by Sean Paul for mdss:
      https://patchwork.kernel.org/patch/10671457/Signed-off-by: default avatarVivek Gautam <vivek.gautam@codeaurora.org>
      Acked-by: default avatarStanimir Varbanov <stanimir.varbanov@linaro.org>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      181aa135
    • Leo Yan's avatar
      coresight: tmc: Fix bad register address for CLAIM · b436f384
      Leo Yan authored
      [ Upstream commit 323ed1e0 ]
      
      Commit 4d3ebd36 ("coreisght: tmc: Claim device before use") uses
      CLAIM tag to validate if the device is available, it needs to pass
      the device base address to access related registers.
      
      In the function tmc_etb_disable_hw() it wrongly passes the driver data
      pointer as register base address, thus it's easily to produce the kernel
      warning info like below:
      
      [   83.579898] WARNING: CPU: 4 PID: 2970 at drivers/hwtracing/coresight/coresight.c:207 coresight_disclaim_device_unlocked+0x44/0x80
      [   83.591448] Modules linked in:
      [   83.594485] CPU: 4 PID: 2970 Comm: uname Not tainted 4.19.0-rc6-00417-g721b509 #110
      [   83.602067] Hardware name: ARM Juno development board (r2) (DT)
      [   83.607932] pstate: 80000085 (Nzcv daIf -PAN -UAO)
      [   83.612681] pc : coresight_disclaim_device_unlocked+0x44/0x80
      [   83.618375] lr : coresight_disclaim_device_unlocked+0x44/0x80
      [   83.624064] sp : ffff00000fe3ba20
      [   83.627347] x29: ffff00000fe3ba20 x28: ffff80002d430dc0
      [   83.632618] x27: ffff800033177c00 x26: ffff80002eb44480
      [   83.637889] x25: 0000000000000001 x24: ffff800033c72600
      [   83.643160] x23: ffff0000099b11f8 x22: ffff0000099b11c8
      [   83.648430] x21: 0000000000000002 x20: ffff800033a90418
      [   83.653701] x19: ffff0000099b11c8 x18: 0000000000000000
      [   83.658971] x17: 0000000000000000 x16: 0000000000000000
      [   83.664241] x15: 0000000000000000 x14: 0000000000000000
      [   83.669511] x13: 0000000000000000 x12: 0000000000000000
      [   83.674782] x11: 0000000000000000 x10: 0000000000000000
      [   83.680052] x9 : 0000000000000000 x8 : 0000000000000001
      [   83.685322] x7 : 0000000000010000 x6 : ffff800033ebab18
      [   83.690593] x5 : ffff800033ebab18 x4 : ffff800033e6c698
      [   83.695862] x3 : 0000000000000001 x2 : 0000000000000000
      [   83.701133] x1 : 0000000000000000 x0 : 0000000000000001
      [   83.706404] Call trace:
      [   83.708830]  coresight_disclaim_device_unlocked+0x44/0x80
      [   83.714180]  coresight_disclaim_device+0x34/0x48
      [   83.718756]  tmc_disable_etf_sink+0xc4/0xf0
      [   83.722902]  coresight_disable_path_from+0xc8/0x240
      [   83.727735]  coresight_disable_path+0x24/0x30
      [   83.732053]  etm_event_stop+0x130/0x170
      [   83.735854]  etm_event_del+0x24/0x30
      [   83.739399]  event_sched_out.isra.51+0xcc/0x1e8
      [   83.743887]  group_sched_out.part.53+0x44/0xb0
      [   83.748291]  ctx_sched_out+0x298/0x2b8
      [   83.752005]  task_ctx_sched_out+0x74/0xa8
      [   83.755980]  perf_event_exit_task+0x140/0x418
      [   83.760298]  do_exit+0x3f4/0xcf0
      [   83.763497]  do_group_exit+0x5c/0xc0
      [   83.767041]  __arm64_sys_exit_group+0x24/0x28
      [   83.771359]  el0_svc_common+0x110/0x178
      [   83.775160]  el0_svc_handler+0x94/0xe8
      [   83.778875]  el0_svc+0x8/0xc
      [   83.781728] ---[ end trace 02d8d8eac46db9e5 ]---
      
      This patch is to fix this bug by using 'drvdata->base' as the
      register base address for CLAIM related operation.
      
      Fixes: 4d3ebd36 ("coreisght: tmc: Claim device before use")
      Cc: Suzuki Poulose <suzuki.poulose@arm.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Mike Leach <mike.leach@linaro.org>
      Cc: Robert Walker <robert.walker@arm.com>
      Signed-off-by: default avatarLeo Yan <leo.yan@linaro.org>
      Reviewed-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b436f384
    • Yu Zhao's avatar
      ASoC: use dma_ops of parent device for acp_audio_dma · b4ba1c27
      Yu Zhao authored
      [ Upstream commit 23aa128b ]
      
      AMD platform device acp_audio_dma can only be created by parent PCI
      device driver (drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c). Pass struct
      device of the parent to snd_pcm_lib_preallocate_pages() so
      dma_alloc_coherent() can use correct dma_ops. Otherwise, it will
      use default dma_ops which is nommu_dma_ops on x86_64 even when
      IOMMU is enabled and set to non passthrough mode.
      
      Though platform device inherits some dma related fields during its
      creation in mfd_add_device(), we can't simply pass its struct device
      to snd_pcm_lib_preallocate_pages() because dma_ops is not among the
      inherited fields. Even it were, drivers/iommu/amd_iommu.c would
      ignore it because get_device_id() doesn't handle platform device.
      
      This change shouldn't give us any trouble even struct device of the
      parent becomes null or represents some non PCI device in the future,
      because get_dma_ops() correctly handles null struct device or uses
      the default dma_ops if struct device doesn't have it set.
      Signed-off-by: default avatarYu Zhao <yuzhao@google.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b4ba1c27
    • Nathan Chancellor's avatar
      media: firewire: Fix app_info parameter type in avc_ca{,_app}_info · e6256cb1
      Nathan Chancellor authored
      [ Upstream commit b2e9a4ed ]
      
      Clang warns:
      
      drivers/media/firewire/firedtv-avc.c:999:45: warning: implicit
      conversion from 'int' to 'char' changes value from 159 to -97
      [-Wconstant-conversion]
              app_info[0] = (EN50221_TAG_APP_INFO >> 16) & 0xff;
                          ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
      drivers/media/firewire/firedtv-avc.c:1000:45: warning: implicit
      conversion from 'int' to 'char' changes value from 128 to -128
      [-Wconstant-conversion]
              app_info[1] = (EN50221_TAG_APP_INFO >>  8) & 0xff;
                          ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
      drivers/media/firewire/firedtv-avc.c:1040:44: warning: implicit
      conversion from 'int' to 'char' changes value from 159 to -97
      [-Wconstant-conversion]
              app_info[0] = (EN50221_TAG_CA_INFO >> 16) & 0xff;
                          ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
      drivers/media/firewire/firedtv-avc.c:1041:44: warning: implicit
      conversion from 'int' to 'char' changes value from 128 to -128
      [-Wconstant-conversion]
              app_info[1] = (EN50221_TAG_CA_INFO >>  8) & 0xff;
                          ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
      4 warnings generated.
      
      Change app_info's type to unsigned char to match the type of the
      member msg in struct ca_msg, which is the only thing passed into the
      app_info parameter in this function.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/105Signed-off-by: Nathan Chancellor's avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e6256cb1
    • Ard Biesheuvel's avatar
      arm64: relocatable: fix inconsistencies in linker script and options · 8799dd0b
      Ard Biesheuvel authored
      [ Upstream commit 3bbd3db8 ]
      
      readelf complains about the section layout of vmlinux when building
      with CONFIG_RELOCATABLE=y (for KASLR):
      
        readelf: Warning: [21]: Link field (0) should index a symtab section.
        readelf: Warning: [21]: Info field (0) should index a relocatable section.
      
      Also, it seems that our use of '-pie -shared' is contradictory, and
      thus ambiguous. In general, the way KASLR is wired up at the moment
      is highly tailored to how ld.bfd happens to implement (and conflate)
      PIE executables and shared libraries, so given the current effort to
      support other toolchains, let's fix some of these issues as well.
      
      - Drop the -pie linker argument and just leave -shared. In ld.bfd,
        the differences between them are unclear (except for the ELF type
        of the produced image [0]) but lld chokes on seeing both at the
        same time.
      
      - Rename the .rela output section to .rela.dyn, as is customary for
        shared libraries and PIE executables, so that it is not misidentified
        by readelf as a static relocation section (producing the warnings
        above).
      
      - Pass the -z notext and -z norelro options to explicitly instruct the
        linker to permit text relocations, and to omit the RELRO program
        header (which requires a certain section layout that we don't adhere
        to in the kernel). These are the defaults for current versions of
        ld.bfd.
      
      - Discard .eh_frame and .gnu.hash sections to avoid them from being
        emitted between .head.text and .text, screwing up the section layout.
      
      These changes only affect the ELF image, and produce the same binary
      image.
      
      [0] b9dce7f1 ("arm64: kernel: force ET_DYN ELF type for ...")
      
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Peter Smith <peter.smith@linaro.org>
      Tested-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8799dd0b
    • Breno Leitao's avatar
      powerpc/pseries/cpuidle: Fix preempt warning · a95bc96d
      Breno Leitao authored
      [ Upstream commit 2b038cbc ]
      
      When booting a pseries kernel with PREEMPT enabled, it dumps the
      following warning:
      
         BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
         caller is pseries_processor_idle_init+0x5c/0x22c
         CPU: 13 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc3-00090-g12201a0128bc-dirty #828
         Call Trace:
         [c000000429437ab0] [c0000000009c8878] dump_stack+0xec/0x164 (unreliable)
         [c000000429437b00] [c0000000005f2f24] check_preemption_disabled+0x154/0x160
         [c000000429437b90] [c000000000cab8e8] pseries_processor_idle_init+0x5c/0x22c
         [c000000429437c10] [c000000000010ed4] do_one_initcall+0x64/0x300
         [c000000429437ce0] [c000000000c54500] kernel_init_freeable+0x3f0/0x500
         [c000000429437db0] [c0000000000112dc] kernel_init+0x2c/0x160
         [c000000429437e20] [c00000000000c1d0] ret_from_kernel_thread+0x5c/0x6c
      
      This happens because the code calls get_lppaca() which calls
      get_paca() and it checks if preemption is disabled through
      check_preemption_disabled().
      
      Preemption should be disabled because the per CPU variable may make no
      sense if there is a preemption (and a CPU switch) after it reads the
      per CPU data and when it is used.
      
      In this device driver specifically, it is not a problem, because this
      code just needs to have access to one lppaca struct, and it does not
      matter if it is the current per CPU lppaca struct or not (i.e. when
      there is a preemption and a CPU migration).
      
      That said, the most appropriate fix seems to be related to avoiding
      the debug_smp_processor_id() call at get_paca(), instead of calling
      preempt_disable() before get_paca().
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: Michael Ellerman's avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a95bc96d
    • Breno Leitao's avatar
      powerpc/xmon: Fix invocation inside lock region · 8196c073
      Breno Leitao authored
      [ Upstream commit 8d4a8622 ]
      
      Currently xmon needs to get devtree_lock (through rtas_token()) during its
      invocation (at crash time). If there is a crash while devtree_lock is being
      held, then xmon tries to get the lock but spins forever and never get into
      the interactive debugger, as in the following case:
      
      	int *ptr = NULL;
      	raw_spin_lock_irqsave(&devtree_lock, flags);
      	*ptr = 0xdeadbeef;
      
      This patch avoids calling rtas_token(), thus trying to get the same lock,
      at crash time. This new mechanism proposes getting the token at
      initialization time (xmon_init()) and just consuming it at crash time.
      
      This would allow xmon to be possible invoked independent of devtree_lock
      being held or not.
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Reviewed-by: default avatarThiago Jung Bauermann <bauerman@linux.ibm.com>
      Signed-off-by: Michael Ellerman's avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8196c073
    • Daniel Axtens's avatar
      media: uvcvideo: Refactor teardown of uvc on USB disconnect · 13e97606
      Daniel Axtens authored
      [ Upstream commit 10e1fdb9 ]
      
      Currently, disconnecting a USB webcam while it is in use prints out a
      number of warnings, such as:
      
      WARNING: CPU: 2 PID: 3118 at /build/linux-ezBi1T/linux-4.8.0/fs/sysfs/group.c:237 sysfs_remove_group+0x8b/0x90
      sysfs group ffffffffa7cd0780 not found for kobject 'event13'
      
      This has been noticed before. [0]
      
      This is because of the order in which things are torn down.
      
      If there are no streams active during a USB disconnect:
      
       - uvc_disconnect() is invoked via device_del() through the bus
         notifier mechanism.
      
       - this calls uvc_unregister_video().
      
       - uvc_unregister_video() unregisters the video device for each
         stream,
      
       - because there are no streams open, it calls uvc_delete()
      
       - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
         input device.
      
       - uvc_delete() calls media_device_unregister(), which cleans up the
         media device
      
       - uvc_delete(), uvc_unregister_video() and uvc_disconnect() all
         return, and we end up back in device_del().
      
       - device_del() then cleans up the sysfs folder for the camera with
         dpm_sysfs_remove(). Because uvc_status_cleanup() and
         media_device_unregister() have already been called, this all works
         nicely.
      
      If, on the other hand, there *are* streams active during a USB disconnect:
      
       - uvc_disconnect() is invoked
      
       - this calls uvc_unregister_video()
      
       - uvc_unregister_video() unregisters the video device for each
         stream,
      
       - uvc_unregister_video() and uvc_disconnect() return, and we end up
         back in device_del().
      
       - device_del() then cleans up the sysfs folder for the camera with
         dpm_sysfs_remove(). Because the status input device and the media
         device are children of the USB device, this also deletes their
         sysfs folders.
      
       - Sometime later, the final stream is closed, invoking uvc_release().
      
       - uvc_release() calls uvc_delete()
      
       - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
         input device. Because the sysfs directory has already been removed,
         this causes a WARNing.
      
       - uvc_delete() calls media_device_unregister(), which cleans up the
         media device. Because the sysfs directory has already been removed,
         this causes another WARNing.
      
      To fix this, we need to make sure the devices are always unregistered
      before the end of uvc_disconnect(). To this, move the unregistration
      into the disconnect path:
      
       - split uvc_status_cleanup() into two parts, one on disconnect that
         unregisters and one on delete that frees.
      
       - move v4l2_device_unregister() and media_device_unregister() into
         the disconnect path.
      
      [0]: https://lkml.org/lkml/2016/12/8/657
      
      [Renamed uvc_input_cleanup() to uvc_input_unregister()]
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: Laurent Pinchart's avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      13e97606
    • Joel Fernandes (Google)'s avatar
      pstore/ram: Do not treat empty buffers as valid · 9e969ba4
      Joel Fernandes (Google) authored
      [ Upstream commit 30696378 ]
      
      The ramoops backend currently calls persistent_ram_save_old() even
      if a buffer is empty. While this appears to work, it is does not seem
      like the right thing to do and could lead to future bugs so lets avoid
      that. It also prevents misleading prints in the logs which claim the
      buffer is valid.
      
      I got something like:
      
      	found existing buffer, size 0, start 0
      
      When I was expecting:
      
      	no valid data in buffer (sig = ...)
      
      This bails out early (and reports with pr_debug()), since it's an
      acceptable state.
      Signed-off-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Co-developed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9e969ba4
    • A.s. Dong's avatar
      clk: imx: make mux parent strings const · 6029666f
      A.s. Dong authored
      [ Upstream commit 9e5ef7a5 ]
      
      As the commit 2893c379 ("clk: make strings in parent name arrays
      const"), let's make the parent strings const, otherwise we may meet
      the following warning when compiling:
      
      drivers/clk/imx/clk-imx7ulp.c: In function 'imx7ulp_clocks_init':
      drivers/clk/imx/clk-imx7ulp.c:73:35: warning: passing argument 5 of
      	'imx_clk_mux_flags' discards 'const' qualifier from pointer target type
      
        clks[IMX7ULP_CLK_APLL_PRE_SEL] = imx_clk_mux_flags("apll_pre_sel", base + 0x508, 0,
      	1, pll_pre_sels, ARRAY_SIZE(pll_pre_sels), CLK_SET_PARENT_GATE);
                                         ^
      In file included from drivers/clk/imx/clk-imx7ulp.c:23:0:
      drivers/clk/imx/clk.h:200:27: note: expected 'const char **' but argument is
       of type 'const char * const*'
      ...
      
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarDong Aisheng <aisheng.dong@nxp.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6029666f
    • Masahiro Yamada's avatar
      kbuild: let fixdep directly write to .*.cmd files · a41c9b57
      Masahiro Yamada authored
      [ Upstream commit 392885ee ]
      
      Currently, fixdep writes dependencies to .*.tmp, which is renamed to
      .*.cmd after everything succeeds. This is a very safe way to avoid
      corrupted .*.cmd files. The if_changed_dep has carried this safety
      mechanism since it was added in 2002.
      
      If fixdep fails for some reasons or a user terminates the build while
      fixdep is running, the incomplete output from the fixdep could be
      troublesome.
      
      This is my insight about some bad scenarios:
      
      [1] If the compiler succeeds to generate *.o file, but fixdep fails
          to write necessary dependencies to .*.cmd file, Make will miss
          to rebuild the object when headers or CONFIG options are changed.
          In this case, fixdep should not generate .*.cmd file at all so
          that 'arg-check' will surely trigger the rebuild of the object.
      
      [2] A partially constructed .*.cmd file may not be a syntactically
          correct makefile. The next time Make runs, it would include it,
          then fail to parse it. Once this happens, 'make clean' is be the
          only way to fix it.
      
      In fact, [1] is no longer a problem since commit 9c2af1c7 ("kbuild:
      add .DELETE_ON_ERROR special target"). Make deletes a target file on
      any failure in its recipe. Because fixdep is a part of the recipe of
      *.o target, if it fails, the *.o is deleted anyway. However, I am a
      bit worried about the slight possibility of [2].
      
      So, here is a solution. Let fixdep directly write to a .*.cmd file,
      but allow makefiles to include it only when its corresponding target
      exists.
      
      This effectively reverts commit 2982c953 ("kbuild: remove redundant
      $(wildcard ...) for cmd_files calculation"), and commit 00d78ab2
      ("kbuild: remove dead code in cmd_files calculation in top Makefile")
      because now we must check the presence of targets.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a41c9b57
    • Daniel Santos's avatar
      jffs2: Fix use of uninitialized delayed_work, lockdep breakage · 39e10358
      Daniel Santos authored
      [ Upstream commit a788c527 ]
      
      jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
      is defined then a write buffer is available and has been initialized.
      However, this does is not the case when the mtd device has no
      out-of-band buffer:
      
      int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
      {
              if (!c->mtd->oobsize)
                      return 0;
      ...
      
      The resulting call to cancel_delayed_work_sync passing a uninitialized
      (but zeroed) delayed_work struct forces lockdep to become disabled.
      
      [   90.050639] overlayfs: upper fs does not support tmpfile.
      [   90.652264] INFO: trying to register non-static key.
      [   90.662171] the code is fine but needs lockdep annotation.
      [   90.673090] turning off the locking correctness validator.
      [   90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0
      [   90.696672] Stack : 00000000 00000000 80d8f6a2 00000038 805f0000 80444600 8fe364f4 805dfbe7
      [   90.713349]         80563a30 000006e2 8068370c 00000001 00000000 00000001 8e2fdc48 ffffffff
      [   90.730020]         00000000 00000000 80d90000 00000000 00000106 00000000 6465746e 312e3420
      [   90.746690]         6b636f6c 03bf0000 f8000000 20676e69 00000000 80000000 00000000 8e2c2a90
      [   90.763362]         80d90000 00000001 00000000 8e2c2a90 00000003 80260dc0 08052098 80680000
      [   90.780033]         ...
      [   90.784902] Call Trace:
      [   90.789793] [<8000f0d8>] show_stack+0xb8/0x148
      [   90.798659] [<8005a000>] register_lock_class+0x270/0x55c
      [   90.809247] [<8005cb64>] __lock_acquire+0x13c/0xf7c
      [   90.818964] [<8005e314>] lock_acquire+0x194/0x1dc
      [   90.828345] [<8003f27c>] flush_work+0x200/0x24c
      [   90.837374] [<80041dfc>] __cancel_work_timer+0x158/0x210
      [   90.847958] [<801a8770>] jffs2_sync_fs+0x20/0x54
      [   90.857173] [<80125cf4>] iterate_supers+0xf4/0x120
      [   90.866729] [<80158fc4>] sys_sync+0x44/0x9c
      [   90.875067] [<80014424>] syscall_common+0x34/0x58
      Signed-off-by: Daniel Santos's avatarDaniel Santos <daniel.santos@pobox.com>
      Reviewed-by: default avatarHou Tao <houtao1@huawei.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      39e10358
    • Nathan Chancellor's avatar
      efi/libstub: Disable some warnings for x86{,_64} · 27556568
      Nathan Chancellor authored
      [ Upstream commit 3db5e0ba ]
      
      When building the kernel with Clang, some disabled warnings appear
      because this Makefile overrides KBUILD_CFLAGS for x86{,_64}. Add them to
      this list so that the build is clean again.
      
      -Wpointer-sign was disabled for the whole kernel before the beginning of Git history.
      
      -Waddress-of-packed-member was disabled for the whole kernel and for
      the early boot code in these commits:
      
        bfb38988 ("kbuild: clang: Disable 'address-of-packed-member' warning")
        20c6c189 ("x86/boot: Disable the address-of-packed-member compiler warning").
      
      -Wgnu was disabled for the whole kernel and for the early boot code in
      these commits:
      
        61163efa ("kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang")
        6c3b56b1 ("x86/boot: Disable Clang warnings about GNU extensions").
      
       [ mingo: Made the changelog more readable. ]
      Tested-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      Signed-off-by: Nathan Chancellor's avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
      Cc: Bhupesh Sharma <bhsharma@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Eric Snowberg <eric.snowberg@oracle.com>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Jon Hunter <jonathanh@nvidia.com>
      Cc: Julien Thierry <julien.thierry@arm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: YiFei Zhu <zhuyifei1999@gmail.com>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20181129171230.18699-8-ard.biesheuvel@linaro.org
      Link: https://github.com/ClangBuiltLinux/linux/issues/112Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      27556568
    • Chuck Lever's avatar
      rxe: IB_WR_REG_MR does not capture MR's iova field · 1da48f58
      Chuck Lever authored
      [ Upstream commit b024dd0e ]
      
      FRWR memory registration is done with a series of calls and WRs.
      1. ULP invokes ib_dma_map_sg()
      2. ULP invokes ib_map_mr_sg()
      3. ULP posts an IB_WR_REG_MR on the Send queue
      
      Step 2 generates an iova. It is permissible for ULPs to change this
      iova (with certain restrictions) between steps 2 and 3.
      
      rxe_map_mr_sg captures the MR's iova but later when rxe processes the
      REG_MR WR, it ignores the MR's iova field. If a ULP alters the MR's iova
      after step 2 but before step 3, rxe never captures that change.
      
      When the remote sends an RDMA Read targeting that MR, rxe looks up the
      R_key, but the altered iova does not match the iova stored in the MR,
      causing the RDMA Read request to fail.
      Reported-by: default avatarAnna Schumaker <schumaker.anna@gmail.com>
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Reviewed-by: Sagi Grimberg's avatarSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1da48f58
    • Chris Wilson's avatar
      drm/amdgpu: Reorder uvd ring init before uvd resume · c5656fd9
      Chris Wilson authored
      [ Upstream commit 3b34c14f ]
      
      As amd_uvd_resume() accesses the uvd ring, it must be initialised first
      or else we trigger errors like:
      
      [    5.595963] [drm] Found UVD firmware Version: 1.87 Family ID: 17
      [    5.595969] [drm] PSP loading UVD firmware
      [    5.596266] ------------[ cut here ]------------
      [    5.596268] ODEBUG: assert_init not available (active state 0) object type: timer_list hint:           (null)
      [    5.596285] WARNING: CPU: 0 PID: 507 at lib/debugobjects.c:329 debug_print_object+0x6a/0x80
      [    5.596286] Modules linked in: amdgpu(+) hid_logitech_hidpp(+) chash gpu_sched amd_iommu_v2 ttm drm_kms_helper crc32c_intel drm hid_sony ff_memless igb hid_logitech_dj nvme dca i2c_algo_bit nvme_core wmi pinctrl_amd uas usb_storage
      [    5.596299] CPU: 0 PID: 507 Comm: systemd-udevd Tainted: G        W         4.20.0-0.rc1.git4.1.fc30.x86_64 #1
      [    5.596301] Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING, BIOS 0901 07/23/2018
      [    5.596303] RIP: 0010:debug_print_object+0x6a/0x80
      [    5.596305] Code: 8b 43 10 83 c2 01 8b 4b 14 4c 89 e6 89 15 e6 82 b0 02 4c 8b 45 00 48 c7 c7 60 fd 34 a6 48 8b 14 c5 a0 da 08 a6 e8 6a 6a b8 ff <0f> 0b 5b 83 05 d0 45 3e 01 01 5d 41 5c c3 83 05 c5 45 3e 01 01 c3
      [    5.596306] RSP: 0018:ffffa02ac863f8c0 EFLAGS: 00010282
      [    5.596307] RAX: 0000000000000000 RBX: ffffa02ac863f8e0 RCX: 0000000000000006
      [    5.596308] RDX: 0000000000000007 RSI: ffff9160e9a7bfe8 RDI: ffff9160f91d6c60
      [    5.596310] RBP: ffffffffa6742740 R08: 0000000000000002 R09: 0000000000000000
      [    5.596311] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa634ff69
      [    5.596312] R13: 00000000000b79d0 R14: ffffffffa80f76d8 R15: 0000000000266000
      [    5.596313] FS:  00007f762abf7940(0000) GS:ffff9160f9000000(0000) knlGS:0000000000000000
      [    5.596314] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    5.596315] CR2: 000055fdc593f000 CR3: 00000007e999c000 CR4: 00000000003406f0
      [    5.596317] Call Trace:
      [    5.596321]  debug_object_assert_init+0x14a/0x180
      [    5.596327]  del_timer+0x2e/0x90
      [    5.596383]  amdgpu_fence_process+0x47/0x100 [amdgpu]
      [    5.596430]  amdgpu_uvd_resume+0xf6/0x120 [amdgpu]
      [    5.596475]  uvd_v7_0_sw_init+0xe0/0x280 [amdgpu]
      [    5.596523]  amdgpu_device_init.cold.30+0xf97/0x14b6 [amdgpu]
      [    5.596563]  ? amdgpu_driver_load_kms+0x53/0x330 [amdgpu]
      [    5.596604]  amdgpu_driver_load_kms+0x86/0x330 [amdgpu]
      [    5.596614]  drm_dev_register+0x115/0x150 [drm]
      [    5.596654]  amdgpu_pci_probe+0xbd/0x120 [amdgpu]
      [    5.596658]  local_pci_probe+0x41/0x90
      [    5.596661]  pci_device_probe+0x188/0x1a0
      [    5.596666]  really_probe+0xf8/0x3b0
      [    5.596669]  driver_probe_device+0xb3/0xf0
      [    5.596672]  __driver_attach+0xe1/0x110
      [    5.596674]  ? driver_probe_device+0xf0/0xf0
      [    5.596676]  bus_for_each_dev+0x79/0xc0
      [    5.596679]  bus_add_driver+0x155/0x230
      [    5.596681]  ? 0xffffffffc07d9000
      [    5.596683]  driver_register+0x6b/0xb0
      [    5.596685]  ? 0xffffffffc07d9000
      [    5.596688]  do_one_initcall+0x5d/0x2be
      [    5.596691]  ? rcu_read_lock_sched_held+0x79/0x80
      [    5.596693]  ? kmem_cache_alloc_trace+0x264/0x290
      [    5.596695]  ? do_init_module+0x22/0x210
      [    5.596698]  do_init_module+0x5a/0x210
      [    5.596701]  load_module+0x2137/0x2430
      [    5.596703]  ? lockdep_hardirqs_on+0xed/0x180
      [    5.596714]  ? __do_sys_init_module+0x150/0x1a0
      [    5.596715]  __do_sys_init_module+0x150/0x1a0
      [    5.596722]  do_syscall_64+0x60/0x1f0
      [    5.596725]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [    5.596726] RIP: 0033:0x7f762b877dee
      [    5.596728] Code: 48 8b 0d 9d 20 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 6a 20 0c 00 f7 d8 64 89 01 48
      [    5.596729] RSP: 002b:00007ffc777b8558 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
      [    5.596730] RAX: ffffffffffffffda RBX: 000055fdc48da320 RCX: 00007f762b877dee
      [    5.596731] RDX: 00007f762b9f284d RSI: 00000000006c5fc6 RDI: 000055fdc527a060
      [    5.596732] RBP: 00007f762b9f284d R08: 0000000000000003 R09: 0000000000000002
      [    5.596733] R10: 000055fdc48ad010 R11: 0000000000000246 R12: 000055fdc527a060
      [    5.596734] R13: 000055fdc48dca20 R14: 0000000000020000 R15: 0000000000000000
      [    5.596740] irq event stamp: 134618
      [    5.596743] hardirqs last  enabled at (134617): [<ffffffffa513d52e>] console_unlock+0x45e/0x610
      [    5.596744] hardirqs last disabled at (134618): [<ffffffffa50037e8>] trace_hardirqs_off_thunk+0x1a/0x1c
      [    5.596746] softirqs last  enabled at (133146): [<ffffffffa5e00365>] __do_softirq+0x365/0x47c
      [    5.596748] softirqs last disabled at (133139): [<ffffffffa50c64f9>] irq_exit+0x119/0x120
      [    5.596749] ---[ end trace eaee508abfebccdc ]---
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108709Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Alex Deucher <alexdeucher@gmail.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c5656fd9
    • Kunihiko Hayashi's avatar
      net: ethernet: ave: Set initial wol state to disabled · 2ca0f9b6
      Kunihiko Hayashi authored
      [ Upstream commit 7200f2e3 ]
      
      If wol state of phy hardware is enabled after reset, phy_ethtool_get_wol()
      returns that wol.wolopts is true.
      
      However, since net_device.wol_enabled is zero and this doesn't apply wol
      state until calling ethtool_set_wol(), so mdio_bus_phy_may_suspend()
      returns true, that is, it's in a state where phy can suspend even though
      wol state is enabled.
      
      In this inconsistency, phy_suspend() returns -EBUSY, and at last,
      suspend sequence fails with the following message:
      
          dpm_run_callback(): mdio_bus_phy_suspend+0x0/0x58 returns -16
          PM: Device 65000000.ethernet-ffffffff:01 failed to suspend: error -16
          PM: Some devices failed to suspend, or early wake event detected
      
      In order to fix the above issue, this patch forces to set initial wol state
      to disabled as default.
      Signed-off-by: default avatarKunihiko Hayashi <hayashi.kunihiko@socionext.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2ca0f9b6
    • Manish Rangankar's avatar
      scsi: qedi: Check for session online before getting iSCSI TLV data. · d09c144e
      Manish Rangankar authored
      [ Upstream commit d5632b11 ]
      
      The kernel panic was observed after switch side perturbation,
      
      BUG: unable to handle kernel NULL pointer dereference at (null)
           IP: [<ffffffff8132b5a0>] strcmp+0x20/0x40
           PGD 0 Oops: 0000 [#1] SMP
      CPU: 8 PID: 647 Comm: kworker/8:1 Tainted: G        W  OE  ------------   3.10.0-693.el7.x86_64 #1
      Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/20/2018
      Workqueue: slowpath-13:00. qed_slowpath_task [qed]
      task: ffff880429eb8fd0 ti: ffff880429190000 task.ti: ffff880429190000
      RIP: 0010:[<ffffffff8132b5a0>]  [<ffffffff8132b5a0>] strcmp+0x20/0x40
      RSP: 0018:ffff880429193c68  EFLAGS: 00010202
      RAX: 000000000000000a RBX: 0000000000000002 RCX: 0000000000000000
      RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff88042bda7a41
      RBP: ffff880429193c68 R08: 000000000000ffff R09: 000000000000ffff
      R10: 0000000000000007 R11: ffff88042b3af338 R12: ffff880420b007a0
      R13: ffff88081aa56af8 R14: 0000000000000001 R15: ffff88081aa50410
      FS:  0000000000000000(0000) GS:ffff88042fe00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 00000000019f2000 CR4: 00000000003407e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Stack:
      ffff880429193d20 ffffffffc02a0c90 ffffc90004b32000 ffff8803fd3ec600
      ffff88042bda7800 ffff88042bda7a00 ffff88042bda7840 ffff88042bda7a40
      0000000129193d10 2e3836312e323931 ff000a342e363232 ffffffffc01ad99d
      Call Trace:
      [<ffffffffc02a0c90>] qedi_get_protocol_tlv_data+0x270/0x470 [qedi]
      [<ffffffffc01ad99d>] ? qed_mfw_process_tlv_req+0x24d/0xbf0 [qed]
      [<ffffffffc01653ae>] qed_mfw_fill_tlv_data+0x5e/0xd0 [qed]
      [<ffffffffc01ad9b9>] qed_mfw_process_tlv_req+0x269/0xbf0 [qed]
      
      Fix kernel NULL pointer deref by checking for session is online before
      getting iSCSI TLV data.
      Signed-off-by: default avatarManish Rangankar <manish.rangankar@cavium.com>
      Reviewed-by: default avatarLee Duncan <lduncan@suse.com>
      Signed-off-by: Martin K. Petersen's avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d09c144e
    • Jiada Wang's avatar
      ASoC: pcm3168a: Don't disable pcm3168a when CONFIG_PM defined · 05bb55dd
      Jiada Wang authored
      [ Upstream commit 489db5d9 ]
      
      pcm3168 codec support runtime_[resume|suspend], whenever it
      is not active, it enters suspend mode, and it's clock and regulators
      will be disabled. so there is no need to disable them again in
      remove callback.  Otherwise we got following kernel warnings,
      when unload pcm3168a driver
      
      [  222.257514] unbalanced disables for amp-en-regulator
      [  222.262526] ------------[ cut here ]------------
      [  222.267158] WARNING: CPU: 0 PID: 2423 at drivers/regulator/core.c:2264 _regulator_disable+0x28/0x108
      [  222.276291] Modules linked in:
      [  222.279343]  snd_soc_pcm3168a_i2c(-)
      [  222.282916]  snd_aloop
      [  222.285272]  arc4
      [  222.287194]  wl18xx
      [  222.289289]  wlcore
      [  222.291385]  mac80211
      [  222.293654]  cfg80211
      [  222.295923]  aes_ce_blk
      [  222.298366]  crypto_simd
      [  222.300896]  cryptd
      [  222.302992]  aes_ce_cipher
      [  222.305696]  crc32_ce
      [  222.307965]  ghash_ce
      [  222.310234]  aes_arm64
      [  222.312590]  gf128mul
      [  222.314860]  snd_soc_rcar
      [  222.317476]  sha2_ce
      [  222.319658]  xhci_plat_hcd
      [  222.322362]  sha256_arm64
      [  222.324978]  xhci_hcd
      [  222.327247]  sha1_ce
      [  222.329430]  renesas_usbhs
      [  222.332133]  evdev
      [  222.334142]  sha1_generic
      [  222.336758]  rcar_gen3_thermal
      [  222.339810]  cpufreq_dt
      [  222.342253]  ravb_streaming(C)
      [  222.345304]  wlcore_sdio
      [  222.347834]  thermal_sys
      [  222.350363]  udc_core
      [  222.352632]  mch_core(C)
      [  222.355161]  usb_dmac
      [  222.357430]  snd_soc_pcm3168a
      [  222.360394]  snd_soc_ak4613
      [  222.363184]  gpio_keys
      [  222.365540]  virt_dma
      [  222.367809]  nfsd
      [  222.369730]  ipv6
      [  222.371652]  autofs4
      [  222.373834]  [last unloaded: snd_soc_pcm3168a_i2c]
      [  222.378629] CPU: 0 PID: 2423 Comm: rmmod Tainted: G        WC      4.14.63-04798-gd456126e4a42-dirty #457
      [  222.388196] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT)
      [  222.396199] task: ffff8006fa8c6200 task.stack: ffff00000a0a0000
      [  222.402117] PC is at _regulator_disable+0x28/0x108
      [  222.406906] LR is at _regulator_disable+0x28/0x108
      [  222.411695] pc : [<ffff0000083bd89c>] lr : [<ffff0000083bd89c>] pstate: 00000145
      [  222.419089] sp : ffff00000a0a3c80
      [  222.422401] x29: ffff00000a0a3c80
      [  222.425799] x28: ffff8006fa8c6200
      [  222.429199] x27: ffff0000086f1000
      [  222.432597] x26: 000000000000006a
      [  222.435997] x25: 0000000000000124
      [  222.439395] x24: 0000000000000018
      [  222.442795] x23: 0000000000000006
      [  222.446193] x22: ffff8006f925d490
      [  222.449592] x21: ffff8006f9ac2068
      [  222.452991] x20: ffff8006f9ac2000
      [  222.456390] x19: 0000000000000005
      [  222.459787] x18: 000000000000000a
      [  222.463186] x17: 0000000000000000
      [  222.466584] x16: 0000000000000000
      [  222.469984] x15: 000000000d3f616a
      [  222.473382] x14: 0720072007200720
      [  222.476781] x13: 0720072007200720
      [  222.480179] x12: 0720072007200720
      [  222.483578] x11: 0720072007200720
      [  222.486975] x10: 0720072007200720
      [  222.490375] x9 : 0720072007200720
      [  222.493773] x8 : 07200772076f0774
      [  222.497172] x7 : 0000000000000000
      [  222.500570] x6 : 0000000000000007
      [  222.503969] x5 : 0000000000000000
      [  222.507367] x4 : 0000000000000000
      [  222.510766] x3 : 0000000000000000
      [  222.514164] x2 : c790b852091e2600
      [  222.517563] x1 : 0000000000000000
      [  222.520961] x0 : 0000000000000028
      [  222.524361] Call trace:
      [  222.526805] Exception stack(0xffff00000a0a3b40 to 0xffff00000a0a3c80)
      [  222.533245] 3b40: 0000000000000028 0000000000000000 c790b852091e2600 0000000000000000
      [  222.541075] 3b60: 0000000000000000 0000000000000000 0000000000000007 0000000000000000
      [  222.548905] 3b80: 07200772076f0774 0720072007200720 0720072007200720 0720072007200720
      [  222.556735] 3ba0: 0720072007200720 0720072007200720 0720072007200720 000000000d3f616a
      [  222.564564] 3bc0: 0000000000000000 0000000000000000 000000000000000a 0000000000000005
      [  222.572394] 3be0: ffff8006f9ac2000 ffff8006f9ac2068 ffff8006f925d490 0000000000000006
      [  222.580224] 3c00: 0000000000000018 0000000000000124 000000000000006a ffff0000086f1000
      [  222.588053] 3c20: ffff8006fa8c6200 ffff00000a0a3c80 ffff0000083bd89c ffff00000a0a3c80
      [  222.595883] 3c40: ffff0000083bd89c 0000000000000145 0000000000000000 0000000000000000
      [  222.603713] 3c60: 0000ffffffffffff ffff00000a0a3c30 ffff00000a0a3c80 ffff0000083bd89c
      [  222.611543] [<ffff0000083bd89c>] _regulator_disable+0x28/0x108
      [  222.617375] [<ffff0000083bd9c4>] regulator_disable+0x48/0x68
      [  222.623033] [<ffff0000083be8e4>] regulator_bulk_disable+0x58/0xc0
      [  222.629134] [<ffff0000007d831c>] pcm3168a_remove+0x30/0x50 [snd_soc_pcm3168a]
      [  222.636270] [<ffff0000007e5010>] pcm3168a_i2c_remove+0x10/0x1c [snd_soc_pcm3168a_i2c]
      [  222.644106] [<ffff0000084b9d9c>] i2c_device_remove+0x38/0x70
      [  222.649766] [<ffff00000843cd5c>] device_release_driver_internal+0xd0/0x1c0
      [  222.656640] [<ffff00000843ced8>] driver_detach+0x70/0x7c
      [  222.661951] [<ffff00000843bf68>] bus_remove_driver+0x74/0xa0
      [  222.667609] [<ffff00000843d7e4>] driver_unregister+0x48/0x4c
      [  222.673268] [<ffff0000084ba8dc>] i2c_del_driver+0x24/0x30
      [  222.678666] [<ffff0000007e5078>] pcm3168a_i2c_driver_exit+0x10/0xf98 [snd_soc_pcm3168a_i2c]
      [  222.687019] [<ffff00000811bd28>] SyS_delete_module+0x198/0x1d4
      [  222.692850] Exception stack(0xffff00000a0a3ec0 to 0xffff00000a0a4000)
      [  222.699289] 3ec0: 0000aaaafeb4b268 0000000000000800 14453f6470497100 0000fffffaa520d8
      [  222.707119] 3ee0: 0000fffffaa520d9 000000000000000a 1999999999999999 0000000000000000
      [  222.714948] 3f00: 000000000000006a 0000ffffa8f7d1d8 000000000000000a 0000000000000005
      [  222.722778] 3f20: 0000000000000000 0000000000000000 000000000000002d 0000000000000000
      [  222.730607] 3f40: 0000aaaae19b9f68 0000ffffa8f411f0 0000000000000000 0000aaaae19b9000
      [  222.738436] 3f60: 0000fffffaa533b8 0000fffffaa531f0 0000000000000000 0000000000000001
      [  222.746266] 3f80: 0000fffffaa53ec6 0000000000000000 0000aaaafeb4b200 0000aaaafeb4a010
      [  222.754096] 3fa0: 0000000000000000 0000fffffaa53130 0000aaaae199f36c 0000fffffaa53130
      [  222.761926] 3fc0: 0000ffffa8f411f8 0000000000000000 0000aaaafeb4b268 000000000000006a
      [  222.769755] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [  222.777589] [<ffff0000080832c0>] el0_svc_naked+0x34/0x38
      [  222.782899] ---[ end trace eaf8939a3698b1a8 ]---
      [  222.787609] Failed to disable VCCDA2: -5
      [  222.791649] ------------[ cut here ]------------
      [  222.796283] WARNING: CPU: 0 PID: 2423 at drivers/clk/clk.c:595 clk_core_disable+0xc/0x1d8
      [  222.804460] Modules linked in:
      [  222.807511]  snd_soc_pcm3168a_i2c(-)
      [  222.811083]  snd_aloop
      [  222.813439]  arc4
      [  222.815360]  wl18xx
      [  222.817456]  wlcore
      [  222.819551]  mac80211
      [  222.821820]  cfg80211
      [  222.824088]  aes_ce_blk
      [  222.826531]  crypto_simd
      [  222.829060]  cryptd
      [  222.831155]  aes_ce_cipher
      [  222.833859]  crc32_ce
      [  222.836127]  ghash_ce
      [  222.838396]  aes_arm64
      [  222.840752]  gf128mul
      [  222.843020]  snd_soc_rcar
      [  222.845637]  sha2_ce
      [  222.847818]  xhci_plat_hcd
      [  222.850522]  sha256_arm64
      [  222.853138]  xhci_hcd
      [  222.855407]  sha1_ce
      [  222.857589]  renesas_usbhs
      [  222.860292]  evdev
      [  222.862300]  sha1_generic
      [  222.864917]  rcar_gen3_thermal
      [  222.867968]  cpufreq_dt
      [  222.870410]  ravb_streaming(C)
      [  222.873461]  wlcore_sdio
      [  222.875991]  thermal_sys
      [  222.878520]  udc_core
      [  222.880789]  mch_core(C)
      [  222.883318]  usb_dmac
      [  222.885587]  snd_soc_pcm3168a
      [  222.888551]  snd_soc_ak4613
      [  222.891341]  gpio_keys
      [  222.893696]  virt_dma
      [  222.895965]  nfsd
      [  222.897886]  ipv6
      [  222.899808]  autofs4
      [  222.901990]  [last unloaded: snd_soc_pcm3168a_i2c]
      [  222.906783] CPU: 0 PID: 2423 Comm: rmmod Tainted: G        WC      4.14.63-04798-gd456126e4a42-dirty #457
      [  222.916349] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT)
      [  222.924351] task: ffff8006fa8c6200 task.stack: ffff00000a0a0000
      [  222.930270] PC is at clk_core_disable+0xc/0x1d8
      [  222.934799] LR is at clk_core_disable_lock+0x20/0x34
      [  222.939761] pc : [<ffff0000083ab9b8>] lr : [<ffff0000083acd28>] pstate: 800001c5
      [  222.947154] sp : ffff00000a0a3cf0
      [  222.950466] x29: ffff00000a0a3cf0
      [  222.953864] x28: ffff8006fa8c6200
      [  222.957263] x27: ffff0000086f1000
      [  222.960661] x26: 000000000000006a
      [  222.964061] x25: 0000000000000124
      [  222.967458] x24: 0000000000000015
      [  222.970858] x23: ffff8006f9ffa8d0
      [  222.974256] x22: ffff8006faf16480
      [  222.977655] x21: ffff0000007e7040
      [  222.981053] x20: ffff8006faadd100
      [  222.984452] x19: 0000000000000140
      [  222.987850] x18: 000000000000000a
      [  222.991249] x17: 0000000000000000
      [  222.994647] x16: 0000000000000000
      [  222.998046] x15: 000000000d477819
      [  223.001444] x14: 0720072007200720
      [  223.004843] x13: 0720072007200720
      [  223.008242] x12: 0720072007200720
      [  223.011641] x11: 0720072007200720
      [  223.015039] x10: 0720072007200720
      [  223.018438] x9 : 0720072007200720
      [  223.021837] x8 : 0720072007200720
      [  223.025236] x7 : 0000000000000000
      [  223.028634] x6 : 0000000000000007
      [  223.032034] x5 : 0000000000000000
      [  223.035432] x4 : 0000000000000000
      [  223.038831] x3 : 0000000000000000
      [  223.042229] x2 : 0000000004720471
      [  223.045628] x1 : 0000000000000000
      [  223.049026] x0 : ffff8006faadd100
      [  223.052426] Call trace:
      [  223.054870] Exception stack(0xffff00000a0a3bb0 to 0xffff00000a0a3cf0)
      [  223.061309] 3ba0:                                   ffff8006faadd100 0000000000000000
      [  223.069139] 3bc0: 0000000004720471 0000000000000000 0000000000000000 0000000000000000
      [  223.076969] 3be0: 0000000000000007 0000000000000000 0720072007200720 0720072007200720
      [  223.084798] 3c00: 0720072007200720 0720072007200720 0720072007200720 0720072007200720
      [  223.092628] 3c20: 0720072007200720 000000000d477819 0000000000000000 0000000000000000
      [  223.100458] 3c40: 000000000000000a 0000000000000140 ffff8006faadd100 ffff0000007e7040
      [  223.108287] 3c60: ffff8006faf16480 ffff8006f9ffa8d0 0000000000000015 0000000000000124
      [  223.116117] 3c80: 000000000000006a ffff0000086f1000 ffff8006fa8c6200 ffff00000a0a3cf0
      [  223.123947] 3ca0: ffff0000083acd28 ffff00000a0a3cf0 ffff0000083ab9b8 00000000800001c5
      [  223.131777] 3cc0: ffff00000a0a3cf0 ffff0000083acd1c 0000ffffffffffff ffff8006faadd100
      [  223.139606] 3ce0: ffff00000a0a3cf0 ffff0000083ab9b8
      [  223.144483] [<ffff0000083ab9b8>] clk_core_disable+0xc/0x1d8
      [  223.150054] [<ffff0000083acd58>] clk_disable+0x1c/0x28
      [  223.155198] [<ffff0000007d8328>] pcm3168a_remove+0x3c/0x50 [snd_soc_pcm3168a]
      [  223.162334] [<ffff0000007e5010>] pcm3168a_i2c_remove+0x10/0x1c [snd_soc_pcm3168a_i2c]
      [  223.170167] [<ffff0000084b9d9c>] i2c_device_remove+0x38/0x70
      [  223.175826] [<ffff00000843cd5c>] device_release_driver_internal+0xd0/0x1c0
      [  223.182700] [<ffff00000843ced8>] driver_detach+0x70/0x7c
      [  223.188012] [<ffff00000843bf68>] bus_remove_driver+0x74/0xa0
      [  223.193669] [<ffff00000843d7e4>] driver_unregister+0x48/0x4c
      [  223.199329] [<ffff0000084ba8dc>] i2c_del_driver+0x24/0x30
      [  223.204726] [<ffff0000007e5078>] pcm3168a_i2c_driver_exit+0x10/0xf98 [snd_soc_pcm3168a_i2c]
      [  223.213079] [<ffff00000811bd28>] SyS_delete_module+0x198/0x1d4
      [  223.218909] Exception stack(0xffff00000a0a3ec0 to 0xffff00000a0a4000)
      [  223.225349] 3ec0: 0000aaaafeb4b268 0000000000000800 14453f6470497100 0000fffffaa520d8
      [  223.233179] 3ee0: 0000fffffaa520d9 000000000000000a 1999999999999999 0000000000000000
      [  223.241008] 3f00: 000000000000006a 0000ffffa8f7d1d8 000000000000000a 0000000000000005
      [  223.248838] 3f20: 0000000000000000 0000000000000000 000000000000002d 0000000000000000
      [  223.256668] 3f40: 0000aaaae19b9f68 0000ffffa8f411f0 0000000000000000 0000aaaae19b9000
      [  223.264497] 3f60: 0000fffffaa533b8 0000fffffaa531f0 0000000000000000 0000000000000001
      [  223.272327] 3f80: 0000fffffaa53ec6 0000000000000000 0000aaaafeb4b200 0000aaaafeb4a010
      [  223.280157] 3fa0: 0000000000000000 0000fffffaa53130 0000aaaae199f36c 0000fffffaa53130
      [  223.287986] 3fc0: 0000ffffa8f411f8 0000000000000000 0000aaaafeb4b268 000000000000006a
      [  223.295816] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [  223.303648] [<ffff0000080832c0>] el0_svc_naked+0x34/0x38
      [  223.308958] ---[ end trace eaf8939a3698b1a9 ]---
      [  223.313752] ------------[ cut here ]------------
      [  223.318383] WARNING: CPU: 0 PID: 2423 at drivers/clk/clk.c:477 clk_core_unprepare+0xc/0x1ac
      [  223.326733] Modules linked in:
      [  223.329784]  snd_soc_pcm3168a_i2c(-)
      [  223.333356]  snd_aloop
      [  223.335712]  arc4
      [  223.337633]  wl18xx
      [  223.339728]  wlcore
      [  223.341823]  mac80211
      [  223.344092]  cfg80211
      [  223.346360]  aes_ce_blk
      [  223.348803]  crypto_simd
      [  223.351332]  cryptd
      [  223.353428]  aes_ce_cipher
      [  223.356131]  crc32_ce
      [  223.358400]  ghash_ce
      [  223.360668]  aes_arm64
      [  223.363024]  gf128mul
      [  223.365293]  snd_soc_rcar
      [  223.367909]  sha2_ce
      [  223.370091]  xhci_plat_hcd
      [  223.372794]  sha256_arm64
      [  223.375410]  xhci_hcd
      [  223.377679]  sha1_ce
      [  223.379861]  renesas_usbhs
      [  223.382564]  evdev
      [  223.384572]  sha1_generic
      [  223.387188]  rcar_gen3_thermal
      [  223.390239]  cpufreq_dt
      [  223.392682]  ravb_streaming(C)
      [  223.395732]  wlcore_sdio
      [  223.398261]  thermal_sys
      [  223.400790]  udc_core
      [  223.403059]  mch_core(C)
      [  223.405588]  usb_dmac
      [  223.407856]  snd_soc_pcm3168a
      [  223.410820]  snd_soc_ak4613
      [  223.413609]  gpio_keys
      [  223.415965]  virt_dma
      [  223.418234]  nfsd
      [  223.420155]  ipv6
      [  223.422076]  autofs4
      [  223.424258]  [last unloaded: snd_soc_pcm3168a_i2c]
      [  223.429050] CPU: 0 PID: 2423 Comm: rmmod Tainted: G        WC      4.14.63-04798-gd456126e4a42-dirty #457
      [  223.438616] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT)
      [  223.446618] task: ffff8006fa8c6200 task.stack: ffff00000a0a0000
      [  223.452536] PC is at clk_core_unprepare+0xc/0x1ac
      [  223.457239] LR is at clk_unprepare+0x28/0x3c
      [  223.461506] pc : [<ffff0000083ab5a4>] lr : [<ffff0000083ace4c>] pstate: 60000145
      [  223.468900] sp : ffff00000a0a3d00
      [  223.472211] x29: ffff00000a0a3d00
      [  223.475609] x28: ffff8006fa8c6200
      [  223.479009] x27: ffff0000086f1000
      [  223.482407] x26: 000000000000006a
      [  223.485807] x25: 0000000000000124
      [  223.489205] x24: 0000000000000015
      [  223.492604] x23: ffff8006f9ffa8d0
      [  223.496003] x22: ffff8006faf16480
      [  223.499402] x21: ffff0000007e7040
      [  223.502800] x20: ffff8006faf16420
      [  223.506199] x19: ffff8006faadd100
      [  223.509597] x18: 000000000000000a
      [  223.512997] x17: 0000000000000000
      [  223.516395] x16: 0000000000000000
      [  223.519794] x15: 0000000000000000
      [  223.523192] x14: 00000033fe89076c
      [  223.526591] x13: 0000000000000400
      [  223.529989] x12: 0000000000000400
      [  223.533388] x11: 0000000000000000
      [  223.536786] x10: 00000000000009e0
      [  223.540185] x9 : ffff00000a0a3be0
      [  223.543583] x8 : ffff8006fa8c6c40
      [  223.546982] x7 : ffff8006fa8c6400
      [  223.550380] x6 : 0000000000000001
      [  223.553780] x5 : 0000000000000000
      [  223.557178] x4 : ffff8006fa8c6200
      [  223.560577] x3 : 0000000000000000
      [  223.563975] x2 : ffff8006fa8c6200
      [  223.567374] x1 : 0000000000000000
      [  223.570772] x0 : ffff8006faadd100
      [  223.574170] Call trace:
      [  223.576615] Exception stack(0xffff00000a0a3bc0 to 0xffff00000a0a3d00)
      [  223.583054] 3bc0: ffff8006faadd100 0000000000000000 ffff8006fa8c6200 0000000000000000
      [  223.590884] 3be0: ffff8006fa8c6200 0000000000000000 0000000000000001 ffff8006fa8c6400
      [  223.598714] 3c00: ffff8006fa8c6c40 ffff00000a0a3be0 00000000000009e0 0000000000000000
      [  223.606544] 3c20: 0000000000000400 0000000000000400 00000033fe89076c 0000000000000000
      [  223.614374] 3c40: 0000000000000000 0000000000000000 000000000000000a ffff8006faadd100
      [  223.622204] 3c60: ffff8006faf16420 ffff0000007e7040 ffff8006faf16480 ffff8006f9ffa8d0
      [  223.630033] 3c80: 0000000000000015 0000000000000124 000000000000006a ffff0000086f1000
      [  223.637863] 3ca0: ffff8006fa8c6200 ffff00000a0a3d00 ffff0000083ace4c ffff00000a0a3d00
      [  223.645693] 3cc0: ffff0000083ab5a4 0000000060000145 0000000000000140 ffff8006faadd100
      [  223.653523] 3ce0: 0000ffffffffffff ffff0000083ace44 ffff00000a0a3d00 ffff0000083ab5a4
      [  223.661353] [<ffff0000083ab5a4>] clk_core_unprepare+0xc/0x1ac
      [  223.667103] [<ffff0000007d8330>] pcm3168a_remove+0x44/0x50 [snd_soc_pcm3168a]
      [  223.674239] [<ffff0000007e5010>] pcm3168a_i2c_remove+0x10/0x1c [snd_soc_pcm3168a_i2c]
      [  223.682070] [<ffff0000084b9d9c>] i2c_device_remove+0x38/0x70
      [  223.687731] [<ffff00000843cd5c>] device_release_driver_internal+0xd0/0x1c0
      [  223.694604] [<ffff00000843ced8>] driver_detach+0x70/0x7c
      [  223.699915] [<ffff00000843bf68>] bus_remove_driver+0x74/0xa0
      [  223.705572] [<ffff00000843d7e4>] driver_unregister+0x48/0x4c
      [  223.711230] [<ffff0000084ba8dc>] i2c_del_driver+0x24/0x30
      [  223.716628] [<ffff0000007e5078>] pcm3168a_i2c_driver_exit+0x10/0xf98 [snd_soc_pcm3168a_i2c]
      [  223.724980] [<ffff00000811bd28>] SyS_delete_module+0x198/0x1d4
      [  223.730811] Exception stack(0xffff00000a0a3ec0 to 0xffff00000a0a4000)
      [  223.737250] 3ec0: 0000aaaafeb4b268 0000000000000800 14453f6470497100 0000fffffaa520d8
      [  223.745079] 3ee0: 0000fffffaa520d9 000000000000000a 1999999999999999 0000000000000000
      [  223.752909] 3f00: 000000000000006a 0000ffffa8f7d1d8 000000000000000a 0000000000000005
      [  223.760739] 3f20: 0000000000000000 0000000000000000 000000000000002d 0000000000000000
      [  223.768568] 3f40: 0000aaaae19b9f68 0000ffffa8f411f0 0000000000000000 0000aaaae19b9000
      [  223.776398] 3f60: 0000fffffaa533b8 0000fffffaa531f0 0000000000000000 0000000000000001
      [  223.784227] 3f80: 0000fffffaa53ec6 0000000000000000 0000aaaafeb4b200 0000aaaafeb4a010
      [  223.792057] 3fa0: 0000000000000000 0000fffffaa53130 0000aaaae199f36c 0000fffffaa53130
      [  223.799886] 3fc0: 0000ffffa8f411f8 0000000000000000 0000aaaafeb4b268 000000000000006a
      [  223.807715] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [  223.815546] [<ffff0000080832c0>] el0_svc_naked+0x34/0x38
      [  223.820855] ---[ end trace eaf8939a3698b1aa ]---
      
      Fix this issue by only disable clock and regulators in remove callback
      when CONFIG_PM isn't defined
      Signed-off-by: default avatarJiada Wang <jiada_wang@mentor.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      05bb55dd