~thopiekar/linux/+git/linux-stable:linux-4.3.y

Last commit made on 2016-02-19
Get this branch:
git clone -b linux-4.3.y https://git.launchpad.net/~thopiekar/linux/+git/linux-stable

Branch merges

Branch information

Name:
linux-4.3.y
Repository:
lp:~thopiekar/linux/+git/linux-stable

Recent commits

49f9ae9... by Greg Kroah-Hartman <email address hidden>

Linux 4.3.6

1c141a1... by Benjamin Tissoires <email address hidden>

HID: multitouch: fix input mode switching on some Elan panels

commit 73e7d63efb4d774883a338997943bfa59e127085 upstream.

as reported by https://bugzilla.kernel.org/show_bug.cgi?id=108481

This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature
reports on demand for Win8 devices") as the origin of the problem but this
commit actually masked 2 firmware bugs that are annihilating each other:

The report descriptor declares two features in reports 3 and 5:

0x05, 0x0d, // Usage Page (Digitizers) 318
0x09, 0x0e, // Usage (Device Configuration) 320
0xa1, 0x01, // Collection (Application) 322
0x85, 0x03, // Report ID (3) 324
0x09, 0x22, // Usage (Finger) 326
0xa1, 0x00, // Collection (Physical) 328
0x09, 0x52, // Usage (Inputmode) 330
0x15, 0x00, // Logical Minimum (0) 332
0x25, 0x0a, // Logical Maximum (10) 334
0x75, 0x08, // Report Size (8) 336
0x95, 0x02, // Report Count (2) 338
0xb1, 0x02, // Feature (Data,Var,Abs) 340
0xc0, // End Collection 342
0x09, 0x22, // Usage (Finger) 343
0xa1, 0x00, // Collection (Physical) 345
0x85, 0x05, // Report ID (5) 347
0x09, 0x57, // Usage (Surface Switch) 349
0x09, 0x58, // Usage (Button Switch) 351
0x15, 0x00, // Logical Minimum (0) 353
0x75, 0x01, // Report Size (1) 355
0x95, 0x02, // Report Count (2) 357
0x25, 0x03, // Logical Maximum (3) 359
0xb1, 0x02, // Feature (Data,Var,Abs) 361
0x95, 0x0e, // Report Count (14) 363
0xb1, 0x03, // Feature (Cnst,Var,Abs) 365
0xc0, // End Collection 367

The report ID 3 presents 2 input mode features, while only the first one
is handled by the device. Given that we did not checked if one was
previously assigned, we were dealing with the ignored featured and we
should never have been able to switch this panel into the multitouch mode.

However, the firmware presents an other bugs which allowed 6d4f5440
to counteract the faulty report descriptor. When we request the values
of the feature 5, the firmware answers "03 03 00". The fields are correct
but the report id is wrong. Before 6d4f5440, we retrieved all the features
and injected them in the system. So when we called report 5, we injected
in the system the report 3 with the values "03 00".
Setting the second input mode to 03 in this report changed it to "03 03"
and the touchpad switched to the mt mode. We could have set anything
in the second field because the actual value (the first 03 in this report)
was given by the query of report ID 5.

To sum up: 2 bugs in the firmware were hiding that we were accessing the
wrong feature.

Signed-off-by: Benjamin Tissoires <email address hidden>
Signed-off-by: Jiri Kosina <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

3123ba7... by Tetsuo Handa <email address hidden>

mm, vmstat: fix wrong WQ sleep when memory reclaim doesn't make any progress

commit 564e81a57f9788b1475127012e0fd44e9049e342 upstream.

Jan Stancek has reported that system occasionally hanging after "oom01"
testcase from LTP triggers OOM. Guessing from a result that there is a
kworker thread doing memory allocation and the values between "Node 0
Normal free:" and "Node 0 Normal:" differs when hanging, vmstat is not
up-to-date for some reason.

According to commit 373ccbe59270 ("mm, vmstat: allow WQ concurrency to
discover memory reclaim doesn't make any progress"), it meant to force
the kworker thread to take a short sleep, but it by error used
schedule_timeout(1). We missed that schedule_timeout() in state
TASK_RUNNING doesn't do anything.

Fix it by using schedule_timeout_uninterruptible(1) which forces the
kworker thread to take a short sleep in order to make sure that vmstat
is up-to-date.

Fixes: 373ccbe59270 ("mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress")
Signed-off-by: Tetsuo Handa <email address hidden>
Reported-by: Jan Stancek <email address hidden>
Acked-by: Michal Hocko <email address hidden>
Cc: Tejun Heo <email address hidden>
Cc: Cristopher Lameter <email address hidden>
Cc: Joonsoo Kim <email address hidden>
Cc: Arkadiusz Miskiewicz <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

881a1fb... by "Maciej W. Rozycki" <email address hidden>

binfmt_elf: Don't clobber passed executable's file header

commit b582ef5c53040c5feef4c96a8f9585b6831e2441 upstream.

Do not clobber the buffer space passed from `search_binary_handler' and
originally preloaded by `prepare_binprm' with the executable's file
header by overwriting it with its interpreter's file header. Instead
keep the buffer space intact and directly use the data structure locally
allocated for the interpreter's file header, fixing a bug introduced in
2.1.14 with loadable module support (linux-mips.org commit beb11695
[Import of Linux/MIPS 2.1.14], predating kernel.org repo's history).
Adjust the amount of data read from the interpreter's file accordingly.

This was not an issue before loadable module support, because back then
`load_elf_binary' was executed only once for a given ELF executable,
whether the function succeeded or failed.

With loadable module support supported and enabled, upon a failure of
`load_elf_binary' -- which may for example be caused by architecture
code rejecting an executable due to a missing hardware feature requested
in the file header -- a module load is attempted and then the function
reexecuted by `search_binary_handler'. With the executable's file
header replaced with its interpreter's file header the executable can
then be erroneously accepted in this subsequent attempt.

Signed-off-by: Maciej W. Rozycki <email address hidden>
Signed-off-by: Al Viro <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

dc0f7c5... by Eric Biggers

fs/pipe.c: return error code rather than 0 in pipe_write()

commit 6ae08069939f17422835448acae76bda8d96b16a upstream.

pipe_write() would return 0 if it failed to merge the beginning of the
data to write with the last, partially filled pipe buffer. It should
return an error code instead. Userspace programs could be confused by
write() returning 0 when called with a nonzero 'count'.

The EFAULT error case was a regression from f0d1bec9d5 ("new helper:
copy_page_from_iter()"), while the ops->confirm() error case was a much
older bug.

Test program:

 #include <assert.h>
 #include <errno.h>
 #include <unistd.h>

 int main(void)
 {
  int fd[2];
  char data[1] = {0};

  assert(0 == pipe(fd));
  assert(1 == write(fd[1], data, 1));

  /* prior to this patch, write() returned 0 here */
  assert(-1 == write(fd[1], NULL, 1));
  assert(errno == EFAULT);
 }

Signed-off-by: Eric Biggers <email address hidden>
Signed-off-by: Al Viro <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

d5c7bab... by Junil Lee <email address hidden>

zsmalloc: fix migrate_zspage-zs_free race condition

commit c102f07ca0b04f2cb49cfc161c83f6239d17f491 upstream.

record_obj() in migrate_zspage() does not preserve handle's
HANDLE_PIN_BIT, set by find_aloced_obj()->trypin_tag(), and implicitly
(accidentally) un-pins the handle, while migrate_zspage() still performs
an explicit unpin_tag() on the that handle. This additional explicit
unpin_tag() introduces a race condition with zs_free(), which can pin
that handle by this time, so the handle becomes un-pinned.

Schematically, it goes like this:

  CPU0 CPU1
  migrate_zspage
    find_alloced_obj
      trypin_tag
        set HANDLE_PIN_BIT zs_free()
                                                pin_tag()
  obj_malloc() -- new object, no tag
  record_obj() -- remove HANDLE_PIN_BIT set HANDLE_PIN_BIT
  unpin_tag() -- remove zs_free's HANDLE_PIN_BIT

The race condition may result in a NULL pointer dereference:

  Unable to handle kernel NULL pointer dereference at virtual address 00000000
  CPU: 0 PID: 19001 Comm: CookieMonsterCl Tainted:
  PC is at get_zspage_mapping+0x0/0x24
  LR is at obj_free.isra.22+0x64/0x128
  Call trace:
     get_zspage_mapping+0x0/0x24
     zs_free+0x88/0x114
     zram_free_page+0x64/0xcc
     zram_slot_free_notify+0x90/0x108
     swap_entry_free+0x278/0x294
     free_swap_and_cache+0x38/0x11c
     unmap_single_vma+0x480/0x5c8
     unmap_vmas+0x44/0x60
     exit_mmap+0x50/0x110
     mmput+0x58/0xe0
     do_exit+0x320/0x8dc
     do_group_exit+0x44/0xa8
     get_signal+0x538/0x580
     do_signal+0x98/0x4b8
     do_notify_resume+0x14/0x5c

This patch keeps the lock bit in migration path and update value
atomically.

Signed-off-by: Junil Lee <email address hidden>
Signed-off-by: Minchan Kim <email address hidden>
Acked-by: Vlastimil Babka <email address hidden>
Cc: Sergey Senozhatsky <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

b3143ec... by Jerome Marchand <email address hidden>

zram: don't call idr_remove() from zram_remove()

commit 17ec4cd985780a7e30aa45bb8f272237c12502a4 upstream.

The use of idr_remove() is forbidden in the callback functions of
idr_for_each(). It is therefore unsafe to call idr_remove in
zram_remove().

This patch moves the call to idr_remove() from zram_remove() to
hot_remove_store(). In the detroy_devices() path, idrs are removed by
idr_destroy(). This solves an use-after-free detected by KASan.

[<email address hidden>: fix coding stype, per Sergey]
Signed-off-by: Jerome Marchand <email address hidden>
Acked-by: Sergey Senozhatsky <email address hidden>
Cc: Minchan Kim <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

5b243a2... by Kyeongdon Kim <email address hidden>

zram: try vmalloc() after kmalloc()

commit d913897abace843bba20249f3190167f7895e9c3 upstream.

When we're using LZ4 multi compression streams for zram swap, we found
out page allocation failure message in system running test. That was
not only once, but a few(2 - 5 times per test). Also, some failure
cases were continually occurring to try allocation order 3.

In order to make parallel compression private data, we should call
kzalloc() with order 2/3 in runtime(lzo/lz4). But if there is no order
2/3 size memory to allocate in that time, page allocation fails. This
patch makes to use vmalloc() as fallback of kmalloc(), this prevents
page alloc failure warning.

After using this, we never found warning message in running test, also
It could reduce process startup latency about 60-120ms in each case.

For reference a call trace :

    Binder_1: page allocation failure: order:3, mode:0x10c0d0
    CPU: 0 PID: 424 Comm: Binder_1 Tainted: GW 3.10.49-perf-g991d02b-dirty #20
    Call trace:
      dump_backtrace+0x0/0x270
      show_stack+0x10/0x1c
      dump_stack+0x1c/0x28
      warn_alloc_failed+0xfc/0x11c
      __alloc_pages_nodemask+0x724/0x7f0
      __get_free_pages+0x14/0x5c
      kmalloc_order_trace+0x38/0xd8
      zcomp_lz4_create+0x2c/0x38
      zcomp_strm_alloc+0x34/0x78
      zcomp_strm_multi_find+0x124/0x1ec
      zcomp_strm_find+0xc/0x18
      zram_bvec_rw+0x2fc/0x780
      zram_make_request+0x25c/0x2d4
      generic_make_request+0x80/0xbc
      submit_bio+0xa4/0x15c
      __swap_writepage+0x218/0x230
      swap_writepage+0x3c/0x4c
      shrink_page_list+0x51c/0x8d0
      shrink_inactive_list+0x3f8/0x60c
      shrink_lruvec+0x33c/0x4cc
      shrink_zone+0x3c/0x100
      try_to_free_pages+0x2b8/0x54c
      __alloc_pages_nodemask+0x514/0x7f0
      __get_free_pages+0x14/0x5c
      proc_info_read+0x50/0xe4
      vfs_read+0xa0/0x12c
      SyS_read+0x44/0x74
    DMA: 3397*4kB (MC) 26*8kB (RC) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB
         0*512kB 0*1024kB 0*2048kB 0*4096kB = 13796kB

[<email address hidden>: change vmalloc gfp and adding comment about gfp]
[<email address hidden>: tweak comments and styles]
Signed-off-by: Kyeongdon Kim <email address hidden>
Signed-off-by: Minchan Kim <email address hidden>
Acked-by: Sergey Senozhatsky <email address hidden>
Sergey Senozhatsky <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

1e200f6... by Sergey Senozhatsky <email address hidden>

zram/zcomp: use GFP_NOIO to allocate streams

commit 3d5fe03a3ea013060ebba2a811aeb0f23f56aefa upstream.

We can end up allocating a new compression stream with GFP_KERNEL from
within the IO path, which may result is nested (recursive) IO
operations. That can introduce problems if the IO path in question is a
reclaimer, holding some locks that will deadlock nested IOs.

Allocate streams and working memory using GFP_NOIO flag, forbidding
recursive IO and FS operations.

An example:

  inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
  git/20158 [HC0[0]:SC0[0]:HE1:SE1] takes:
   (jbd2_handle){+.+.?.}, at: start_this_handle+0x4ca/0x555
  {IN-RECLAIM_FS-W} state was registered at:
     __lock_acquire+0x8da/0x117b
     lock_acquire+0x10c/0x1a7
     start_this_handle+0x52d/0x555
     jbd2__journal_start+0xb4/0x237
     __ext4_journal_start_sb+0x108/0x17e
     ext4_dirty_inode+0x32/0x61
     __mark_inode_dirty+0x16b/0x60c
     iput+0x11e/0x274
     __dentry_kill+0x148/0x1b8
     shrink_dentry_list+0x274/0x44a
     prune_dcache_sb+0x4a/0x55
     super_cache_scan+0xfc/0x176
     shrink_slab.part.14.constprop.25+0x2a2/0x4d3
     shrink_zone+0x74/0x140
     kswapd+0x6b7/0x930
     kthread+0x107/0x10f
     ret_from_fork+0x3f/0x70
  irq event stamp: 138297
  hardirqs last enabled at (138297): debug_check_no_locks_freed+0x113/0x12f
  hardirqs last disabled at (138296): debug_check_no_locks_freed+0x33/0x12f
  softirqs last enabled at (137818): __do_softirq+0x2d3/0x3e9
  softirqs last disabled at (137813): irq_exit+0x41/0x95

               other info that might help us debug this:
   Possible unsafe locking scenario:
         CPU0
         ----
    lock(jbd2_handle);
    <Interrupt>
      lock(jbd2_handle);

                *** DEADLOCK ***
  5 locks held by git/20158:
   #0: (sb_writers#7){.+.+.+}, at: [<ffffffff81155411>] mnt_want_write+0x24/0x4b
   #1: (&type->i_mutex_dir_key#2/1){+.+.+.}, at: [<ffffffff81145087>] lock_rename+0xd9/0xe3
   #2: (&sb->s_type->i_mutex_key#11){+.+.+.}, at: [<ffffffff8114f8e2>] lock_two_nondirectories+0x3f/0x6b
   #3: (&sb->s_type->i_mutex_key#11/4){+.+.+.}, at: [<ffffffff8114f909>] lock_two_nondirectories+0x66/0x6b
   #4: (jbd2_handle){+.+.?.}, at: [<ffffffff811e31db>] start_this_handle+0x4ca/0x555

               stack backtrace:
  CPU: 2 PID: 20158 Comm: git Not tainted 4.1.0-rc7-next-20150615-dbg-00016-g8bdf555-dirty #211
  Call Trace:
    dump_stack+0x4c/0x6e
    mark_lock+0x384/0x56d
    mark_held_locks+0x5f/0x76
    lockdep_trace_alloc+0xb2/0xb5
    kmem_cache_alloc_trace+0x32/0x1e2
    zcomp_strm_alloc+0x25/0x73 [zram]
    zcomp_strm_multi_find+0xe7/0x173 [zram]
    zcomp_strm_find+0xc/0xe [zram]
    zram_bvec_rw+0x2ca/0x7e0 [zram]
    zram_make_request+0x1fa/0x301 [zram]
    generic_make_request+0x9c/0xdb
    submit_bio+0xf7/0x120
    ext4_io_submit+0x2e/0x43
    ext4_bio_write_page+0x1b7/0x300
    mpage_submit_page+0x60/0x77
    mpage_map_and_submit_buffers+0x10f/0x21d
    ext4_writepages+0xc8c/0xe1b
    do_writepages+0x23/0x2c
    __filemap_fdatawrite_range+0x84/0x8b
    filemap_flush+0x1c/0x1e
    ext4_alloc_da_blocks+0xb8/0x117
    ext4_rename+0x132/0x6dc
    ? mark_held_locks+0x5f/0x76
    ext4_rename2+0x29/0x2b
    vfs_rename+0x540/0x636
    SyS_renameat2+0x359/0x44d
    SyS_rename+0x1e/0x20
    entry_SYSCALL_64_fastpath+0x12/0x6f

[<email address hidden>: add stable mark]
Signed-off-by: Sergey Senozhatsky <email address hidden>
Acked-by: Minchan Kim <email address hidden>
Cc: Kyeongdon Kim <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

233ffe5... by Alexandre Courbot <email address hidden>

drm/nouveau/pmu: do not assume a PMU is present

commit 579b7c58215329803ce184704463de09f0f310ac upstream.

Some devices may not have a PMU. Avoid a NULL pointer dereference in
such cases by checking whether the pointer given to nvkm_pmu_pgob() is
valid.

Signed-off-by: Alexandre Courbot <email address hidden>
Signed-off-by: Ben Skeggs <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>