linux-stable.git/drivers, branch v4.13.3

md/raid5: release/flush io in raid5_do_work()

2017-09-20T06:27:51+00:00

commit 9c72a18e46ebe0f09484cce8ebf847abdab58498 upstream.

In raid5, there are scenarios where some ios are deferred to a later
time, and some IO need a flush to complete. To make sure we make
progress with these IOs, we need to call the following functions:

    flush_deferred_bios(conf);
    r5l_flush_stripe_to_raid(conf->log);

Both of these functions are called in raid5d(), but missing in
raid5_do_work(). As a result, these functions are not called
when multi-threading (group_thread_cnt > 0) is enabled. This patch
adds calls to these function to raid5_do_work().

Note for stable branches:

  r5l_flush_stripe_to_raid(conf->log) is need for 4.4+
  flush_deferred_bios(conf) is only needed for 4.11+

Signed-off-by: Song Liu 
Signed-off-by: Shaohua Li 
Signed-off-by: Greg Kroah-Hartman

md/raid1/10: reset bio allocated from mempool

2017-09-20T06:27:51+00:00

commit 208410b546207cfc4c832635fa46419cfa86b4cd upstream.

Data allocated from mempool doesn't always get initialized, this happens when
the data is reused instead of fresh allocation. In the raid1/10 case, we must
reinitialize the bios.

Reported-by: Jonathan G. Underwood 
Fixes: f0250618361d(md: raid10: don't use bio's vec table to manage resync pages)
Fixes: 98d30c5812c3(md: raid1: don't use bio's vec table to manage resync pages)
Cc: Ming Lei 
Signed-off-by: Shaohua Li 
Signed-off-by: Greg Kroah-Hartman

libnvdimm: fix integer overflow static analysis warning

2017-09-20T06:27:48+00:00

commit 58738c495e15badd2015e19ff41f1f1ed55200bc upstream.

Dan reports:
    The patch 62232e45f4a2: "libnvdimm: control (ioctl) messages for
    nvdimm_bus and nvdimm devices" from Jun 8, 2015, leads to the
    following static checker warning:

            drivers/nvdimm/bus.c:1018 __nd_ioctl()
            warn: integer overflows 'buf_len'

    From a casual review, this seems like it might be a real bug.  On
    the first iteration we load some data into in_env[].  On the second
    iteration we read a use controlled "in_size" from nd_cmd_in_size().
    It can go up to UINT_MAX - 1.  A high number means we will fill the
    whole in_env[] buffer.  But we potentially keep looping and adding
    more to in_len so now it can be any value.

    It simple enough to change, but it feels weird that we keep looping
    even though in_env is totally full.  Shouldn't we just return an
    error if we don't have space for desc->in_num.

We keep looping because the size of the total input is allowed to be
bigger than the 'envelope' which is a subset of the payload that tells
us how much data to expect. For safety explicitly check that buf_len
does not overflow which is what the checker flagged.

Fixes: 62232e45f4a2: "libnvdimm: control (ioctl) messages for nvdimm_bus..."
Reported-by: Dan Carpenter 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

libnvdimm, btt: check memory allocation failure

2017-09-20T06:27:48+00:00

commit ed36b4dba54a421ce5551638f6a9790b2c2116b1 upstream.

Check memory allocation failures and return -ENOMEM in such cases, as
already done few lines below for another memory allocation.

This avoids NULL pointers dereference.

Fixes: 14e494542636 ("libnvdimm, btt: BTT updates for UEFI 2.7 format")
Signed-off-by: Christophe JAILLET 
Reviewed-by: Vishal Verma 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

thunderbolt: Allow clearing the key

2017-09-20T06:27:48+00:00

commit e545f0d8a54a9594fe604d67d80ca6fddf72ca59 upstream.

If secure authentication of a devices fails, either because the device
already has another key uploaded, or there is some other error sending
challenge to the device, and the user only wants to approve the device
just once (without a new key being uploaded to the device) the current
implementation does not allow this because the key cannot be cleared
once set even if we allow it to be changed.

Make this scenario possible and allow clearing the key by writing
empty string to the key sysfs file.

Signed-off-by: Yehezkel Bernat 
Acked-by: Mika Westerberg 
Signed-off-by: Greg Kroah-Hartman

thunderbolt: Make key root-only accessible

2017-09-20T06:27:47+00:00

commit 0956e41169222822d3557871fcd1d32e4fa7e934 upstream.

Non-root user may read the key back after root wrote it there.
This removes read access to everyone but root.

Signed-off-by: Yehezkel Bernat 
Acked-by: Mika Westerberg 
Signed-off-by: Greg Kroah-Hartman

thunderbolt: Remove superfluous check

2017-09-20T06:27:47+00:00

commit 8fdd6ab36197ad891233572c57781b1f537da0ac upstream.

The key size is tested by hex2bin() already (as '\0' isn't an hex digit)

Suggested-by: Andy Shevchenko 
Signed-off-by: Yehezkel Bernat 
Acked-by: Mika Westerberg 
Signed-off-by: Greg Kroah-Hartman

vhost_net: correctly check tx avail during rx busy polling

2017-09-20T06:27:46+00:00

[ Upstream commit 8b949bef9172ca69d918e93509a4ecb03d0355e0 ]

We check tx avail through vhost_enable_notify() in the past which is
wrong since it only checks whether or not guest has filled more
available buffer since last avail idx synchronization which was just
done by vhost_vq_avail_empty() before. What we really want is checking
pending buffers in the avail ring. Fix this by calling
vhost_vq_avail_empty() instead.

This issue could be noticed by doing netperf TCP_RR benchmark as
client from guest (but not host). With this fix, TCP_RR from guest to
localhost restores from 1375.91 trans per sec to 55235.28 trans per
sec on my laptop (Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz).

Fixes: 030881372460 ("vhost_net: basic polling support")
Signed-off-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

gianfar: Fix Tx flow control deactivation

2017-09-20T06:27:46+00:00

[ Upstream commit 5d621672bc1a1e5090c1ac5432a18c79e0e13e03 ]

The wrong register is checked for the Tx flow control bit,
it should have been maccfg1 not maccfg2.
This went unnoticed for so long probably because the impact is
hardly visible, not to mention the tangled code from adjust_link().
First, link flow control (i.e. handling of Rx/Tx link level pause frames)
is disabled by default (needs to be enabled via 'ethtool -A').
Secondly, maccfg2 always returns 0 for tx_flow_oldval (except for a few
old boards), which results in Tx flow control remaining always on
once activated.

Fixes: 45b679c9a3ccd9e34f28e6ec677b812a860eb8eb ("gianfar: Implement PAUSE frame generation support")
Signed-off-by: Claudiu Manoil 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

rt2800: fix TX_PIN_CFG setting for non MT7620 chips

2017-09-13T21:20:54+00:00

commit 83ec489193894e52bd395eec470f4f7c4286d4a5 upstream.

Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not
initialize TX_PIN_CFG setting. This cause breakage at least on some
RT3573 devices. To fix the problem patch restores previous behaviour
for non MT7620 chips.

Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1480829
Reported-and-tested-by: Jussi Eloranta 
Cc: Daniel Golle 
Signed-off-by: Stanislaw Gruszka 
Acked-by: Daniel Golle 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman