1. 02 Oct, 2016 17 commits
    • Balbir Singh's avatar
      sched/core: Fix a race between try_to_wake_up() and a woken up task · 431d09f2
      Balbir Singh authored
      [ Upstream commit 135e8c92 ]
      
      The origin of the issue I've seen is related to
      a missing memory barrier between check for task->state and
      the check for task->on_rq.
      
      The task being woken up is already awake from a schedule()
      and is doing the following:
      
      	do {
      		schedule()
      		set_current_state(TASK_(UN)INTERRUPTIBLE);
      	} while (!cond);
      
      The waker, actually gets stuck doing the following in
      try_to_wake_up():
      
      	while (p->on_cpu)
      		cpu_relax();
      
      Analysis:
      
      The instance I've seen involves the following race:
      
       CPU1					CPU2
      
       while () {
         if (cond)
           break;
         do {
           schedule();
           set_current_state(TASK_UN..)
         } while (!cond);
      					wakeup_routine()
      					  spin_lock_irqsave(wait_lock)
         raw_spin_lock_irqsave(wait_lock)	  wake_up_process()
       }					  try_to_wake_up()
       set_current_state(TASK_RUNNING);	  ..
       list_del(&waiter.list);
      
      CPU2 wakes up CPU1, but before it can get the wait_lock and set
      current state to TASK_RUNNING the following occurs:
      
       CPU3
       wakeup_routine()
       raw_spin_lock_irqsave(wait_lock)
       if (!list_empty)
         wake_up_process()
         try_to_wake_up()
         raw_spin_lock_irqsave(p->pi_lock)
         ..
         if (p->on_rq && ttwu_wakeup())
         ..
         while (p->on_cpu)
           cpu_relax()
         ..
      
      CPU3 tries to wake up the task on CPU1 again since it finds
      it on the wait_queue, CPU1 is spinning on wait_lock, but immediately
      after CPU2, CPU3 got it.
      
      CPU3 checks the state of p on CPU1, it is TASK_UNINTERRUPTIBLE and
      the task is spinning on the wait_lock. Interestingly since p->on_rq
      is checked under pi_lock, I've noticed that try_to_wake_up() finds
      p->on_rq to be 0. This was the most confusing bit of the analysis,
      but p->on_rq is changed under runqueue lock, rq_lock, the p->on_rq
      check is not reliable without this fix IMHO. The race is visible
      (based on the analysis) only when ttwu_queue() does a remote wakeup
      via ttwu_queue_remote. In which case the p->on_rq change is not
      done uder the pi_lock.
      
      The result is that after a while the entire system locks up on
      the raw_spin_irqlock_save(wait_lock) and the holder spins infintely
      
      Reproduction of the issue:
      
      The issue can be reproduced after a long run on my system with 80
      threads and having to tweak available memory to very low and running
      memory stress-ng mmapfork test. It usually takes a long time to
      reproduce. I am trying to work on a test case that can reproduce
      the issue faster, but thats work in progress. I am still testing the
      changes on my still in a loop and the tests seem OK thus far.
      
      Big thanks to Benjamin and Nick for helping debug this as well.
      Ben helped catch the missing barrier, Nick caught every missing
      bit in my theory.
      Signed-off-by: default avatarBalbir Singh <bsingharora@gmail.com>
      [ Updated comment to clarify matching barriers. Many
        architectures do not have a full barrier in switch_to()
        so that cannot be relied upon. ]
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Nicholas Piggin <nicholas.piggin@gmail.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: <stable@vger.kernel.org>
      Link: http://lkml.kernel.org/r/e02cce7b-d9ca-1ad0-7a61-ea97c7582b37@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      431d09f2
    • Linus Walleij's avatar
      iio: accel: kxsd9: Fix scaling bug · 1ea35b9f
      Linus Walleij authored
      [ Upstream commit 307fe9dd ]
      
      All the scaling of the KXSD9 involves multiplication with a
      fraction number < 1.
      
      However the scaling value returned from IIO_INFO_SCALE was
      unpredictable as only the micros of the value was assigned, and
      not the integer part, resulting in scaling like this:
      
      $cat in_accel_scale
      -1057462640.011978
      
      Fix this by assigning zero to the integer part.
      
      Cc: stable@vger.kernel.org
      Tested-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1ea35b9f
    • Vegard Nossum's avatar
      ALSA: timer: fix NULL pointer dereference in read()/ioctl() race · 193eb8f1
      Vegard Nossum authored
      [ Upstream commit 11749e08 ]
      
      I got this with syzkaller:
      
          ==================================================================
          BUG: KASAN: null-ptr-deref on address 0000000000000020
          Read of size 32 by task syz-executor/22519
          CPU: 1 PID: 22519 Comm: syz-executor Not tainted 4.8.0-rc2+ #169
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2
          014
           0000000000000001 ffff880111a17a00 ffffffff81f9f141 ffff880111a17a90
           ffff880111a17c50 ffff880114584a58 ffff880114584a10 ffff880111a17a80
           ffffffff8161fe3f ffff880100000000 ffff880118d74a48 ffff880118d74a68
          Call Trace:
           [<ffffffff81f9f141>] dump_stack+0x83/0xb2
           [<ffffffff8161fe3f>] kasan_report_error+0x41f/0x4c0
           [<ffffffff8161ff74>] kasan_report+0x34/0x40
           [<ffffffff82c84b54>] ? snd_timer_user_read+0x554/0x790
           [<ffffffff8161e79e>] check_memory_region+0x13e/0x1a0
           [<ffffffff8161e9c1>] kasan_check_read+0x11/0x20
           [<ffffffff82c84b54>] snd_timer_user_read+0x554/0x790
           [<ffffffff82c84600>] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
           [<ffffffff817d0831>] ? proc_fault_inject_write+0x1c1/0x250
           [<ffffffff817d0670>] ? next_tgid+0x2a0/0x2a0
           [<ffffffff8127c278>] ? do_group_exit+0x108/0x330
           [<ffffffff8174653a>] ? fsnotify+0x72a/0xca0
           [<ffffffff81674dfe>] __vfs_read+0x10e/0x550
           [<ffffffff82c84600>] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
           [<ffffffff81674cf0>] ? do_sendfile+0xc50/0xc50
           [<ffffffff81745e10>] ? __fsnotify_update_child_dentry_flags+0x60/0x60
           [<ffffffff8143fec6>] ? kcov_ioctl+0x56/0x190
           [<ffffffff81e5ada2>] ? common_file_perm+0x2e2/0x380
           [<ffffffff81746b0e>] ? __fsnotify_parent+0x5e/0x2b0
           [<ffffffff81d93536>] ? security_file_permission+0x86/0x1e0
           [<ffffffff816728f5>] ? rw_verify_area+0xe5/0x2b0
           [<ffffffff81675355>] vfs_read+0x115/0x330
           [<ffffffff81676371>] SyS_read+0xd1/0x1a0
           [<ffffffff816762a0>] ? vfs_write+0x4b0/0x4b0
           [<ffffffff82001c2c>] ? __this_cpu_preempt_check+0x1c/0x20
           [<ffffffff8150455a>] ? __context_tracking_exit.part.4+0x3a/0x1e0
           [<ffffffff816762a0>] ? vfs_write+0x4b0/0x4b0
           [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
           [<ffffffff810052fc>] ? syscall_return_slowpath+0x16c/0x1d0
           [<ffffffff83c3276a>] entry_SYSCALL64_slow_path+0x25/0x25
          ==================================================================
      
      There are a couple of problems that I can see:
      
       - ioctl(SNDRV_TIMER_IOCTL_SELECT), which potentially sets
         tu->queue/tu->tqueue to NULL on memory allocation failure, so read()
         would get a NULL pointer dereference like the above splat
      
       - the same ioctl() can free tu->queue/to->tqueue which means read()
         could potentially see (and dereference) the freed pointer
      
      We can fix both by taking the ioctl_lock mutex when dereferencing
      ->queue/->tqueue, since that's always held over all the ioctl() code.
      
      Just looking at the code I find it likely that there are more problems
      here such as tu->qhead pointing outside the buffer if the size is
      changed concurrently using SNDRV_TIMER_IOCTL_PARAMS.
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      193eb8f1
    • Takashi Sakamoto's avatar
      ALSA: fireworks: accessing to user space outside spinlock · 854a40fa
      Takashi Sakamoto authored
      [ Upstream commit 6b1ca4bc ]
      
      In hwdep interface of fireworks driver, accessing to user space is in a
      critical section with disabled local interrupt. Depending on architecture,
      accessing to user space can cause page fault exception. Then local
      processor stores machine status and handles the synchronous event. A
      handler corresponding to the event can call task scheduler to wait for
      preparing pages. In a case of usage of single core processor, the state to
      disable local interrupt is worse because it don't handle usual interrupts
      from hardware.
      
      This commit fixes this bug, performing the accessing outside spinlock. This
      commit also gives up counting the number of queued response messages to
      simplify ring-buffer management.
      Reported-by: default avatarVaishali Thakkar <vaishali.thakkar@oracle.com>
      Cc: stable@vger.kernel.org
      Fixes: 555e8a8f('ALSA: fireworks: Add command/response functionality into hwdep interface')
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      854a40fa
    • Anson Huang's avatar
      ARM: imx6: add missing BM_CLPCR_BYPASS_PMIC_READY setting for imx6sx · 82ae68a8
      Anson Huang authored
      [ Upstream commit 8aade778 ]
      
      i.MX6SX has bypass PMIC ready function, as this function
      is normally NOT enabled on the board design, so we need
      to bypass the PMIC ready pin check during DSM mode resume
      flow, otherwise, the internal DSM resume logic will be
      waiting for this signal to be ready forever and cause
      resume fail.
      Signed-off-by: default avatarAnson Huang <Anson.Huang@nxp.com>
      Fixes: ff843d62 ("ARM: imx: add suspend support for i.mx6sx")
      Cc: <stable@vger.kernel.org>
      Tested-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      82ae68a8
    • Kai-Heng Feng's avatar
      ALSA: hda - Enable subwoofer on Dell Inspiron 7559 · 6558ce65
      Kai-Heng Feng authored
      [ Upstream commit fd06c77e ]
      
      The subwoofer on Inspiron 7559 was disabled originally.
      Applying a pin fixup to node 0x1b can enable it and make it work.
      
      Old pin: 0x411111f0
      New pin: 0x90170151
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6558ce65
    • Ken Lin's avatar
      ALSA: usb-audio: Add sample rate inquiry quirk for B850V3 CP2114 · 7b7cc699
      Ken Lin authored
      [ Upstream commit 83d9956b ]
      
      Avoid getting sample rate on B850V3 CP2114 as it is unsupported and
      causes noisy "current rate is different from the runtime rate" messages
      when playback starts.
      Signed-off-by: default avatarKen Lin <ken.lin@advantech.com.tw>
      Signed-off-by: default avatarAkshay Bhat <akshay.bhat@timesys.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7b7cc699
    • Vegard Nossum's avatar
      ALSA: timer: fix NULL pointer dereference on memory allocation failure · 6138d59d
      Vegard Nossum authored
      [ Upstream commit 8ddc0563 ]
      
      I hit this with syzkaller:
      
          kasan: CONFIG_KASAN_INLINE enabled
          kasan: GPF could be caused by NULL-ptr deref or user memory access
          general protection fault: 0000 [#1] PREEMPT SMP KASAN
          CPU: 0 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #190
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
          task: ffff88011278d600 task.stack: ffff8801120c0000
          RIP: 0010:[<ffffffff82c8ba07>]  [<ffffffff82c8ba07>] snd_hrtimer_start+0x77/0x100
          RSP: 0018:ffff8801120c7a60  EFLAGS: 00010006
          RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000007
          RDX: 0000000000000009 RSI: 1ffff10023483091 RDI: 0000000000000048
          RBP: ffff8801120c7a78 R08: ffff88011a5cf768 R09: ffff88011a5ba790
          R10: 0000000000000002 R11: ffffed00234b9ef1 R12: ffff880114843980
          R13: ffffffff84213c00 R14: ffff880114843ab0 R15: 0000000000000286
          FS:  00007f72958f3700(0000) GS:ffff88011aa00000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          CR2: 0000000000603001 CR3: 00000001126ab000 CR4: 00000000000006f0
          Stack:
           ffff880114843980 ffff880111eb2dc0 ffff880114843a34 ffff8801120c7ad0
           ffffffff82c81ab1 0000000000000000 ffffffff842138e0 0000000100000000
           ffff880111eb2dd0 ffff880111eb2dc0 0000000000000001 ffff880111eb2dc0
          Call Trace:
           [<ffffffff82c81ab1>] snd_timer_start1+0x331/0x670
           [<ffffffff82c85bfd>] snd_timer_start+0x5d/0xa0
           [<ffffffff82c8795e>] snd_timer_user_ioctl+0x88e/0x2830
           [<ffffffff8159f3a0>] ? __follow_pte.isra.49+0x430/0x430
           [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
           [<ffffffff815a26fa>] ? do_wp_page+0x3aa/0x1c90
           [<ffffffff8132762f>] ? put_prev_entity+0x108f/0x21a0
           [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
           [<ffffffff816b0733>] do_vfs_ioctl+0x193/0x1050
           [<ffffffff813510af>] ? cpuacct_account_field+0x12f/0x1a0
           [<ffffffff816b05a0>] ? ioctl_preallocate+0x200/0x200
           [<ffffffff81002f2f>] ? syscall_trace_enter+0x3cf/0xdb0
           [<ffffffff815045ba>] ? __context_tracking_exit.part.4+0x9a/0x1e0
           [<ffffffff81002b60>] ? exit_to_usermode_loop+0x190/0x190
           [<ffffffff82001a97>] ? check_preemption_disabled+0x37/0x1e0
           [<ffffffff81d93889>] ? security_file_ioctl+0x89/0xb0
           [<ffffffff816b167f>] SyS_ioctl+0x8f/0xc0
           [<ffffffff816b15f0>] ? do_vfs_ioctl+0x1050/0x1050
           [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
           [<ffffffff83c32b2a>] entry_SYSCALL64_slow_path+0x25/0x25
          Code: c7 c7 c4 b9 c8 82 48 89 d9 4c 89 ee e8 63 88 7f fe e8 7e 46 7b fe 48 8d 7b 48 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 04 84 c0 7e 65 80 7b 48 00 74 0e e8 52 46
          RIP  [<ffffffff82c8ba07>] snd_hrtimer_start+0x77/0x100
           RSP <ffff8801120c7a60>
          ---[ end trace 5955b08db7f2b029 ]---
      
      This can happen if snd_hrtimer_open() fails to allocate memory and
      returns an error, which is currently not checked by snd_timer_open():
      
          ioctl(SNDRV_TIMER_IOCTL_SELECT)
           - snd_timer_user_tselect()
      	- snd_timer_close()
      	   - snd_hrtimer_close()
      	      - (struct snd_timer *) t->private_data = NULL
              - snd_timer_open()
                 - snd_hrtimer_open()
                    - kzalloc() fails; t->private_data is still NULL
      
          ioctl(SNDRV_TIMER_IOCTL_START)
           - snd_timer_user_start()
      	- snd_timer_start()
      	   - snd_timer_start1()
      	      - snd_hrtimer_start()
      		- t->private_data == NULL // boom
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6138d59d
    • Vegard Nossum's avatar
      ALSA: timer: fix division by zero after SNDRV_TIMER_IOCTL_CONTINUE · 2350481b
      Vegard Nossum authored
      [ Upstream commit 6b760bb2 ]
      
      I got this:
      
          divide error: 0000 [#1] PREEMPT SMP KASAN
          CPU: 1 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #189
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
          task: ffff8801120a9580 task.stack: ffff8801120b0000
          RIP: 0010:[<ffffffff82c8bd9a>]  [<ffffffff82c8bd9a>] snd_hrtimer_callback+0x1da/0x3f0
          RSP: 0018:ffff88011aa87da8  EFLAGS: 00010006
          RAX: 0000000000004f76 RBX: ffff880112655e88 RCX: 0000000000000000
          RDX: 0000000000000000 RSI: ffff880112655ea0 RDI: 0000000000000001
          RBP: ffff88011aa87e00 R08: ffff88013fff905c R09: ffff88013fff9048
          R10: ffff88013fff9050 R11: 00000001050a7b8c R12: ffff880114778a00
          R13: ffff880114778ab4 R14: ffff880114778b30 R15: 0000000000000000
          FS:  00007f071647c700(0000) GS:ffff88011aa80000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          CR2: 0000000000603001 CR3: 0000000112021000 CR4: 00000000000006e0
          Stack:
           0000000000000000 ffff880114778ab8 ffff880112655ea0 0000000000004f76
           ffff880112655ec8 ffff880112655e80 ffff880112655e88 ffff88011aa98fc0
           00000000b97ccf2b dffffc0000000000 ffff88011aa98fc0 ffff88011aa87ef0
          Call Trace:
           <IRQ>
           [<ffffffff813abce7>] __hrtimer_run_queues+0x347/0xa00
           [<ffffffff82c8bbc0>] ? snd_hrtimer_close+0x130/0x130
           [<ffffffff813ab9a0>] ? retrigger_next_event+0x1b0/0x1b0
           [<ffffffff813ae1a6>] ? hrtimer_interrupt+0x136/0x4b0
           [<ffffffff813ae220>] hrtimer_interrupt+0x1b0/0x4b0
           [<ffffffff8120f91e>] local_apic_timer_interrupt+0x6e/0xf0
           [<ffffffff81227ad3>] ? kvm_guest_apic_eoi_write+0x13/0xc0
           [<ffffffff83c35086>] smp_apic_timer_interrupt+0x76/0xa0
           [<ffffffff83c3416c>] apic_timer_interrupt+0x8c/0xa0
           <EOI>
           [<ffffffff83c3239c>] ? _raw_spin_unlock_irqrestore+0x2c/0x60
           [<ffffffff82c8185d>] snd_timer_start1+0xdd/0x670
           [<ffffffff82c87015>] snd_timer_continue+0x45/0x80
           [<ffffffff82c88100>] snd_timer_user_ioctl+0x1030/0x2830
           [<ffffffff8159f3a0>] ? __follow_pte.isra.49+0x430/0x430
           [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
           [<ffffffff815a26fa>] ? do_wp_page+0x3aa/0x1c90
           [<ffffffff815aa4f8>] ? handle_mm_fault+0xbc8/0x27f0
           [<ffffffff815a9930>] ? __pmd_alloc+0x370/0x370
           [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
           [<ffffffff816b0733>] do_vfs_ioctl+0x193/0x1050
           [<ffffffff816b05a0>] ? ioctl_preallocate+0x200/0x200
           [<ffffffff81002f2f>] ? syscall_trace_enter+0x3cf/0xdb0
           [<ffffffff815045ba>] ? __context_tracking_exit.part.4+0x9a/0x1e0
           [<ffffffff81002b60>] ? exit_to_usermode_loop+0x190/0x190
           [<ffffffff82001a97>] ? check_preemption_disabled+0x37/0x1e0
           [<ffffffff81d93889>] ? security_file_ioctl+0x89/0xb0
           [<ffffffff816b167f>] SyS_ioctl+0x8f/0xc0
           [<ffffffff816b15f0>] ? do_vfs_ioctl+0x1050/0x1050
           [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
           [<ffffffff83c32b2a>] entry_SYSCALL64_slow_path+0x25/0x25
          Code: e8 fc 42 7b fe 8b 0d 06 8a 50 03 49 0f af cf 48 85 c9 0f 88 7c 01 00 00 48 89 4d a8 e8 e0 42 7b fe 48 8b 45 c0 48 8b 4d a8 48 99 <48> f7 f9 49 01 c7 e8 cb 42 7b fe 48 8b 55 d0 48 b8 00 00 00 00
          RIP  [<ffffffff82c8bd9a>] snd_hrtimer_callback+0x1da/0x3f0
           RSP <ffff88011aa87da8>
          ---[ end trace 6aa380f756a21074 ]---
      
      The problem happens when you call ioctl(SNDRV_TIMER_IOCTL_CONTINUE) on a
      completely new/unused timer -- it will have ->sticks == 0, which causes a
      divide by 0 in snd_hrtimer_callback().
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      2350481b
    • Simon Baatz's avatar
      ARM: kirkwood: ib62x0: fix size of u-boot environment partition · 8773752e
      Simon Baatz authored
      [ Upstream commit a7789378 ]
      
      Commit 148c274e ("ARM: kirkwood: ib62x0: add u-boot environment
      partition") split the "u-boot" partition into "u-boot" and "u-boot
      environment".  However, instead of the size of the environment, an offset
      was given, resulting in overlapping partitions.
      Signed-off-by: default avatarSimon Baatz <gmbnomis@gmail.com>
      Fixes: 148c274e ("ARM: kirkwood: ib62x0: add u-boot environment partition")
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Gregory Clement <gregory.clement@free-electrons.com>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: Luka Perkov <luka@openwrt.org>
      Cc: stable@vger.kernel.org # 3.13+
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      8773752e
    • Miklos Szeredi's avatar
      fuse: direct-io: don't dirty ITER_BVEC pages · 7933dd87
      Miklos Szeredi authored
      [ Upstream commit 8fba54ae ]
      
      When reading from a loop device backed by a fuse file it deadlocks on
      lock_page().
      
      This is because the page is already locked by the read() operation done on
      the loop device.  In this case we don't want to either lock the page or
      dirty it.
      
      So do what fs/direct-io.c does: only dirty the page for ITER_IOVEC vectors.
      Reported-by: default avatarSheng Yang <sheng@yasker.org>
      Fixes: aa4d8616 ("block: loop: switch to VFS ITER_BVEC")
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Cc: <stable@vger.kernel.org> # v4.1+
      Reviewed-by: default avatarSheng Yang <sheng@yasker.org>
      Reviewed-by: default avatarAshish Samant <ashish.samant@oracle.com>
      Tested-by: default avatarSheng Yang <sheng@yasker.org>
      Tested-by: default avatarAshish Samant <ashish.samant@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7933dd87
    • Felix Fietkau's avatar
      ath9k: fix using sta->drv_priv before initializing it · bb5c68e0
      Felix Fietkau authored
      [ Upstream commit 7711aaf0 ]
      
      A station pointer can be passed to the driver on tx, before it has been
      marked as associated. Since ath9k_sta_state was initializing the entry
      too late, it resulted in some spurious crashes.
      
      Fixes: df3c6eb3 ("ath9k: Use sta_state() callback")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      bb5c68e0
    • Pawel Moll's avatar
      bus: arm-ccn: Fix XP watchpoint settings bitmask · c3e7a0e5
      Pawel Moll authored
      [ Upstream commit b928466b ]
      
      The code setting XP watchpoint comparator and mask registers should, in
      order to be fully compliant with specification, zero one or more most
      significant bits of each field. In both L cases it means zeroing bit 63.
      The bitmask doing this was wrong, though, zeroing bit 60 instead.
      Fortunately, due to a lucky coincidence, this turned out to be fairly
      innocent with the existing hardware.
      
      Fixed now.
      
      Cc: stable@vger.kernel.org # 3.17+
      Signed-off-by: default avatarPawel Moll <pawel.moll@arm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c3e7a0e5
    • Pawel Moll's avatar
      bus: arm-ccn: Do not attempt to configure XPs for cycle counter · b9d45ce3
      Pawel Moll authored
      [ Upstream commit b7c1beb2 ]
      
      Fuzzing the CCN perf driver revealed a small but definitely dangerous
      mistake in the event setup code. When a cycle counter is requested, the
      driver should not reconfigure the events bus at all, otherwise it will
      corrupt (in most but the simplest cases) its configuration and may end
      up accessing XP array out of its bounds and corrupting control
      registers.
      Reported-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Tested-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: stable@vger.kernel.org # 3.17+
      Signed-off-by: default avatarPawel Moll <pawel.moll@arm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b9d45ce3
    • Tyrel Datwyler's avatar
      scsi: fix upper bounds check of sense key in scsi_sense_key_string() · 0dd4c68f
      Tyrel Datwyler authored
      [ Upstream commit a87eeb90 ]
      
      Commit 655ee63c ("scsi constants: command, sense key + additional
      sense string") added a "Completed" sense string with key 0xF to
      snstext[], but failed to updated the upper bounds check of the sense key
      in scsi_sense_key_string().
      
      Fixes: 655ee63c ("[SCSI] scsi constants: command, sense key + additional sense strings")
      Cc: <stable@vger.kernel.org> # v3.12+
      Signed-off-by: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Reviewed-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      0dd4c68f
    • Johannes Berg's avatar
      Revert "wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel" · cfad3a5a
      Johannes Berg authored
      [ Upstream commit 4d0bd46a ]
      
      This reverts commit 3d5fdff4.
      
      Ben Hutchings pointed out that the commit isn't safe since it assumes
      that the structure used by the driver is iw_point, when in fact there's
      no way to know about that.
      
      Fortunately, the only driver in the tree that ever runs this code path
      is the wilc1000 staging driver, so it doesn't really matter.
      
      Clearly I should have investigated this better before applying, sorry.
      Reported-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Cc: stable@vger.kernel.org [though I guess it doesn't matter much]
      Fixes: 3d5fdff4 ("wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      cfad3a5a
    • Sebastian Reichel's avatar
      ARM: OMAP3: hwmod data: Add sysc information for DSI · bd2d7040
      Sebastian Reichel authored
      [ Upstream commit b46211d6 ]
      
      Add missing sysconfig/sysstatus information
      to OMAP3 hwmod. The information has been
      checked against OMAP34xx and OMAP36xx TRM.
      
      Without this change DSI block is not reset
      during boot, which is required for working
      Nokia N950 display.
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      bd2d7040
  2. 18 Sep, 2016 1 commit
    • James Hogan's avatar
      MIPS: KVM: Check for pfn noslot case · 3b23ff99
      James Hogan authored
      commit ba913e4f upstream.
      
      When mapping a page into the guest we error check using is_error_pfn(),
      however this doesn't detect a value of KVM_PFN_NOSLOT, indicating an
      error HVA for the page. This can only happen on MIPS right now due to
      unusual memslot management (e.g. being moved / removed / resized), or
      with an Enhanced Virtual Memory (EVA) configuration where the default
      KVM_HVA_ERR_* and kvm_is_error_hva() definitions are unsuitable (fixed
      in a later patch). This case will be treated as a pfn of zero, mapping
      the first page of physical memory into the guest.
      
      It would appear the MIPS KVM port wasn't updated prior to being merged
      (in v3.10) to take commit 81c52c56 ("KVM: do not treat noslot pfn as
      a error pfn") into account (merged v3.8), which converted a bunch of
      is_error_pfn() calls to is_error_noslot_pfn(). Switch to using
      is_error_noslot_pfn() instead to catch this case properly.
      
      Fixes: 858dd5d4 ("KVM/MIPS32: MMU/TLB operations for the Guest.")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "Radim Krčmář" <rkrcmar@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      [james.hogan@imgtec.com: Backport to v4.7.y]
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      3b23ff99
  3. 17 Sep, 2016 1 commit
  4. 15 Sep, 2016 15 commits
  5. 12 Sep, 2016 6 commits