linux.git, branch v3.0.48

Linux 3.0.48

2012-10-22T15:36:19+00:00

Revert "block: fix request_queue->flags initialization"

2012-10-22T15:33:26+00:00

This reverts commit 2101aa5bb084931f22fa08cacd6d69c80afade7f which is
commit 60ea8226cbd5c8301f9a39edc574ddabcb8150e0 upstream.

To quote Ben:
	This is not needed, as there is no QUEUE_FLAG_BYPASS in 3.0.y.

To quote Tejun:
	I don't think it will break anything as it simply changes
	assignment to |= to avoid overwriting existing flags.  That
	said, any patch can break anything, so if possible it would be
	better to drop for 3.0.y.

So I'll revert this to be safe.

Cc: Tejun Heo 
Cc: Vivek Goyal 
Cc: Jens Axboe 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

Linux 3.0.47

2012-10-21T16:17:50+00:00

ALSA: emu10k1: add chip details for E-mu 1010 PCIe card

2012-10-21T16:17:12+00:00

commit 10f571d09106c3eb85951896522c9650596eff2e upstream.

Add chip details for E-mu 1010 PCIe card. It has the same
chip as found in E-mu 1010b but it uses different PCI id.

Signed-off-by: Maxim Kachur 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: ac97 - Fix missing NULL check in snd_ac97_cvol_new()

2012-10-21T16:17:12+00:00

commit 733a48e5ae5bf28b046fad984d458c747cbb8c21 upstream.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=44721

Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

udf: fix retun value on error path in udf_load_logicalvol

2012-10-21T16:17:12+00:00

commit 68766a2edcd5cd744262a70a2f67a320ac944760 upstream.

In case we detect a problem and bail out, we fail to set "ret" to a
nonzero value, and udf_load_logicalvol will mistakenly report success.

Signed-off-by: Nikola Pajkovsky 
Signed-off-by: Jan Kara 
Signed-off-by: Greg Kroah-Hartman

tpm: Propagate error from tpm_transmit to fix a timeout hang

2012-10-21T16:17:12+00:00

commit abce9ac292e13da367bbd22c1f7669f988d931ac upstream.

tpm_write calls tpm_transmit without checking the return value and
assigns the return value unconditionally to chip->pending_data, even if
it's an error value.
This causes three bugs.

So if we write to /dev/tpm0 with a tpm_param_size bigger than
TPM_BUFSIZE=0x1000 (e.g. 0x100a)
and a bufsize also bigger than TPM_BUFSIZE (e.g. 0x100a)
tpm_transmit returns -E2BIG which is assigned to chip->pending_data as
-7, but tpm_write returns that TPM_BUFSIZE bytes have been successfully
been written to the TPM, altough this is not true (bug #1).

As we did write more than than TPM_BUFSIZE bytes but tpm_write reports
that only TPM_BUFSIZE bytes have been written the vfs tries to write
the remaining bytes (in this case 10 bytes) to the tpm device driver via
tpm_write which then blocks at

 /* cannot perform a write until the read has cleared
 either via tpm_read or a user_read_timer timeout */
 while (atomic_read(&chip->data_pending) != 0)
	 msleep(TPM_TIMEOUT);

for 60 seconds, since data_pending is -7 and nobody is able to
read it (since tpm_read luckily checks if data_pending is greater than
0) (#bug 2).

After that the remaining bytes are written to the TPM which are
interpreted by the tpm as a normal command. (bug #3)
So if the last bytes of the command stream happen to be a e.g.
tpm_force_clear this gets accidentally sent to the TPM.

This patch fixes all three bugs, by propagating the error code of
tpm_write and returning -E2BIG if the input buffer is too big,
since the response from the tpm for a truncated value is bogus anyway.
Moreover it returns -EBUSY to userspace if there is a response ready to be
read.

Signed-off-by: Peter Huewe 
Signed-off-by: Kent Yoder 
Signed-off-by: Greg Kroah-Hartman

x86, random: Verify RDRAND functionality and allow it to be disabled

2012-10-21T16:17:12+00:00

commit 49d859d78c5aeb998b6936fcb5f288f78d713489 upstream.

If the CPU declares that RDRAND is available, go through a guranteed
reseed sequence, and make sure that it is actually working (producing
data.)   If it does not, disable the CPU feature flag.

Allow RDRAND to be disabled on the command line (as opposed to at
compile time) for a user who has special requirements with regards to
random numbers.

Signed-off-by: H. Peter Anvin 
Cc: Matt Mackall 
Cc: Herbert Xu 
Cc: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

x86, random: Architectural inlines to get random integers with RDRAND

2012-10-21T16:17:12+00:00

commit 628c6246d47b85f5357298601df2444d7f4dd3fd upstream.

Architectural inlines to get random ints and longs using the RDRAND
instruction.

Intel has introduced a new RDRAND instruction, a Digital Random Number
Generator (DRNG), which is functionally an high bandwidth entropy
source, cryptographic whitener, and integrity monitor all built into
hardware.  This enables RDRAND to be used directly, bypassing the
kernel random number pool.

For technical documentation, see:

http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/

In this patch, this is *only* used for the nonblocking random number
pool.  RDRAND is a nonblocking source, similar to our /dev/urandom,
and is therefore not a direct replacement for /dev/random.  The
architectural hooks presented in the previous patch only feed the
kernel internal users, which only use the nonblocking pool, and so
this is not a problem.

Since this instruction is available in userspace, there is no reason
to have a /dev/hw_rng device driver for the purpose of feeding rngd.
This is especially so since RDRAND is a nonblocking source, and needs
additional whitening and reduction (see the above technical
documentation for details) in order to be of "pure entropy source"
quality.

The CONFIG_EXPERT compile-time option can be used to disable this use
of RDRAND.

Signed-off-by: H. Peter Anvin 
Originally-by: Fenghua Yu 
Cc: Matt Mackall 
Cc: Herbert Xu 
Cc: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

jbd: Fix assertion failure in commit code due to lacking transaction credits

2012-10-21T16:17:12+00:00

commit 09e05d4805e6c524c1af74e524e5d0528bb3fef3 upstream.

ext3 users of data=journal mode with blocksize < pagesize were occasionally
hitting assertion failure in journal_commit_transaction() checking whether the
transaction has at least as many credits reserved as buffers attached.  The
core of the problem is that when a file gets truncated, buffers that still need
checkpointing or that are attached to the committing transaction are left with
buffer_mapped set. When this happens to buffers beyond i_size attached to a
page stradding i_size, subsequent write extending the file will see these
buffers and as they are mapped (but underlying blocks were freed) things go
awry from here.

The assertion failure just coincidentally (and in this case luckily as we would
start corrupting filesystem) triggers due to journal_head not being properly
cleaned up as well.

Under some rare circumstances this bug could even hit data=ordered mode users.
There the assertion won't trigger and we would end up corrupting the
filesystem.

We fix the problem by unmapping buffers if possible (in lots of cases we just
need a buffer attached to a transaction as a place holder but it must not be
written out anyway). And in one case, we just have to bite the bullet and wait
for transaction commit to finish.

Reviewed-by: Josef Bacik 
Signed-off-by: Jan Kara 
Signed-off-by: Greg Kroah-Hartman