1. 05 Aug, 2019 1 commit
  2. 24 Jul, 2019 1 commit
  3. 12 Jul, 2019 2 commits
  4. 11 Jul, 2019 1 commit
    • Chris Paterson's avatar
      Add gitlab-ci.yaml · 69d7bc3a
      Chris Paterson authored
      This is configured to build and test the following configurations:
      
      * BUILD_ARCH: arm
      * CONFIG: renesas_shmobile_defconfig
      * CONFIG_LOC: cip-kernel-config
      * DEVICES: r8a7743-iwg20d-q7 r8a7745-iwg22d-sodimm
      * DTBS: r8a7743-iwg20d-q7-dbcm-ca.dtb r8a7745-iwg22d-sodimm-dbhd-ca.dtb
      
      * BUILD_ARCH: arm
      * CONFIG: shmobile_defconfig
      * CONFIG_LOC: intree
      * DEVICES: r8a7743-iwg20d-q7 r8a7745-iwg22d-sodimm
      * DTBS: r8a7743-iwg20d-q7-dbcm-ca.dtb r8a7745-iwg22d-sodimm-dbhd-ca.dtb
      
      Over time support will be added for all CIP supported architectures and
      configurations.
      
      At the moment only simple boot tests are run. Real tests will be added in
      the future
      Signed-off-by: 's avatarChris Paterson <chris.paterson2@renesas.com>
      Signed-off-by: Pavel Machek's avatarPavel Machek <pavel@denx.de>
      69d7bc3a
  5. 10 Jul, 2019 35 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.185 · 7bbf4894
      Greg Kroah-Hartman authored
      7bbf4894
    • Yibin Gong's avatar
      dmaengine: imx-sdma: remove BD_INTR for channel0 · f66168a2
      Yibin Gong authored
      commit 3f93a4f297961c12bb17aa16cb3a4d1291823cae upstream.
      
      It is possible for an irq triggered by channel0 to be received later
      after clks are disabled once firmware loaded during sdma probe. If
      that happens then clearing them by writing to SDMA_H_INTR won't work
      and the kernel will hang processing infinite interrupts. Actually,
      don't need interrupt triggered on channel0 since it's pollling
      SDMA_H_STATSTOP to know channel0 done rather than interrupt in
      current code, just clear BD_INTR to disable channel0 interrupt to
      avoid the above case.
      This issue was brought by commit 1d069bfa ("dmaengine: imx-sdma:
      ack channel 0 IRQ in the interrupt handler") which didn't take care
      the above case.
      
      Fixes: 1d069bfa ("dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler")
      Cc: stable@vger.kernel.org #5.0+
      Signed-off-by: Yibin Gong's avatarRobin Gong <yibin.gong@nxp.com>
      Reported-by: 's avatarSven Van Asbroeck <thesven73@gmail.com>
      Tested-by: 's avatarSven Van Asbroeck <thesven73@gmail.com>
      Reviewed-by: 's avatarMichael Olbrich <m.olbrich@pengutronix.de>
      Signed-off-by: 's avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f66168a2
    • Paolo Bonzini's avatar
      KVM: x86: degrade WARN to pr_warn_ratelimited · 2fec7f2e
      Paolo Bonzini authored
      commit 3f16a5c318392cbb5a0c7a3d19dff8c8ef3c38ee upstream.
      
      This warning can be triggered easily by userspace, so it should certainly not
      cause a panic if panic_on_warn is set.
      
      Reported-by: syzbot+c03f30b4f4c46bdf8575@syzkaller.appspotmail.com
      Suggested-by: 's avatarAlexander Potapenko <glider@google.com>
      Acked-by: 's avatarAlexander Potapenko <glider@google.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2fec7f2e
    • Kees Cook's avatar
      arm64, vdso: Define vdso_{start,end} as array · c0309c78
      Kees Cook authored
      Commit dbbb08f5 upstream.
      
      Adjust vdso_{start|end} to be char arrays to avoid compile-time analysis
      that flags "too large" memcmp() calls with CONFIG_FORTIFY_SOURCE.
      
      Cc: Jisheng Zhang <jszhang@marvell.com>
      Acked-by: 's avatarCatalin Marinas <catalin.marinas@arm.com>
      Suggested-by: 's avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: 's avatarKees Cook <keescook@chromium.org>
      Signed-off-by: 's avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      c0309c78
    • Vineet Gupta's avatar
      ARC: handle gcc generated __builtin_trap for older compiler · a62a40c8
      Vineet Gupta authored
      commit af1be2e2 upstream.
      
      ARC gcc prior to GNU 2018.03 release didn't have a target specific
      __builtin_trap() implementation, generating default abort() call.
      
      Implement the abort() call - emulating what newer gcc does for the same,
      as suggested by Arnd.
      Acked-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a62a40c8
    • Linus Torvalds's avatar
      tty: rocket: fix incorrect forward declaration of 'rp_init()' · 1ed8ed6d
      Linus Torvalds authored
      [ Upstream commit 423ea3255424b954947d167681b71ded1b8fca53 ]
      
      Make the forward declaration actually match the real function
      definition, something that previous versions of gcc had just ignored.
      
      This is another patch to fix new warnings from gcc-9 before I start the
      merge window pulls.  I don't want to miss legitimate new warnings just
      because my system update brought a new compiler with new warnings.
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      1ed8ed6d
    • Nikolay Borisov's avatar
      btrfs: Ensure replaced device doesn't have pending chunk allocation · 986543fc
      Nikolay Borisov authored
      commit debd1c065d2037919a7da67baf55cc683fee09f0 upstream.
      
      Recent FITRIM work, namely bbbf7243d62d ("btrfs: combine device update
      operations during transaction commit") combined the way certain
      operations are recoded in a transaction. As a result an ASSERT was added
      in dev_replace_finish to ensure the new code works correctly.
      Unfortunately I got reports that it's possible to trigger the assert,
      meaning that during a device replace it's possible to have an unfinished
      chunk allocation on the source device.
      
      This is supposed to be prevented by the fact that a transaction is
      committed before finishing the replace oepration and alter acquiring the
      chunk mutex. This is not sufficient since by the time the transaction is
      committed and the chunk mutex acquired it's possible to allocate a chunk
      depending on the workload being executed on the replaced device. This
      bug has been present ever since device replace was introduced but there
      was never code which checks for it.
      
      The correct way to fix is to ensure that there is no pending device
      modification operation when the chunk mutex is acquire and if there is
      repeat transaction commit. Unfortunately it's not possible to just
      exclude the source device from btrfs_fs_devices::dev_alloc_list since
      this causes ENOSPC to be hit in transaction commit.
      
      Fixing that in another way would need to add special cases to handle the
      last writes and forbid new ones. The looped transaction fix is more
      obvious, and can be easily backported. The runtime of dev-replace is
      long so there's no noticeable delay caused by that.
      Reported-by: 's avatarDavid Sterba <dsterba@suse.com>
      Fixes: 391cd9df ("Btrfs: fix unprotected alloc list insertion during the finishing procedure of replace")
      CC: stable@vger.kernel.org # 4.4+
      Signed-off-by: 's avatarNikolay Borisov <nborisov@suse.com>
      Reviewed-by: 's avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: 's avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      986543fc
    • Herbert Xu's avatar
      lib/mpi: Fix karactx leak in mpi_powm · adbf2b44
      Herbert Xu authored
      commit c8ea9fce2baf7b643384f36f29e4194fa40d33a6 upstream.
      
      Sometimes mpi_powm will leak karactx because a memory allocation
      failure causes a bail-out that skips the freeing of karactx.  This
      patch moves the freeing of karactx to the end of the function like
      everything else so that it can't be skipped.
      
      Reported-by: syzbot+f7baccc38dcc1e094e77@syzkaller.appspotmail.com
      Fixes: cdec9cb5 ("crypto: GnuPG based MPI lib - source files...")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      Reviewed-by: 's avatarEric Biggers <ebiggers@kernel.org>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      adbf2b44
    • Colin Ian King's avatar
      ALSA: usb-audio: fix sign unintended sign extension on left shifts · 52e0b9fc
      Colin Ian King authored
      commit 2acf5a3e6e9371e63c9e4ff54d84d08f630467a0 upstream.
      
      There are a couple of left shifts of unsigned 8 bit values that
      first get promoted to signed ints and hence get sign extended
      on the shift if the top bit of the 8 bit values are set. Fix
      this by casting the 8 bit values to unsigned ints to stop the
      unintentional sign extension.
      
      Addresses-Coverity: ("Unintended sign extension")
      Signed-off-by: 's avatarColin Ian King <colin.king@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52e0b9fc
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib/fireworks: fix miss detection of received MIDI messages · 3864c897
      Takashi Sakamoto authored
      commit 7fbd1753b64eafe21cf842348a40a691d0dee440 upstream.
      
      In IEC 61883-6, 8 MIDI data streams are multiplexed into single
      MIDI conformant data channel. The index of stream is calculated by
      modulo 8 of the value of data block counter.
      
      In fireworks, the value of data block counter in CIP header has a quirk
      with firmware version v5.0.0, v5.7.3 and v5.8.0. This brings ALSA
      IEC 61883-1/6 packet streaming engine to miss detection of MIDI
      messages.
      
      This commit fixes the miss detection to modify the value of data block
      counter for the modulo calculation.
      
      For maintainers, this bug exists since a commit 18f5ed36 ("ALSA:
      fireworks/firewire-lib: add support for recent firmware quirk") in Linux
      kernel v4.2. There're many changes since the commit.  This fix can be
      backported to Linux kernel v4.4 or later. I tagged a base commit to the
      backport for your convenience.
      
      Besides, my work for Linux kernel v5.3 brings heavy code refactoring and
      some structure members are renamed in 'sound/firewire/amdtp-stream.h'.
      The content of this patch brings conflict when merging -rc tree with
      this patch and the latest tree. I request maintainers to solve the
      conflict to replace 'tx_first_dbc' with 'ctx_data.tx.first_dbc'.
      
      Fixes: df075fee ("ALSA: firewire-lib: complete AM824 data block processing layer")
      Cc: <stable@vger.kernel.org> # v4.4+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3864c897
    • Colin Ian King's avatar
      ALSA: seq: fix incorrect order of dest_client/dest_ports arguments · 13088bad
      Colin Ian King authored
      commit c3ea60c231446663afd6ea1054da6b7f830855ca upstream.
      
      There are two occurrances of a call to snd_seq_oss_fill_addr where
      the dest_client and dest_port arguments are in the wrong order. Fix
      this by swapping them around.
      
      Addresses-Coverity: ("Arguments in wrong order")
      Signed-off-by: 's avatarColin Ian King <colin.king@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      13088bad
    • Eric Biggers's avatar
      crypto: user - prevent operating on larval algorithms · 6e5d6d15
      Eric Biggers authored
      commit 21d4120ec6f5b5992b01b96ac484701163917b63 upstream.
      
      Michal Suchanek reported [1] that running the pcrypt_aead01 test from
      LTP [2] in a loop and holding Ctrl-C causes a NULL dereference of
      alg->cra_users.next in crypto_remove_spawns(), via crypto_del_alg().
      The test repeatedly uses CRYPTO_MSG_NEWALG and CRYPTO_MSG_DELALG.
      
      The crash occurs when the instance that CRYPTO_MSG_DELALG is trying to
      unregister isn't a real registered algorithm, but rather is a "test
      larval", which is a special "algorithm" added to the algorithms list
      while the real algorithm is still being tested.  Larvals don't have
      initialized cra_users, so that causes the crash.  Normally pcrypt_aead01
      doesn't trigger this because CRYPTO_MSG_NEWALG waits for the algorithm
      to be tested; however, CRYPTO_MSG_NEWALG returns early when interrupted.
      
      Everything else in the "crypto user configuration" API has this same bug
      too, i.e. it inappropriately allows operating on larval algorithms
      (though it doesn't look like the other cases can cause a crash).
      
      Fix this by making crypto_alg_match() exclude larval algorithms.
      
      [1] https://lkml.kernel.org/r/20190625071624.27039-1-msuchanek@suse.de
      [2] https://github.com/linux-test-project/ltp/blob/20190517/testcases/kernel/crypto/pcrypt_aead01.cReported-by: 's avatarMichal Suchanek <msuchanek@suse.de>
      Fixes: a38f7907 ("crypto: Add userspace configuration API")
      Cc: <stable@vger.kernel.org> # v3.2+
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e5d6d15
    • Jann Horn's avatar
      ptrace: Fix ->ptracer_cred handling for PTRACE_TRACEME · 54562d2b
      Jann Horn authored
      commit 6994eefb0053799d2e07cd140df6c2ea106c41ee upstream.
      
      Fix two issues:
      
      When called for PTRACE_TRACEME, ptrace_link() would obtain an RCU
      reference to the parent's objective credentials, then give that pointer
      to get_cred().  However, the object lifetime rules for things like
      struct cred do not permit unconditionally turning an RCU reference into
      a stable reference.
      
      PTRACE_TRACEME records the parent's credentials as if the parent was
      acting as the subject, but that's not the case.  If a malicious
      unprivileged child uses PTRACE_TRACEME and the parent is privileged, and
      at a later point, the parent process becomes attacker-controlled
      (because it drops privileges and calls execve()), the attacker ends up
      with control over two processes with a privileged ptrace relationship,
      which can be abused to ptrace a suid binary and obtain root privileges.
      
      Fix both of these by always recording the credentials of the process
      that is requesting the creation of the ptrace relationship:
      current_cred() can't change under us, and current is the proper subject
      for access control.
      
      This change is theoretically userspace-visible, but I am not aware of
      any code that it will actually break.
      
      Fixes: 64b875f7 ("ptrace: Capture the ptracer's creds not PT_PTRACE_CAP")
      Signed-off-by: 's avatarJann Horn <jannh@google.com>
      Acked-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      54562d2b
    • Paul Burton's avatar
      MIPS: Workaround GCC __builtin_unreachable reordering bug · 18eee992
      Paul Burton authored
      [ Upstream commit 906d441febc0de974b2a6ef848a8f058f3bfada3 ]
      
      Some versions of GCC for the MIPS architecture suffer from a bug which
      can lead to instructions from beyond an unreachable statement being
      incorrectly reordered into earlier branch delay slots if the unreachable
      statement is the only content of a case in a switch statement. This can
      lead to seemingly random behaviour, such as invalid memory accesses from
      incorrectly reordered loads or stores, and link failures on microMIPS
      builds.
      
      See this potential GCC fix for details:
      
          https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html
      
      Runtime problems resulting from this bug were initially observed using a
      maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape
      SDK 2015.06-05 toolchain), with the result being an address exception
      taken after log messages about the L1 caches (during probe of the L2
      cache):
      
          Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff]
          VPE topology {2,2} total 4
          Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
          Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
          <AdEL exception here>
      
      This is early enough that the kernel exception vectors are not in use,
      so any further output depends upon the bootloader. This is reproducible
      in QEMU where no further output occurs - ie. the system hangs here.
      Given the nature of the bug it may potentially be hit with differing
      symptoms. The bug is known to affect GCC versions as recent as 7.3, and
      it is unclear whether GCC 8 fixed it or just happens not to encounter
      the bug in the testcase found at the link above due to differing
      optimizations.
      
      This bug can be worked around by placing a volatile asm statement, which
      GCC is prevented from reordering past, prior to the
      __builtin_unreachable call.
      
      That was actually done already for other reasons by commit 173a3efd
      ("bug.h: work around GCC PR82365 in BUG()"), but creates problems for
      microMIPS builds due to the lack of a .insn directive. The microMIPS ISA
      allows for interlinking with regular MIPS32 code by repurposing bit 0 of
      the program counter as an ISA mode bit. To switch modes one changes the
      value of this bit in the PC. However typical branch instructions encode
      their offsets as multiples of 2-byte instruction halfwords, which means
      they cannot change ISA mode - this must be done using either an indirect
      branch (a jump-register in MIPS terminology) or a dedicated jalx
      instruction. In order to ensure that regular branches don't attempt to
      target code in a different ISA which they can't actually switch to, the
      linker will check that branch targets are code in the same ISA as the
      branch.
      
      Unfortunately our empty asm volatile statements don't qualify as code,
      and the link for microMIPS builds fails with errors such as:
      
          arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA mode
          arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA mode
      
      Resolve this by adding a .insn directive within the asm statement which
      declares that what comes next is code. This may or may not be true,
      since we don't really know what comes next, but as this code is in an
      unreachable path anyway that doesn't matter since we won't execute it.
      
      We do this in asm/compiler.h & select CONFIG_HAVE_ARCH_COMPILER_H in
      order to have this included by linux/compiler_types.h after
      linux/compiler-gcc.h. This will result in asm/compiler.h being included
      in all C compilations via the -include linux/compiler_types.h argument
      in c_flags, which should be harmless.
      Signed-off-by: 's avatarPaul Burton <paul.burton@mips.com>
      Fixes: 173a3efd ("bug.h: work around GCC PR82365 in BUG()")
      Patchwork: https://patchwork.linux-mips.org/patch/20270/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      18eee992
    • Arnd Bergmann's avatar
      bug.h: work around GCC PR82365 in BUG() · 2fbaa1af
      Arnd Bergmann authored
      [ Upstream commit 173a3efd ]
      
      Looking at functions with large stack frames across all architectures
      led me discovering that BUG() suffers from the same problem as
      fortify_panic(), which I've added a workaround for already.
      
      In short, variables that go out of scope by calling a noreturn function
      or __builtin_unreachable() keep using stack space in functions
      afterwards.
      
      A workaround that was identified is to insert an empty assembler
      statement just before calling the function that doesn't return.  I'm
      adding a macro "barrier_before_unreachable()" to document this, and
      insert calls to that in all instances of BUG() that currently suffer
      from this problem.
      
      The files that saw the largest change from this had these frame sizes
      before, and much less with my patch:
      
        fs/ext4/inode.c:82:1: warning: the frame size of 1672 bytes is larger than 800 bytes [-Wframe-larger-than=]
        fs/ext4/namei.c:434:1: warning: the frame size of 904 bytes is larger than 800 bytes [-Wframe-larger-than=]
        fs/ext4/super.c:2279:1: warning: the frame size of 1160 bytes is larger than 800 bytes [-Wframe-larger-than=]
        fs/ext4/xattr.c:146:1: warning: the frame size of 1168 bytes is larger than 800 bytes [-Wframe-larger-than=]
        fs/f2fs/inode.c:152:1: warning: the frame size of 1424 bytes is larger than 800 bytes [-Wframe-larger-than=]
        net/netfilter/ipvs/ip_vs_core.c:1195:1: warning: the frame size of 1068 bytes is larger than 800 bytes [-Wframe-larger-than=]
        net/netfilter/ipvs/ip_vs_core.c:395:1: warning: the frame size of 1084 bytes is larger than 800 bytes [-Wframe-larger-than=]
        net/netfilter/ipvs/ip_vs_ftp.c:298:1: warning: the frame size of 928 bytes is larger than 800 bytes [-Wframe-larger-than=]
        net/netfilter/ipvs/ip_vs_ftp.c:418:1: warning: the frame size of 908 bytes is larger than 800 bytes [-Wframe-larger-than=]
        net/netfilter/ipvs/ip_vs_lblcr.c:718:1: warning: the frame size of 960 bytes is larger than 800 bytes [-Wframe-larger-than=]
        drivers/net/xen-netback/netback.c:1500:1: warning: the frame size of 1088 bytes is larger than 800 bytes [-Wframe-larger-than=]
      
      In case of ARC and CRIS, it turns out that the BUG() implementation
      actually does return (or at least the compiler thinks it does),
      resulting in lots of warnings about uninitialized variable use and
      leaving noreturn functions, such as:
      
        block/cfq-iosched.c: In function 'cfq_async_queue_prio':
        block/cfq-iosched.c:3804:1: error: control reaches end of non-void function [-Werror=return-type]
        include/linux/dmaengine.h: In function 'dma_maxpq':
        include/linux/dmaengine.h:1123:1: error: control reaches end of non-void function [-Werror=return-type]
      
      This makes them call __builtin_trap() instead, which should normally
      dump the stack and kill the current process, like some of the other
      architectures already do.
      
      I tried adding barrier_before_unreachable() to panic() and
      fortify_panic() as well, but that had very little effect, so I'm not
      submitting that patch.
      
      Vineet said:
      
      : For ARC, it is double win.
      :
      : 1. Fixes 3 -Wreturn-type warnings
      :
      : | ../net/core/ethtool.c:311:1: warning: control reaches end of non-void function
      : [-Wreturn-type]
      : | ../kernel/sched/core.c:3246:1: warning: control reaches end of non-void function
      : [-Wreturn-type]
      : | ../include/linux/sunrpc/svc_xprt.h:180:1: warning: control reaches end of
      : non-void function [-Wreturn-type]
      :
      : 2.  bloat-o-meter reports code size improvements as gcc elides the
      :    generated code for stack return.
      
      Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
      Link: http://lkml.kernel.org/r/20171219114112.939391-1-arnd@arndb.deSigned-off-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: Vineet Gupta <vgupta@synopsys.com>	[arch/arc]
      Tested-by: Vineet Gupta <vgupta@synopsys.com>	[arch/arc]
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Christopher Li <sparse@chrisli.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      [ removed cris changes - gregkh]
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2fbaa1af
    • Thierry Reding's avatar
      swiotlb: Make linux/swiotlb.h standalone includible · 2f8180ff
      Thierry Reding authored
      [ Upstream commit 38674442 ]
      
      This header file uses the enum dma_data_direction and struct page types
      without explicitly including the corresponding header files. This makes
      it rely on the includer to have included the proper headers before.
      
      To fix this, include linux/dma-direction.h and forward-declare struct
      page. The swiotlb_free() function is also annotated __init, therefore
      requires linux/init.h to be included as well.
      Signed-off-by: 's avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: 's avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      2f8180ff
    • Arnd Bergmann's avatar
      mfd: omap-usb-tll: Fix register offsets · f1a9886d
      Arnd Bergmann authored
      [ Upstream commit 993dc737 ]
      
      gcc-8 notices that the register number calculation is wrong
      when the offset is an 'u8' but the number is larger than 256:
      
      drivers/mfd/omap-usb-tll.c: In function 'omap_tll_init':
      drivers/mfd/omap-usb-tll.c:90:46: error: overflow in conversion from 'int' to 'u8 {aka unsigned char}' chages value from 'i * 256 + 2070' to '22' [-Werror=overflow]
      
      This addresses it by always using a 32-bit offset number for
      the register. This is apparently an old problem that previous
      compilers did not find.
      
      Fixes: 16fa3dc7 ("mfd: omap-usb-tll: HOST TLL platform driver")
      Signed-off-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      f1a9886d
    • Manuel Lauss's avatar
      MIPS: math-emu: do not use bools for arithmetic · a1877fd3
      Manuel Lauss authored
      [ Upstream commit 8535f2ba ]
      
      GCC-7 complains about a boolean value being used with an arithmetic
      AND:
      
      arch/mips/math-emu/cp1emu.c: In function 'cop1Emulate':
      arch/mips/math-emu/cp1emu.c:838:14: warning: '~' on a boolean expression [-Wbool-operation]
        fpr = (x) & ~(cop1_64bit(xcp) == 0);    \
                    ^
      arch/mips/math-emu/cp1emu.c:1068:3: note: in expansion of macro 'DITOREG'
         DITOREG(dval, MIPSInst_RT(ir));
         ^~~~~~~
      arch/mips/math-emu/cp1emu.c:838:14: note: did you mean to use logical not?
        fpr = (x) & ~(cop1_64bit(xcp) == 0);    \
      
      Since cop1_64bit() returns and int, just flip the LSB.
      Suggested-by: 's avatarMaciej W. Rozycki <macro@imgtec.com>
      Signed-off-by: 's avatarManuel Lauss <manuel.lauss@gmail.com>
      Reviewed-by: 's avatarMaciej W. Rozycki <macro@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17058/Signed-off-by: 's avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      a1877fd3
    • Vineet Gupta's avatar
      ARC: fix build warning in elf.h · 014275fd
      Vineet Gupta authored
      [ Upstream commit 1dec7858 ]
      
      The cast valid since TASK_SIZE * 2 will never actually cause overflow.
      
      |   CC      fs/binfmt_elf.o
      | In file included from ../include/linux/elf.h:4:0,
      |                  from ../include/linux/module.h:15,
      |                  from ../fs/binfmt_elf.c:12:
      | ../fs/binfmt_elf.c: In function load_elf_binar:
      | ../arch/arc/include/asm/elf.h:57:29: warning: integer overflow in expression [-Woverflow]
      |  #define ELF_ET_DYN_BASE  (2 * TASK_SIZE / 3)
      |                              ^
      | ../fs/binfmt_elf.c:921:16: note: in expansion of macro ELF_ET_DYN_BASE
      |     load_bias = ELF_ET_DYN_BASE - vaddr;
      Signed-off-by: 's avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      014275fd
    • Vineet Gupta's avatar
      ARC: Assume multiplier is always present · a414c474
      Vineet Gupta authored
      [ Upstream commit 0eca6fdb ]
      
      It is unlikely that designs running Linux will not have multiplier.
      Further the current support is not complete as tool don't generate a
      multilib w/o multiplier.
      Signed-off-by: 's avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      a414c474
    • Don Brace's avatar
      scsi: hpsa: correct ioaccel2 chaining · b3e8f6bc
      Don Brace authored
      [ Upstream commit 625d7d3518875c4d303c652a198feaa13d9f52d9 ]
      
      - set ioaccel2_sg_element member 'chain_indicator' to IOACCEL2_LAST_SG for
        the last s/g element.
      
      - set ioaccel2_sg_element member 'chain_indicator' to IOACCEL2_CHAIN when
        chaining.
      Reviewed-by: 's avatarBader Ali - Saleh <bader.alisaleh@microsemi.com>
      Reviewed-by: 's avatarScott Teel <scott.teel@microsemi.com>
      Reviewed-by: 's avatarMatt Perricone <matt.perricone@microsemi.com>
      Signed-off-by: 's avatarDon Brace <don.brace@microsemi.com>
      Signed-off-by: 's avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      b3e8f6bc
    • Alexandre Belloni's avatar
      usb: gadget: udc: lpc32xx: allocate descriptor with GFP_ATOMIC · 8978dce0
      Alexandre Belloni authored
      [ Upstream commit fbc318afadd6e7ae2252d6158cf7d0c5a2132f7d ]
      
      Gadget drivers may queue request in interrupt context. This would lead to
      a descriptor allocation in that context. In that case we would hit
      BUG_ON(in_interrupt()) in __get_vm_area_node.
      
      Also remove the unnecessary cast.
      Acked-by: 's avatarSylvain Lemieux <slemieux.tyco@gmail.com>
      Tested-by: 's avatarJames Grant <jamesg@zaltys.org>
      Signed-off-by: 's avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: 's avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      8978dce0
    • Young Xiao's avatar
      usb: gadget: fusb300_udc: Fix memory leak of fusb300->ep[i] · 53f1c783
      Young Xiao authored
      [ Upstream commit 62fd0e0a24abeebe2c19fce49dd5716d9b62042d ]
      
      There is no deallocation of fusb300->ep[i] elements, allocated at
      fusb300_probe.
      
      The patch adds deallocation of fusb300->ep array elements.
      Signed-off-by: 's avatarYoung Xiao <92siuyang@gmail.com>
      Signed-off-by: 's avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      53f1c783
    • Yu-Hsuan Hsu's avatar
      ASoC: max98090: remove 24-bit format support if RJ is 0 · 5b3f5706
      Yu-Hsuan Hsu authored
      [ Upstream commit 5628c8979642a076f91ee86c3bae5ad251639af0 ]
      
      The supported formats are S16_LE and S24_LE now. However, by datasheet
      of max98090, S24_LE is only supported when it is in the right justified
      mode. We should remove 24-bit format if it is not in that mode to avoid
      triggering error.
      Signed-off-by: 's avatarYu-Hsuan Hsu <yuhsuan@chromium.org>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      5b3f5706
    • YueHaibing's avatar
      spi: bitbang: Fix NULL pointer dereference in spi_unregister_master · 05d6e618
      YueHaibing authored
      [ Upstream commit 5caaf29af5ca82d5da8bc1d0ad07d9e664ccf1d8 ]
      
      If spi_register_master fails in spi_bitbang_start
      because device_add failure, We should return the
      error code other than 0, otherwise calling
      spi_bitbang_stop may trigger NULL pointer dereference
      like this:
      
      BUG: KASAN: null-ptr-deref in __list_del_entry_valid+0x45/0xd0
      Read of size 8 at addr 0000000000000000 by task syz-executor.0/3661
      
      CPU: 0 PID: 3661 Comm: syz-executor.0 Not tainted 5.1.0+ #28
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      Call Trace:
       dump_stack+0xa9/0x10e
       ? __list_del_entry_valid+0x45/0xd0
       ? __list_del_entry_valid+0x45/0xd0
       __kasan_report+0x171/0x18d
       ? __list_del_entry_valid+0x45/0xd0
       kasan_report+0xe/0x20
       __list_del_entry_valid+0x45/0xd0
       spi_unregister_controller+0x99/0x1b0
       spi_lm70llp_attach+0x3ae/0x4b0 [spi_lm70llp]
       ? 0xffffffffc1128000
       ? klist_next+0x131/0x1e0
       ? driver_detach+0x40/0x40 [parport]
       port_check+0x3b/0x50 [parport]
       bus_for_each_dev+0x115/0x180
       ? subsys_dev_iter_exit+0x20/0x20
       __parport_register_driver+0x1f0/0x210 [parport]
       ? 0xffffffffc1150000
       do_one_initcall+0xb9/0x3b5
       ? perf_trace_initcall_level+0x270/0x270
       ? kasan_unpoison_shadow+0x30/0x40
       ? kasan_unpoison_shadow+0x30/0x40
       do_init_module+0xe0/0x330
       load_module+0x38eb/0x4270
       ? module_frob_arch_sections+0x20/0x20
       ? kernel_read_file+0x188/0x3f0
       ? find_held_lock+0x6d/0xd0
       ? fput_many+0x1a/0xe0
       ? __do_sys_finit_module+0x162/0x190
       __do_sys_finit_module+0x162/0x190
       ? __ia32_sys_init_module+0x40/0x40
       ? __mutex_unlock_slowpath+0xb4/0x3f0
       ? wait_for_completion+0x240/0x240
       ? vfs_write+0x160/0x2a0
       ? lockdep_hardirqs_off+0xb5/0x100
       ? mark_held_locks+0x1a/0x90
       ? do_syscall_64+0x14/0x2a0
       do_syscall_64+0x72/0x2a0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      Reported-by: 's avatarHulk Robot <hulkci@huawei.com>
      Fixes: 702a4879 ("spi: bitbang: Let spi_bitbang_start() take a reference to master")
      Signed-off-by: 's avatarYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: 's avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: 's avatarAxel Lin <axel.lin@ingics.com>
      Reviewed-by: 's avatarMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      05d6e618
    • Matt Flax's avatar
      ASoC : cs4265 : readable register too low · d4dcab62
      Matt Flax authored
      [ Upstream commit f3df05c805983427319eddc2411a2105ee1757cf ]
      
      The cs4265_readable_register function stopped short of the maximum
      register.
      
      An example bug is taken from :
      https://github.com/Audio-Injector/Ultra/issues/25
      
      Where alsactl store fails with :
      Cannot read control '2,0,0,C Data Buffer,0': Input/output error
      
      This patch fixes the bug by setting the cs4265 to have readable
      registers up to the maximum hardware register CS4265_MAX_REGISTER.
      Signed-off-by: 's avatarMatt Flax <flatmax@flatmax.org>
      Reviewed-by: 's avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      d4dcab62
    • Jason A. Donenfeld's avatar
      um: Compile with modern headers · 3c738429
      Jason A. Donenfeld authored
      commit 530ba6c7cb3c22435a4d26de47037bb6f86a5329 upstream.
      
      Recent libcs have gotten a bit more strict, so we actually need to
      include the right headers and use the right types. This enables UML to
      compile again.
      Signed-off-by: 's avatarJason A. Donenfeld <Jason@zx2c4.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: Richard Weinberger's avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: 's avatarAlessio Balsini <balsini@android.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c738429
    • Matias Karhumaa's avatar
      Bluetooth: Fix faulty expression for minimum encryption key size check · 993699d9
      Matias Karhumaa authored
      commit eca94432934fe5f141d084f2e36ee2c0e614cc04 upstream.
      
      Fix minimum encryption key size check so that HCI_MIN_ENC_KEY_SIZE is
      also allowed as stated in the comment.
      
      This bug caused connection problems with devices having maximum
      encryption key size of 7 octets (56-bit).
      
      Fixes: 693cd8ce3f88 ("Bluetooth: Fix regression with minimum encryption key size alignment")
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203997Signed-off-by: 's avatarMatias Karhumaa <matias.karhumaa@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      993699d9
    • Josh Elsasser's avatar
      net: check before dereferencing netdev_ops during busy poll · b3c963d5
      Josh Elsasser authored
      init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads
      to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi
      wireless adapter and checks napi->dev->netdev_ops->ndo_busy_poll.
      
      Avoid this by ensuring napi->dev->netdev_ops is valid before following
      the pointer, avoiding the following panic when busy polling on a dummy
      netdev:
      
        BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8
        IP: [<ffffffff817b4b72>] sk_busy_loop+0x92/0x2f0
        Call Trace:
         [<ffffffff815a3134>] ? uart_write_room+0x74/0xf0
         [<ffffffff817964a9>] sock_poll+0x99/0xa0
         [<ffffffff81223142>] do_sys_poll+0x2e2/0x520
         [<ffffffff8118d3fc>] ? get_page_from_freelist+0x3bc/0xa30
         [<ffffffff810ada22>] ? update_curr+0x62/0x140
         [<ffffffff811ea671>] ? __slab_free+0xa1/0x2a0
         [<ffffffff811ea671>] ? __slab_free+0xa1/0x2a0
         [<ffffffff8179dbb1>] ? skb_free_head+0x21/0x30
         [<ffffffff81221bd0>] ? poll_initwait+0x50/0x50
         [<ffffffff811eaa36>] ? kmem_cache_free+0x1c6/0x1e0
         [<ffffffff815a4884>] ? uart_write+0x124/0x1d0
         [<ffffffff810bd1cd>] ? remove_wait_queue+0x4d/0x60
         [<ffffffff810bd224>] ? __wake_up+0x44/0x50
         [<ffffffff81582731>] ? tty_write_unlock+0x31/0x40
         [<ffffffff8158c5c6>] ? tty_ldisc_deref+0x16/0x20
         [<ffffffff81584820>] ? tty_write+0x1e0/0x2f0
         [<ffffffff81587e50>] ? process_echoes+0x80/0x80
         [<ffffffff8120c17b>] ? __vfs_write+0x2b/0x130
         [<ffffffff8120d09a>] ? vfs_write+0x15a/0x1a0
         [<ffffffff81223455>] SyS_poll+0x75/0x100
         [<ffffffff819a6524>] entry_SYSCALL_64_fastpath+0x24/0xcf
      
      Commit 79e7fff4 ("net: remove support for per driver ndo_busy_poll()")
      indirectly fixed this upstream in linux-4.11 by removing the offending
      pointer usage. No other users of napi->dev touch its netdev_ops.
      
      Fixes: 8b80cda5 ("net: rename include/net/ll_poll.h to include/net/busy_poll.h") # 4.4.y
      Signed-off-by: 's avatarJosh Elsasser <jelsasser@appneta.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3c963d5
    • YueHaibing's avatar
      bonding: Always enable vlan tx offload · ec109e6a
      YueHaibing authored
      [ Upstream commit 30d8177e8ac776d89d387fad547af6a0f599210e ]
      
      We build vlan on top of bonding interface, which vlan offload
      is off, bond mode is 802.3ad (LACP) and xmit_hash_policy is
      BOND_XMIT_POLICY_ENCAP34.
      
      Because vlan tx offload is off, vlan tci is cleared and skb push
      the vlan header in validate_xmit_vlan() while sending from vlan
      devices. Then in bond_xmit_hash, __skb_flow_dissect() fails to
      get information from protocol headers encapsulated within vlan,
      because 'nhoff' is points to IP header, so bond hashing is based
      on layer 2 info, which fails to distribute packets across slaves.
      
      This patch always enable bonding's vlan tx offload, pass the vlan
      packets to the slave devices with vlan tci, let them to handle
      vlan implementation.
      
      Fixes: 278339a4 ("bonding: propogate vlan_features to bonding master")
      Suggested-by: 's avatarJiri Pirko <jiri@resnulli.us>
      Signed-off-by: 's avatarYueHaibing <yuehaibing@huawei.com>
      Acked-by: 's avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec109e6a
    • Stephen Suryaputra's avatar
      ipv4: Use return value of inet_iif() for __raw_v4_lookup in the while loop · 012e59ea
      Stephen Suryaputra authored
      [ Upstream commit 38c73529de13e1e10914de7030b659a2f8b01c3b ]
      
      In commit 19e4e768064a8 ("ipv4: Fix raw socket lookup for local
      traffic"), the dif argument to __raw_v4_lookup() is coming from the
      returned value of inet_iif() but the change was done only for the first
      lookup. Subsequent lookups in the while loop still use skb->dev->ifIndex.
      
      Fixes: 19e4e768064a8 ("ipv4: Fix raw socket lookup for local traffic")
      Signed-off-by: 's avatarStephen Suryaputra <ssuryaextr@gmail.com>
      Reviewed-by: 's avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      012e59ea
    • YueHaibing's avatar
      team: Always enable vlan tx offload · 8b4c9dfa
      YueHaibing authored
      [ Upstream commit ee4297420d56a0033a8593e80b33fcc93fda8509 ]
      
      We should rather have vlan_tci filled all the way down
      to the transmitting netdevice and let it do the hw/sw
      vlan implementation.
      Suggested-by: 's avatarJiri Pirko <jiri@resnulli.us>
      Signed-off-by: 's avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b4c9dfa
    • Xin Long's avatar
      tipc: check msg->req data len in tipc_nl_compat_bearer_disable · 36ad5e8b
      Xin Long authored
      [ Upstream commit 4f07b80c973348a99b5d2a32476a2e7877e94a05 ]
      
      This patch is to fix an uninit-value issue, reported by syzbot:
      
        BUG: KMSAN: uninit-value in memchr+0xce/0x110 lib/string.c:981
        Call Trace:
          __dump_stack lib/dump_stack.c:77 [inline]
          dump_stack+0x191/0x1f0 lib/dump_stack.c:113
          kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622
          __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310
          memchr+0xce/0x110 lib/string.c:981
          string_is_valid net/tipc/netlink_compat.c:176 [inline]
          tipc_nl_compat_bearer_disable+0x2a1/0x480 net/tipc/netlink_compat.c:449
          __tipc_nl_compat_doit net/tipc/netlink_compat.c:327 [inline]
          tipc_nl_compat_doit+0x3ac/0xb00 net/tipc/netlink_compat.c:360
          tipc_nl_compat_handle net/tipc/netlink_compat.c:1178 [inline]
          tipc_nl_compat_recv+0x1b1b/0x27b0 net/tipc/netlink_compat.c:1281
      
      TLV_GET_DATA_LEN() may return a negtive int value, which will be
      used as size_t (becoming a big unsigned long) passed into memchr,
      cause this issue.
      
      Similar to what it does in tipc_nl_compat_bearer_enable(), this
      fix is to return -EINVAL when TLV_GET_DATA_LEN() is negtive in
      tipc_nl_compat_bearer_disable(), as well as in
      tipc_nl_compat_link_stat_dump() and tipc_nl_compat_link_reset_stats().
      
      v1->v2:
        - add the missing Fixes tags per Eric's request.
      
      Fixes: 0762216c0ad2 ("tipc: fix uninit-value in tipc_nl_compat_bearer_enable")
      Fixes: 8b66fee7f8ee ("tipc: fix uninit-value in tipc_nl_compat_link_reset_stats")
      Reported-by: syzbot+30eaa8bf392f7fafffaf@syzkaller.appspotmail.com
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36ad5e8b
    • Xin Long's avatar
      tipc: change to use register_pernet_device · 253c7176
      Xin Long authored
      [ Upstream commit c492d4c74dd3f87559883ffa0f94a8f1ae3fe5f5 ]
      
      This patch is to fix a dst defcnt leak, which can be reproduced by doing:
      
        # ip net a c; ip net a s; modprobe tipc
        # ip net e s ip l a n eth1 type veth peer n eth1 netns c
        # ip net e c ip l s lo up; ip net e c ip l s eth1 up
        # ip net e s ip l s lo up; ip net e s ip l s eth1 up
        # ip net e c ip a a 1.1.1.2/8 dev eth1
        # ip net e s ip a a 1.1.1.1/8 dev eth1
        # ip net e c tipc b e m udp n u1 localip 1.1.1.2
        # ip net e s tipc b e m udp n u1 localip 1.1.1.1
        # ip net d c; ip net d s; rmmod tipc
      
      and it will get stuck and keep logging the error:
      
        unregister_netdevice: waiting for lo to become free. Usage count = 1
      
      The cause is that a dst is held by the udp sock's sk_rx_dst set on udp rx
      path with udp_early_demux == 1, and this dst (eventually holding lo dev)
      can't be released as bearer's removal in tipc pernet .exit happens after
      lo dev's removal, default_device pernet .exit.
      
       "There are two distinct types of pernet_operations recognized: subsys and
        device.  At creation all subsys init functions are called before device
        init functions, and at destruction all device exit functions are called
        before subsys exit function."
      
      So by calling register_pernet_device instead to register tipc_net_ops, the
      pernet .exit() will be invoked earlier than loopback dev's removal when a
      netns is being destroyed, as fou/gue does.
      
      Note that vxlan and geneve udp tunnels don't have this issue, as the udp
      sock is released in their device ndo_stop().
      
      This fix is also necessary for tipc dst_cache, which will hold dsts on tx
      path and I will introduce in my next patch.
      Reported-by: 's avatarLi Shuang <shuali@redhat.com>
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Acked-by: 's avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      253c7176
    • Xin Long's avatar
      sctp: change to hold sk after auth shkey is created successfully · 92598c5d
      Xin Long authored
      [ Upstream commit 25bff6d5478b2a02368097015b7d8eb727c87e16 ]
      
      Now in sctp_endpoint_init(), it holds the sk then creates auth
      shkey. But when the creation fails, it doesn't release the sk,
      which causes a sk defcnf leak,
      
      Here to fix it by only holding the sk when auth shkey is created
      successfully.
      
      Fixes: a29a5bd4 ("[SCTP]: Implement SCTP-AUTH initializations.")
      Reported-by: syzbot+afabda3890cc2f765041@syzkaller.appspotmail.com
      Reported-by: syzbot+276ca1c77a19977c0130@syzkaller.appspotmail.com
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Acked-by: 's avatarNeil Horman <nhorman@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      92598c5d