linux-toradex.git/drivers, branch v3.15.3

efi-pstore: Fix an overflow on 32-bit builds

2014-07-01T03:14:04+00:00

commit 783ee43118dc773bc8b0342c5b230e017d5a04d0 upstream.

In generic_id the long int timestamp is multiplied by 100000 and needs
an explicit cast to u64.

Without that the id in the resulting pstore filename is wrong and
userspace may have problems parsing it, but more importantly files in
pstore can never be deleted and may fill the EFI flash (brick device?).
This happens because when generic pstore code wants to delete a file,
it passes the id to the EFI backend which reinterpretes it and a wrong
variable name is attempted to be deleted.  There's no error message but
after remounting pstore, deleted files would reappear.

Signed-off-by: Andrew Zaborowski 
Acked-by: David Rientjes 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

random: fix nasty entropy accounting bug

2014-07-01T03:14:04+00:00

commit e33ba5fa7afce1a9f159704121d4e4d110df8185 upstream.

Commit 0fb7a01af5b0 "random: simplify accounting code", introduced in
v3.15, has a very nasty accounting problem when the entropy pool has
has fewer bytes of entropy than the number of requested reserved
bytes.  In that case, "have_bytes - reserved" goes negative, and since
size_t is unsigned, the expression:

       ibytes = min_t(size_t, ibytes, have_bytes - reserved);

... does not do the right thing.  This is rather bad, because it
defeats the catastrophic reseeding feature in the
xfer_secondary_pool() path.

It also can cause the "BUG: spinlock trylock failure on UP" for some
kernel configurations when prandom_reseed() calls get_random_bytes()
in the early init, since when the entropy count gets corrupted,
credit_entropy_bits() erroneously believes that the nonblocking pool
has been fully initialized (when in fact it is not), and so it calls
prandom_reseed(true) recursively leading to the spinlock BUG.

The logic is *not* the same it was originally, but in the cases where
it matters, the behavior is the same, and the resulting code is
hopefully easier to read and understand.

Fixes: 0fb7a01af5b0 "random: simplify accounting code"
Signed-off-by: Theodore Ts'o 
Cc: Greg Price 
Signed-off-by: Greg Kroah-Hartman

Revert "offb: Add palette hack for little endian"

2014-07-01T03:14:01+00:00

commit 68986c9f0f4552c34c248501eb0c690553866d6e upstream.

This reverts commit e1edf18b20076da83dd231dbd2146cbbc31c0b14.

This patch was a misguided attempt at fixing offb for LE ppc64
kernels on BE qemu but is just wrong ... it breaks real LE/LE
setups, LE with real HW, and existing mixed endian systems
that did the fight thing with the appropriate device-tree
property. Bad reviewing on my part, sorry.

The right fix is to either make qemu change its endian when
the guest changes endian (working on that) or to use the
existing foreign endian support.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

Revert "drm/radeon: use variable UVD clocks"

2014-07-01T03:14:01+00:00

commit 0690a229c69f40a6c9c459ab455c85df49822525 upstream.

This caused reduced performance for some users with advanced post
processing enabled.  We need a better method to pick the
UVD state based on the amount of post processing required or tune
the advanced post processing to fit within the lower power state
envelope.

This reverts commit 14a9579ddbf15dd1992a9481a4ec80b0b91656d5.

Signed-off-by: Greg Kroah-Hartman

TARGET/sbc,loopback: Adjust command data length in case pi exists on the wire

2014-07-01T03:14:00+00:00

commit e2a4f55c6498b59a17a85a1bb6db122a993ffe02 upstream.

In various areas of the code, it is assumed that
se_cmd->data_length describes pure data. In case
that protection information exists over the wire
(protect bits is are on) the target core re-calculates
the data length from the CDB and the backed device
block size (instead of each transport peeking in the cdb).

Modify loopback device to include protection information
in the transferred data length (like other scsi transports).

Signed-off-by: Sagi Grimberg 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

libiscsi, iser: Adjust data_length to include protection information

2014-07-01T03:14:00+00:00

commit d77e65350f2d82dfa0557707d505711f5a43c8fd upstream.

In case protection information exists over the wire
iscsi header data length is required to include it.
Use protection information aware scsi helpers to set
the correct transfer length.

In order to avoid breakage, remove iser transfer length
checks for each task as they are not always true and
somewhat redundant anyway.

Signed-off-by: Sagi Grimberg 
Reviewed-by: Mike Christie 
Acked-by: Mike Christie 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

target: Report correct response length for some commands

2014-07-01T03:14:00+00:00

commit 2426bd456a61407388b6e61fc5f98dbcbebc50e2 upstream.

When an initiator sends an allocation length bigger than what its
command consumes, the target should only return the actual response data
and set the residual length to the unused part of the allocation length.

Add a helper function that command handlers (INQUIRY, READ CAPACITY,
etc) can use to do this correctly, and use this code to get the correct
residual for commands that don't use the full initiator allocation in the
handlers for READ CAPACITY, READ CAPACITY(16), INQUIRY, MODE SENSE and
REPORT LUNS.

This addresses a handful of failures as reported by Christophe with
the Windows Certification Kit:

  http://permalink.gmane.org/gmane.linux.scsi.target.devel/6515

Signed-off-by: Roland Dreier 
Tested-by: Christophe Vu-Brugier 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

Target/iscsi: Fix sendtargets response pdu for iser transport

2014-07-01T03:14:00+00:00

commit 22c7aaa57e80853b4904a46c18f97db0036a3b97 upstream.

In case the transport is iser we should not include the
iscsi target info in the sendtargets text response pdu.
This causes sendtargets response to include the target
info twice.

Modify iscsit_build_sendtargets_response to filter
transport types that don't match.

Signed-off-by: Sagi Grimberg 
Reported-by: Slava Shwartsman 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

Target/iser: Fix a wrong dereference in case discovery session is over iser

2014-07-01T03:14:00+00:00

commit e0546fc1ba66c90cb38a5764357366267d3e58e4 upstream.

In case the discovery session is carried over iser, we can't
access the assumed network portal since the default portal is
used. In this case we don't really need to allocate the fastreg
pool, just prepare to the text pdu that will follow.

Signed-off-by: Sagi Grimberg 
Reported-by: Alex Tabachnik 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

iscsi-target: Fix ABORT_TASK + connection reset iscsi_queue_req memory leak

2014-07-01T03:14:00+00:00

commit bbc050488525e1ab1194c27355f63c66814385b8 upstream.

This patch fixes a iscsi_queue_req memory leak when ABORT_TASK response
has been queued by TFO->queue_tm_rsp() -> lio_queue_tm_rsp() after a
long standing I/O completes, but the connection has already reset and
waiting for cleanup to complete in iscsit_release_commands_from_conn()
-> transport_generic_free_cmd() -> transport_wait_for_tasks() code.

It moves iscsit_free_queue_reqs_for_conn() after the per-connection command
list has been released, so that the associated se_cmd tag can be completed +
released by target-core before freeing any remaining iscsi_queue_req memory
for the connection generated by lio_queue_tm_rsp().

Cc: Thomas Glanzmann 
Cc: Charalampos Pournaris 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman