linux-toradex.git/drivers, branch v4.9.25

device-dax: switch to srcu, fix rcu_read_lock() vs pte allocation

2017-04-27T07:10:39+00:00

commit 956a4cd2c957acf638ff29951aabaa9d8e92bbc2 upstream.

The following warning triggers with a new unit test that stresses the
device-dax interface.

 ===============================
 [ ERR: suspicious RCU usage.  ]
 4.11.0-rc4+ #1049 Tainted: G           O
 -------------------------------
 ./include/linux/rcupdate.h:521 Illegal context switch in RCU read-side critical section!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 0
 2 locks held by fio/9070:
  #0:  (&mm->mmap_sem){++++++}, at: [] __do_page_fault+0x167/0x4f0
  #1:  (rcu_read_lock){......}, at: [] dax_dev_huge_fault+0x32/0x620 [dax]

 Call Trace:
  dump_stack+0x86/0xc3
  lockdep_rcu_suspicious+0xd7/0x110
  ___might_sleep+0xac/0x250
  __might_sleep+0x4a/0x80
  __alloc_pages_nodemask+0x23a/0x360
  alloc_pages_current+0xa1/0x1f0
  pte_alloc_one+0x17/0x80
  __pte_alloc+0x1e/0x120
  __get_locked_pte+0x1bf/0x1d0
  insert_pfn.isra.70+0x3a/0x100
  ? lookup_memtype+0xa6/0xd0
  vm_insert_mixed+0x64/0x90
  dax_dev_huge_fault+0x520/0x620 [dax]
  ? dax_dev_huge_fault+0x32/0x620 [dax]
  dax_dev_fault+0x10/0x20 [dax]
  __do_fault+0x1e/0x140
  __handle_mm_fault+0x9af/0x10d0
  handle_mm_fault+0x16d/0x370
  ? handle_mm_fault+0x47/0x370
  __do_page_fault+0x28c/0x4f0
  trace_do_page_fault+0x58/0x2a0
  do_async_page_fault+0x1a/0xa0
  async_page_fault+0x28/0x30

Inserting a page table entry may trigger an allocation while we are
holding a read lock to keep the device instance alive for the duration
of the fault. Use srcu for this keep-alive protection.

Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

ubi/upd: Always flush after prepared for an update

2017-04-27T07:10:38+00:00

commit 9cd9a21ce070be8a918ffd3381468315a7a76ba6 upstream.

In commit 6afaf8a484cb ("UBI: flush wl before clearing update marker") I
managed to trigger and fix a similar bug. Now here is another version of
which I assumed it wouldn't matter back then but it turns out UBI has a
check for it and will error out like this:

|ubi0 warning: validate_vid_hdr: inconsistent used_ebs
|ubi0 error: validate_vid_hdr: inconsistent VID header at PEB 592

All you need to trigger this is? "ubiupdatevol /dev/ubi0_0 file" + a
powercut in the middle of the operation.
ubi_start_update() sets the update-marker and puts all EBs on the erase
list. After that userland can proceed to write new data while the old EB
aren't erased completely. A powercut at this point is usually not that
much of a tragedy. UBI won't give read access to the static volume
because it has the update marker. It will most likely set the corrupted
flag because it misses some EBs.
So we are all good. Unless the size of the image that has been written
differs from the old image in the magnitude of at least one EB. In that
case UBI will find two different values for `used_ebs' and refuse to
attach the image with the error message mentioned above.

So in order not to get in the situation, the patch will ensure that we
wait until everything is removed before it tries to write any data.
The alternative would be to detect such a case and remove all EBs at the
attached time after we processed the volume-table and see the
update-marker set. The patch looks bigger and I doubt it is worth it
since usually the write() will wait from time to time for a new EB since
usually there not that many spare EB that can be used.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-esdhc-imx: increase the pad I/O drive strength for DDR50 card

2017-04-27T07:10:38+00:00

commit 9f327845358d3dd0d8a5a7a5436b0aa5c432e757 upstream.

Currently for DDR50 card, it need tuning in default. We meet tuning fail
issue for DDR50 card and some data CRC error when DDR50 sd card works.

This is because the default pad I/O drive strength can't make sure DDR50
card work stable. So increase the pad I/O drive strength for DDR50 card,
and use pins_100mhz.

This fixes DDR50 card support for IMX since DDR50 tuning was enabled from
commit 9faac7b95ea4 ("mmc: sdhci: enable tuning for DDR50")

Tested-and-reported-by: Tim Harvey 
Signed-off-by: Haibo Chen 
Acked-by: Dong Aisheng 
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

ACPI / power: Avoid maybe-uninitialized warning

2017-04-27T07:10:38+00:00

commit fe8c470ab87d90e4b5115902dd94eced7e3305c3 upstream.

gcc -O2 cannot always prove that the loop in acpi_power_get_inferred_state()
is enterered at least once, so it assumes that cur_state might not get
initialized:

drivers/acpi/power.c: In function 'acpi_power_get_inferred_state':
drivers/acpi/power.c:222:9: error: 'cur_state' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This sets the variable to zero at the start of the loop, to ensure that
there is well-defined behavior even for an empty list. This gets rid of
the warning.

The warning first showed up when the -Os flag got removed in a bug fix
patch in linux-4.11-rc5.

I would suggest merging this addon patch on top of that bug fix to avoid
introducing a new warning in the stable kernels.

Fixes: 61b79e16c68d (ACPI: Fix incompatibility with mcount-based function graph tracing)
Signed-off-by: Arnd Bergmann 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled

2017-04-27T07:10:38+00:00

commit 704de489e0e3640a2ee2d0daf173e9f7375582ba upstream.

Temporary got a Lifebook E547 into my hands and noticed the touchpad
only works after running:

	echo "1" > /sys/devices/platform/i8042/serio2/crc_enabled

Add it to the list of machines that need this workaround.

Signed-off-by: Thorsten Leemhuis 
Reviewed-by: Ulrik De Bie 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

virtio-console: avoid DMA from stack

2017-04-21T07:31:24+00:00

commit c4baad50297d84bde1a7ad45e50c73adae4a2192 upstream.

put_chars() stuffs the buffer it gets into an sg, but that buffer may be
on the stack. This breaks with CONFIG_VMAP_STACK=y (for me, it
manifested as printks getting turned into NUL bytes).

Signed-off-by: Omar Sandoval 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Amit Shah 
Cc: Ben Hutchings 
Cc: Brad Spengler 
Signed-off-by: Greg Kroah-Hartman

cxusb: Use a dma capable buffer also for reading

2017-04-21T07:31:24+00:00

commit 3f190e3aec212fc8c61e202c51400afa7384d4bc upstream.

Commit 17ce039b4e54 ("[media] cxusb: don't do DMA on stack")
added a kmalloc'ed bounce buffer for writes, but missed to do the same
for reads. As the read only happens after the write is finished, we can
reuse the same buffer.

As dvb_usb_generic_rw handles a read length of 0 by itself, avoid calling
it using the dvb_usb_generic_read wrapper function.

Signed-off-by: Stefan Brüns 
Signed-off-by: Mauro Carvalho Chehab 
Cc: Ben Hutchings 
Cc: Brad Spengler 
Signed-off-by: Greg Kroah-Hartman

dvb-usb-firmware: don't do DMA on stack

2017-04-21T07:31:24+00:00

commit 67b0503db9c29b04eadfeede6bebbfe5ddad94ef upstream.

The buffer allocation for the firmware data was changed in
commit 43fab9793c1f ("[media] dvb-usb: don't use stack for firmware load")
but the same applies for the reset value.

Fixes: 43fab9793c1f ("[media] dvb-usb: don't use stack for firmware load")
Signed-off-by: Stefan Brüns 
Signed-off-by: Mauro Carvalho Chehab 
Cc: Ben Hutchings 
Cc: Brad Spengler 
Signed-off-by: Greg Kroah-Hartman

dvb-usb: don't use stack for firmware load

2017-04-21T07:31:24+00:00

commit 43fab9793c1f44e665b4f98035a14942edf03ddc upstream.

As reported by Marc Duponcheel , firmware load on
dvb-usb is using the stack, with is not allowed anymore on default
Kernel configurations:

[ 1025.958836] dvb-usb: found a 'WideView WT-220U PenType Receiver (based on ZL353)' in cold state, will try to load a firmware
[ 1025.958853] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw'
[ 1025.958855] dvb-usb: could not stop the USB controller CPU.
[ 1025.958856] dvb-usb: error while transferring firmware (transferred size: -11, block size: 3)
[ 1025.958856] dvb-usb: firmware download failed at 8 with -22
[ 1025.958867] usbcore: registered new interface driver dvb_usb_dtt200u

[    2.789902] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw'
[    2.789905] ------------[ cut here ]------------
[    2.789911] WARNING: CPU: 3 PID: 2196 at drivers/usb/core/hcd.c:1584 usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore]
[    2.789912] transfer buffer not dma capable
[    2.789912] Modules linked in: btusb dvb_usb_dtt200u(+) dvb_usb_af9035(+) btrtl btbcm dvb_usb dvb_usb_v2 btintel dvb_core bluetooth rc_core rfkill x86_pkg_temp_thermal intel_powerclamp coretemp crc32_pclmul aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd drm_kms_helper syscopyarea sysfillrect pcspkr i2c_i801 sysimgblt fb_sys_fops drm i2c_smbus i2c_core r8169 lpc_ich mfd_core mii thermal fan rtc_cmos video button acpi_cpufreq processor snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd crc32c_intel ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd usbcore usb_common dm_mirror dm_region_hash dm_log dm_mod
[    2.789936] CPU: 3 PID: 2196 Comm: systemd-udevd Not tainted 4.9.0-gentoo #1
[    2.789937] Hardware name: ASUS All Series/H81I-PLUS, BIOS 0401 07/23/2013
[    2.789938]  ffffc9000339b690 ffffffff812bd397 ffffc9000339b6e0 0000000000000000
[    2.789939]  ffffc9000339b6d0 ffffffff81055c86 000006300339b6a0 ffff880116c0c000
[    2.789941]  0000000000000000 0000000000000000 0000000000000001 ffff880116c08000
[    2.789942] Call Trace:
[    2.789945]  [] dump_stack+0x4d/0x66
[    2.789947]  [] __warn+0xc6/0xe0
[    2.789948]  [] warn_slowpath_fmt+0x4a/0x50
[    2.789952]  [] usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore]
[    2.789954]  [] ? io_schedule_timeout+0xd8/0x110
[    2.789956]  [] usb_hcd_submit_urb+0x9c/0x980 [usbcore]
[    2.789958]  [] ? copy_page_to_iter+0x14f/0x2b0
[    2.789960]  [] ? pagecache_get_page+0x28/0x240
[    2.789962]  [] ? touch_atime+0x20/0xa0
[    2.789964]  [] usb_submit_urb+0x2c4/0x520 [usbcore]
[    2.789967]  [] usb_start_wait_urb+0x5a/0xe0 [usbcore]
[    2.789969]  [] usb_control_msg+0xbc/0xf0 [usbcore]
[    2.789970]  [] usb_cypress_writemem+0x3d/0x40 [dvb_usb]
[    2.789972]  [] usb_cypress_load_firmware+0x4f/0x130 [dvb_usb]
[    2.789973]  [] ? console_unlock+0x2fe/0x5d0
[    2.789974]  [] ? vprintk_emit+0x27c/0x410
[    2.789975]  [] ? vprintk_default+0x1a/0x20
[    2.789976]  [] ? printk+0x43/0x4b
[    2.789977]  [] dvb_usb_download_firmware+0x60/0xd0 [dvb_usb]
[    2.789979]  [] dvb_usb_device_init+0x3d8/0x610 [dvb_usb]
[    2.789981]  [] dtt200u_usb_probe+0x92/0xd0 [dvb_usb_dtt200u]
[    2.789984]  [] usb_probe_interface+0xfc/0x270 [usbcore]
[    2.789985]  [] driver_probe_device+0x215/0x2d0
[    2.789986]  [] __driver_attach+0x96/0xa0
[    2.789987]  [] ? driver_probe_device+0x2d0/0x2d0
[    2.789988]  [] bus_for_each_dev+0x5b/0x90
[    2.789989]  [] driver_attach+0x19/0x20
[    2.789990]  [] bus_add_driver+0x11c/0x220
[    2.789991]  [] driver_register+0x5b/0xd0
[    2.789994]  [] usb_register_driver+0x7c/0x130 [usbcore]
[    2.789994]  [] ? 0xffffffffa06a5000
[    2.789996]  [] dtt200u_usb_driver_init+0x1e/0x20 [dvb_usb_dtt200u]
[    2.789997]  [] do_one_initcall+0x38/0x140
[    2.789998]  [] ? __vunmap+0x7c/0xc0
[    2.789999]  [] ? do_init_module+0x22/0x1d2
[    2.790000]  [] do_init_module+0x5a/0x1d2
[    2.790002]  [] load_module+0x1e11/0x2580
[    2.790003]  [] ? show_taint+0x30/0x30
[    2.790004]  [] ? kernel_read_file+0x100/0x190
[    2.790005]  [] SyS_finit_module+0xba/0xc0
[    2.790007]  [] entry_SYSCALL_64_fastpath+0x13/0x94
[    2.790008] ---[ end trace c78a74e78baec6fc ]---

So, allocate the structure dynamically.

Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 4.9: adjust context]
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

mm: Tighten x86 /dev/mem with zeroing reads

2017-04-21T07:31:24+00:00

commit a4866aa812518ed1a37d8ea0c881dc946409de94 upstream.

Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
disallowed. However, on x86, the first 1MB was always allowed for BIOS
and similar things, regardless of it actually being System RAM. It was
possible for heap to end up getting allocated in low 1MB RAM, and then
read by things like x86info or dd, which would trip hardened usercopy:

usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes)

This changes the x86 exception for the low 1MB by reading back zeros for
System RAM areas instead of blindly allowing them. More work is needed to
extend this to mmap, but currently mmap doesn't go through usercopy, so
hardened usercopy won't Oops the kernel.

Reported-by: Tommi Rantala 
Tested-by: Tommi Rantala 
Signed-off-by: Kees Cook 
Cc: Brad Spengler 
Signed-off-by: Greg Kroah-Hartman