1. 17 12月, 2018 40 次提交
    • C
      nvme: warn when finding multi-port subsystems without multipathing enabled · 1bda8b79
      Christoph Hellwig 提交于
      [ Upstream commit 14a1336e6fff47dd1028b484d6c802105c58e2ee ]
      
      Without CONFIG_NVME_MULTIPATH enabled a multi-port subsystem might
      show up as invididual devices and cause problems, warn about it.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1bda8b79
    • C
      fscache, cachefiles: remove redundant variable 'cache' · 1f925643
      Colin Ian King 提交于
      [ Upstream commit 31ffa563833576bd49a8bf53120568312755e6e2 ]
      
      Variable 'cache' is being assigned but is never used hence it is
      redundant and can be removed.
      
      Cleans up clang warning:
      warning: variable 'cache' set but not used [-Wunused-but-set-variable]
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1f925643
    • N
      cachefiles: Explicitly cast enumerated type in put_object · d8bf97a0
      Nathan Chancellor 提交于
      [ Upstream commit b7e768b7e3522695ed36dcb48ecdcd344bd30a9b ]
      
      Clang warns when one enumerated type is implicitly converted to another.
      
      fs/cachefiles/namei.c:247:50: warning: implicit conversion from
      enumeration type 'enum cachefiles_obj_ref_trace' to different
      enumeration type 'enum fscache_obj_ref_trace' [-Wenum-conversion]
              cache->cache.ops->put_object(&xobject->fscache,
      cachefiles_obj_put_wait_retry);
      
      Silence this warning by explicitly casting to fscache_obj_ref_trace,
      which is also done in put_object.
      Reported-by: NNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d8bf97a0
    • N
      fscache: fix race between enablement and dropping of object · 02bd7b74
      NeilBrown 提交于
      [ Upstream commit c5a94f434c82529afda290df3235e4d85873c5b4 ]
      
      It was observed that a process blocked indefintely in
      __fscache_read_or_alloc_page(), waiting for FSCACHE_COOKIE_LOOKING_UP
      to be cleared via fscache_wait_for_deferred_lookup().
      
      At this time, ->backing_objects was empty, which would normaly prevent
      __fscache_read_or_alloc_page() from getting to the point of waiting.
      This implies that ->backing_objects was cleared *after*
      __fscache_read_or_alloc_page was was entered.
      
      When an object is "killed" and then "dropped",
      FSCACHE_COOKIE_LOOKING_UP is cleared in fscache_lookup_failure(), then
      KILL_OBJECT and DROP_OBJECT are "called" and only in DROP_OBJECT is
      ->backing_objects cleared.  This leaves a window where
      something else can set FSCACHE_COOKIE_LOOKING_UP and
      __fscache_read_or_alloc_page() can start waiting, before
      ->backing_objects is cleared
      
      There is some uncertainty in this analysis, but it seems to be fit the
      observations.  Adding the wake in this patch will be handled correctly
      by __fscache_read_or_alloc_page(), as it checks if ->backing_objects
      is empty again, after waiting.
      
      Customer which reported the hang, also report that the hang cannot be
      reproduced with this fix.
      
      The backtrace for the blocked process looked like:
      
      PID: 29360  TASK: ffff881ff2ac0f80  CPU: 3   COMMAND: "zsh"
       #0 [ffff881ff43efbf8] schedule at ffffffff815e56f1
       #1 [ffff881ff43efc58] bit_wait at ffffffff815e64ed
       #2 [ffff881ff43efc68] __wait_on_bit at ffffffff815e61b8
       #3 [ffff881ff43efca0] out_of_line_wait_on_bit at ffffffff815e625e
       #4 [ffff881ff43efd08] fscache_wait_for_deferred_lookup at ffffffffa04f2e8f [fscache]
       #5 [ffff881ff43efd18] __fscache_read_or_alloc_page at ffffffffa04f2ffe [fscache]
       #6 [ffff881ff43efd58] __nfs_readpage_from_fscache at ffffffffa0679668 [nfs]
       #7 [ffff881ff43efd78] nfs_readpage at ffffffffa067092b [nfs]
       #8 [ffff881ff43efda0] generic_file_read_iter at ffffffff81187a73
       #9 [ffff881ff43efe50] nfs_file_read at ffffffffa066544b [nfs]
      #10 [ffff881ff43efe70] __vfs_read at ffffffff811fc756
      #11 [ffff881ff43efee8] vfs_read at ffffffff811fccfa
      #12 [ffff881ff43eff18] sys_read at ffffffff811fda62
      #13 [ffff881ff43eff50] entry_SYSCALL_64_fastpath at ffffffff815e986e
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      02bd7b74
    • D
      afs: Fix validation/callback interaction · 52da87f0
      David Howells 提交于
      [ Upstream commit ae3b7361dc0ee9a425bf7d77ce211f533500b39b ]
      
      When afs_validate() is called to validate a vnode (inode), there are two
      unhandled cases in the fastpath at the top of the function:
      
       (1) If the vnode is promised (AFS_VNODE_CB_PROMISED is set), the break
           counters match and the data has expired, then there's an implicit case
           in which the vnode needs revalidating.
      
           This has no consequences since the default "valid = false" set at the
           top of the function happens to do the right thing.
      
       (2) If the vnode is not promised and it hasn't been deleted
           (AFS_VNODE_DELETED is not set) then there's a default case we're not
           handling in which the vnode is invalid.  If the vnode is invalid, we
           need to bring cb_s_break and cb_v_break up to date before we refetch
           the status.
      
           As a consequence, once the server loses track of the client
           (ie. sufficient time has passed since we last sent it an operation),
           it will send us a CB.InitCallBackState* operation when we next try to
           talk to it.  This calls afs_init_callback_state() which increments
           afs_server::cb_s_break, but this then doesn't propagate to the
           afs_vnode record.
      
           The result being that every afs_validate() call thereafter sends a
           status fetch operation to the server.
      
      Clarify and fix this by:
      
       (A) Setting valid in all the branches rather than initialising it at the
           top so that the compiler catches where we've missed.
      
       (B) Restructuring the logic in the 'promised' branch so that we set valid
           to false if the callback is due to expire (or has expired) and so that
           the final case is that the vnode is still valid.
      
       (C) Adding an else-statement that ups cb_s_break and cb_v_break if the
           promised and deleted cases don't match.
      
      Fixes: c435ee34 ("afs: Overhaul the callback handling")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      52da87f0
    • K
      pstore/ram: Correctly calculate usable PRZ bytes · ce469db0
      Kees Cook 提交于
      [ Upstream commit 89d328f637b9904b6d4c9af73c8a608b8dd4d6f8 ]
      
      The actual number of bytes stored in a PRZ is smaller than the
      bytes requested by platform data, since there is a header on each
      PRZ. Additionally, if ECC is enabled, there are trailing bytes used
      as well. Normally this mismatch doesn't matter since PRZs are circular
      buffers and the leading "overflow" bytes are just thrown away. However, in
      the case of a compressed record, this rather badly corrupts the results.
      
      This corruption was visible with "ramoops.mem_size=204800 ramoops.ecc=1".
      Any stored crashes would not be uncompressable (producing a pstorefs
      "dmesg-*.enc.z" file), and triggering errors at boot:
      
        [    2.790759] pstore: crypto_comp_decompress failed, ret = -22!
      
      Backporting this depends on commit 70ad35db ("pstore: Convert console
      write to use ->write_buf")
      Reported-by: NJoel Fernandes <joel@joelfernandes.org>
      Fixes: b0aad7a9 ("pstore: Add compression support to pstore")
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Reviewed-by: NJoel Fernandes (Google) <joel@joelfernandes.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ce469db0
    • P
      pvcalls-front: fixes incorrect error handling · ff5ac9bd
      Pan Bian 提交于
      [ Upstream commit 975ef94a0284648fb0137bd5e949b18cef604e33 ]
      
      kfree() is incorrectly used to release the pages allocated by
      __get_free_page() and __get_free_pages(). Use the matching deallocators
      i.e., free_page() and free_pages(), respectively.
      Signed-off-by: NPan Bian <bianpan2016@163.com>
      Reviewed-by: NStefano Stabellini <sstabellini@kernel.org>
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ff5ac9bd
    • I
      Revert "xen/balloon: Mark unallocated host memory as UNUSABLE" · a9d79a07
      Igor Druzhinin 提交于
      [ Upstream commit 123664101aa2156d05251704fc63f9bcbf77741a ]
      
      This reverts commit b3cf8528.
      
      That commit unintentionally broke Xen balloon memory hotplug with
      "hotplug_unpopulated" set to 1. As long as "System RAM" resource
      got assigned under a new "Unusable memory" resource in IO/Mem tree
      any attempt to online this memory would fail due to general kernel
      restrictions on having "System RAM" resources as 1st level only.
      
      The original issue that commit has tried to workaround fa564ad9
      ("x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f,
      60-7f)") also got amended by the following 03a55173 ("x86/PCI: Move
      and shrink AMD 64-bit window to avoid conflict") which made the
      original fix to Xen ballooning unnecessary.
      Signed-off-by: NIgor Druzhinin <igor.druzhinin@citrix.com>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a9d79a07
    • S
      xen: xlate_mmu: add missing header to fix 'W=1' warning · c1a21086
      Srikanth Boddepalli 提交于
      [ Upstream commit 72791ac854fea36034fa7976b748fde585008e78 ]
      
      Add a missing header otherwise compiler warns about missed prototype:
      
      drivers/xen/xlate_mmu.c:183:5: warning: no previous prototype for 'xen_xlate_unmap_gfn_range?' [-Wmissing-prototypes]
        int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
            ^~~~~~~~~~~~~~~~~~~~~~~~~
      Signed-off-by: NSrikanth Boddepalli <boddepalli.srikanth@gmail.com>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Reviewed-by: NJoey Pabalinas <joeypabalinas@gmail.com>
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c1a21086
    • Y
      drm/ast: fixed reading monitor EDID not stable issue · f3c73ae4
      Y.C. Chen 提交于
      [ Upstream commit 300625620314194d9e6d4f6dda71f2dc9cf62d9f ]
      
      v1: over-sample data to increase the stability with some specific monitors
      v2: refine to avoid infinite loop
      v3: remove un-necessary "volatile" declaration
      
      [airlied: fix two checkpatch warnings]
      Signed-off-by: NY.C. Chen <yc_chen@aspeedtech.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1542858988-1127-1-git-send-email-yc_chen@aspeedtech.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      f3c73ae4
    • S
      drm/amdgpu: Add delay after enable RLC ucode · cbd6a7ea
      shaoyunl 提交于
      [ Upstream commit ad97d9de45835b6a0f71983b0ae0cffd7306730a ]
      
      Driver shouldn't try to access any GFX registers until RLC is idle.
      During the test, it took 12 seconds for RLC to clear the BUSY bit
      in RLC_GPM_STAT register which is un-acceptable for driver.
      As per RLC engineer, it would take RLC Ucode less than 10,000 GFXCLK
      cycles to finish its critical section. In a lowest 300M enginer clock
      setting(default from vbios), 50 us delay is enough.
      
      This commit fix the hang when RLC introduce the work around for XGMI
      which requires more cycles to setup more registers than normal
      Signed-off-by: Nshaoyunl <shaoyun.liu@amd.com>
      Acked-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cbd6a7ea
    • P
      net: hisilicon: remove unexpected free_netdev · 3b54558a
      Pan Bian 提交于
      [ Upstream commit c758940158bf29fe14e9d0f89d5848f227b48134 ]
      
      The net device ndev is freed via free_netdev when failing to register
      the device. The control flow then jumps to the error handling code
      block. ndev is used and freed again. Resulting in a use-after-free bug.
      Signed-off-by: NPan Bian <bianpan2016@163.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3b54558a
    • J
      ixgbe: recognize 1000BaseLX SFP modules as 1Gbps · e3fb9d84
      Josh Elsasser 提交于
      [ Upstream commit a8bf879af7b1999eba36303ce9cc60e0e7dd816c ]
      
      Add the two 1000BaseLX enum values to the X550's check for 1Gbps modules,
      allowing the core driver code to establish a link over this SFP type.
      
      This is done by the out-of-tree driver but the fix wasn't in mainline.
      
      Fixes: e23f3336 ("ixgbe: Fix 1G and 10G link stability for X550EM_x SFP+”)
      Fixes: 6a14ee0c ("ixgbe: Add X550 support function pointers")
      Signed-off-by: NJosh Elsasser <jelsasser@appneta.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e3fb9d84
    • Y
      igb: fix uninitialized variables · 4b0f9f88
      Yunjian Wang 提交于
      [ Upstream commit e4c39f7926b4de355f7df75651d75003806aae09 ]
      
      This patch fixes the variable 'phy_word' may be used uninitialized.
      Signed-off-by: NYunjian Wang <wangyunjian@huawei.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4b0f9f88
    • K
      cachefiles: Fix page leak in cachefiles_read_backing_file while vmscan is active · eee2269f
      Kiran Kumar Modukuri 提交于
      [ Upstream commit 9a24ce5b66f9c8190d63b15f4473600db4935f1f ]
      
      [Description]
      
      In a heavily loaded system where the system pagecache is nearing memory
      limits and fscache is enabled, pages can be leaked by fscache while trying
      read pages from cachefiles backend.  This can happen because two
      applications can be reading same page from a single mount, two threads can
      be trying to read the backing page at same time.  This results in one of
      the threads finding that a page for the backing file or netfs file is
      already in the radix tree.  During the error handling cachefiles does not
      clean up the reference on backing page, leading to page leak.
      
      [Fix]
      The fix is straightforward, to decrement the reference when error is
      encountered.
      
        [dhowells: Note that I've removed the clearance and put of newpage as
         they aren't attested in the commit message and don't appear to actually
         achieve anything since a new page is only allocated is newpage!=NULL and
         any residual new page is cleared before returning.]
      
      [Testing]
      I have tested the fix using following method for 12+ hrs.
      
      1) mkdir -p /mnt/nfs ; mount -o vers=3,fsc <server_ip>:/export /mnt/nfs
      2) create 10000 files of 2.8MB in a NFS mount.
      3) start a thread to simulate heavy VM presssure
         (while true ; do echo 3 > /proc/sys/vm/drop_caches ; sleep 1 ; done)&
      4) start multiple parallel reader for data set at same time
         find /mnt/nfs -type f | xargs -P 80 cat > /dev/null &
         find /mnt/nfs -type f | xargs -P 80 cat > /dev/null &
         find /mnt/nfs -type f | xargs -P 80 cat > /dev/null &
         ..
         ..
         find /mnt/nfs -type f | xargs -P 80 cat > /dev/null &
         find /mnt/nfs -type f | xargs -P 80 cat > /dev/null &
      5) finally check using cat /proc/fs/fscache/stats | grep -i pages ;
         free -h , cat /proc/meminfo and page-types -r -b lru
         to ensure all pages are freed.
      Reviewed-by: NDaniel Axtens <dja@axtens.net>
      Signed-off-by: NShantanu Goel <sgoel01@yahoo.com>
      Signed-off-by: NKiran Kumar Modukuri <kiran.modukuri@gmail.com>
      [dja: forward ported to current upstream]
      Signed-off-by: NDaniel Axtens <dja@axtens.net>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      eee2269f
    • K
      fscache: Fix race in fscache_op_complete() due to split atomic_sub & read · a4a7a0d7
      kiran.modukuri 提交于
      [ Upstream commit 3f2b7b9035107d6096ea438ea3d97dcf0481b6d2 ]
      
      The code in fscache_retrieval_complete is using atomic_sub followed by an
      atomic_read:
      
              atomic_sub(n_pages, &op->n_pages);
              if (atomic_read(&op->n_pages) <= 0)
                      fscache_op_complete(&op->op, true);
      
      This causes two threads doing a decrement of n_pages to race with each
      other seeing the op->refcount 0 at same time - and they end up calling
      fscache_op_complete() in both the threads leading to an assertion failure.
      
      Fix this by using atomic_sub_return_relaxed() instead of two calls.  Note
      that I'm using 'relaxed' rather than, say, 'release' as there aren't
      multiple variables that appear to need ordering across the release.
      
      The oops looks something like:
      
      FS-Cache: Assertion failed
      FS-Cache: 0 > 0 is false
      ...
      kernel BUG at /usr/src/linux-4.4.0/fs/fscache/operation.c:449!
      ...
      Workqueue: fscache_operation fscache_op_work_func [fscache]
      ...
      RIP: 0010:[<ffffffffc037eacd>] fscache_op_complete+0x10d/0x180 [fscache]
      ...
      Call Trace:
       [<ffffffffc1464cf9>] cachefiles_read_copier+0x3a9/0x410 [cachefiles]
       [<ffffffffc037e272>] fscache_op_work_func+0x22/0x50 [fscache]
       [<ffffffff81096da0>] process_one_work+0x150/0x3f0
       [<ffffffff8109751a>] worker_thread+0x11a/0x470
       [<ffffffff81808e59>] ? __schedule+0x359/0x980
       [<ffffffff81097400>] ? rescuer_thread+0x310/0x310
       [<ffffffff8109cdd6>] kthread+0xd6/0xf0
       [<ffffffff8109cd00>] ? kthread_park+0x60/0x60
       [<ffffffff8180d0cf>] ret_from_fork+0x3f/0x70
       [<ffffffff8109cd00>] ? kthread_park+0x60/0x60
      
      This seen this in 4.4.x kernels and the same bug affects fscache in latest
      upstreams kernels.
      
      Fixes: 1bb4b7f9 ("FS-Cache: The retrieval remaining-pages counter needs to be atomic_t")
      Signed-off-by: NKiran Kumar Modukuri <kiran.modukuri@gmail.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a4a7a0d7
    • D
      cachefiles: Fix an assertion failure when trying to update a failed object · 5132f913
      David Howells 提交于
      [ Upstream commit e6bc06faf64a83384cc0abc537df954c9d3ff942 ]
      
      If cachefiles gets an error other then ENOENT when trying to look up an
      object in the cache (in this case, EACCES), the object state machine will
      eventually transition to the DROP_OBJECT state.
      
      This state invokes fscache_drop_object() which tries to sync the auxiliary
      data with the cache (this is done lazily since commit 402cb8dd) on an
      incomplete cache object struct.
      
      The problem comes when cachefiles_update_object_xattr() is called to
      rewrite the xattr holding the data.  There's an assertion there that the
      cache object points to a dentry as we're going to update its xattr.  The
      assertion trips, however, as dentry didn't get set.
      
      Fix the problem by skipping the update in cachefiles if the object doesn't
      refer to a dentry.  A better way to do it could be to skip the update from
      the DROP_OBJECT state handler in fscache, but that might deny the cache the
      opportunity to update intermediate state.
      
      If this error occurs, the kernel log includes lines that look like the
      following:
      
       CacheFiles: Lookup failed error -13
       CacheFiles:
       CacheFiles: Assertion failed
       ------------[ cut here ]------------
       kernel BUG at fs/cachefiles/xattr.c:138!
       ...
       Workqueue: fscache_object fscache_object_work_func [fscache]
       RIP: 0010:cachefiles_update_object_xattr.cold.4+0x18/0x1a [cachefiles]
       ...
       Call Trace:
        cachefiles_update_object+0xdd/0x1c0 [cachefiles]
        fscache_update_aux_data+0x23/0x30 [fscache]
        fscache_drop_object+0x18e/0x1c0 [fscache]
        fscache_object_work_func+0x74/0x2b0 [fscache]
        process_one_work+0x18d/0x340
        worker_thread+0x2e/0x390
        ? pwq_unbound_release_workfn+0xd0/0xd0
        kthread+0x112/0x130
        ? kthread_bind+0x30/0x30
        ret_from_fork+0x35/0x40
      
      Note that there are actually two issues here: (1) EACCES happened on a
      cache object and (2) an oops occurred.  I think that the second is a
      consequence of the first (it certainly looks like it ought to be).  This
      patch only deals with the second.
      
      Fixes: 402cb8dd ("fscache: Attach the index key and aux data to the cookie")
      Reported-by: NZhibin Li <zhibli@redhat.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5132f913
    • H
      ALSA: usb-audio: Add vendor and product name for Dell WD19 Dock · 815899cf
      Hui Wang 提交于
      [ Upstream commit 8159a6a4a7d2a092d5375f695ecfca22b4562b5f ]
      
      Like the Dell WD15 Dock, the WD19 Dock (0bda:402e) doens't provide
      useful string for the vendor and product names too. In order to share
      the UCM with WD15, here we keep the profile_name same as the WD15.
      Signed-off-by: NHui Wang <hui.wang@canonical.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      815899cf
    • T
      netfilter: nf_tables: deactivate expressions in rule replecement routine · e5f42e06
      Taehee Yoo 提交于
      [ Upstream commit ca089878 ]
      
      There is no expression deactivation call from the rule replacement path,
      hence, chain counter is not decremented. A few steps to reproduce the
      problem:
      
         %nft add table ip filter
         %nft add chain ip filter c1
         %nft add chain ip filter c1
         %nft add rule ip filter c1 jump c2
         %nft replace rule ip filter c1 handle 3 accept
         %nft flush ruleset
      
      <jump c2> expression means immediate NFT_JUMP to chain c2.
      Reference count of chain c2 is increased when the rule is added.
      
      When rule is deleted or replaced, the reference counter of c2 should be
      decreased via nft_rule_expr_deactivate() which calls
      nft_immediate_deactivate().
      
      Splat looks like:
      [  214.396453] WARNING: CPU: 1 PID: 21 at net/netfilter/nf_tables_api.c:1432 nf_tables_chain_destroy.isra.38+0x2f9/0x3a0 [nf_tables]
      [  214.398983] Modules linked in: nf_tables nfnetlink
      [  214.398983] CPU: 1 PID: 21 Comm: kworker/1:1 Not tainted 4.20.0-rc2+ #44
      [  214.398983] Workqueue: events nf_tables_trans_destroy_work [nf_tables]
      [  214.398983] RIP: 0010:nf_tables_chain_destroy.isra.38+0x2f9/0x3a0 [nf_tables]
      [  214.398983] Code: 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 8e 00 00 00 48 8b 7b 58 e8 e1 2c 4e c6 48 89 df e8 d9 2c 4e c6 eb 9a <0f> 0b eb 96 0f 0b e9 7e fe ff ff e8 a7 7e 4e c6 e9 a4 fe ff ff e8
      [  214.398983] RSP: 0018:ffff8881152874e8 EFLAGS: 00010202
      [  214.398983] RAX: 0000000000000001 RBX: ffff88810ef9fc28 RCX: ffff8881152876f0
      [  214.398983] RDX: dffffc0000000000 RSI: 1ffff11022a50ede RDI: ffff88810ef9fc78
      [  214.398983] RBP: 1ffff11022a50e9d R08: 0000000080000000 R09: 0000000000000000
      [  214.398983] R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff11022a50eba
      [  214.398983] R13: ffff888114446e08 R14: ffff8881152876f0 R15: ffffed1022a50ed6
      [  214.398983] FS:  0000000000000000(0000) GS:ffff888116400000(0000) knlGS:0000000000000000
      [  214.398983] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  214.398983] CR2: 00007fab9bb5f868 CR3: 000000012aa16000 CR4: 00000000001006e0
      [  214.398983] Call Trace:
      [  214.398983]  ? nf_tables_table_destroy.isra.37+0x100/0x100 [nf_tables]
      [  214.398983]  ? __kasan_slab_free+0x145/0x180
      [  214.398983]  ? nf_tables_trans_destroy_work+0x439/0x830 [nf_tables]
      [  214.398983]  ? kfree+0xdb/0x280
      [  214.398983]  nf_tables_trans_destroy_work+0x5f5/0x830 [nf_tables]
      [ ... ]
      
      Fixes: bb7b40ae ("netfilter: nf_tables: bogus EBUSY in chain deletions")
      Reported by: Christoph Anton Mitterer <calestyo@scientia.net>
      Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914505
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=201791Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e5f42e06
    • M
      usb: gadget: u_ether: fix unsafe list iteration · 6d665dab
      Marek Szyprowski 提交于
      [ Upstream commit c9287fa657b3328b4549c0ab39ea7f197a3d6a50 ]
      
      list_for_each_entry_safe() is not safe for deleting entries from the
      list if the spin lock, which protects it, is released and reacquired during
      the list iteration. Fix this issue by replacing this construction with
      a simple check if list is empty and removing the first entry in each
      iteration. This is almost equivalent to a revert of the commit mentioned in
      the Fixes: tag.
      
      This patch fixes following issue:
      --->8---
      Unable to handle kernel NULL pointer dereference at virtual address 00000104
      pgd = (ptrval)
      [00000104] *pgd=00000000
      Internal error: Oops: 817 [#1] PREEMPT SMP ARM
      Modules linked in:
      CPU: 1 PID: 84 Comm: kworker/1:1 Not tainted 4.20.0-rc2-next-20181114-00009-g8266b35ec404 #1061
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      Workqueue: events eth_work
      PC is at rx_fill+0x60/0xac
      LR is at _raw_spin_lock_irqsave+0x50/0x5c
      pc : [<c065fee0>]    lr : [<c0a056b8>]    psr: 80000093
      sp : ee7fbee8  ip : 00000100  fp : 00000000
      r10: 006000c0  r9 : c10b0ab0  r8 : ee7eb5c0
      r7 : ee7eb614  r6 : ee7eb5ec  r5 : 000000dc  r4 : ee12ac00
      r3 : ee12ac24  r2 : 00000200  r1 : 60000013  r0 : ee7eb5ec
      Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: 6d5dc04a  DAC: 00000051
      Process kworker/1:1 (pid: 84, stack limit = 0x(ptrval))
      Stack: (0xee7fbee8 to 0xee7fc000)
      ...
      [<c065fee0>] (rx_fill) from [<c0143b7c>] (process_one_work+0x200/0x738)
      [<c0143b7c>] (process_one_work) from [<c0144118>] (worker_thread+0x2c/0x4c8)
      [<c0144118>] (worker_thread) from [<c014a8a4>] (kthread+0x128/0x164)
      [<c014a8a4>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
      Exception stack(0xee7fbfb0 to 0xee7fbff8)
      ...
      ---[ end trace 64480bc835eba7d6 ]---
      
      Fixes: fea14e68 ("usb: gadget: u_ether: use better list accessors")
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6d665dab
    • L
      net: thunderx: fix NULL pointer dereference in nic_remove · 227b1745
      Lorenzo Bianconi 提交于
      [ Upstream commit 24a6d2dd263bc910de018c78d1148b3e33b94512 ]
      
      Fix a possible NULL pointer dereference in nic_remove routine
      removing the nicpf module if nic_probe fails.
      The issue can be triggered with the following reproducer:
      
      $rmmod nicvf
      $rmmod nicpf
      
      [  521.412008] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000014
      [  521.422777] Mem abort info:
      [  521.425561]   ESR = 0x96000004
      [  521.428624]   Exception class = DABT (current EL), IL = 32 bits
      [  521.434535]   SET = 0, FnV = 0
      [  521.437579]   EA = 0, S1PTW = 0
      [  521.440730] Data abort info:
      [  521.443603]   ISV = 0, ISS = 0x00000004
      [  521.447431]   CM = 0, WnR = 0
      [  521.450417] user pgtable: 4k pages, 48-bit VAs, pgdp = 0000000072a3da42
      [  521.457022] [0000000000000014] pgd=0000000000000000
      [  521.461916] Internal error: Oops: 96000004 [#1] SMP
      [  521.511801] Hardware name: GIGABYTE H270-T70/MT70-HD0, BIOS T49 02/02/2018
      [  521.518664] pstate: 80400005 (Nzcv daif +PAN -UAO)
      [  521.523451] pc : nic_remove+0x24/0x88 [nicpf]
      [  521.527808] lr : pci_device_remove+0x48/0xd8
      [  521.532066] sp : ffff000013433cc0
      [  521.535370] x29: ffff000013433cc0 x28: ffff810f6ac50000
      [  521.540672] x27: 0000000000000000 x26: 0000000000000000
      [  521.545974] x25: 0000000056000000 x24: 0000000000000015
      [  521.551274] x23: ffff8007ff89a110 x22: ffff000001667070
      [  521.556576] x21: ffff8007ffb170b0 x20: ffff8007ffb17000
      [  521.561877] x19: 0000000000000000 x18: 0000000000000025
      [  521.567178] x17: 0000000000000000 x16: 000000000000010ffc33ff98 x8 : 0000000000000000
      [  521.593683] x7 : 0000000000000000 x6 : 0000000000000001
      [  521.598983] x5 : 0000000000000002 x4 : 0000000000000003
      [  521.604284] x3 : ffff8007ffb17184 x2 : ffff8007ffb17184
      [  521.609585] x1 : ffff000001662118 x0 : ffff000008557be0
      [  521.614887] Process rmmod (pid: 1897, stack limit = 0x00000000859535c3)
      [  521.621490] Call trace:
      [  521.623928]  nic_remove+0x24/0x88 [nicpf]
      [  521.627927]  pci_device_remove+0x48/0xd8
      [  521.631847]  device_release_driver_internal+0x1b0/0x248
      [  521.637062]  driver_detach+0x50/0xc0
      [  521.640628]  bus_remove_driver+0x60/0x100
      [  521.644627]  driver_unregister+0x34/0x60
      [  521.648538]  pci_unregister_driver+0x24/0xd8
      [  521.652798]  nic_cleanup_module+0x14/0x111c [nicpf]
      [  521.657672]  __arm64_sys_delete_module+0x150/0x218
      [  521.662460]  el0_svc_handler+0x94/0x110
      [  521.666287]  el0_svc+0x8/0xc
      [  521.669160] Code: aa1e03e0 9102c295 d503201f f9404eb3 (b9401660)
      
      Fixes: 4863dea3 ("net: Adding support for Cavium ThunderX network controller")
      Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      227b1745
    • Y
      x86/kvm/vmx: fix old-style function declaration · bf1b47f3
      Yi Wang 提交于
      [ Upstream commit 1e4329ee ]
      
      The inline keyword which is not at the beginning of the function
      declaration may trigger the following build warnings, so let's fix it:
      
      arch/x86/kvm/vmx.c:1309:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
      arch/x86/kvm/vmx.c:5947:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
      arch/x86/kvm/vmx.c:5985:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
      arch/x86/kvm/vmx.c:6023:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
      Signed-off-by: NYi Wang <wang.yi59@zte.com.cn>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bf1b47f3
    • Y
      KVM: x86: fix empty-body warnings · d6b1692d
      Yi Wang 提交于
      [ Upstream commit 354cb410 ]
      
      We get the following warnings about empty statements when building
      with 'W=1':
      
      arch/x86/kvm/lapic.c:632:53: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
      arch/x86/kvm/lapic.c:1907:42: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
      arch/x86/kvm/lapic.c:1936:65: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
      arch/x86/kvm/lapic.c:1975:44: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
      
      Rework the debug helper macro to get rid of these warnings.
      Signed-off-by: NYi Wang <wang.yi59@zte.com.cn>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d6b1692d
    • L
      KVM: VMX: Update shared MSRs to be saved/restored on MSR_EFER.LMA changes · 3c7670d5
      Liran Alon 提交于
      [ Upstream commit f48b4711dd6e1cf282f9dfd159c14a305909c97c ]
      
      When guest transitions from/to long-mode by modifying MSR_EFER.LMA,
      the list of shared MSRs to be saved/restored on guest<->host
      transitions is updated (See vmx_set_efer() call to setup_msrs()).
      
      On every entry to guest, vcpu_enter_guest() calls
      vmx_prepare_switch_to_guest(). This function should also take care
      of setting the shared MSRs to be saved/restored. However, the
      function does nothing in case we are already running with loaded
      guest state (vmx->loaded_cpu_state != NULL).
      
      This means that even when guest modifies MSR_EFER.LMA which results
      in updating the list of shared MSRs, it isn't being taken into account
      by vmx_prepare_switch_to_guest() because it happens while we are
      running with loaded guest state.
      
      To fix above mentioned issue, add a flag to mark that the list of
      shared MSRs has been updated and modify vmx_prepare_switch_to_guest()
      to set shared MSRs when running with host state *OR* list of shared
      MSRs has been updated.
      
      Note that this issue was mistakenly introduced by commit
      678e315e ("KVM: vmx: add dedicated utility to access guest's
      kernel_gs_base") because previously vmx_set_efer() always called
      vmx_load_host_state() which resulted in vmx_prepare_switch_to_guest() to
      set shared MSRs.
      
      Fixes: 678e315e ("KVM: vmx: add dedicated utility to access guest's kernel_gs_base")
      Reported-by: NEyal Moscovici <eyal.moscovici@oracle.com>
      Reviewed-by: NMihai Carabas <mihai.carabas@oracle.com>
      Reviewed-by: NLiam Merwick <liam.merwick@oracle.com>
      Reviewed-by: NJim Mattson <jmattson@google.com>
      Signed-off-by: NLiran Alon <liran.alon@oracle.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3c7670d5
    • T
      netfilter: nf_conncount: remove wrong condition check routine · 8038f92d
      Taehee Yoo 提交于
      [ Upstream commit 53ca0f2f ]
      
      All lists that reach the tree_nodes_free() function have both zero
      counter and true dead flag. The reason for this is that lists to be
      release are selected by nf_conncount_gc_list() which already decrements
      the list counter and sets on the dead flag. Therefore, this if statement
      in tree_nodes_free() is unnecessary and wrong.
      
      Fixes: 31568ec0 ("netfilter: nf_conncount: fix list_del corruption in conn_free")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8038f92d
    • T
      netfilter: nat: fix double register in masquerade modules · 5517d4c6
      Taehee Yoo 提交于
      [ Upstream commit 095faf45e64be00bff4da2d6182dface3d69c9b7 ]
      
      There is a reference counter to ensure that masquerade modules register
      notifiers only once. However, the existing reference counter approach is
      not safe, test commands are:
      
         while :
         do
         	   modprobe ip6t_MASQUERADE &
      	   modprobe nft_masq_ipv6 &
      	   modprobe -rv ip6t_MASQUERADE &
      	   modprobe -rv nft_masq_ipv6 &
         done
      
      numbers below represent the reference counter.
      --------------------------------------------------------
      CPU0        CPU1        CPU2        CPU3        CPU4
      [insmod]    [insmod]    [rmmod]     [rmmod]     [insmod]
      --------------------------------------------------------
      0->1
      register    1->2
                  returns     2->1
      			returns     1->0
                                                      0->1
                                                      register <--
                                          unregister
      --------------------------------------------------------
      
      The unregistation of CPU3 should be processed before the
      registration of CPU4.
      
      In order to fix this, use a mutex instead of reference counter.
      
      splat looks like:
      [  323.869557] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [modprobe:1381]
      [  323.869574] Modules linked in: nf_tables(+) nf_nat_ipv6(-) nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 n]
      [  323.869574] irq event stamp: 194074
      [  323.898930] hardirqs last  enabled at (194073): [<ffffffff90004a0d>] trace_hardirqs_on_thunk+0x1a/0x1c
      [  323.898930] hardirqs last disabled at (194074): [<ffffffff90004a29>] trace_hardirqs_off_thunk+0x1a/0x1c
      [  323.898930] softirqs last  enabled at (182132): [<ffffffff922006ec>] __do_softirq+0x6ec/0xa3b
      [  323.898930] softirqs last disabled at (182109): [<ffffffff90193426>] irq_exit+0x1a6/0x1e0
      [  323.898930] CPU: 0 PID: 1381 Comm: modprobe Not tainted 4.20.0-rc2+ #27
      [  323.898930] RIP: 0010:raw_notifier_chain_register+0xea/0x240
      [  323.898930] Code: 3c 03 0f 8e f2 00 00 00 44 3b 6b 10 7f 4d 49 bc 00 00 00 00 00 fc ff df eb 22 48 8d 7b 10 488
      [  323.898930] RSP: 0018:ffff888101597218 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13
      [  323.898930] RAX: 0000000000000000 RBX: ffffffffc04361c0 RCX: 0000000000000000
      [  323.898930] RDX: 1ffffffff26132ae RSI: ffffffffc04aa3c0 RDI: ffffffffc04361d0
      [  323.898930] RBP: ffffffffc04361c8 R08: 0000000000000000 R09: 0000000000000001
      [  323.898930] R10: ffff8881015972b0 R11: fffffbfff26132c4 R12: dffffc0000000000
      [  323.898930] R13: 0000000000000000 R14: 1ffff110202b2e44 R15: ffffffffc04aa3c0
      [  323.898930] FS:  00007f813ed41540(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000
      [  323.898930] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  323.898930] CR2: 0000559bf2c9f120 CR3: 000000010bc80000 CR4: 00000000001006f0
      [  323.898930] Call Trace:
      [  323.898930]  ? atomic_notifier_chain_register+0x2d0/0x2d0
      [  323.898930]  ? down_read+0x150/0x150
      [  323.898930]  ? sched_clock_cpu+0x126/0x170
      [  323.898930]  ? nf_tables_core_module_init+0xe4/0xe4 [nf_tables]
      [  323.898930]  ? nf_tables_core_module_init+0xe4/0xe4 [nf_tables]
      [  323.898930]  register_netdevice_notifier+0xbb/0x790
      [  323.898930]  ? __dev_close_many+0x2d0/0x2d0
      [  323.898930]  ? __mutex_unlock_slowpath+0x17f/0x740
      [  323.898930]  ? wait_for_completion+0x710/0x710
      [  323.898930]  ? nf_tables_core_module_init+0xe4/0xe4 [nf_tables]
      [  323.898930]  ? up_write+0x6c/0x210
      [  323.898930]  ? nf_tables_core_module_init+0xe4/0xe4 [nf_tables]
      [  324.127073]  ? nf_tables_core_module_init+0xe4/0xe4 [nf_tables]
      [  324.127073]  nft_chain_filter_init+0x1e/0xe8a [nf_tables]
      [  324.127073]  nf_tables_module_init+0x37/0x92 [nf_tables]
      [ ... ]
      
      Fixes: 8dd33cc9 ("netfilter: nf_nat: generalize IPv4 masquerading support for nf_tables")
      Fixes: be6b635c ("netfilter: nf_nat: generalize IPv6 masquerading support for nf_tables")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5517d4c6
    • T
      netfilter: add missing error handling code for register functions · 18218f82
      Taehee Yoo 提交于
      [ Upstream commit 584eab291c67894cb17cc87544b9d086228ea70f ]
      
      register_{netdevice/inetaddr/inet6addr}_notifier may return an error
      value, this patch adds the code to handle these error paths.
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      18218f82
    • A
      IB/mlx5: Fix page fault handling for MW · 4f03e063
      Artemy Kovalyov 提交于
      [ Upstream commit 75b7b86bdb0df37e08e44b6c1f99010967f81944 ]
      
      Memory windows are implemented with an indirect MKey, when a page fault
      event comes for a MW Mkey we need to find the MR at the end of the list of
      the indirect MKeys by iterating on all items from the first to the last.
      
      The offset calculated during this process has to be zeroed after the first
      iteration or the next iteration will start from a wrong address, resulting
      incorrect ODP faulting behavior.
      
      Fixes: db570d7d ("IB/mlx5: Add ODP support to MW")
      Signed-off-by: NArtemy Kovalyov <artemyko@mellanox.com>
      Signed-off-by: NMoni Shoua <monis@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4f03e063
    • A
      netfilter: ipv6: Preserve link scope traffic original oif · 9838090d
      Alin Nastac 提交于
      [ Upstream commit 508b09046c0f21678652fb66fd1e9959d55591d2 ]
      
      When ip6_route_me_harder is invoked, it resets outgoing interface of:
        - link-local scoped packets sent by neighbor discovery
        - multicast packets sent by MLD host
        - multicast packets send by MLD proxy daemon that sets outgoing
          interface through IPV6_PKTINFO ipi6_ifindex
      
      Link-local and multicast packets must keep their original oif after
      ip6_route_me_harder is called.
      Signed-off-by: NAlin Nastac <alin.nastac@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9838090d
    • C
      drm/meson: add support for 1080p25 mode · bf6f1276
      Christian Hewitt 提交于
      [ Upstream commit 31e1ab494559fb46de304cc6c2aed1528f94b298 ]
      
      This essential mode for PAL users is missing, so add it.
      
      Fixes: 335e3713 ("drm/meson: Add support for HDMI venc modes and settings")
      Signed-off-by: NChristian Hewitt <christianshewitt@gmail.com>
      Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1542793169-13008-1-git-send-email-christianshewitt@gmail.comSigned-off-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bf6f1276
    • M
      thunderbolt: Prevent root port runtime suspend during NVM upgrade · 5dda1e7d
      Mika Westerberg 提交于
      [ Upstream commit 1830b6eeda1fed42d85f2388f79c926331a9b2d0 ]
      
      During NVM upgrade process the host router is hot-removed for a short
      while. During this time it is possible that the root port is moved into
      D3cold which would be fine if the root port could trigger PME on itself.
      However, many systems actually do not implement it so what happens is
      that the root port goes into D3cold and never wakes up unless userspace
      does PCI config space access, such as running 'lscpi'.
      
      For this reason we explicitly prevent the root port from runtime
      suspending during NVM upgrade.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5dda1e7d
    • A
      USB: omap_udc: fix rejection of out transfers when DMA is used · 9ca88f3c
      Aaro Koskinen 提交于
      [ Upstream commit 069caf5950dfa75d0526cd89c439ff9d9d3136d8 ]
      
      Commit 387f869d ("usb: gadget: u_ether: conditionally align
      transfer size") started aligning transfer size only if requested,
      breaking omap_udc DMA mode. Set quirk_ep_out_aligned_size to restore
      the old behaviour.
      
      Fixes: 387f869d ("usb: gadget: u_ether: conditionally align transfer size")
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9ca88f3c
    • A
      USB: omap_udc: fix USB gadget functionality on Palm Tungsten E · b5812813
      Aaro Koskinen 提交于
      [ Upstream commit 2c2322fbcab8102b8cadc09d66714700a2da42c2 ]
      
      On Palm TE nothing happens when you try to use gadget drivers and plug
      the USB cable. Fix by adding the board to the vbus sense quirk list.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b5812813
    • A
      USB: omap_udc: fix omap_udc_start() on 15xx machines · 634395d2
      Aaro Koskinen 提交于
      [ Upstream commit 6ca6695f576b8453fe68865e84d25946d63b10ad ]
      
      On OMAP 15xx machines there are no transceivers, and omap_udc_start()
      always fails as it forgot to adjust the default return value.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      634395d2
    • A
      USB: omap_udc: fix crashes on probe error and module removal · 27b61cba
      Aaro Koskinen 提交于
      [ Upstream commit 99f700366fcea1aa2fa3c49c99f371670c3c62f8 ]
      
      We currently crash if usb_add_gadget_udc_release() fails, since the
      udc->done is not initialized until in the remove function.
      Furthermore, on module removal the udc data is accessed although
      the release function is already triggered by usb_del_gadget_udc()
      early in the function.
      
      Fix by rewriting the release and remove functions, basically moving
      all the cleanup into the release function, and doing the completion
      only in the module removal case.
      
      The patch fixes omap_udc module probe with a failing gadged, and also
      allows the removal of omap_udc. Tested by running "modprobe omap_udc;
      modprobe -r omap_udc" in a loop.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      27b61cba
    • A
      USB: omap_udc: use devm_request_irq() · 66d73a4e
      Aaro Koskinen 提交于
      [ Upstream commit 286afdde1640d8ea8916a0f05e811441fbbf4b9d ]
      
      The current code fails to release the third irq on the error path
      (observed by reading the code), and we get also multiple WARNs with
      failing gadget drivers due to duplicate IRQ releases. Fix by using
      devm_request_irq().
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      66d73a4e
    • X
      ipvs: call ip_vs_dst_notifier earlier than ipv6_dev_notf · 28ad9091
      Xin Long 提交于
      [ Upstream commit 2a31e4bd ]
      
      ip_vs_dst_event is supposed to clean up all dst used in ipvs'
      destinations when a net dev is going down. But it works only
      when the dst's dev is the same as the dev from the event.
      
      Now with the same priority but late registration,
      ip_vs_dst_notifier is always called later than ipv6_dev_notf
      where the dst's dev is set to lo for NETDEV_DOWN event.
      
      As the dst's dev lo is not the same as the dev from the event
      in ip_vs_dst_event, ip_vs_dst_notifier doesn't actually work.
      Also as these dst have to wait for dest_trash_timer to clean
      them up. It would cause some non-permanent kernel warnings:
      
        unregister_netdevice: waiting for br0 to become free. Usage count = 3
      
      To fix it, call ip_vs_dst_notifier earlier than ipv6_dev_notf
      by increasing its priority to ADDRCONF_NOTIFY_PRIORITY + 5.
      
      Note that for ipv4 route fib_netdev_notifier doesn't set dst's
      dev to lo in NETDEV_DOWN event, so this fix is only needed when
      IP_VS_IPV6 is defined.
      
      Fixes: 7a4f0761 ("IPVS: init and cleanup restructuring")
      Reported-by: NLi Shuang <shuali@redhat.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NJulian Anastasov <ja@ssi.bg>
      Acked-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      28ad9091
    • A
      fsi: master-ast-cf: select GENERIC_ALLOCATOR · 2aad202f
      Arnd Bergmann 提交于
      [ Upstream commit 64999fa7aa2c076ec6d05aee481f11f5296ceb8c ]
      
      In randconfig builds without CONFIG_GENERIC_ALLOCATOR, this driver
      fails to link:
      
      ERROR: "gen_pool_alloc_algo" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
      ERROR: "gen_pool_fixed_alloc" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
      ERROR: "of_gen_pool_get" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
      ERROR: "gen_pool_free" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
      
      Select the dependency as all other users do.
      
      Fixes: 6a794a27 ("fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2aad202f
    • M
      bpf: fix check of allowed specifiers in bpf_trace_printk · 6bfebeda
      Martynas Pumputis 提交于
      [ Upstream commit 1efb6ee3edea57f57f9fb05dba8dcb3f7333f61f ]
      
      A format string consisting of "%p" or "%s" followed by an invalid
      specifier (e.g. "%p%\n" or "%s%") could pass the check which
      would make format_decode (lib/vsprintf.c) to warn.
      
      Fixes: 9c959c86 ("tracing: Allow BPF programs to call bpf_trace_printk()")
      Reported-by: syzbot+1ec5c5ec949c4adaa0c4@syzkaller.appspotmail.com
      Signed-off-by: NMartynas Pumputis <m@lambda.lt>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6bfebeda
    • Y
      RDMA/hns: Bugfix pbl configuration for rereg mr · 4c7d50c2
      Yixian Liu 提交于
      [ Upstream commit ca088320 ]
      
      Current hns driver assigned the first two PBL page addresses from previous
      registered MR to the hardware when reregister MR changing the memory
      locations occurred. This will lead to PBL addressing error as the PBL has
      already been released. This patch fixes this wrong assignment by using the
      page address from new allocated PBL.
      
      Fixes: a2c80b7b ("RDMA/hns: Add rereg mr support for hip08")
      Signed-off-by: NYixian Liu <liuyixian@huawei.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4c7d50c2