1. 20 Feb, 2019 40 commits
    • Hauke Mehrtens's avatar
      uapi/if_ether.h: move __UAPI_DEF_ETHHDR libc define · cb4f43bf
      Hauke Mehrtens authored
      commit da360299 upstream.
      This fixes a compile problem of some user space applications by not
      including linux/libc-compat.h in uapi/if_ether.h.
      linux/libc-compat.h checks which "features" the header files, included
      from the libc, provide to make the Linux kernel uapi header files only
      provide no conflicting structures and enums. If a user application mixes
      kernel headers and libc headers it could happen that linux/libc-compat.h
      gets included too early where not all other libc headers are included
      yet. Then the linux/libc-compat.h would not prevent all the
      redefinitions and we run into compile problems.
      This patch removes the include of linux/libc-compat.h from
      uapi/if_ether.h to fix the recently introduced case, but not all as this
      is more or less impossible.
      It is no problem to do the check directly in the if_ether.h file and not
      in libc-compat.h as this does not need any fancy glibc header detection
      as glibc never provided struct ethhdr and should define
      __UAPI_DEF_ETHHDR by them self when they will provide this.
      The following test program did not compile correctly any more:
      #include <linux/if_ether.h>
      #include <netinet/in.h>
      #include <linux/in.h>
      int main(void)
      	return 0;
      Fixes: 6926e041
       ("uapi/if_ether.h: prevent redefinition of struct ethhdr")
      Reported-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Cc: <stable@vger.kernel.org> # 4.15
      Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Christian Lamparter's avatar
      pinctrl: msm: fix gpio-hog related boot issues · d5800cff
      Christian Lamparter authored
      commit a86caa9ba5d70696ceb35d1d39caa20d8b641387 upstream.
      Sven Eckelmann reported an issue with the current IPQ4019 pinctrl.
      Setting up any gpio-hog in the device-tree for his device would
      "kill the bootup completely":
      | [    0.477838] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe
      | [    0.499828] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferring probe
      | [    1.298883] requesting hog GPIO enable USB2 power (chip 1000000.pinctrl, offset 58) failed, -517
      | [    1.299609] gpiochip_add_data: GPIOs 0..99 (1000000.pinctrl) failed to register
      | [    1.308589] ipq4019-pinctrl 1000000.pinctrl: Failed register gpiochip
      | [    1.316586] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe
      | [    1.322415] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferri
      This was also verified on a RT-AC58U (IPQ4018) which would
      no longer boot, if a gpio-hog was specified. (Tried forcing
      the USB LED PIN (GPIO0) to high.).
      The problem is that Pinctrl+GPIO registration is currently
      peformed in the following order in pinctrl-msm.c:
      	1. pinctrl_register()
      	2. gpiochip_add()
      	3. gpiochip_add_pin_range()
      The actual error code -517 == -EPROBE_DEFER is coming from
      pinctrl_get_device_gpio_range(), which is called through:
      pinctrl_get_device_gpio_range() is unable to find any valid
      pin ranges, since nothing has been added to the pinctrldev_list yet.
      so the range can't be found, and the operation fails with -EPROBE_DEFER.
      This patch fixes the issue by adding the "gpio-ranges" property to
      the pinctrl device node of all upstream Qcom SoC. The pin ranges are
      then added by the gpio core.
      In order to remain compatible with older, existing DTs (and ACPI)
      a check for the "gpio-ranges" property has been added to
      msm_gpio_init(). This prevents the driver of adding the same entry
      to the pinctrldev_list twice.
      Reported-by: default avatarSven Eckelmann <sven.eckelmann@openmesh.com>
      Tested-by: Sven Eckelmann <sven.eckelmann@openmesh.com> [ipq4019]
      Reviewed-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • John Youn's avatar
      usb: dwc2: Remove unnecessary kfree · a4af2252
      John Youn authored
      commit cd4b1e34
      This shouldn't be freed by the HCD as it is owned by the core and
      allocated with devm_kzalloc.
      Signed-off-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric Dumazet's avatar
      kaweth: use skb_cow_head() to deal with cloned skbs · 49cf68d7
      Eric Dumazet authored
      commit 39fba783
      We can use skb_cow_head() to properly deal with clones,
      especially the ones coming from TCP stack that allow their head being
      modified. This avoids a copy.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: James Hughes <james.hughes@raspberrypi.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric Dumazet's avatar
      ch9200: use skb_cow_head() to deal with cloned skbs · 4307a871
      Eric Dumazet authored
      commit 6bc6895b upstream.
      We need to ensure there is enough headroom to push extra header,
      but we also need to check if we are allowed to change headers.
      skb_cow_head() is the proper helper to deal with this.
      Fixes: 4a476bd6
       ("usbnet: New driver for QinHeng CH9200 devices")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: James Hughes <james.hughes@raspberrypi.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • James Hughes's avatar
      smsc95xx: Use skb_cow_head to deal with cloned skbs · f8e3d1b1
      James Hughes authored
      commit e9156cd2
      The driver was failing to check that the SKB wasn't cloned
      before adding checksum data.
      Replace existing handling to extend/copy the header buffer
      with skb_cow_head.
      Signed-off-by: default avatarJames Hughes <james.hughes@raspberrypi.org>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarWoojung Huh <Woojung.Huh@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Nikos Tsironis's avatar
      dm thin: fix bug where bio that overwrites thin block ignores FUA · 27a70770
      Nikos Tsironis authored
      commit 4ae280b4ee3463fa57bbe6eede26b97daff8a0f1 upstream.
      When provisioning a new data block for a virtual block, either because
      the block was previously unallocated or because we are breaking sharing,
      if the whole block of data is being overwritten the bio that triggered
      the provisioning is issued immediately, skipping copying or zeroing of
      the data block.
      When this bio completes the new mapping is inserted in to the pool's
      metadata by process_prepared_mapping(), where the bio completion is
      signaled to the upper layers.
      This completion is signaled without first committing the metadata.  If
      the bio in question has the REQ_FUA flag set and the system crashes
      right after its completion and before the next metadata commit, then the
      write is lost despite the REQ_FUA flag requiring that I/O completion for
      this request must only be signaled after the data has been committed to
      non-volatile storage.
      Fix this by deferring the completion of overwrite bios, with the REQ_FUA
      flag set, until after the metadata has been committed.
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNikos Tsironis <ntsironis@arrikto.com>
      Acked-by: default avatarJoe Thornber <ejt@redhat.com>
      Acked-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Borislav Petkov's avatar
      x86/a.out: Clear the dump structure initially · 5079b1d1
      Borislav Petkov authored
      commit 10970e1b4be9c74fce8ab6e3c34a7d718f063f2c upstream.
      dump_thread32() in aout_core_dump() does not clear the user32 structure
      allocated on the stack as the first thing on function entry.
      As a result, the dump.u_comm, dump.u_ar0 and dump.signal which get
      assigned before the clearing, get overwritten.
      Rename that function to fill_dump() to make it clear what it does and
      call it first thing.
      This was caught while staring at a patch by Derek Robson
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Derek Robson <robsonde@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Matz <matz@suse.de>
      Cc: x86@kernel.org
      Cc: <stable@vger.kernel.org>
      Link: https://lkml.kernel.org/r/20190202005512.3144-1-robsonde@gmail.com
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric W. Biederman's avatar
      signal: Restore the stop PTRACE_EVENT_EXIT · 492647b2
      Eric W. Biederman authored
      commit cf43a757fd49442bc38f76088b70c2299eed2c2f upstream.
      In the middle of do_exit() there is there is a call
      "ptrace_event(PTRACE_EVENT_EXIT, code);" That call places the process
      in TACKED_TRACED aka "(TASK_WAKEKILL | __TASK_TRACED)" and waits for
      for the debugger to release the task or SIGKILL to be delivered.
      Skipping past dequeue_signal when we know a fatal signal has already
      been delivered resulted in SIGKILL remaining pending and
      TIF_SIGPENDING remaining set.  This in turn caused the
      scheduler to not sleep in PTACE_EVENT_EXIT as it figured
      a fatal signal was pending.  This also caused ptrace_freeze_traced
      in ptrace_check_attach to fail because it left a per thread
      SIGKILL pending which is what fatal_signal_pending tests for.
      This difference in signal state caused strace to report
      strace: Exit of unknown pid NNNNN ignored
      Therefore update the signal handling state like dequeue_signal
      would when removing a per thread SIGKILL, by removing SIGKILL
      from the per thread signal mask and clearing TIF_SIGPENDING.
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Reported-by: default avatarOleg Nesterov <oleg@redhat.com>
      Reported-by: default avatarIvan Delalande <colona@arista.com>
      Cc: stable@vger.kernel.org
      Fixes: 35634ffa1751 ("signal: Always notice exiting tasks")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Hedi Berriche's avatar
      x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls · 7212e37c
      Hedi Berriche authored
      commit f331e766c4be33f4338574f3c9f7f77e98ab4571 upstream.
      Calls into UV firmware must be protected against concurrency, expose the
      efi_runtime_lock to the UV platform, and use it to serialise UV BIOS
      Signed-off-by: default avatarHedi Berriche <hedi.berriche@hpe.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarRuss Anderson <rja@hpe.com>
      Reviewed-by: default avatarDimitri Sivanich <sivanich@hpe.com>
      Reviewed-by: default avatarMike Travis <mike.travis@hpe.com>
      Cc: Andy Shevchenko <andy@infradead.org>
      Cc: Bhupesh Sharma <bhsharma@redhat.com>
      Cc: Darren Hart <dvhart@infradead.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: linux-efi <linux-efi@vger.kernel.org>
      Cc: platform-driver-x86@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.9+
      Cc: Steve Wahl <steve.wahl@hpe.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20190213193413.25560-5-hedi.berriche@hpe.com
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Andreas Ziegler's avatar
      tracing/uprobes: Fix output for multiple string arguments · 137f4db1
      Andreas Ziegler authored
      commit 0722069a5374b904ec1a67f91249f90e1cfae259 upstream.
      When printing multiple uprobe arguments as strings the output for the
      earlier arguments would also include all later string arguments.
      This is best explained in an example:
      Consider adding a uprobe to a function receiving two strings as
      parameters which is at offset 0xa0 in strlib.so and we want to print
      both parameters when the uprobe is hit (on x86_64):
      $ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
      When the function is called as func("foo", "bar") and we hit the probe,
      the trace file shows a line like the following:
        [...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"
      Note the extra "bar" printed as part of arg1. This behaviour stacks up
      for additional string arguments.
      The strings are stored in a dynamically growing part of the uprobe
      buffer by fetch_store_string() after copying them from userspace via
      strncpy_from_user(). The return value of strncpy_from_user() is then
      directly used as the required size for the string. However, this does
      not take the terminating null byte into account as the documentation
      for strncpy_from_user() cleary states that it "[...] returns the
      length of the string (not including the trailing NUL)" even though the
      null byte will be copied to the destination.
      Therefore, subsequent calls to fetch_store_string() will overwrite
      the terminating null byte of the most recently fetched string with
      the first character of the current string, leading to the
      "accumulation" of strings in earlier arguments in the output.
      Fix this by incrementing the return value of strncpy_from_user() by
      one if we did not hit the maximum buffer size.
      Link: http://lkml.kernel.org/r/20190116141629.5752-1-andreas.ziegler@fau.de
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: stable@vger.kernel.org
      Fixes: 5baaa59e
       ("tracing/probes: Implement 'memory' fetch method for uprobes")
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarAndreas Ziegler <andreas.ziegler@fau.de>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Meelis Roos's avatar
      alpha: Fix Eiger NR_IRQS to 128 · 5fc95186
      Meelis Roos authored
      commit bfc913682464f45bc4d6044084e370f9048de9d5 upstream.
      Eiger machine vector definition has nr_irqs 128, and working 2.6.26
      boot shows SCSI getting IRQ-s 64 and 65. Current kernel boot fails
      because Symbios SCSI fails to request IRQ-s and does not find the disks.
      It has been broken at least since 3.18 - the earliest I could test with
      my gcc-5.
      The headers have moved around and possibly another order of defines has
      worked in the past - but since 128 seems to be correct and used, fix
      arch/alpha/include/asm/irq.h to have NR_IRQS=128 for Eiger.
      This fixes 4.19-rc7 boot on my Force Flexor A264 (Eiger subarch).
      Cc: stable@vger.kernel.org # v3.18+
      Signed-off-by: default avatarMeelis Roos <mroos@linux.ee>
      Signed-off-by: default avatarMatt Turner <mattst88@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Sergei Trofimovich's avatar
      alpha: fix page fault handling for r16-r18 targets · 1d8b2030
      Sergei Trofimovich authored
      commit 491af60ffb848b59e82f7c9145833222e0bf27a5 upstream.
      Fix page fault handling code to fixup r16-r18 registers.
      Before the patch code had off-by-two registers bug.
      This bug caused overwriting of ps,pc,gp registers instead
      of fixing intended r16,r17,r18 (see `struct pt_regs`).
      More details:
      Initially Dmitry noticed a kernel bug as a failure
      on strace test suite. Test passes unmapped userspace
      pointer to io_submit:
          #include <err.h>
          #include <unistd.h>
          #include <sys/mman.h>
          #include <asm/unistd.h>
          int main(void)
              unsigned long ctx = 0;
              if (syscall(__NR_io_setup, 1, &ctx))
                  err(1, "io_setup");
              const size_t page_size = sysconf(_SC_PAGESIZE);
              const size_t size = page_size * 2;
              void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE,
                               MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
              if (MAP_FAILED == ptr)
                  err(1, "mmap(%zu)", size);
              if (munmap(ptr, size))
                  err(1, "munmap");
              syscall(__NR_io_submit, ctx, 1, ptr + page_size);
              syscall(__NR_io_destroy, ctx);
              return 0;
      Running this test causes kernel to crash when handling page fault:
          Unable to handle kernel paging request at virtual address ffffffffffff9468
          CPU 3
          aio(26027): Oops 0
          pc = [<fffffc00004eddf8>]  ra = [<fffffc00004edd5c>]  ps = 0000    Not tainted
          pc is at sys_io_submit+0x108/0x200
          ra is at sys_io_submit+0x6c/0x200
          v0 = fffffc00c58e6300  t0 = fffffffffffffff2  t1 = 000002000025e000
          t2 = fffffc01f159fef8  t3 = fffffc0001009640  t4 = fffffc0000e0f6e0
          t5 = 0000020001002e9e  t6 = 4c41564e49452031  t7 = fffffc01f159c000
          s0 = 0000000000000002  s1 = 000002000025e000  s2 = 0000000000000000
          s3 = 0000000000000000  s4 = 0000000000000000  s5 = fffffffffffffff2
          s6 = fffffc00c58e6300
          a0 = fffffc00c58e6300  a1 = 0000000000000000  a2 = 000002000025e000
          a3 = 00000200001ac260  a4 = 00000200001ac1e8  a5 = 0000000000000001
          t8 = 0000000000000008  t9 = 000000011f8bce30  t10= 00000200001ac440
          t11= 0000000000000000  pv = fffffc00006fd320  at = 0000000000000000
          gp = 0000000000000000  sp = 00000000265fd174
          Disabling lock debugging due to kernel taint
          [<fffffc0000311404>] entSys+0xa4/0xc0
      Here `gp` has invalid value. `gp is s overwritten by a fixup for the
      following page fault handler in `io_submit` syscall handler:
              ldq     a1,0(t1)
              bne     t0,4280 <__se_sys_io_submit+0x180>
      After a page fault `t0` should contain -EFALUT and `a1` is 0.
      Instead `gp` was overwritten in place of `a1`.
      This happens due to a off-by-two bug in `dpf_reg()` for `r16-r18`
      (aka `a0-a2`).
      I think the bug went unnoticed for a long time as `gp` is one
      of scratch registers. Any kernel function call would re-calculate `gp`.
      Dmitry tracked down the bug origin back to 2.1.32 kernel version
      where trap_a{0,1,2} fields were inserted into struct pt_regs.
      And even before that `dpf_reg()` contained off-by-one error.
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: linux-alpha@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Reported-and-reviewed-by: default avatar"Dmitry V. Levin" <ldv@altlinux.org>
      Cc: stable@vger.kernel.org # v2.1.32+
      Bug: https://bugs.gentoo.org/672040
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      Signed-off-by: default avatarMatt Turner <mattst88@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Matti Kurkela's avatar
      Input: elantech - enable 3rd button support on Fujitsu CELSIUS H780 · fd08513b
      Matti Kurkela authored
      commit e8b22d0a329f0fb5c7ef95406872d268f01ee3b1 upstream.
      Like Fujitsu CELSIUS H760, the H780 also has a three-button Elantech
      touchpad, but the driver needs to be told so to enable the middle touchpad
      The elantech_dmi_force_crc_enabled quirk was not necessary with the H780.
      Also document the fw_version and caps values detected for both H760 and
      H780 models.
      Signed-off-by: default avatarMatti Kurkela <Matti.Kurkela@iki.fi>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jonathan Bakker's avatar
      Input: bma150 - register input device after setting private data · 6d6d6255
      Jonathan Bakker authored
      commit 90cc55f067f6ca0e64e5e52883ece47d8af7b67b upstream.
      Otherwise we introduce a race condition where userspace can request input
      before we're ready leading to null pointer dereference such as
      input: bma150 as /devices/platform/i2c-gpio-2/i2c-5/5-0038/input/input3
      Unable to handle kernel NULL pointer dereference at virtual address 00000018
      pgd = (ptrval)
      [00000018] *pgd=55dac831, *pte=00000000, *ppte=00000000
      Internal error: Oops: 17 [#1] PREEMPT ARM
      Modules linked in: bma150 input_polldev [last unloaded: bma150]
      CPU: 0 PID: 2870 Comm: accelerometer Not tainted 5.0.0-rc3-dirty #46
      Hardware name: Samsung S5PC110/S5PV210-based board
      PC is at input_event+0x8/0x60
      LR is at bma150_report_xyz+0x9c/0xe0 [bma150]
      pc : [<80450f70>]    lr : [<7f0a614c>]    psr: 800d0013
      sp : a4c1fd78  ip : 00000081  fp : 00020000
      r10: 00000000  r9 : a5e2944c  r8 : a7455000
      r7 : 00000016  r6 : 00000101  r5 : a7617940  r4 : 80909048
      r3 : fffffff2  r2 : 00000000  r1 : 00000003  r0 : 00000000
      Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: 54e34019  DAC: 00000051
      Process accelerometer (pid: 2870, stack limit = 0x(ptrval))
      Stackck: (0xa4c1fd78 to 0xa4c20000)
      fd60:                                                       fffffff3 fc813f6c
      fd80: 40410581 d7530ce3 a5e2817c a7617f00 a5e29404 a5e2817c 00000000 7f008324
      fda0: a5e28000 8044f59c a5fdd9d0 a5e2945c a46a4a00 a5e29668 a7455000 80454f10
      fdc0: 80909048 a5e29668 a5fdd9d0 a46a4a00 806316d0 00000000 a46a4a00 801df5f0
      fde0: 00000000 d7530ce3 a4c1fec0 a46a4a00 00000000 a5fdd9d0 a46a4a08 801df53c
      fe00: 00000000 801d74bc a4c1fec0 00000000 a4c1ff70 00000000 a7038da8 00000000
      fe20: a46a4a00 801e91fc a411bbe0 801f2e88 00000004 00000000 80909048 00000041
      fe40: 00000000 00020000 00000000 dead4ead a6a88da0 00000000 ffffe000 806fcae8
      fe60: a4c1fec8 00000000 80909048 00000002 a5fdd9d0 a7660110 a411bab0 00000001
      fe80: dead4ead ffffffff ffffffff a4c1fe8c a4c1fe8c d7530ce3 20000013 80909048
      fea0: 80909048 a4c1ff70 00000001 fffff000 a4c1e000 00000005 00026038 801eabd8
      fec0: a7660110 a411bab0 b9394901 00000006 a696201b 76fb3000 00000000 a7039720
      fee0: a5fdd9d0 00000101 00000002 00000096 00000000 00000000 00000000 a4c1ff00
      ff00: a6b310f4 805cb174 a6b310f4 00000010 00000fe0 00000010 a4c1e000 d7530ce3
      ff20: 00000003 a5f41400 a5f41424 00000000 a6962000 00000000 00000003 00000002
      ff40: ffffff9c 000a0000 80909048 d7530ce3 a6962000 00000003 80909048 ffffff9c
      ff60: a6962000 801d890c 00000000 00000000 00020000 a7590000 00000004 00000100
      ff80: 00000001 d7530ce3 000288b8 00026320 000288b8 00000005 80101204 a4c1e000
      ffa0: 00000005 80101000 000288b8 00026320 000288b8 000a0000 00000000 00000000
      ffc0: 000288b8 00026320 000288b8 00000005 7eef3bac 000264e8 00028ad8 00026038
      ffe0: 00000005 7eef3300 76f76e91 76f78546 800d0030 000288b8 00000000 00000000
      [<80450f70>] (input_event) from [<a5e2817c>] (0xa5e2817c)
      Code: e1a08148 eaffffa8 e351001f 812fff1e (e590c018)
      ---[ end trace 1c691ee85f2ff243 ]---
      Signed-off-by: default avatarJonathan Bakker <xc-racer2@live.ca>
      Signed-off-by: default avatarPaweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Manuel Reinhardt's avatar
      ALSA: usb-audio: Fix implicit fb endpoint setup by quirk · 05268b5c
      Manuel Reinhardt authored
      commit 2bc16b9f3223d049b57202ee702fcb5b9b507019 upstream.
      The commit a60945fd ("ALSA: usb-audio: move implicit fb quirks to
      separate function") introduced an error in the handling of quirks for
      implicit feedback endpoints. This commit fixes this.
      If a quirk successfully sets up an implicit feedback endpoint, usb-audio
      no longer tries to find the implicit fb endpoint itself.
      Fixes: a60945fd
       ("ALSA: usb-audio: move implicit fb quirks to separate function")
      Signed-off-by: default avatarManuel Reinhardt <manuel.rhdt@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jurica Vukadin's avatar
      ALSA: hda - Add quirk for HP EliteBook 840 G5 · 422e1adf
      Jurica Vukadin authored
      commit 4cd3016ce996494f78fdfd87ea35c8ca5d0b413e upstream.
      This enables mute LED support and fixes switching jacks when the laptop
      is docked.
      Signed-off-by: default avatarJurica Vukadin <jurica.vukadin@rt-rk.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Ingo Molnar's avatar
      perf/core: Fix impossible ring-buffer sizes warning · 222b22e1
      Ingo Molnar authored
      commit 528871b456026e6127d95b1b2bd8e3a003dc1614 upstream.
      The following commit:
        9dff0aa95a32 ("perf/core: Don't WARN() for impossible ring-buffer sizes")
      results in perf recording failures with larger mmap areas:
        root@skl:/tmp# perf record -g -a
        failed to mmap with 12 (Cannot allocate memory)
      The root cause is that the following condition is buggy:
      	if (order_base_2(size) >= MAX_ORDER)
      		goto fail;
      The problem is that @size is in bytes and MAX_ORDER is in pages,
      so the right test is:
      	if (order_base_2(size) >= PAGE_SHIFT+MAX_ORDER)
      		goto fail;
      Fix it.
      Reported-by: default avatar"Jin, Yao" <yao.jin@linux.intel.com>
      Bisected-by: default avatarBorislav Petkov <bp@alien8.de>
      Analyzed-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Julien Thierry <julien.thierry@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: <stable@vger.kernel.org>
      Fixes: 9dff0aa95a32 ("perf/core: Don't WARN() for impossible ring-buffer sizes")
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mauro Ciancio's avatar
      Input: elan_i2c - add ACPI ID for touchpad in Lenovo V330-15ISK · b7febf3b
      Mauro Ciancio authored
      commit 7ad222b3aed350adfc27ee7eec4587ffe55dfdce upstream.
      This adds ELAN0617 to the ACPI table to support Elan touchpad found in
      Lenovo V330-15ISK.
      Signed-off-by: default avatarMauro Ciancio <mauro@acadeu.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dmitry Torokhov's avatar
      Revert "Input: elan_i2c - add ACPI ID for touchpad in ASUS Aspire F5-573G" · d347a894
      Dmitry Torokhov authored
      commit f420c54e4b12c1361c6ed313002ee7bd7ac58362 upstream.
      This reverts commit 7db54c89f0b30a101584e09d3729144e6170059d as it
      breaks Acer Aspire V-371 and other devices. According to Elan:
      "Acer Aspire F5-573G is MS Precision touchpad which should use hid
       multitouch driver. ELAN0501 should not be added in elan_i2c."
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202503
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mark Rustad's avatar
      Documentation/network: reword kernel version reference · 29c84aa9
      Mark Rustad authored
      It seemed odd to say "since 4.17" in a 4.4 kernel. Consider
      rewording the reference to indicate where in the stable series
      it was introduced as well as where it originated.
      Signed-off-by: default avatarMark Rustad <mrustad@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Ross Lagerwall's avatar
      cifs: Limit memory used by lock request calls to a page · 1f39e518
      Ross Lagerwall authored
      [ Upstream commit 92a8109e4d3a34fb6b115c9098b51767dc933444 ]
      The code tries to allocate a contiguous buffer with a size supplied by
      the server (maxBuf). This could fail if memory is fragmented since it
      results in high order allocations for commonly used server
      implementations. It is also wasteful since there are probably
      few locks in the usual case. Limit the buffer to be no larger than a
      page to avoid memory allocation failures due to fragmentation.
      Signed-off-by: default avatarRoss Lagerwall <ross.lagerwall@citrix.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Nicholas Mc Guire's avatar
      gpio: pl061: handle failed allocations · 83476701
      Nicholas Mc Guire authored
      [ Upstream commit df209c43a0e8258e096fb722dfbdae4f0dd13fde ]
      devm_kzalloc(), devm_kstrdup() and devm_kasprintf() all can
      fail internal allocation and return NULL. Using any of the assigned
      objects without checking is not safe. As this is early in the boot
      phase and these allocations really should not fail, any failure here
      is probably an indication of a more serious issue so it makes little
      sense to try and rollback the previous allocated resources or try to
      continue;  but rather the probe function is simply exited with -ENOMEM.
      Signed-off-by: default avatarNicholas Mc Guire <hofrat@osadl.org>
      Fixes: 684284b6
       ("ARM: integrator: add MMCI device to IM-PD1")
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Linus Walleij's avatar
      ARM: dts: kirkwood: Fix polarity of GPIO fan lines · 32f04710
      Linus Walleij authored
      [ Upstream commit b5f034845e70916fd33e172fad5ad530a29c10ab ]
      These two lines are active high, not active low. The bug was
      found when we changed the kernel to respect the polarity defined
      in the device tree.
      Fixes: 1b90e06b
       ("ARM: kirkwood: Use devicetree to define DNS-32[05] fan")
      Cc: Jamie Lentin <jm@lentin.co.uk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Gregory Clement <gregory.clement@bootlin.com>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: Julien D'Ascenzio <jdascenzio@posteo.net>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Tested-by: default avatarJamie Lentin <jm@lentin.co.uk>
      Reported-by: default avatarJulien D'Ascenzio <jdascenzio@posteo.net>
      Tested-by: default avatarJulien D'Ascenzio <jdascenzio@posteo.net>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@bootlin.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Peter Ujfalusi's avatar
      ARM: dts: da850-evm: Correct the sound card name · 20ad5046
      Peter Ujfalusi authored
      [ Upstream commit 7fca69d4e43fa1ae9cb4f652772c132dc5a659c6 ]
      To avoid  the following error:
      asoc-simple-card sound: ASoC: Failed to create card debugfs directory
      Which is because the card name contains '/' character, which can not be
      used in file or directory names.
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Hauke Mehrtens's avatar
      uapi/if_ether.h: prevent redefinition of struct ethhdr · 28b5d0be
      Hauke Mehrtens authored
      commit 6926e041
      Musl provides its own ethhdr struct definition. Add a guard to prevent
      its definition of the appropriate musl header has already been included.
      glibc does not implement this header, but when glibc will implement this
      they can just define __UAPI_DEF_ETHHDR 0 to make it work with the
      Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Linus Torvalds's avatar
      Revert "exec: load_script: don't blindly truncate shebang string" · 7cbbbf75
      Linus Torvalds authored
      commit cb5b020a8d38f77209d0472a0fea755299a8ec78 upstream.
      This reverts commit 8099b047ecc431518b9bb6bdbba3549bbecdc343.
      It turns out that people do actually depend on the shebang string being
      truncated, and on the fact that an interpreter (like perl) will often
      just re-interpret it entirely to get the full argument list.
      Reported-by: default avatarSamuel Dionne-Riel <samuel@dionne-riel.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Sven Eckelmann's avatar
      batman-adv: Force mac header to start of data on xmit · b2942d59
      Sven Eckelmann authored
      commit 9114daa825fc3f335f9bea3313ce667090187280 upstream.
      The caller of ndo_start_xmit may not already have called
      skb_reset_mac_header. The returned value of skb_mac_header/eth_hdr
      therefore can be in the wrong position and even outside the current skbuff.
      This for example happens when the user binds to the device using a
      PF_PACKET-SOCK_RAW with enabled qdisc-bypass:
        int opt = 4;
        setsockopt(sock, SOL_PACKET, PACKET_QDISC_BYPASS, &opt, sizeof(opt));
      Since eth_hdr is used all over the codebase, the batadv_interface_tx
      function must always take care of resetting it.
      Fixes: c6c8fea2
       ("net: Add batman-adv meshing protocol")
      Reported-by: syzbot+9d7405c7faa390e60b4e@syzkaller.appspotmail.com
      Reported-by: syzbot+7d20bc3f1ddddc0f9079@syzkaller.appspotmail.com
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Sven Eckelmann's avatar
      batman-adv: Avoid WARN on net_device without parent in netns · 8fe16146
      Sven Eckelmann authored
      commit 955d3411a17f590364238bd0d3329b61f20c1cd2 upstream.
      It is not allowed to use WARN* helpers on potential incorrect input from
      the user or transient problems because systems configured as panic_on_warn
      will reboot due to such a problem.
      A NULL return value of __dev_get_by_index can be caused by various problems
      which can either be related to the system configuration or problems
      (incorrectly returned network namespaces) in other (virtual) net_device
      drivers. batman-adv should not cause a (harmful) WARN in this situation and
      instead only report it via a simple message.
      Fixes: b7eddd0b
       ("batman-adv: prevent using any virtual device created on batman-adv as hard-interface")
      Reported-by: syzbot+c764de0fcfadca9a8595@syzkaller.appspotmail.com
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Florian Westphal's avatar
      xfrm: refine validation of template and selector families · ca6fd8df
      Florian Westphal authored
      commit 35e6103861a3a970de6c84688c6e7a1f65b164ca upstream.
      The check assumes that in transport mode, the first templates family
      must match the address family of the policy selector.
      Syzkaller managed to build a template using MODE_ROUTEOPTIMIZATION,
      with ipv4-in-ipv6 chain, leading to following splat:
      BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x1db/0x1854
      Read of size 4 at addr ffff888063e57aa0 by task a.out/2050
       xfrm_resolve_and_create_bundle+0x108/0x1000 [..]
      Problem is that addresses point into flowi4 struct, but xfrm_state_find
      treats them as being ipv6 because it uses templ->encap_family is used
      (AF_INET6 in case of reproducer) rather than family (AF_INET).
      This patch inverts the logic: Enforce 'template family must match
      selector' EXCEPT for tunnel and BEET mode.
      In BEET and Tunnel mode, xfrm_tmpl_resolve_one will have remote/local
      address pointers changed to point at the addresses found in the template,
      rather than the flowi ones, so no oob read will occur.
      Reported-by: 3ntr0py1337@gmail.com
      Reported-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Ilya Dryomov's avatar
      libceph: avoid KEEPALIVE_PENDING races in ceph_con_keepalive() · 2e9e4e15
      Ilya Dryomov authored
      commit 4aac9228d16458cedcfd90c7fb37211cf3653ac3 upstream.
      con_fault() can transition the connection into STANDBY right after
      ceph_con_keepalive() clears STANDBY in clear_standby():
          libceph user thread               ceph-msgr worker
                                        if KEEPALIVE_PENDING isn't set
                                          set state to STANDBY
        set WRITE_PENDING
      This triggers warnings in clear_standby() when either ceph_con_send()
      or ceph_con_keepalive() get to clearing STANDBY next time.
      I don't see a reason to condition queue_con() call on the previous
      value of KEEPALIVE_PENDING, so move the setting of KEEPALIVE_PENDING
      into the critical section -- unlike WRITE_PENDING, KEEPALIVE_PENDING
      could have been a non-atomic flag.
      Reported-by: syzbot+acdeb633f6211ccdf886@syzkaller.appspotmail.com
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Tested-by: default avatarMyungho Jung <mhjungk@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Greg Kroah-Hartman's avatar
      Revert "cifs: In Kconfig CONFIG_CIFS_POSIX needs depends on legacy (insecure cifs)" · 1793dc65
      Greg Kroah-Hartman authored
      This reverts commit 60da90b2 which is
      commit 6e785302dad32228819d8066e5376acd15d0e6ba upstream.
      Yi writes:
      	I notice that 4.4.169 merged 60da90b2
       ("cifs: In Kconfig
      	CONFIG_CIFS_POSIX needs depends on legacy (insecure cifs)") add
      	a Kconfig dependency CIFS_ALLOW_INSECURE_LEGACY, which was not
      	defined in 4.4 stable, so after this patch we are not able to
      	enable CIFS_POSIX anymore. Linux 4.4 stable didn't merge the
      	legacy dialects codes, so do we really need this patch for 4.4?
      So revert this patch.
      Reported-by: default avatar"zhangyi (F)" <yi.zhang@huawei.com>
      Cc: Steve French <stfrench@microsoft.com>
      Cc: Pavel Shilovsky <pshilov@microsoft.com>
      Cc: Sasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Guenter Roeck's avatar
      NFC: nxp-nci: Include unaligned.h instead of access_ok.h · 2a41ed30
      Guenter Roeck authored
      commit 2eee74b7
      Directly including access_ok.h can result in the following compile errors
      if an architecture such as ia64 does not support direct unaligned accesses.
      include/linux/unaligned/access_ok.h:7:19: error:
      	redefinition of 'get_unaligned_le16'
      include/linux/unaligned/le_struct.h:6:19: note:
      	previous definition of 'get_unaligned_le16' was here
      include/linux/unaligned/access_ok.h:12:19: error:
      	redefinition of 'get_unaligned_le32'
      include/linux/unaligned/le_struct.h:11:19: note:
      	previous definition of 'get_unaligned_le32' was here
      Include asm/unaligned.h instead and let the architecture decide which
      access functions to use.
      Cc: Clément Perrochaud <clement.perrochaud@effinnov.com>
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      Cc: Matthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vladis Dronov's avatar
      HID: debug: fix the ring buffer implementation · b661fff5
      Vladis Dronov authored
      commit 13054abbaa4f1fd4e6f3b4b63439ec033b4c8035 upstream.
      Ring buffer implementation in hid_debug_event() and hid_debug_events_read()
      is strange allowing lost or corrupted data. After commit 717adfdaf147
      ("HID: debug: check length before copy_to_user()") it is possible to enter
      an infinite loop in hid_debug_events_read() by providing 0 as count, this
      locks up a system. Fix this by rewriting the ring buffer implementation
      with kfifo and simplify the code.
      This fixes CVE-2019-3819.
      v2: fix an execution logic and add a comment
      v3: use __set_current_state() instead of set_current_state()
      Backport to v4.4: some (tree-wide) patches are missing in v4.4 so
      cherry-pick relevant pieces from:
       * 6396bb22151 ("treewide: kzalloc() -> kcalloc()")
       * a9a08845 ("vfs: do bulk POLL* -> EPOLL* replacement")
       * 92529623 ("HID: debug: improve hid_debug_event()")
       * 174cd4b1 ("sched/headers: Prepare to move signal wakeup & sigpending
         methods from <linux/sched.h> into <linux/sched/signal.h>")
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=1669187
      Cc: stable@vger.kernel.org # v4.18+
      Fixes: cd667ce2
       ("HID: use debugfs for events/reports dumping")
      Fixes: 717adfdaf147 ("HID: debug: check length before copy_to_user()")
      Signed-off-by: default avatarVladis Dronov <vdronov@redhat.com>
      Reviewed-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Thomas Hellstrom's avatar
      drm/vmwgfx: Return error code from vmw_execbuf_copy_fence_user · 697c6f72
      Thomas Hellstrom authored
      commit 728354c005c36eaf44b6e5552372b67e60d17f56 upstream.
      The function was unconditionally returning 0, and a caller would have to
      rely on the returned fence pointer being NULL to detect errors. However,
      the function vmw_execbuf_copy_fence_user() would expect a non-zero error
      code in that case and would BUG otherwise.
      So make sure we return a proper non-zero error code if the fence pointer
      returned is NULL.
      Cc: <stable@vger.kernel.org>
      Fixes: ae2a1040
      : ("vmwgfx: Implement fence objects")
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: default avatarDeepak Rawat <drawat@vmware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Thomas Hellstrom's avatar
      drm/vmwgfx: Fix setting of dma masks · 6bcca0bc
      Thomas Hellstrom authored
      commit 4cbfa1e6c09e98450aab3240e5119b0ab2c9795b upstream.
      Previously we set only the dma mask and not the coherent mask. Fix that.
      Also, for clarity, make sure both are initially set to 64 bits.
      Cc: <stable@vger.kernel.org>
      Fixes: 0d00c488
      : ("drm/vmwgfx: Fix the driver for large dma addresses")
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: default avatarDeepak Rawat <drawat@vmware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Tina Zhang's avatar
      drm/modes: Prevent division by zero htotal · f1cd557e
      Tina Zhang authored
      commit a2fcd5c84f7a7825e028381b10182439067aa90d upstream.
      This patch prevents division by zero htotal.
      In a follow-up mail Tina writes:
      > > How did you manage to get here with htotal == 0? This needs backtraces (or if
      > > this is just about static checkers, a mention of that).
      > > -Daniel
      > In GVT-g, we are trying to enable a virtual display w/o setting timings for a pipe
      > (a.k.a htotal=0), then we met the following kernel panic:
      > [   32.832048] divide error: 0000 [#1] SMP PTI
      > [   32.833614] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc4-sriov+ #33
      > [   32.834438] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-dirty-20180511_165818-tinazhang-linux-1 04/01/2014
      > [   32.835901] RIP: 0010:drm_mode_hsync+0x1e/0x40
      > [   32.836004] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
      > [   32.836004] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
      > [   32.836004] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
      > [   32.836004] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
      > [   32.836004] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
      > [   32.836004] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
      > [   32.836004] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
      > [   32.836004] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
      > [   32.836004] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      > [   32.836004] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
      > [   32.836004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > [   32.836004] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      > [   32.836004] Call Trace:
      > [   32.836004]  intel_mode_from_pipe_config+0x72/0x90
      > [   32.836004]  intel_modeset_setup_hw_state+0x569/0xf90
      > [   32.836004]  intel_modeset_init+0x905/0x1db0
      > [   32.836004]  i915_driver_load+0xb8c/0x1120
      > [   32.836004]  i915_pci_probe+0x4d/0xb0
      > [   32.836004]  local_pci_probe+0x44/0xa0
      > [   32.836004]  ? pci_assign_irq+0x27/0x130
      > [   32.836004]  pci_device_probe+0x102/0x1c0
      > [   32.836004]  driver_probe_device+0x2b8/0x480
      > [   32.836004]  __driver_attach+0x109/0x110
      > [   32.836004]  ? driver_probe_device+0x480/0x480
      > [   32.836004]  bus_for_each_dev+0x67/0xc0
      > [   32.836004]  ? klist_add_tail+0x3b/0x70
      > [   32.836004]  bus_add_driver+0x1e8/0x260
      > [   32.836004]  driver_register+0x5b/0xe0
      > [   32.836004]  ? mipi_dsi_bus_init+0x11/0x11
      > [   32.836004]  do_one_initcall+0x4d/0x1eb
      > [   32.836004]  kernel_init_freeable+0x197/0x237
      > [   32.836004]  ? rest_init+0xd0/0xd0
      > [   32.836004]  kernel_init+0xa/0x110
      > [   32.836004]  ret_from_fork+0x35/0x40
      > [   32.836004] Modules linked in:
      > [   32.859183] ---[ end trace 525608b0ed0e8665 ]---
      > [   32.859722] RIP: 0010:drm_mode_hsync+0x1e/0x40
      > [   32.860287] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
      > [   32.862680] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
      > [   32.863309] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
      > [   32.864182] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
      > [   32.865206] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
      > [   32.866359] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
      > [   32.867213] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
      > [   32.868075] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
      > [   32.868983] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      > [   32.869659] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
      > [   32.870599] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > [   32.871598] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      > [   32.872549] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      > Since drm_mode_hsync() has the logic to check mode->htotal, I just extend it to cover the case htotal==0.
      Signed-off-by: default avatarTina Zhang <tina.zhang@intel.com>
      Cc: Adam Jackson <ajax@redhat.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      [danvet: Add additional explanations + cc: stable.]
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/1548228539-3061-1-git-send-email-tina.zhang@intel.com
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Felix Fietkau's avatar
      mac80211: ensure that mgmt tx skbs have tailroom for encryption · 06288a8e
      Felix Fietkau authored
      commit 9d0f50b80222dc273e67e4e14410fcfa4130a90c upstream.
      Some drivers use IEEE80211_KEY_FLAG_SW_MGMT_TX to indicate that management
      frames need to be software encrypted. Since normal data packets are still
      encrypted by the hardware, crypto_tx_tailroom_needed_cnt gets decremented
      after key upload to hw. This can lead to passing skbs to ccmp_encrypt_skb,
      which don't have the necessary tailroom for software encryption.
      Change the code to add tailroom for encrypted management packets, even if
      crypto_tx_tailroom_needed_cnt is 0.
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Russell King's avatar
      ARM: iop32x/n2100: fix PCI IRQ mapping · fd9d0553
      Russell King authored
      commit db4090920ba2d61a5827a23e441447926a02ffee upstream.
      Booting 4.20 on a TheCUS N2100 results in a kernel oops while probing
      PCI, due to n2100_pci_map_irq() having been discarded during boot.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Cc: stable@vger.kernel.org # 2.6.18+
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Paul Burton's avatar
      MIPS: VDSO: Include $(ccflags-vdso) in o32,n32 .lds builds · dfb35362
      Paul Burton authored
      commit 67fc5dc8a541e8f458d7f08bf88ff55933bf9f9d upstream.
      When generating vdso-o32.lds & vdso-n32.lds for use with programs
      running as compat ABIs under 64b kernels, we previously haven't included
      the compiler flags that are supposedly common to all ABIs - ie. those in
      the ccflags-vdso variable.
      This is problematic in cases where we need to provide the -m%-float flag
      in order to ensure that we don't attempt to use a floating point ABI
      that's incompatible with the target CPU & ABI. For example a toolchain
      using current gcc trunk configured --with-fp-32=xx fails to build a
      64r6el_defconfig kernel with the following error:
        cc1: error: '-march=mips1' requires '-mfp32'
        make[2]: *** [arch/mips/vdso/Makefile:135: arch/mips/vdso/vdso-o32.lds] Error 1
      Include $(ccflags-vdso) for the compat VDSO .lds builds, just as it is
      included for the native VDSO .lds & when compiling objects for the
      compat VDSOs. This ensures we consistently provide the -msoft-float flag
      amongst others, avoiding the problem by ensuring we're agnostic to the
      toolchain defaults.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: ebb5e78c
       ("MIPS: Initial implementation of a VDSO")
      Cc: linux-mips@vger.kernel.org
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Maciej W . Rozycki <macro@linux-mips.org>
      Cc: stable@vger.kernel.org # v4.4+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>