1. 25 May, 2017 40 commits
    • Kristian Evensen's avatar
      net: qmi_wwan: Add SIMCom 7230E · 0aa3b8ef
      Kristian Evensen authored
      commit 18715b26 upstream.
      
      SIMCom 7230E is a QMI LTE module with support for most "normal" bands.
      Manual testing has showed that only interface five works.
      
      Cc: Bjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarKristian Evensen <kristian.evensen@gmail.com>
      Acked-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0aa3b8ef
    • Dan Carpenter's avatar
      ext4 crypto: fix some error handling · 22823e95
      Dan Carpenter authored
      commit 4762cc3f upstream.
      
      We should be testing for -ENOMEM but the minus sign is missing.
      
      Fixes: c9af28fd ('ext4 crypto: don't let data integrity writebacks fail with ENOMEM')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22823e95
    • Theodore Ts'o's avatar
      ext4 crypto: don't let data integrity writebacks fail with ENOMEM · 0a76f023
      Theodore Ts'o authored
      commit c9af28fd upstream.
      
      We don't want the writeback triggered from the journal commit (in
      data=writeback mode) to cause the journal to abort due to
      generic_writepages() returning an ENOMEM error.  In addition, if
      fsync() fails with ENOMEM, most applications will probably not do the
      right thing.
      
      So if we are doing a data integrity sync, and ext4_encrypt() returns
      ENOMEM, we will submit any queued I/O to date, and then retry the
      allocation using GFP_NOFAIL.
      
      Google-Bug-Id: 27641567
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0a76f023
    • Andrey Korolyov's avatar
      USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs · f0486aa7
      Andrey Korolyov authored
      commit 5f63424a upstream.
      
      This patch adds support for recognition of ARM-USB-TINY(H) devices which
      are almost identical to ARM-USB-OCD(H) but lacking separate barrel jack
      and serial console.
      
      By suggestion from Johan Hovold it is possible to replace
      ftdi_jtag_quirk with a bit more generic construction. Since all
      Olimex-ARM debuggers has exactly two ports, we could safely always use
      only second port within the debugger family.
      Signed-off-by: default avatarAndrey Korolyov <andrey@xdel.ru>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0486aa7
    • Anthony Mallet's avatar
      USB: serial: ftdi_sio: fix setting latency for unprivileged users · 16ac61cf
      Anthony Mallet authored
      commit bb246681 upstream.
      
      Commit 557aaa7f ("ft232: support the ASYNC_LOW_LATENCY
      flag") enables unprivileged users to set the FTDI latency timer,
      but there was a logic flaw that skipped sending the corresponding
      USB control message to the device.
      
      Specifically, the device latency timer would not be updated until next
      open, something which was later also inadvertently broken by commit
      c19db4c9 ("USB: ftdi_sio: set device latency timeout at port
      probe").
      
      A recent commit c6dce262 ("USB: serial: ftdi_sio: fix extreme
      low-latency setting") disabled the low-latency mode by default so we now
      need this fix to allow unprivileged users to again enable it.
      Signed-off-by: default avatarAnthony Mallet <anthony.mallet@laas.fr>
      [johan: amend commit message]
      Fixes: 557aaa7f ("ft232: support the ASYNC_LOW_LATENCY flag")
      Fixes: c19db4c9 ("USB: ftdi_sio: set device latency timeout at port probe").
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16ac61cf
    • Kirill Tkhai's avatar
      pid_ns: Fix race between setns'ed fork() and zap_pid_ns_processes() · 6a70a583
      Kirill Tkhai authored
      commit 3fd37226 upstream.
      
      Imagine we have a pid namespace and a task from its parent's pid_ns,
      which made setns() to the pid namespace. The task is doing fork(),
      while the pid namespace's child reaper is dying. We have the race
      between them:
      
      Task from parent pid_ns             Child reaper
      copy_process()                      ..
        alloc_pid()                       ..
        ..                                zap_pid_ns_processes()
        ..                                  disable_pid_allocation()
        ..                                  read_lock(&tasklist_lock)
        ..                                  iterate over pids in pid_ns
        ..                                    kill tasks linked to pids
        ..                                  read_unlock(&tasklist_lock)
        write_lock_irq(&tasklist_lock);   ..
        attach_pid(p, PIDTYPE_PID);       ..
        ..                                ..
      
      So, just created task p won't receive SIGKILL signal,
      and the pid namespace will be in contradictory state.
      Only manual kill will help there, but does the userspace
      care about this? I suppose, the most users just inject
      a task into a pid namespace and wait a SIGCHLD from it.
      
      The patch fixes the problem. It simply checks for
      (pid_ns->nr_hashed & PIDNS_HASH_ADDING) in copy_process().
      We do it under the tasklist_lock, and can't skip
      PIDNS_HASH_ADDING as noted by Oleg:
      
      "zap_pid_ns_processes() does disable_pid_allocation()
      and then takes tasklist_lock to kill the whole namespace.
      Given that copy_process() checks PIDNS_HASH_ADDING
      under write_lock(tasklist) they can't race;
      if copy_process() takes this lock first, the new child will
      be killed, otherwise copy_process() can't miss
      the change in ->nr_hashed."
      
      If allocation is disabled, we just return -ENOMEM
      like it's made for such cases in alloc_pid().
      
      v2: Do not move disable_pid_allocation(), do not
      introduce a new variable in copy_process() and simplify
      the patch as suggested by Oleg Nesterov.
      Account the problem with double irq enabling
      found by Eric W. Biederman.
      
      Fixes: c876ad76 ("pidns: Stop pid allocation when init dies")
      Signed-off-by: default avatarKirill Tkhai <ktkhai@virtuozzo.com>
      CC: Andrew Morton <akpm@linux-foundation.org>
      CC: Ingo Molnar <mingo@kernel.org>
      CC: Peter Zijlstra <peterz@infradead.org>
      CC: Oleg Nesterov <oleg@redhat.com>
      CC: Mike Rapoport <rppt@linux.vnet.ibm.com>
      CC: Michal Hocko <mhocko@suse.com>
      CC: Andy Lutomirski <luto@kernel.org>
      CC: "Eric W. Biederman" <ebiederm@xmission.com>
      CC: Andrei Vagin <avagin@openvz.org>
      CC: Cyrill Gorcunov <gorcunov@openvz.org>
      CC: Serge Hallyn <serge@hallyn.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a70a583
    • Eric W. Biederman's avatar
      pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes · ddf9b92f
      Eric W. Biederman authored
      commit b9a985db upstream.
      
      The code can potentially sleep for an indefinite amount of time in
      zap_pid_ns_processes triggering the hung task timeout, and increasing
      the system average.  This is undesirable.  Sleep with a task state of
      TASK_INTERRUPTIBLE instead of TASK_UNINTERRUPTIBLE to remove these
      undesirable side effects.
      
      Apparently under heavy load this has been allowing Chrome to trigger
      the hung time task timeout error and cause ChromeOS to reboot.
      Reported-by: default avatarVovo Yang <vovoy@google.com>
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Fixes: 6347e900 ("pidns: guarantee that the pidns init will be the last pidns process reaped")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ddf9b92f
    • Pavel Roskin's avatar
      iio: dac: ad7303: fix channel description · 060d2642
      Pavel Roskin authored
      commit ce420fd4 upstream.
      
      realbits, storagebits and shift should be numbers, not ASCII characters.
      Signed-off-by: default avatarPavel Roskin <plroskin@gmail.com>
      Reviewed-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      060d2642
    • Rob Herring's avatar
      of: fix sparse warning in of_pci_range_parser_one · 14323b73
      Rob Herring authored
      commit eb310036 upstream.
      
      sparse gives the following warning for 'pci_space':
      
      ../drivers/of/address.c:266:26: warning: incorrect type in assignment (different base types)
      ../drivers/of/address.c:266:26:    expected unsigned int [unsigned] [usertype] pci_space
      ../drivers/of/address.c:266:26:    got restricted __be32 const [usertype] <noident>
      
      It appears that pci_space is only ever accessed on powerpc, so the endian
      swap is often not needed.
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      14323b73
    • Takashi Iwai's avatar
      proc: Fix unbalanced hard link numbers · 00095931
      Takashi Iwai authored
      commit d66bb160 upstream.
      
      proc_create_mount_point() forgot to increase the parent's nlink, and
      it resulted in unbalanced hard link numbers, e.g. /proc/fs shows one
      less than expected.
      
      Fixes: eb6d38d5 ("proc: Allow creating permanently empty directories...")
      Reported-by: default avatarTristan Ye <tristan.ye@suse.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      00095931
    • Tobias Herzog's avatar
      cdc-acm: fix possible invalid access when processing notification · d22b933f
      Tobias Herzog authored
      commit 1bb9914e upstream.
      
      Notifications may only be 8 bytes long. Accessing the 9th and
      10th byte of unimplemented/unknown notifications may be insecure.
      Also check the length of known notifications before accessing anything
      behind the 8th byte.
      Signed-off-by: default avatarTobias Herzog <t-herzog@gmx.de>
      Acked-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d22b933f
    • Ben Skeggs's avatar
      drm/nouveau/tmr: handle races with hw when updating the next alarm time · e4add1cf
      Ben Skeggs authored
      commit 1b0f8438 upstream.
      
      If the time to the next alarm is short enough, we could race with HW and
      end up with an ~4 second delay until it triggers.
      
      Fix this by checking again after we update HW.
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4add1cf
    • Ben Skeggs's avatar
      drm/nouveau/tmr: avoid processing completed alarms when adding a new one · 9d78e40f
      Ben Skeggs authored
      commit 330bdf62 upstream.
      
      The idea here was to avoid having to "manually" program the HW if there's
      a new earliest alarm.  This was lazy and bad, as it leads to loads of fun
      races between inter-related callers (ie. therm).
      
      Turns out, it's not so difficult after all.  Go figure ;)
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d78e40f
    • Ben Skeggs's avatar
      drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarm · 5e07724c
      Ben Skeggs authored
      commit 9fc64667 upstream.
      
      At least therm/fantog "attempts" to work around this issue, which could
      lead to corruption of the pending alarm list.
      
      Fix it properly by not updating the timestamp without the lock held, or
      trying to add an already pending alarm to the pending alarm list....
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e07724c
    • Ben Skeggs's avatar
      drm/nouveau/tmr: ack interrupt before processing alarms · 27f82df2
      Ben Skeggs authored
      commit 3733bd8b upstream.
      
      Fixes a race where we can miss an alarm that triggers while we're already
      processing previous alarms.
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      27f82df2
    • Ben Skeggs's avatar
      drm/nouveau/therm: remove ineffective workarounds for alarm bugs · 3819271d
      Ben Skeggs authored
      commit e4311ee5 upstream.
      
      These were ineffective due to touching the list without the alarm lock,
      but should no longer be required.
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3819271d
    • Mario Kleiner's avatar
      drm/amdgpu: Make display watermark calculations more accurate · 7d2d6022
      Mario Kleiner authored
      commit d63c277d upstream.
      
      Avoid big roundoff errors in scanline/hactive durations for
      high pixel clocks, especially for >= 500 Mhz, and thereby
      program more accurate display fifo watermarks.
      
      Implemented here for DCE 6,8,10,11.
      Successfully tested on DCE 10 with AMD R9 380 Tonga.
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7d2d6022
    • Mario Kleiner's avatar
      drm/amdgpu: Avoid overflows/divide-by-zero in latency_watermark calculations. · 349666cf
      Mario Kleiner authored
      commit e190ed1e upstream.
      
      At dot clocks > approx. 250 Mhz, some of these calcs will overflow and
      cause miscalculation of latency watermarks, and for some overflows also
      divide-by-zero driver crash ("divide error: 0000 [#1] PREEMPT SMP" in
      "dce_v10_0_latency_watermark+0x12d/0x190").
      
      This zero-divide happened, e.g., on AMD Tonga Pro under DCE-10,
      on a Displayport panel when trying to set a video mode of 2560x1440
      at 165 Hz vrefresh with a dot clock of 635.540 Mhz.
      
      Refine calculations to avoid the overflows.
      
      Tested for DCE-10 with R9 380 Tonga + ASUS ROG PG279 panel.
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      349666cf
    • Johan Hovold's avatar
      ath9k_htc: fix NULL-deref at probe · 670a7c5d
      Johan Hovold authored
      commit ebeb3667 upstream.
      
      Make sure to check the number of endpoints to avoid dereferencing a
      NULL-pointer or accessing memory beyond the endpoint array should a
      malicious device lack the expected endpoints.
      
      Fixes: 36bcce43 ("ath9k_htc: Handle storage devices")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      670a7c5d
    • Dmitry Tunin's avatar
      ath9k_htc: Add support of AirTies 1eda:2315 AR9271 device · 8431037b
      Dmitry Tunin authored
      commit 16ff1fb0 upstream.
      
      T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#=  7 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs=  1
      P:  Vendor=1eda ProdID=2315 Rev=01.08
      S:  Manufacturer=ATHEROS
      S:  Product=USB2.0 WLAN
      S:  SerialNumber=12345
      C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 6 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      Signed-off-by: default avatarDmitry Tunin <hanipouspilot@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8431037b
    • Martin Schwidefsky's avatar
      s390/cputime: fix incorrect system time · c26190b5
      Martin Schwidefsky authored
      commit 07a63cbe upstream.
      
      git commit c5328901 "[S390] entry[64].S improvements" removed
      the update of the exit_timer lowcore field from the critical section
      cleanup of the .Lsysc_restore/.Lsysc_done and .Lio_restore/.Lio_done
      blocks. If the PSW is updated by the critical section cleanup to point to
      user space again, the interrupt entry code will do a vtime calculation
      after the cleanup completed with an exit_timer value which has *not* been
      updated. Due to this incorrect system time deltas are calculated.
      
      If an interrupt occured with an old PSW between .Lsysc_restore/.Lsysc_done
      or .Lio_restore/.Lio_done update __LC_EXIT_TIMER with the system entry
      time of the interrupt.
      Tested-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c26190b5
    • Michael Holzheu's avatar
      s390/kdump: Add final note · d1f8ea3b
      Michael Holzheu authored
      commit dcc00b79 upstream.
      
      Since linux v3.14 with commit 38dfac84 ("vmcore: prevent PT_NOTE
      p_memsz overflow during header update") on s390 we get the following
      message in the kdump kernel:
      
        Warning: Exceeded p_memsz, dropping PT_NOTE entry n_namesz=0x6b6b6b6b,
        n_descsz=0x6b6b6b6b
      
      The reason for this is that we don't create a final zero note in
      the ELF header which the proc/vmcore code uses to find out the end
      of the notes section (see also kernel/kexec_core.c:final_note()).
      
      It still worked on s390 by chance because we (most of the time?) have the
      byte pattern 0x6b6b6b6b after the notes section which also makes the notes
      parsing code stop in update_note_header_size_elf64() because 0x6b6b6b6b is
      interpreded as note size:
      
        if ((real_sz + sz) > max_sz) {
                pr_warn("Warning: Exceeded p_memsz, dropping P ...);
                break;
        }
      
      So fix this and add the missing final note to the ELF header.
      We don't have to adjust the memory size for ELF header ("alloc_size")
      because the new ELF note still fits into the 0x1000 base memory.
      Signed-off-by: default avatarMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1f8ea3b
    • Richard Cochran's avatar
      regulator: tps65023: Fix inverted core enable logic. · de74aedd
      Richard Cochran authored
      commit c90722b5 upstream.
      
      Commit 43530b69 ("regulator: Use
      regmap_read/write(), regmap_update_bits functions directly") intended
      to replace working inline helper functions with standard regmap
      calls.  However, it also inverted the set/clear logic of the "CORE ADJ
      Allowed" bit.  That patch was clearly never tested, since without that
      bit cleared, the core VDCDC1 voltage output does not react to I2C
      configuration changes.
      
      This patch fixes the issue by clearing the bit as in the original,
      correct implementation.  Note for stable back porting that, due to
      subsequent driver churn, this patch will not apply on every kernel
      version.
      
      Fixes: 43530b69 ("regulator: Use regmap_read/write(), regmap_update_bits functions directly")
      Signed-off-by: default avatarRichard Cochran <rcochran@linutronix.de>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de74aedd
    • Wanpeng Li's avatar
      KVM: X86: Fix read out-of-bounds vulnerability in kvm pio emulation · 6d380f50
      Wanpeng Li authored
      commit cbfc6c91 upstream.
      
      Huawei folks reported a read out-of-bounds vulnerability in kvm pio emulation.
      
      - "inb" instruction to access PIT Mod/Command register (ioport 0x43, write only,
        a read should be ignored) in guest can get a random number.
      - "rep insb" instruction to access PIT register port 0x43 can control memcpy()
        in emulator_pio_in_emulated() to copy max 0x400 bytes but only read 1 bytes,
        which will disclose the unimportant kernel memory in host but no crash.
      
      The similar test program below can reproduce the read out-of-bounds vulnerability:
      
      void hexdump(void *mem, unsigned int len)
      {
              unsigned int i, j;
      
              for(i = 0; i < len + ((len % HEXDUMP_COLS) ? (HEXDUMP_COLS - len % HEXDUMP_COLS) : 0); i++)
              {
                      /* print offset */
                      if(i % HEXDUMP_COLS == 0)
                      {
                              printf("0x%06x: ", i);
                      }
      
                      /* print hex data */
                      if(i < len)
                      {
                              printf("%02x ", 0xFF & ((char*)mem)[i]);
                      }
                      else /* end of block, just aligning for ASCII dump */
                      {
                              printf("   ");
                      }
      
                      /* print ASCII dump */
                      if(i % HEXDUMP_COLS == (HEXDUMP_COLS - 1))
                      {
                              for(j = i - (HEXDUMP_COLS - 1); j <= i; j++)
                              {
                                      if(j >= len) /* end of block, not really printing */
                                      {
                                              putchar(' ');
                                      }
                                      else if(isprint(((char*)mem)[j])) /* printable char */
                                      {
                                              putchar(0xFF & ((char*)mem)[j]);
                                      }
                                      else /* other char */
                                      {
                                              putchar('.');
                                      }
                              }
                              putchar('\n');
                      }
              }
      }
      
      int main(void)
      {
      	int i;
      	if (iopl(3))
      	{
      		err(1, "set iopl unsuccessfully\n");
      		return -1;
      	}
      	static char buf[0x40];
      
      	/* test ioport 0x40,0x41,0x42,0x43,0x44,0x45 */
      
      	memset(buf, 0xab, sizeof(buf));
      
      	asm volatile("push %rdi;");
      	asm volatile("mov %0, %%rdi;"::"q"(buf));
      
      	asm volatile ("mov $0x40, %rdx;");
      	asm volatile ("in %dx,%al;");
      	asm volatile ("stosb;");
      
      	asm volatile ("mov $0x41, %rdx;");
      	asm volatile ("in %dx,%al;");
      	asm volatile ("stosb;");
      
      	asm volatile ("mov $0x42, %rdx;");
      	asm volatile ("in %dx,%al;");
      	asm volatile ("stosb;");
      
      	asm volatile ("mov $0x43, %rdx;");
      	asm volatile ("in %dx,%al;");
      	asm volatile ("stosb;");
      
      	asm volatile ("mov $0x44, %rdx;");
      	asm volatile ("in %dx,%al;");
      	asm volatile ("stosb;");
      
      	asm volatile ("mov $0x45, %rdx;");
      	asm volatile ("in %dx,%al;");
      	asm volatile ("stosb;");
      
      	asm volatile ("pop %rdi;");
      	hexdump(buf, 0x40);
      
      	printf("\n");
      
      	/* ins port 0x40 */
      
      	memset(buf, 0xab, sizeof(buf));
      
      	asm volatile("push %rdi;");
      	asm volatile("mov %0, %%rdi;"::"q"(buf));
      
      	asm volatile ("mov $0x20, %rcx;");
      	asm volatile ("mov $0x40, %rdx;");
      	asm volatile ("rep insb;");
      
      	asm volatile ("pop %rdi;");
      	hexdump(buf, 0x40);
      
      	printf("\n");
      
      	/* ins port 0x43 */
      
      	memset(buf, 0xab, sizeof(buf));
      
      	asm volatile("push %rdi;");
      	asm volatile("mov %0, %%rdi;"::"q"(buf));
      
      	asm volatile ("mov $0x20, %rcx;");
      	asm volatile ("mov $0x43, %rdx;");
      	asm volatile ("rep insb;");
      
      	asm volatile ("pop %rdi;");
      	hexdump(buf, 0x40);
      
      	printf("\n");
      	return 0;
      }
      
      The vcpu->arch.pio_data buffer is used by both in/out instrutions emulation
      w/o clear after using which results in some random datas are left over in
      the buffer. Guest reads port 0x43 will be ignored since it is write only,
      however, the function kernel_pio() can't distigush this ignore from successfully
      reads data from device's ioport. There is no new data fill the buffer from
      port 0x43, however, emulator_pio_in_emulated() will copy the stale data in
      the buffer to the guest unconditionally. This patch fixes it by clearing the
      buffer before in instruction emulation to avoid to grant guest the stale data
      in the buffer.
      
      In addition, string I/O is not supported for in kernel device. So there is no
      iteration to read ioport %RCX times for string I/O. The function kernel_pio()
      just reads one round, and then copy the io size * %RCX to the guest unconditionally,
      actually it copies the one round ioport data w/ other random datas which are left
      over in the vcpu->arch.pio_data buffer to the guest. This patch fixes it by
      introducing the string I/O support for in kernel device in order to grant the right
      ioport datas to the guest.
      
      Before the patch:
      
      0x000000: fe 38 93 93 ff ff ab ab .8......
      0x000008: ab ab ab ab ab ab ab ab ........
      0x000010: ab ab ab ab ab ab ab ab ........
      0x000018: ab ab ab ab ab ab ab ab ........
      0x000020: ab ab ab ab ab ab ab ab ........
      0x000028: ab ab ab ab ab ab ab ab ........
      0x000030: ab ab ab ab ab ab ab ab ........
      0x000038: ab ab ab ab ab ab ab ab ........
      
      0x000000: f6 00 00 00 00 00 00 00 ........
      0x000008: 00 00 00 00 00 00 00 00 ........
      0x000010: 00 00 00 00 4d 51 30 30 ....MQ00
      0x000018: 30 30 20 33 20 20 20 20 00 3
      0x000020: ab ab ab ab ab ab ab ab ........
      0x000028: ab ab ab ab ab ab ab ab ........
      0x000030: ab ab ab ab ab ab ab ab ........
      0x000038: ab ab ab ab ab ab ab ab ........
      
      0x000000: f6 00 00 00 00 00 00 00 ........
      0x000008: 00 00 00 00 00 00 00 00 ........
      0x000010: 00 00 00 00 4d 51 30 30 ....MQ00
      0x000018: 30 30 20 33 20 20 20 20 00 3
      0x000020: ab ab ab ab ab ab ab ab ........
      0x000028: ab ab ab ab ab ab ab ab ........
      0x000030: ab ab ab ab ab ab ab ab ........
      0x000038: ab ab ab ab ab ab ab ab ........
      
      After the patch:
      
      0x000000: 1e 02 f8 00 ff ff ab ab ........
      0x000008: ab ab ab ab ab ab ab ab ........
      0x000010: ab ab ab ab ab ab ab ab ........
      0x000018: ab ab ab ab ab ab ab ab ........
      0x000020: ab ab ab ab ab ab ab ab ........
      0x000028: ab ab ab ab ab ab ab ab ........
      0x000030: ab ab ab ab ab ab ab ab ........
      0x000038: ab ab ab ab ab ab ab ab ........
      
      0x000000: d2 e2 d2 df d2 db d2 d7 ........
      0x000008: d2 d3 d2 cf d2 cb d2 c7 ........
      0x000010: d2 c4 d2 c0 d2 bc d2 b8 ........
      0x000018: d2 b4 d2 b0 d2 ac d2 a8 ........
      0x000020: ab ab ab ab ab ab ab ab ........
      0x000028: ab ab ab ab ab ab ab ab ........
      0x000030: ab ab ab ab ab ab ab ab ........
      0x000038: ab ab ab ab ab ab ab ab ........
      
      0x000000: 00 00 00 00 00 00 00 00 ........
      0x000008: 00 00 00 00 00 00 00 00 ........
      0x000010: 00 00 00 00 00 00 00 00 ........
      0x000018: 00 00 00 00 00 00 00 00 ........
      0x000020: ab ab ab ab ab ab ab ab ........
      0x000028: ab ab ab ab ab ab ab ab ........
      0x000030: ab ab ab ab ab ab ab ab ........
      0x000038: ab ab ab ab ab ab ab ab ........
      Reported-by: default avatarMoguofang <moguofang@huawei.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Moguofang <moguofang@huawei.com>
      Signed-off-by: default avatarWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d380f50
    • Wanpeng Li's avatar
      KVM: x86: Fix load damaged SSEx MXCSR register · e9c9e758
      Wanpeng Li authored
      commit a575813b upstream.
      
      Reported by syzkaller:
      
         BUG: unable to handle kernel paging request at ffffffffc07f6a2e
         IP: report_bug+0x94/0x120
         PGD 348e12067
         P4D 348e12067
         PUD 348e14067
         PMD 3cbd84067
         PTE 80000003f7e87161
      
         Oops: 0003 [#1] SMP
         CPU: 2 PID: 7091 Comm: kvm_load_guest_ Tainted: G           OE   4.11.0+ #8
         task: ffff92fdfb525400 task.stack: ffffbda6c3d04000
         RIP: 0010:report_bug+0x94/0x120
         RSP: 0018:ffffbda6c3d07b20 EFLAGS: 00010202
          do_trap+0x156/0x170
          do_error_trap+0xa3/0x170
          ? kvm_load_guest_fpu.part.175+0x12a/0x170 [kvm]
          ? mark_held_locks+0x79/0xa0
          ? retint_kernel+0x10/0x10
          ? trace_hardirqs_off_thunk+0x1a/0x1c
          do_invalid_op+0x20/0x30
          invalid_op+0x1e/0x30
         RIP: 0010:kvm_load_guest_fpu.part.175+0x12a/0x170 [kvm]
          ? kvm_load_guest_fpu.part.175+0x1c/0x170 [kvm]
          kvm_arch_vcpu_ioctl_run+0xed6/0x1b70 [kvm]
          kvm_vcpu_ioctl+0x384/0x780 [kvm]
          ? kvm_vcpu_ioctl+0x384/0x780 [kvm]
          ? sched_clock+0x13/0x20
          ? __do_page_fault+0x2a0/0x550
          do_vfs_ioctl+0xa4/0x700
          ? up_read+0x1f/0x40
          ? __do_page_fault+0x2a0/0x550
          SyS_ioctl+0x79/0x90
          entry_SYSCALL_64_fastpath+0x23/0xc2
      
      SDM mentioned that "The MXCSR has several reserved bits, and attempting to write
      a 1 to any of these bits will cause a general-protection exception(#GP) to be
      generated". The syzkaller forks' testcase overrides xsave area w/ random values
      and steps on the reserved bits of MXCSR register. The damaged MXCSR register
      values of guest will be restored to SSEx MXCSR register before vmentry. This
      patch fixes it by catching userspace override MXCSR register reserved bits w/
      random values and bails out immediately.
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e9c9e758
    • Daniel Glöckner's avatar
      ima: accept previously set IMA_NEW_FILE · 08e589a9
      Daniel Glöckner authored
      commit 1ac202e9 upstream.
      
      Modifying the attributes of a file makes ima_inode_post_setattr reset
      the IMA cache flags. So if the file, which has just been created,
      is opened a second time before the first file descriptor is closed,
      verification fails since the security.ima xattr has not been written
      yet. We therefore have to look at the IMA_NEW_FILE even if the file
      already existed.
      
      With this patch there should no longer be an error when cat tries to
      open testfile:
      
      $ rm -f testfile
      $ ( echo test >&3 ; touch testfile ; cat testfile ) 3>testfile
      
      A file being new is no reason to accept that it is missing a digital
      signature demanded by the policy.
      Signed-off-by: default avatarDaniel Glöckner <dg@emlix.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      08e589a9
    • Brian Norris's avatar
      mwifiex: pcie: fix cmd_buf use-after-free in remove/reset · 0c99c8a2
      Brian Norris authored
      commit 3c8cb9ad upstream.
      
      Command buffers (skb's) are allocated by the main driver, and freed upon
      the last use. That last use is often in mwifiex_free_cmd_buffer(). In
      the meantime, if the command buffer gets used by the PCI driver, we map
      it as DMA-able, and store the mapping information in the 'cb' memory.
      
      However, if a command was in-flight when resetting the device (and
      therefore was still mapped), we don't get a chance to unmap this memory
      until after the core has cleaned up its command handling.
      
      Let's keep a refcount within the PCI driver, so we ensure the memory
      only gets freed after we've finished unmapping it.
      
      Noticed by KASAN when forcing a reset via:
      
        echo 1 > /sys/bus/pci/.../reset
      
      The same code path can presumably be exercised in remove() and
      shutdown().
      
      [  205.390377] mwifiex_pcie 0000:01:00.0: info: shutdown mwifiex...
      [  205.400393] ==================================================================
      [  205.407719] BUG: KASAN: use-after-free in mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie] at addr ffffffc0ad471b28
      [  205.419040] Read of size 16 by task bash/1913
      [  205.423421] =============================================================================
      [  205.431625] BUG skbuff_head_cache (Tainted: G    B          ): kasan: bad access detected
      [  205.439815] -----------------------------------------------------------------------------
      [  205.439815]
      [  205.449534] INFO: Allocated in __build_skb+0x48/0x114 age=1311 cpu=4 pid=1913
      [  205.456709] 	alloc_debug_processing+0x124/0x178
      [  205.461282] 	___slab_alloc.constprop.58+0x528/0x608
      [  205.466196] 	__slab_alloc.isra.54.constprop.57+0x44/0x54
      [  205.471542] 	kmem_cache_alloc+0xcc/0x278
      [  205.475497] 	__build_skb+0x48/0x114
      [  205.479019] 	__netdev_alloc_skb+0xe0/0x170
      [  205.483244] 	mwifiex_alloc_cmd_buffer+0x68/0xdc [mwifiex]
      [  205.488759] 	mwifiex_init_fw+0x40/0x6cc [mwifiex]
      [  205.493584] 	_mwifiex_fw_dpc+0x158/0x520 [mwifiex]
      [  205.498491] 	mwifiex_reinit_sw+0x2c4/0x398 [mwifiex]
      [  205.503510] 	mwifiex_pcie_reset_notify+0x114/0x15c [mwifiex_pcie]
      [  205.509643] 	pci_reset_notify+0x5c/0x6c
      [  205.513519] 	pci_reset_function+0x6c/0x7c
      [  205.517567] 	reset_store+0x68/0x98
      [  205.521003] 	dev_attr_store+0x54/0x60
      [  205.524705] 	sysfs_kf_write+0x9c/0xb0
      [  205.528413] INFO: Freed in __kfree_skb+0xb0/0xbc age=131 cpu=4 pid=1913
      [  205.535064] 	free_debug_processing+0x264/0x370
      [  205.539550] 	__slab_free+0x84/0x40c
      [  205.543075] 	kmem_cache_free+0x1c8/0x2a0
      [  205.547030] 	__kfree_skb+0xb0/0xbc
      [  205.550465] 	consume_skb+0x164/0x178
      [  205.554079] 	__dev_kfree_skb_any+0x58/0x64
      [  205.558304] 	mwifiex_free_cmd_buffer+0xa0/0x158 [mwifiex]
      [  205.563817] 	mwifiex_shutdown_drv+0x578/0x5c4 [mwifiex]
      [  205.569164] 	mwifiex_shutdown_sw+0x178/0x310 [mwifiex]
      [  205.574353] 	mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie]
      [  205.580398] 	pci_reset_notify+0x5c/0x6c
      [  205.584274] 	pci_dev_save_and_disable+0x24/0x6c
      [  205.588837] 	pci_reset_function+0x30/0x7c
      [  205.592885] 	reset_store+0x68/0x98
      [  205.596324] 	dev_attr_store+0x54/0x60
      [  205.600017] 	sysfs_kf_write+0x9c/0xb0
      ...
      [  205.800488] Call trace:
      [  205.802980] [<ffffffc00020a69c>] dump_backtrace+0x0/0x190
      [  205.808415] [<ffffffc00020a96c>] show_stack+0x20/0x28
      [  205.813506] [<ffffffc0005d020c>] dump_stack+0xa4/0xcc
      [  205.818598] [<ffffffc0003be44c>] print_trailer+0x158/0x168
      [  205.824120] [<ffffffc0003be5f0>] object_err+0x4c/0x5c
      [  205.829210] [<ffffffc0003c45bc>] kasan_report+0x334/0x500
      [  205.834641] [<ffffffc0003c3994>] check_memory_region+0x20/0x14c
      [  205.840593] [<ffffffc0003c3b14>] __asan_loadN+0x14/0x1c
      [  205.845879] [<ffffffbffc46171c>] mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie]
      [  205.854282] [<ffffffbffc461864>] mwifiex_pcie_delete_cmdrsp_buf+0x94/0xa8 [mwifiex_pcie]
      [  205.862421] [<ffffffbffc462028>] mwifiex_pcie_free_buffers+0x11c/0x158 [mwifiex_pcie]
      [  205.870302] [<ffffffbffc4620d4>] mwifiex_pcie_down_dev+0x70/0x80 [mwifiex_pcie]
      [  205.877736] [<ffffffbffc1397a8>] mwifiex_shutdown_sw+0x190/0x310 [mwifiex]
      [  205.884658] [<ffffffbffc4606b4>] mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie]
      [  205.892446] [<ffffffc000635f54>] pci_reset_notify+0x5c/0x6c
      [  205.898048] [<ffffffc00063a044>] pci_dev_save_and_disable+0x24/0x6c
      [  205.904350] [<ffffffc00063cf0c>] pci_reset_function+0x30/0x7c
      [  205.910134] [<ffffffc000641118>] reset_store+0x68/0x98
      [  205.915312] [<ffffffc000771588>] dev_attr_store+0x54/0x60
      [  205.920750] [<ffffffc00046f53c>] sysfs_kf_write+0x9c/0xb0
      [  205.926182] [<ffffffc00046dfb0>] kernfs_fop_write+0x184/0x1f8
      [  205.931963] [<ffffffc0003d64f4>] __vfs_write+0x6c/0x17c
      [  205.937221] [<ffffffc0003d7164>] vfs_write+0xf0/0x1c4
      [  205.942310] [<ffffffc0003d7da0>] SyS_write+0x78/0xd8
      [  205.947312] [<ffffffc000204634>] el0_svc_naked+0x24/0x28
      ...
      [  205.998268] ==================================================================
      
      This bug has been around in different forms for a while. It was sort of
      noticed in commit 955ab095 ("mwifiex: Do not kfree cmd buf while
      unregistering PCIe"), but it just fixed the double-free, without
      acknowledging the potential for use-after-free.
      
      Fixes: fc331460 ("mwifiex: use pci_alloc/free_consistent APIs for PCIe")
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c99c8a2
    • Larry Finger's avatar
      rtlwifi: rtl8821ae: setup 8812ae RFE according to device type · e367d1b0
      Larry Finger authored
      commit 46cfa214 upstream.
      
      Current channel switch implementation sets 8812ae RFE reg value assuming
      that device always has type 2.
      
      Extend possible RFE types set and write corresponding reg values.
      
      Source for new code is
      http://dlcdnet.asus.com/pub/ASUS/wireless/PCE-AC51/DR_PCE_AC51_20232801152016.zipSigned-off-by: default avatarMaxim Samoylov <max7255@gmail.com>
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
      Cc: Pkshih <pkshih@realtek.com>
      Cc: Birming Chiu <birming@realtek.com>
      Cc: Shaofu <shaofu@realtek.com>
      Cc: Steven Ting <steventing@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e367d1b0
    • Dennis Yang's avatar
      md: update slab_cache before releasing new stripes when stripes resizing · c5ff397f
      Dennis Yang authored
      commit 583da48e upstream.
      
      When growing raid5 device on machine with small memory, there is chance that
      mdadm will be killed and the following bug report can be observed. The same
      bug could also be reproduced in linux-4.10.6.
      
      [57600.075774] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [57600.083796] IP: [<ffffffff81a6aa87>] _raw_spin_lock+0x7/0x20
      [57600.110378] PGD 421cf067 PUD 4442d067 PMD 0
      [57600.114678] Oops: 0002 [#1] SMP
      [57600.180799] CPU: 1 PID: 25990 Comm: mdadm Tainted: P           O    4.2.8 #1
      [57600.187849] Hardware name: To be filled by O.E.M. To be filled by O.E.M./MAHOBAY, BIOS QV05AR66 03/06/2013
      [57600.197490] task: ffff880044e47240 ti: ffff880043070000 task.ti: ffff880043070000
      [57600.204963] RIP: 0010:[<ffffffff81a6aa87>]  [<ffffffff81a6aa87>] _raw_spin_lock+0x7/0x20
      [57600.213057] RSP: 0018:ffff880043073810  EFLAGS: 00010046
      [57600.218359] RAX: 0000000000000000 RBX: 000000000000000c RCX: ffff88011e296dd0
      [57600.225486] RDX: 0000000000000001 RSI: ffffe8ffffcb46c0 RDI: 0000000000000000
      [57600.232613] RBP: ffff880043073878 R08: ffff88011e5f8170 R09: 0000000000000282
      [57600.239739] R10: 0000000000000005 R11: 28f5c28f5c28f5c3 R12: ffff880043073838
      [57600.246872] R13: ffffe8ffffcb46c0 R14: 0000000000000000 R15: ffff8800b9706a00
      [57600.253999] FS:  00007f576106c700(0000) GS:ffff88011e280000(0000) knlGS:0000000000000000
      [57600.262078] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [57600.267817] CR2: 0000000000000000 CR3: 00000000428fe000 CR4: 00000000001406e0
      [57600.274942] Stack:
      [57600.276949]  ffffffff8114ee35 ffff880043073868 0000000000000282 000000000000eb3f
      [57600.284383]  ffffffff81119043 ffff880043073838 ffff880043073838 ffff88003e197b98
      [57600.291820]  ffffe8ffffcb46c0 ffff88003e197360 0000000000000286 ffff880043073968
      [57600.299254] Call Trace:
      [57600.301698]  [<ffffffff8114ee35>] ? cache_flusharray+0x35/0xe0
      [57600.307523]  [<ffffffff81119043>] ? __page_cache_release+0x23/0x110
      [57600.313779]  [<ffffffff8114eb53>] kmem_cache_free+0x63/0xc0
      [57600.319344]  [<ffffffff81579942>] drop_one_stripe+0x62/0x90
      [57600.324915]  [<ffffffff81579b5b>] raid5_cache_scan+0x8b/0xb0
      [57600.330563]  [<ffffffff8111b98a>] shrink_slab.part.36+0x19a/0x250
      [57600.336650]  [<ffffffff8111e38c>] shrink_zone+0x23c/0x250
      [57600.342039]  [<ffffffff8111e4f3>] do_try_to_free_pages+0x153/0x420
      [57600.348210]  [<ffffffff8111e851>] try_to_free_pages+0x91/0xa0
      [57600.353959]  [<ffffffff811145b1>] __alloc_pages_nodemask+0x4d1/0x8b0
      [57600.360303]  [<ffffffff8157a30b>] check_reshape+0x62b/0x770
      [57600.365866]  [<ffffffff8157a4a5>] raid5_check_reshape+0x55/0xa0
      [57600.371778]  [<ffffffff81583df7>] update_raid_disks+0xc7/0x110
      [57600.377604]  [<ffffffff81592b73>] md_ioctl+0xd83/0x1b10
      [57600.382827]  [<ffffffff81385380>] blkdev_ioctl+0x170/0x690
      [57600.388307]  [<ffffffff81195238>] block_ioctl+0x38/0x40
      [57600.393525]  [<ffffffff811731c5>] do_vfs_ioctl+0x2b5/0x480
      [57600.399010]  [<ffffffff8115e07b>] ? vfs_write+0x14b/0x1f0
      [57600.404400]  [<ffffffff811733cc>] SyS_ioctl+0x3c/0x70
      [57600.409447]  [<ffffffff81a6ad97>] entry_SYSCALL_64_fastpath+0x12/0x6a
      [57600.415875] Code: 00 00 00 00 55 48 89 e5 8b 07 85 c0 74 04 31 c0 5d c3 ba 01 00 00 00 f0 0f b1 17 85 c0 75 ef b0 01 5d c3 90 31 c0 ba 01 00 00 00 <f0> 0f b1 17 85 c0 75 01 c3 55 89 c6 48 89 e5 e8 85 d1 63 ff 5d
      [57600.435460] RIP  [<ffffffff81a6aa87>] _raw_spin_lock+0x7/0x20
      [57600.441208]  RSP <ffff880043073810>
      [57600.444690] CR2: 0000000000000000
      [57600.448000] ---[ end trace cbc6b5cc4bf9831d ]---
      
      The problem is that resize_stripes() releases new stripe_heads before assigning new
      slab cache to conf->slab_cache. If the shrinker function raid5_cache_scan() gets called
      after resize_stripes() starting releasing new stripes but right before new slab cache
      being assigned, it is possible that these new stripe_heads will be freed with the old
      slab_cache which was already been destoryed and that triggers this bug.
      Signed-off-by: default avatarDennis Yang <dennisyang@qnap.com>
      Fixes: edbe83ab ("md/raid5: allow the stripe_cache to grow and shrink.")
      Reviewed-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5ff397f
    • Joe Thornber's avatar
      dm space map disk: fix some book keeping in the disk space map · d3df9403
      Joe Thornber authored
      commit 0377a07c upstream.
      
      When decrementing the reference count for a block, the free count wasn't
      being updated if the reference count went to zero.
      Signed-off-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3df9403
    • Joe Thornber's avatar
      dm thin metadata: call precommit before saving the roots · 1dc9fb3c
      Joe Thornber authored
      commit 91bcdb92 upstream.
      
      These calls were the wrong way round in __write_initial_superblock.
      Signed-off-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1dc9fb3c
    • Mikulas Patocka's avatar
      dm bufio: make the parameter "retain_bytes" unsigned long · ea4889d6
      Mikulas Patocka authored
      commit 13840d38 upstream.
      
      Change the type of the parameter "retain_bytes" from unsigned to
      unsigned long, so that on 64-bit machines the user can set more than
      4GiB of data to be retained.
      
      Also, change the type of the variable "count" in the function
      "__evict_old_buffers" to unsigned long.  The assignment
      "count = c->n_buffers[LIST_CLEAN] + c->n_buffers[LIST_DIRTY];"
      could result in unsigned long to unsigned overflow and that could result
      in buffers not being freed when they should.
      
      While at it, avoid division in get_retain_buffers().  Division is slow,
      we can change it to shift because we have precalculated the log2 of
      block size.
      Signed-off-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>
      ea4889d6
    • Mike Snitzer's avatar
      dm cache metadata: fail operations if fail_io mode has been established · 4a9631ff
      Mike Snitzer authored
      commit 10add84e upstream.
      
      Otherwise it is possible to trigger crashes due to the metadata being
      inaccessible yet these methods don't safely account for that possibility
      without these checks.
      Reported-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>
      4a9631ff
    • Mikulas Patocka's avatar
      dm bufio: check new buffer allocation watermark every 30 seconds · 8d8fb01a
      Mikulas Patocka authored
      commit 390020ad upstream.
      
      dm-bufio checks a watermark when it allocates a new buffer in
      __bufio_new().  However, it doesn't check the watermark when the user
      changes /sys/module/dm_bufio/parameters/max_cache_size_bytes.
      
      This may result in a problem - if the watermark is high enough so that
      all possible buffers are allocated and if the user lowers the value of
      "max_cache_size_bytes", the watermark will never be checked against the
      new value because no new buffer would be allocated.
      
      To fix this, change __evict_old_buffers() so that it checks the
      watermark.  __evict_old_buffers() is called every 30 seconds, so if the
      user reduces "max_cache_size_bytes", dm-bufio will react to this change
      within 30 seconds and decrease memory consumption.
      
      Depends-on: 1b0fb5a5 ("dm bufio: avoid a possible ABBA deadlock")
      Signed-off-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>
      8d8fb01a
    • Mikulas Patocka's avatar
      dm bufio: avoid a possible ABBA deadlock · 5d1df36c
      Mikulas Patocka authored
      commit 1b0fb5a5 upstream.
      
      __get_memory_limit() tests if dm_bufio_cache_size changed and calls
      __cache_size_refresh() if it did.  It takes dm_bufio_clients_lock while
      it already holds the client lock.  However, lock ordering is violated
      because in cleanup_old_buffers() dm_bufio_clients_lock is taken before
      the client lock.
      
      This results in a possible deadlock and lockdep engine warning.
      
      Fix this deadlock by changing mutex_lock() to mutex_trylock().  If the
      lock can't be taken, it will be re-checked next time when a new buffer
      is allocated.
      
      Also add "unlikely" to the if condition, so that the optimizer assumes
      that the condition is false.
      Signed-off-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>
      5d1df36c
    • Mikulas Patocka's avatar
      dm raid: select the Kconfig option CONFIG_MD_RAID0 · 4df4bf1d
      Mikulas Patocka authored
      commit 7b81ef8b upstream.
      
      Since the commit 0cf45031 ("dm raid: add support for the MD RAID0
      personality"), the dm-raid subsystem can activate a RAID-0 array.
      Therefore, add MD_RAID0 to the dependencies of DM_RAID, so that MD_RAID0
      will be selected when DM_RAID is selected.
      
      Fixes: 0cf45031 ("dm raid: add support for the MD RAID0 personality")
      Signed-off-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>
      4df4bf1d
    • Vinothkumar Raja's avatar
      dm btree: fix for dm_btree_find_lowest_key() · fa499b36
      Vinothkumar Raja authored
      commit 7d1fedb6 upstream.
      
      dm_btree_find_lowest_key() is giving incorrect results.  find_key()
      traverses the btree correctly for finding the highest key, but there is
      an error in the way it traverses the btree for retrieving the lowest
      key.  dm_btree_find_lowest_key() fetches the first key of the rightmost
      block of the btree instead of fetching the first key from the leftmost
      block.
      
      Fix this by conditionally passing the correct parameter to value64()
      based on the @find_highest flag.
      Signed-off-by: default avatarErez Zadok <ezk@fsl.cs.sunysb.edu>
      Signed-off-by: default avatarVinothkumar Raja <vinraja@cs.stonybrook.edu>
      Signed-off-by: default avatarNidhi Panpalia <npanpalia@cs.stonybrook.edu>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa499b36
    • Paolo Abeni's avatar
      infiniband: call ipv6 route lookup via the stub interface · c0439735
      Paolo Abeni authored
      commit eea40b8f upstream.
      
      The infiniband address handle can be triggered to resolve an ipv6
      address in response to MAD packets, regardless of the ipv6
      module being disabled via the kernel command line argument.
      
      That will cause a call into the ipv6 routing code, which is not
      initialized, and a conseguent oops.
      
      This commit addresses the above issue replacing the direct lookup
      call with an indirect one via the ipv6 stub, which is properly
      initialized according to the ipv6 status (e.g. if ipv6 is
      disabled, the routing lookup fails gracefully)
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0439735
    • Jerry Snitselaar's avatar
      tpm_crb: check for bad response size · 63450e38
      Jerry Snitselaar authored
      commit 8569defd upstream.
      
      Make sure size of response buffer is at least 6 bytes, or
      we will underflow and pass large size_t to memcpy_fromio().
      This was encountered while testing earlier version of
      locality patchset.
      
      Fixes: 30fc8d13 ("tpm: TPM 2.0 CRB Interface")
      Signed-off-by: default avatarJerry Snitselaar <jsnitsel@redhat.com>
      Reviewed-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      63450e38
    • Marc Dietrich's avatar
      ARM: tegra: paz00: Mark panel regulator as enabled on boot · 025e33ee
      Marc Dietrich authored
      commit 0c18927f upstream.
      
      Current U-Boot enables the display already. Marking the regulator as
      enabled on boot fixes sporadic panel initialization failures.
      Signed-off-by: default avatarMarc Dietrich <marvin24@gmx.de>
      Tested-by: default avatarMisha Komarovskiy <zombah@gmail.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      025e33ee