linux-toradex.git/drivers/scsi, branch tegra

Merge remote-tracking branch 'remotes/ubifs-v3.1/master' into tegra-nand-next

2015-03-30T12:04:31+00:00

Conflicts:
	drivers/mtd/ubi/ubi.h
	drivers/mtd/ubi/wl.c

random32: rename random32 to prandom

2013-02-22T08:12:20+00:00

This renames all random32 functions to have 'prandom_' prefix as follows:

  void prandom_seed(u32 seed);	/* rename from srandom32() */
  u32 prandom_u32(void);		/* rename from random32() */
  void prandom_seed_state(struct rnd_state *state, u64 seed);
  				/* rename from prandom32_seed() */
  u32 prandom_u32_state(struct rnd_state *state);
  				/* rename from prandom32() */

The purpose of this renaming is to prevent some kernel developers from
assuming that prandom32() and random32() might imply that only
prandom32() was the one using a pseudo-random number generator by
prandom32's "p", and the result may be a very embarassing security
exposure.  This concern was expressed by Theodore Ts'o.

And furthermore, I'm going to introduce new functions for getting the
requested number of pseudo-random bytes.  If I continue to use both
prandom32 and random32 prefixes for these functions, the confusion
is getting worse.

As a result of this renaming, "prandom_" is the common prefix for
pseudo-random number library.

Currently, srandom32() and random32() are preserved because it is
difficult to rename too many users at once.

Signed-off-by: Akinobu Mita 
Cc: "Theodore Ts'o" 
Cc: Robert Love 
Cc: Michel Lespinasse 
Cc: Valdis Kletnieks 
Cc: David Laight 
Cc: Adrian Hunter 
Cc: Artem Bityutskiy 
Cc: David Woodhouse 
Cc: Eilon Greenstein 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

SCSI: mpt2sas : Fix for memory allocation error for large host credits

2012-01-18T15:31:57+00:00

commit aff132d95ffe14eca96cab90597cdd010b457af7 upstream.

The amount of memory required for tracking chain buffers is rather
large, and when the host credit count is big, memory allocation
failure occurs inside __get_free_pages.

The fix is to limit the number of chains to 100,000.  In addition,
the number of host credits is limited to 30,000 IOs. However this
limitation can be overridden this using the command line option
max_queue_depth.  The algorithm for calculating the
reply_post_queue_depth is changed so that it is equal to
(reply_free_queue_depth + 16), previously it was (reply_free_queue_depth * 2).

Signed-off-by: Nagalakshmi Nandigama 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: mpt2sas: Release spinlock for the raid device list before blocking it

2012-01-18T15:31:56+00:00

commit 30c43282f3d347f47f9e05199d2b14f56f3f2837 upstream.

Added code to release the spinlock that is used to protect the
raid device list before calling a function that can block. The
blocking was causing a reschedule, and subsequently it is tried
to acquire the same lock, resulting in a panic (NMI Watchdog
detecting a CPU lockup).

Signed-off-by: Nagalakshmi Nandigama 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: mpt2sas: Added missing mpt2sas_base_detach call from scsih_remove context

2012-01-12T19:33:45+00:00

commit 9ae89b0296e275d5a556068b40b7c2557a556a85 upstream.

mpt2sas_base_detach() call was removed from _scsih_remove() while
doing some code shuffling.  Mainly when we work on adding code for
scsih_shutdown().  I have added back mpt2sas_base_detach() which will
get callled from _scsih_remove().

Signed-off-by: Kashyap Desai 
Signed-off-by: James Bottomley

mpt2sas: fix non-x86 crash on shutdown

2012-01-06T22:17:23+00:00

Upstrem commit: 911ae9434f83e7355d343f6c2be3ef5b00ea7aed

There's a bug in the MSIX backup and restore routines that cause a crash on
non-x86 (direct access to PCI space not via read/write).  These routines are
unnecessary and were removed by the above commit, so also remove them from
stable to fix the crash.

Signed-off-by: Nagalakshmi Nandigama 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: fcoe: Fix preempt count leak in fcoe_filter_frames()

2012-01-06T22:16:54+00:00

commit 7e1e7ead88dff75b11b86ee0d5232c4591be1326 upstream.

The error exit path leaks preempt count. Add the missing put_cpu().

Signed-off-by: Thomas Gleixner 
Reviewed-by: Yi Zou 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: mpt2sas: _scsih_smart_predicted_fault uses GFP_KERNEL in interrupt context

2012-01-06T22:16:54+00:00

commit f6a290b419a2675c4b77a6b0731cd2a64332365e upstream.

_scsih_smart_predicted_fault is called in an interrupt and therefore
must allocate memory using GFP_ATOMIC.

Signed-off-by: Anton Blanchard 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: Silencing 'killing requests for dead queue'

2011-12-09T16:54:31+00:00

commit 745718132c3c7cac98a622b610e239dcd5217f71 upstream.

When we tear down a device we try to flush all outstanding
commands in scsi_free_queue(). However the check in
scsi_request_fn() is imperfect as it only signals that
we _might start_ aborting commands, not that we've actually
aborted some.
So move the printk inside the scsi_kill_request function,
this will also give us a hint about which commands are aborted.

Signed-off-by: Hannes Reinecke 
Signed-off-by: James Bottomley 
Cc: Christoph Biedl 
Signed-off-by: Greg Kroah-Hartman

aacraid: controller hangs if kernel uses non-default ASPM policy

2011-11-26T17:08:33+00:00

commit cf16123c9c8e346ed1dd171295a678d77648d7f8 upstream.

Aacraid controller can hang on some nodes if kernel uses non-default
(powersave) ASPM policy.  Controller hangs shortly after successful load and
hardware detection. Scsi error handler detects this hang and tries to restart
hardware but it does not help.

Initially it was noticed on RHEL6-based openVZ kernel after backporting
aacraid driver from mainline (RHEL6 kernel with original driver works well)
http://bugzilla.openvz.org/show_bug.cgi?id=2043

This issue happens because default ASPM policy was changed in Red Hat
kernels. Therefore guys from Red Hat have noticed this problem long time ago:
on Fedora 12
 https://bugzilla.redhat.com/show_bug.cgi?id=540478
on Fedora 14
 https://bugzilla.redhat.com/show_bug.cgi?id=679385

In RHEL6 kernel this issue was fixed, ASPM was disabled in aacraid driver. In
kernel changelog I've found that seems it was done by Matthew Garrett: -
[scsi] aacraid: Disable ASPM by default (Matthew Garrett) [599735]

However seems this patch was not submitted to mainline. I've reproduced this
issue on vanilla 3.1.0 kernel booted with "pcie_aspm.policy=powersave" option,
So I believe it makes sense to do it now.

Signed-off-by:	Vasily Averin 
[mjg: Checking the Windows drivers indicates that they disable ASPM under all
circumstances, so:]
Acked-by: Matthew Garrett 
Acked-by: Achim Leubner 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman