linux.git/drivers, branch v3.14.31

md/raid5: fetch_block must fetch all the blocks handle_stripe_dirtying wants.

2015-01-30T01:40:53+00:00

commit 108cef3aa41669610e1836fe638812dd067d72de upstream.

It is critical that fetch_block() and handle_stripe_dirtying()
are consistent in their analysis of what needs to be loaded.
Otherwise raid5 can wait forever for a block that won't be loaded.

Currently when writing to a RAID5 that is resyncing, to a location
beyond the resync offset, handle_stripe_dirtying chooses a
reconstruct-write cycle, but fetch_block() assumes a
read-modify-write, and a lockup can happen.

So treat that case just like RAID6, just as we do in
handle_stripe_dirtying.  RAID6 always does reconstruct-write.

This bug was introduced when the behaviour of handle_stripe_dirtying
was changed in 3.7, so the patch is suitable for any kernel since,
though it will need careful merging for some versions.

Cc: stable@vger.kernel.org (v3.7+)
Fixes: a7854487cd7128a30a7f4f5259de9f67d5efb95f
Reported-by: Henry Cai 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: Don't signal the sdio irq if it's not setup

2015-01-30T01:40:51+00:00

[Not needed in newer kernels due to refactoring fixing this issue.]

With 3.14.29 (and older kernels) some of my I.mx6 Sabrelite boards were
crashing with the following oops:

  sdhci: Secure Digital Host Controller Interface driver
  sdhci: Copyright(c) Pierre Ossman
  sdhci-pltfm: SDHCI platform and OF driver helper
  sdhci-esdhc-imx 2198000.usdhc: could not get ultra high speed state, work on normal mode
  mmc0: no vqmmc regulator found
  mmc0: SDHCI controller on 2198000.usdhc [2198000.usdhc] using ADMA
  Unable to handle kernel NULL pointer dereference at virtual address 00000000
  pgd = c0004000
  [00000000] *pgd=00000000
  Internal error: Oops: 5 [#1] SMP ARM
  Modules linked in:
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.29 #1
  task: c08a7120 ti: c089c000 task.ti: c089c000
  PC is at wake_up_process+0x8/0x40
  LR is at sdhci_irq+0x748/0x9c4

Full boot log can be found at:
  http://storage.kernelci.org/stable/v3.14.29/arm-multi_v7_defconfig/lab-collabora/boot-imx6q-sabrelite.html

This happens if the sdhci interrupt status contains SDHCI_INT_CARD_INT,
while the sdio irq was never setup.  This patch fixes that in a minimal
way by checking if the sdio irq was setup.

In more recent kernels this bug went away due to refactoring done by
Russel King. So an alternative (potentially better?) fix for this patch
is to cherrypick the following patches from a recent kernel:

18258f7239a6 - genirq: Provide synchronize_hardirq()
bf3b5ec66bd0 - mmc: sdio_irq: rework sdio irq handling
41005003bcaf - mmc: sdhci: clean up interrupt handling
781e989cf593 - mmc: sdhci: convert to new SDIO IRQ handling

Signed-off-by: Sjoerd Simons 
Cc: Russell King 
Cc: Tyler Baker 
Signed-off-by: Greg Kroah-Hartman

tty: Fix pty master poll() after slave closes v2

2015-01-30T01:40:51+00:00

commit c4dc304677e8d566572c4738d95c48be150c6606 upstream.

Commit f95499c3030f ("n_tty: Don't wait for buffer work in read() loop")
introduces a race window where a pty master can be signalled that the pty
slave was closed before all the data that the slave wrote is delivered.
Commit f8747d4a466a ("tty: Fix pty master read() after slave closes") fixed the
problem in case of n_tty_read, but the problem still exists for n_tty_poll.
This can be seen by running 'for ((i=0; i<100;i++));do ./test.py ;done'
where test.py is:

import os, select, pty

(pid, pty_fd) = pty.fork()

if pid == 0:
   os.write(1, 'This string should be received by parent')
else:
   poller = select.epoll()
   poller.register( pty_fd, select.EPOLLIN )
   ready = poller.poll( 1 * 1000 )
   for fd, events in ready:
      if not events & select.EPOLLIN:
         print 'missed POLLIN event'
      else:
         print os.read(fd, 100)
   poller.close()

The string from the slave is missed several times.
This patch takes the same approach as the fix for read and special cases
this condition for poll.
Tested on 3.16.

Signed-off-by: Francesco Ruggeri 
Cc: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

Input: evdev - fix EVIOCG{type} ioctl

2015-01-30T01:40:50+00:00

commit 7c4f56070fde2367766fa1fb04852599b5e1ad35 upstream.

The 'max' size passed into the function is measured in number of bits
(KEY_MAX, LED_MAX, etc) so we need to convert it accordingly before trying
to copy the data out, otherwise we will try copying too much and end up
with up with a page fault.

Reported-by: Pavel Machek 
Reviewed-by: Pavel Machek 
Reviewed-by: David Herrmann 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

crypto: prefix module autoloading with "crypto-"

2015-01-30T01:40:50+00:00

commit 5d26a105b5a73e5635eae0629b42fa0a90e07b7b upstream.

This prefixes all crypto module loading with "crypto-" so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:

https://lkml.org/lkml/2013/3/4/70

Signed-off-by: Kees Cook 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

drbd: merge_bvec_fn: properly remap bvm->bi_bdev

2015-01-30T01:40:50+00:00

commit 3b9d35d744bb5139f9fed57f38c019bb8c7d351c upstream.

This was not noticed for many years. Affects operation if
md raid is used a backing device for DRBD.

CC: stable@kernel.org # v3.2+
Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

Revert "swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single"

2015-01-30T01:40:50+00:00

commit dbdd74763f1faf799fbb9ed30423182e92919378 upstream.

This reverts commit 2c3fc8d26dd09b9d7069687eead849ee81c78e46.

This commit broke on x86 PV because entries in the generic SWIOTLB are
indexed using (pseudo-)physical address not DMA address and these are
not the same in a x86 PV guest.

Signed-off-by: David Vrabel 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Greg Kroah-Hartman

sata_dwc_460ex: fix resource leak on error path

2015-01-30T01:40:50+00:00

commit 4aaa71873ddb9faf4b0c4826579e2f6d18ff9ab4 upstream.

DMA mapped IO should be unmapped on the error path in probe() and
unconditionally on remove().

Fixes: 62936009f35a ([libata] Add 460EX on-chip SATA driver, sata_dwc_460ex)
Signed-off-by: Andy Shevchenko 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

clocksource: exynos_mct: Fix bitmask regression for exynos4_mct_write

2015-01-30T01:40:49+00:00

commit 8c38d28ba8da98f7102c31d35359b4dbe9d1f329 upstream.

EXYNOS4_MCT_L_MASK is defined as 0xffffff00, so applying this bitmask
produces a number outside the range 0x00 to 0xff, which always results
in execution of the default switch statement.

Obviously this is wrong and git history shows that the bitmask inversion
was incorrectly set during a refactoring of the MCT code.

Fix this by putting the inversion at the correct position again.

Acked-by: Kukjin Kim 
Reported-by: GP Orcullo 
Reviewed-by: Doug Anderson 
Signed-off-by: Tobias Jakobi 
Signed-off-by: Daniel Lezcano 
Signed-off-by: Greg Kroah-Hartman

can: dev: fix crtlmode_supported check

2015-01-30T01:40:49+00:00

commit 9b1087aa5e86448fe6ad40a58964e35f3ba423d5 upstream.

When changing flags in the CAN drivers ctrlmode the provided new content has to
be checked whether the bits are allowed to be changed. The bits that are to be
changed are given as a bitfield in cm->mask. Therefore checking against
cm->flags is wrong as the content can hold any kind of values.

The iproute2 tool sets the bits in cm->mask and cm->flags depending on the
detected command line options. To be robust against bogus user space
applications additionally sanitize the provided flags with the provided mask.

Cc: Wolfgang Grandegger 
Signed-off-by: Oliver Hartkopp 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman