10 years agoALSA: hda - Fix silent output on ASUS A6Rp
Takashi Iwai [Wed, 25 Jan 2012 08:55:46 +0000 (09:55 +0100)]
ALSA: hda - Fix silent output on ASUS A6Rp

commit 3b25eb690e8c7424eecffe1458c02b87b32aa001 upstream.

The refactoring of Realtek codec driver in 3.2 kernel caused a
regression for ASUS A6Rp laptop; it doesn't give any output.
The reason was that this machine has a secret master mute (or EAPD)
control via NID 0x0f VREF.  Setting VREF50 on this node makes the
sound working again.


Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoALSA: hda: set mute led polarity for laptops with buggy BIOS based on SSID
Gustavo Maciel Dias Vieira [Tue, 24 Jan 2012 15:27:56 +0000 (13:27 -0200)]
ALSA: hda: set mute led polarity for laptops with buggy BIOS based on SSID

commit a6a600d10aaddf1da38053c4c6b64f50f56176e6 upstream.

HP laptop models with buggy BIOS are apparently frequent, including
machines with different codecs. Set the polarity of the mute led based
on the SSID and include an entry for the HP Mini 110-3100.

Signed-off-by: Gustavo Maciel Dias Vieira <>
Tested-by: Predrag Ivanovic <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agom68k: Fix assembler constraint to prevent overeager gcc optimisation
Andreas Schwab [Mon, 9 Jan 2012 14:10:15 +0000 (15:10 +0100)]
m68k: Fix assembler constraint to prevent overeager gcc optimisation

commit 2a3535069e33d8b416f406c159ce924427315303 upstream.

Passing the address of a variable as an operand to an asm statement
doesn't mark the value of this variable as used, so gcc may optimize its
initialisation away.  Fix this by using the "m" constraint instead.

Signed-off-by: Andreas Schwab <>
Signed-off-by: Geert Uytterhoeven <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agox86/microcode_amd: Add support for CPU family specific container files
Andreas Herrmann [Fri, 20 Jan 2012 16:44:12 +0000 (17:44 +0100)]
x86/microcode_amd: Add support for CPU family specific container files

commit 5b68edc91cdc972c46f76f85eded7ffddc3ff5c2 upstream.

We've decided to provide CPU family specific container files
(starting with CPU family 15h). E.g. for family 15h we have to
load microcode_amd_fam15h.bin instead of microcode_amd.bin

Rationale is that starting with family 15h patch size is larger
than 2KB which was hard coded as maximum patch size in various
microcode loaders (not just Linux).

Container files which include patches larger than 2KB cause
different kinds of trouble with such old patch loaders. Thus we
have to ensure that the default container file provides only
patches with size less than 2KB.

Signed-off-by: Andreas Herrmann <>
Cc: Borislav Petkov <>
Cc: <>
[ documented the naming convention and tidied the code a bit. ]
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agox86/uv: Fix uv_gpa_to_soc_phys_ram() shift
Russ Anderson [Thu, 19 Jan 2012 02:07:54 +0000 (20:07 -0600)]
x86/uv: Fix uv_gpa_to_soc_phys_ram() shift

commit 5a51467b146ab7948d2f6812892eac120a30529c upstream.

uv_gpa_to_soc_phys_ram() was inadvertently ignoring the
shift values.  This fix takes the shift into account.

Signed-off-by: Russ Anderson <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agox86/uv: Fix uninitialized spinlocks
Cliff Wickman [Wed, 18 Jan 2012 15:40:47 +0000 (09:40 -0600)]
x86/uv: Fix uninitialized spinlocks

commit d2ebc71d472020bc30e29afe8c4d2a85a5b41f56 upstream.

Initialize two spinlocks in tlb_uv.c and also properly define/initialize
the uv_irq_lock.

The lack of explicit initialization seems to be functionally
harmless, but it is diagnosed when these are turned on:


Signed-off-by: Cliff Wickman <>
Cc: Dimitri Sivanich <>
[ Added the uv_irq_lock initialization fix by Dimitri Sivanich ]
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotpm_tis: add delay after aborting command
Stefan Berger [Fri, 11 Nov 2011 17:57:06 +0000 (12:57 -0500)]
tpm_tis: add delay after aborting command

commit a927b8131794ee449b7f6666e7ab61301949b20f upstream.

This patch adds a delay after aborting a command. Some TPMs need
this and will not process the subsequent command correctly otherwise.

It's worth noting that a TPM randomly failing to process a command,
maps to randomly failing suspend/resume operations.

Signed-off-by: Stefan Berger <>
Signed-off-by: Rajiv Andrade <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agocrypto: sha512 - reduce stack usage to safe number
Alexey Dobriyan [Sat, 14 Jan 2012 18:40:57 +0000 (21:40 +0300)]
crypto: sha512 - reduce stack usage to safe number

commit 51fc6dc8f948047364f7d42a4ed89b416c6cc0a3 upstream.

For rounds 16--79, W[i] only depends on W[i - 2], W[i - 7], W[i - 15] and W[i - 16].
Consequently, keeping all W[80] array on stack is unnecessary,
only 16 values are really needed.

Using W[16] instead of W[80] greatly reduces stack usage
(~750 bytes to ~340 bytes on x86_64).

Line by line explanation:
  array is "circular" now, all indexes have to be modulo 16.
  Round number is positive, so remainder operation should be
  without surprises.

* initial full message scheduling is trimmed to first 16 values which
  come from data block, the rest is calculated before it's needed.

* original loop body is unrolled version of new SHA512_0_15 and
  SHA512_16_79 macros, unrolling was done to not do explicit variable
  renaming. Otherwise it's the very same code after preprocessing.
  See sha1_transform() code which does the same trick.

Patch survives in-tree crypto test and original bugreport test
(ping flood with hmac(sha512).

See FIPS 180-2 for SHA-512 definition

Signed-off-by: Alexey Dobriyan <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agocrypto: sha512 - make it work, undo percpu message schedule
Alexey Dobriyan [Sat, 14 Jan 2012 18:27:37 +0000 (21:27 +0300)]
crypto: sha512 - make it work, undo percpu message schedule

commit 84e31fdb7c797a7303e0cc295cb9bc8b73fb872d upstream.

commit f9e2bca6c22d75a289a349f869701214d63b5060
aka "crypto: sha512 - Move message schedule W[80] to static percpu area"
created global message schedule area.

If sha512_update will ever be entered twice, hash will be silently
calculated incorrectly.

Probably the easiest way to notice incorrect hashes being calculated is
to run 2 ping floods over AH with hmac(sha512):

#!/usr/sbin/setkey -f
add IP1 IP2 ah 25 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000025;
add IP2 IP1 ah 52 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000052;
spdadd IP1 IP2 any -P out ipsec ah/transport//require;
spdadd IP2 IP1 any -P in  ipsec ah/transport//require;

XfrmInStateProtoError will start ticking with -EBADMSG being returned
from ah_input(). This never happens with, say, hmac(sha1).

With patch applied (on BOTH sides), XfrmInStateProtoError does not tick
with multiple bidirectional ping flood streams like it doesn't tick
with SHA-1.

After this patch sha512_transform() will start using ~750 bytes of stack on x86_64.
This is OK for simple loads, for something more heavy, stack reduction will be done

Signed-off-by: Alexey Dobriyan <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agojbd: Issue cache flush after checkpointing
Jan Kara [Fri, 25 Nov 2011 23:35:39 +0000 (00:35 +0100)]
jbd: Issue cache flush after checkpointing

commit 353b67d8ced4dc53281c88150ad295e24bc4b4c5 upstream.

When we reach cleanup_journal_tail(), there is no guarantee that
checkpointed buffers are on a stable storage - especially if buffers were
written out by log_do_checkpoint(), they are likely to be only in disk's
caches. Thus when we update journal superblock, effectively removing old
transaction from journal, this write of superblock can get to stable storage
before those checkpointed buffers which can result in filesystem corruption
after a crash.

A similar problem can happen if we replay the journal and wipe it before
flushing disk's caches.

Thus we must unconditionally issue a cache flush before we update journal
superblock in these cases. The fix is slightly complicated by the fact that we
have to get log tail before we issue cache flush but we can store it in the
journal superblock only after the cache flush. Otherwise we risk races where
new tail is written before appropriate cache flush is finished.

I managed to reproduce the corruption using somewhat tweaked Chris Mason's
barrier-test scheduler. Also this should fix occasional reports of 'Bit already
freed' filesystem errors which are totally unreproducible but inspection of
several fs images I've gathered over time points to a problem like this.

Signed-off-by: Jan Kara <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomac80211: fix work removal on deauth request
Johannes Berg [Wed, 18 Jan 2012 13:10:25 +0000 (14:10 +0100)]
mac80211: fix work removal on deauth request

commit bc4934bc61d0a11fd62c5187ff83645628f8be8b upstream.

When deauth is requested while an auth or assoc
work item is in progress, we currently delete it
without regard for any state it might need to
clean up. Fix it by cleaning up for those items.

In the case Pontus found, the problem manifested
itself as such:

authenticate with 00:23:69:aa:dd:7b (try 1)
failed to insert Dummy STA entry for the AP (error -17)
deauthenticating from 00:23:69:aa:dd:7b by local choice (reason=2)

It could also happen differently if the driver
uses the tx_sync callback.

We can't just call the ->done() method of the work
items because that will lock up due to the locking
in cfg80211. This fix isn't very clean, but that
seems acceptable since I have patches pending to
remove this code completely.

Reported-by: Pontus Fuchs <>
Tested-by: Pontus Fuchs <>
Signed-off-by: Johannes Berg <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agobrcmsmac: fix tx queue flush infinite loop
Stanislaw Gruszka [Tue, 17 Jan 2012 11:38:50 +0000 (12:38 +0100)]
brcmsmac: fix tx queue flush infinite loop

commit f96b08a7e6f69c0f0a576554df3df5b1b519c479 upstream.

This patch workaround live deadlock problem caused by infinite loop
in brcms_c_wait_for_tx_completion(). I do not consider the patch as
the proper fix, which should fix the real reason of tx queue flush
failure, but patch helps with system lockup.


Reported-and-tested-by: Patrick <>
Signed-off-by: Stanislaw Gruszka <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoASoC: wm8996: Call _POST_PMU callback for CPVDD
Mark Brown [Sat, 21 Jan 2012 21:48:53 +0000 (21:48 +0000)]
ASoC: wm8996: Call _POST_PMU callback for CPVDD

commit a14304edcd5e8323205db34b08f709feb5357e64 upstream.

We should be allowing a 5ms delay after the charge pump is started in
order to ensure it has finished ramping.

Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoASoC: Don't go through cache when applying WM5100 rev A updates
Mark Brown [Thu, 19 Jan 2012 11:16:37 +0000 (11:16 +0000)]
ASoC: Don't go through cache when applying WM5100 rev A updates

commit 495174a8ffbaa0d15153d855cf206cdc46d51cf4 upstream.

These are all to either uncached registers or fixes to register defaults,
in the former case the cache won't do anything and in the latter case
we're fixing things so the cache sync will do the right thing.

Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoASoC: Disable register synchronisation for low frequency WM8996 SYSCLK
Mark Brown [Wed, 18 Jan 2012 19:17:06 +0000 (19:17 +0000)]
ASoC: Disable register synchronisation for low frequency WM8996 SYSCLK

commit fed22007113cb857e917913ce016d9b539dc3a80 upstream.

With a low frequency SYSCLK and a fast I2C clock register synchronisation
may occasionally take too long to take effect, causing I/O issues. Disable
synchronisation in order to avoid any issues.

Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoASoC: Mark WM5100 register map cache only when going into BIAS_OFF
Mark Brown [Wed, 18 Jan 2012 20:02:38 +0000 (20:02 +0000)]
ASoC: Mark WM5100 register map cache only when going into BIAS_OFF

commit e53e417331c57b9b97e3f8be870214a02c99265c upstream.

Writing to the registers won't work if we do actually manage to hit a fully
powered off state.

Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoxfs: Fix missing xfs_iunlock() on error recovery path in xfs_readlink()
Jan Kara [Wed, 11 Jan 2012 18:52:10 +0000 (18:52 +0000)]
xfs: Fix missing xfs_iunlock() on error recovery path in xfs_readlink()

commit 9b025eb3a89e041bab6698e3858706be2385d692 upstream.

Commit b52a360b forgot to call xfs_iunlock() when it detected corrupted
symplink and bailed out. Fix it by jumping to 'out' instead of doing return.

CC: Carlos Maiolino <>
Signed-off-by: Jan Kara <>
Reviewed-by: Alex Elder <>
Reviewed-by: Dave Chinner <>
Signed-off-by: Ben Myers <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm: Fix authentication kernel crash
Thomas Hellstrom [Tue, 24 Jan 2012 17:54:21 +0000 (18:54 +0100)]
drm: Fix authentication kernel crash

commit 598781d71119827b454fd75d46f84755bca6f0c6 upstream.

If the master tries to authenticate a client using drm_authmagic and
that client has already closed its drm file descriptor,
either wilfully or because it was terminated, the
call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
and corrupt it.

Typically this results in a hard system hang.

This patch fixes that problem by removing any authentication tokens
(struct drm_magic_entry) open for a file descriptor when that file
descriptor is closed.

Signed-off-by: Thomas Hellstrom <>
Reviewed-by: Daniel Vetter <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/radeon/kms: rework modeset sequence for DCE41 and DCE5
Alex Deucher [Fri, 20 Jan 2012 20:01:30 +0000 (15:01 -0500)]
drm/radeon/kms: rework modeset sequence for DCE41 and DCE5

commit 3a47824d85eeca122895646f027dc63480994199 upstream.

dig transmitter control table only has ENABLE/DISABLE actions
on DCE4.1/DCE5.


Signed-off-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/radeon/kms: move panel mode setup into encoder mode set
Alex Deucher [Fri, 20 Jan 2012 20:01:29 +0000 (15:01 -0500)]
drm/radeon/kms: move panel mode setup into encoder mode set

commit 386d4d751e8e0b4b693bb724f09aae064ee5297d upstream.

Needs to happen earlier in the mode set.

Signed-off-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/radeon/kms: Add an MSI quirk for Dell RS690
Alex Deucher [Sun, 15 Jan 2012 13:51:12 +0000 (08:51 -0500)]
drm/radeon/kms: Add an MSI quirk for Dell RS690

commit 44517c44496062180a6376cc704b33129441ce60 upstream.

Interrupts only work with MSIs.

Reported-by: Dmitry Podgorny <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoeCryptfs: Fix oops when printing debug info in extent crypto functions
Tyler Hicks [Tue, 24 Jan 2012 16:02:22 +0000 (10:02 -0600)]
eCryptfs: Fix oops when printing debug info in extent crypto functions

commit 58ded24f0fcb85bddb665baba75892f6ad0f4b8a upstream.

If pages passed to the eCryptfs extent-based crypto functions are not
mapped and the module parameter ecryptfs_verbosity=1 was specified at
loading time, a NULL pointer dereference will occur.

Note that this wouldn't happen on a production system, as you wouldn't
pass ecryptfs_verbosity=1 on a production system. It leaks private
information to the system logs and is for debugging only.

The debugging info printed in these messages is no longer very useful
and rather than doing a kmap() in these debugging paths, it will be
better to simply remove the debugging paths completely.

Signed-off-by: Tyler Hicks <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoeCryptfs: Check inode changes in setattr
Tyler Hicks [Fri, 20 Jan 2012 02:33:44 +0000 (20:33 -0600)]
eCryptfs: Check inode changes in setattr

commit a261a03904849c3df50bd0300efb7fb3f865137d upstream.

Most filesystems call inode_change_ok() very early in ->setattr(), but
eCryptfs didn't call it at all. It allowed the lower filesystem to make
the call in its ->setattr() function. Then, eCryptfs would copy the
appropriate inode attributes from the lower inode to the eCryptfs inode.

This patch changes that and actually calls inode_change_ok() on the
eCryptfs inode, fairly early in ecryptfs_setattr(). Ideally, the call
would happen earlier in ecryptfs_setattr(), but there are some possible
inode initialization steps that must happen first.

Since the call was already being made on the lower inode, the change in
functionality should be minimal, except for the case of a file extending
truncate call. In that case, inode_newsize_ok() was never being
called on the eCryptfs inode. Rather than inode_newsize_ok() catching
maximum file size errors early on, eCryptfs would encrypt zeroed pages
and write them to the lower filesystem until the lower filesystem's
write path caught the error in generic_write_checks(). This patch
introduces a new function, called ecryptfs_inode_newsize_ok(), which
checks if the new lower file size is within the appropriate limits when
the truncate operation will be growing the lower file.

In summary this change prevents eCryptfs truncate operations (and the
resulting page encryptions), which would exceed the lower filesystem
limits or FSIZE rlimits, from ever starting.

Signed-off-by: Tyler Hicks <>
Reviewed-by: Li Wang <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoeCryptfs: Make truncate path killable
Tyler Hicks [Thu, 19 Jan 2012 00:30:04 +0000 (18:30 -0600)]
eCryptfs: Make truncate path killable

commit 5e6f0d769017cc49207ef56996e42363ec26c1f0 upstream.

ecryptfs_write() handles the truncation of eCryptfs inodes. It grabs a
page, zeroes out the appropriate portions, and then encrypts the page
before writing it to the lower filesystem. It was unkillable and due to
the lack of sparse file support could result in tying up a large portion
of system resources, while encrypting pages of zeros, with no way for
the truncate operation to be stopped from userspace.

This patch adds the ability for ecryptfs_write() to detect a pending
fatal signal and return as gracefully as possible. The intent is to
leave the lower file in a useable state, while still allowing a user to
break out of the encryption loop. If a pending fatal signal is detected,
the eCryptfs inode size is updated to reflect the modified inode size
and then -EINTR is returned.

Signed-off-by: Tyler Hicks <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoecryptfs: Improve metadata read failure logging
Tim Gardner [Thu, 12 Jan 2012 15:31:55 +0000 (16:31 +0100)]
ecryptfs: Improve metadata read failure logging

commit 30373dc0c87ffef68d5628e77d56ffb1fa22e1ee upstream.

Print inode on metadata read failure. The only real
way of dealing with metadata read failures is to delete
the underlying file system file. Having the inode
allows one to 'find . -inum INODE`.

[ Removed some minor not-for-stable parts]
Signed-off-by: Tim Gardner <>
Reviewed-by: Kees Cook <>
Signed-off-by: Tyler Hicks <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoeCryptfs: Sanitize write counts of /dev/ecryptfs
Tyler Hicks [Thu, 12 Jan 2012 10:30:44 +0000 (11:30 +0100)]
eCryptfs: Sanitize write counts of /dev/ecryptfs

commit db10e556518eb9d21ee92ff944530d84349684f4 upstream.

A malicious count value specified when writing to /dev/ecryptfs may
result in a a very large kernel memory allocation.

This patch peeks at the specified packet payload size, adds that to the
size of the packet headers and compares the result with the write count
value. The resulting maximum memory allocation size is approximately 532

Signed-off-by: Tyler Hicks <>
Reported-by: Sasha Levin <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoALSA: hda - Fix silent outputs from docking-station jacks of Dell laptops
Takashi Iwai [Mon, 23 Jan 2012 17:23:36 +0000 (18:23 +0100)]
ALSA: hda - Fix silent outputs from docking-station jacks of Dell laptops

commit b4ead019afc201f71c39cd0dfcaafed4a97b3dd2 upstream.

The recent change of the power-widget handling for IDT codecs caused
the silent output from the docking-station line-out jack.  This was
partially fixed by the commit f2cbba7602383cd9cdd21f0a5d0b8bd1aad47b33
"ALSA: hda - Fix the lost power-setup of seconary pins after PM resume".
But the line-out on the docking-station is still silent when booted
with the jack plugged even by this fix.

The remainig bug is that the power-widget is set off in stac92xx_init()
because the pins in cfg->line_out_pins[] aren't checked there properly
but only hp_pins[] are checked in is_nid_hp_pin().

This patch fixes the problem by checking both HP and line-out pins
and leaving the power-map correctly.


Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoALSA: hda - Fix buffer-alignment regression with Nvidia HDMI
Takashi Iwai [Mon, 23 Jan 2012 16:10:24 +0000 (17:10 +0100)]
ALSA: hda - Fix buffer-alignment regression with Nvidia HDMI

commit 52409aa6a0e96337da137c069856298f4dd825a0 upstream.

The commit 2ae66c26550cd94b0e2606a9275eb0ab7070ad0e
    ALSA: hda: option to enable arbitrary buffer/period sizes
introduced a regression on machines with Intel controller and Nvidia
HDMI.  The reason is that the driver modifies the global variable
align_buffer_size when an Intel controller is found, and the Nvidia
HDMI controller is probed after Intel although Nvidia chips require
the aligned buffers.

This patch fixes the problem by moving the flag into the local struct
so that it's not affected by other controllers.


Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoLinux 3.2.2 v3.2.2
Greg Kroah-Hartman [Thu, 26 Jan 2012 00:39:32 +0000 (16:39 -0800)]
Linux 3.2.2

10 years agoSHM_UNLOCK: fix Unevictable pages stranded after swap
Hugh Dickins [Fri, 20 Jan 2012 22:34:21 +0000 (14:34 -0800)]
SHM_UNLOCK: fix Unevictable pages stranded after swap

commit 245132643e1cfcd145bbc86a716c1818371fcb93 upstream.

Commit cc39c6a9bbde ("mm: account skipped entries to avoid looping in
find_get_pages") correctly fixed an infinite loop; but left a problem
that find_get_pages() on shmem would return 0 (appearing to callers to
mean end of tree) when it meets a run of nr_pages swap entries.

The only uses of find_get_pages() on shmem are via pagevec_lookup(),
called from invalidate_mapping_pages(), and from shmctl SHM_UNLOCK's
scan_mapping_unevictable_pages().  The first is already commented, and
not worth worrying about; but the second can leave pages on the
Unevictable list after an unusual sequence of swapping and locking.

Fix that by using shmem_find_get_pages_and_swap() (then ignoring the
swap) instead of pagevec_lookup().

But I don't want to contaminate vmscan.c with shmem internals, nor
shmem.c with LRU locking.  So move scan_mapping_unevictable_pages() into
shmem.c, renaming it shmem_unlock_mapping(); and rename
check_move_unevictable_page() to check_move_unevictable_pages(), looping
down an array of pages, oftentimes under the same lock.

Leave out the "rotate unevictable list" block: that's a leftover from
when this was used for /proc/sys/vm/scan_unevictable_pages, whose flawed
handling involved looking at pages at tail of LRU.

Was there significance to the sequence first ClearPageUnevictable, then
test page_evictable, then SetPageUnevictable here? I think not, we're
under LRU lock, and have no barriers between those.

Signed-off-by: Hugh Dickins <>
Reviewed-by: KOSAKI Motohiro <>
Cc: Minchan Kim <>
Cc: Rik van Riel <>
Cc: Shaohua Li <>
Cc: Eric Dumazet <>
Cc: Johannes Weiner <>
Cc: Michel Lespinasse <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoSHM_UNLOCK: fix long unpreemptible section
Hugh Dickins [Fri, 20 Jan 2012 22:34:19 +0000 (14:34 -0800)]
SHM_UNLOCK: fix long unpreemptible section

commit 85046579bde15e532983438f86b36856e358f417 upstream.

scan_mapping_unevictable_pages() is used to make SysV SHM_LOCKed pages
evictable again once the shared memory is unlocked.  It does this with
pagevec_lookup()s across the whole object (which might occupy most of
memory), and takes 300ms to unlock 7GB here.  A cond_resched() every
PAGEVEC_SIZE pages would be good.

However, KOSAKI-san points out that this is called under shmem.c's
info->lock, and it's also under shm.c's shm_lock(), both spinlocks.
There is no strong reason for that: we need to take these pages off the
unevictable list soonish, but those locks are not required for it.

So move the call to scan_mapping_unevictable_pages() from shmem.c's
unlock handling up to shm.c's unlock handling.  Remove the recently
added barrier, not needed now we have spin_unlock() before the scan.

Use get_file(), with subsequent fput(), to make sure we have a reference
to mapping throughout scan_mapping_unevictable_pages(): that's something
that was previously guaranteed by the shm_lock().

Remove shmctl's lru_add_drain_all(): we don't fault in pages at SHM_LOCK
time, and we lazily discover them to be Unevictable later, so it serves
no purpose for SHM_LOCK; and serves no purpose for SHM_UNLOCK, since
pages still on pagevec are not marked Unevictable.

The original code avoided redundant rescans by checking VM_LOCKED flag
at its level: now avoid them by checking shp's SHM_LOCKED.

The original code called scan_mapping_unevictable_pages() on a locked
area at shm_destroy() time: perhaps we once had accounting cross-checks
which required that, but not now, so skip the overhead and just let
inode eviction deal with them.

Put check_move_unevictable_page() and scan_mapping_unevictable_pages()
under CONFIG_SHMEM (with stub for the TINY case when ramfs is used),
more as comment than to save space; comment them used for SHM_UNLOCK.

Signed-off-by: Hugh Dickins <>
Reviewed-by: KOSAKI Motohiro <>
Cc: Minchan Kim <>
Cc: Rik van Riel <>
Cc: Shaohua Li <>
Cc: Eric Dumazet <>
Cc: Johannes Weiner <>
Cc: Michel Lespinasse <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoiwlegacy: 3945: fix hw passive scan on radar channels
Stanislaw Gruszka [Fri, 23 Dec 2011 07:13:50 +0000 (08:13 +0100)]
iwlegacy: 3945: fix hw passive scan on radar channels

commit 68acc4afb040d98ddfd2cae0de09e2f4e1ee127f upstream.

Patch fix firmware error on "iw dev wlan0 scan passive" for
hardware scanning (with disable_hw_scan=0 module parameter).

 iwl3945 0000:03:00.0: Microcode SW error detected. Restarting 0x82000008.
 iwl3945 0000:03:00.0: Loaded firmware version:
 iwl3945 0000:03:00.0: Start IWL Error Log Dump:
 iwl3945 0000:03:00.0: Status: 0x0002A2E4, count: 1
 iwl3945 0000:03:00.0: Desc       Time       asrtPC blink2 ilink1  nmiPC   Line
 iwl3945 0000:03:00.0: SYSASSERT     (0x5) 0041263900 0x13756 0x0031C 0x00000 764
 iwl3945 0000:03:00.0: Error Reply type 0x000002FC cmd C_SCAN (0x80) seq 0x443E ser 0x00340000
 iwl3945 0000:03:00.0: Command C_SCAN failed: FW Error
 iwl3945 0000:03:00.0: Can't stop Rx DMA.

We have disable ability to change passive scanning to active on
particular channel when traffic is detected on that channel. Otherwise
firmware will report error, when we try to do passive scan on radar

Reported-and-debugged-by: Pedro Francisco <>
Signed-off-by: Stanislaw Gruszka <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoiwlagn: check for SMPS mode
Wey-Yi Guy [Thu, 10 Nov 2011 14:55:04 +0000 (06:55 -0800)]
iwlagn: check for SMPS mode

commit b2ccccdca46273c7b321ecf5041c362cd950da20 upstream.

Check and report WARN only when its invalid


Signed-off-by: Wey-Yi Guy <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomm: fix NULL ptr dereference in __count_immobile_pages
Michal Hocko [Fri, 20 Jan 2012 22:33:55 +0000 (14:33 -0800)]
mm: fix NULL ptr dereference in __count_immobile_pages

commit 687875fb7de4a95223af20ee024282fa9099f860 upstream.

Fix the following NULL ptr dereference caused by

  cat /sys/devices/system/memory/memory0/removable

Pid: 13979, comm: sed Not tainted 3.0.13-0.5-default #1 IBM BladeCenter LS21 -[7971PAM]-/Server Blade
RIP: __count_immobile_pages+0x4/0x100
Process sed (pid: 13979, threadinfo ffff880221c36000, task ffff88022e788480)
Call Trace:

We are crashing because we are trying to dereference NULL zone which
came from pfn=0 (struct page ffffea0000000000). According to the boot
log this page is marked reserved:
e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)

and early_node_map confirms that:
early_node_map[3] active PFN ranges
    1: 0x00000010 -> 0x0000009c
    1: 0x00000100 -> 0x000bffa3
    1: 0x00100000 -> 0x00240000

The problem is that memory_present works in PAGE_SECTION_MASK aligned
blocks so the reserved range sneaks into the the section as well.  This
also means that free_area_init_node will not take care of those reserved
pages and they stay uninitialized.

When we try to read the removable status we walk through all available
sections and hope that the zone is valid for all pages in the section.
But this is not true in this case as the zone and nid are not initialized.

We have only one node in this particular case and it is marked as node=1
(rather than 0) and that made the problem visible because page_to_nid will
return 0 and there are no zones on the node.

Let's check that the zone is valid and that the given pfn falls into its
boundaries and mark the section not removable.  This might cause some
false positives, probably, but we do not have any sane way to find out
whether the page is reserved by the platform or it is just not used for
whatever other reasons.

Signed-off-by: Michal Hocko <>
Acked-by: Mel Gorman <>
Cc: KAMEZAWA Hiroyuki <>
Cc: Andrea Arcangeli <>
Cc: David Rientjes <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoproc: clear_refs: do not clear reserved pages
Will Deacon [Fri, 20 Jan 2012 22:34:09 +0000 (14:34 -0800)]
proc: clear_refs: do not clear reserved pages

commit 85e72aa5384b1a614563ad63257ded0e91d1a620 upstream.

/proc/pid/clear_refs is used to clear the Referenced and YOUNG bits for
pages and corresponding page table entries of the task with PID pid, which
includes any special mappings inserted into the page tables in order to
provide things like vDSOs and user helper functions.

On ARM this causes a problem because the vectors page is mapped as a
global mapping and since ec706dab ("ARM: add a vma entry for the user
accessible vector page"), a VMA is also inserted into each task for this
page to aid unwinding through signals and syscall restarts.  Since the
vectors page is required for handling faults, clearing the YOUNG bit (and
subsequently writing a faulting pte) means that we lose the vectors page
*globally* and cannot fault it back in.  This results in a system deadlock
on the next exception.

To see this problem in action, just run:

$ echo 1 > /proc/self/clear_refs

on an ARM platform (as any user) and watch your system hang.  I think this
has been the case since 2.6.37

This patch avoids clearing the aforementioned bits for reserved pages,
therefore leaving the vectors page intact on ARM.  Since reserved pages
are not candidates for swap, this change should not have any impact on the
usefulness of clear_refs.

Signed-off-by: Will Deacon <>
Reported-by: Moussa Ba <>
Acked-by: Hugh Dickins <>
Cc: David Rientjes <>
Cc: Russell King <>
Acked-by: Nicolas Pitre <>
Cc: Matt Mackall <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agokprobes: initialize before using a hlist
Ananth N Mavinakayanahalli [Fri, 20 Jan 2012 22:34:04 +0000 (14:34 -0800)]
kprobes: initialize before using a hlist

commit d496aab567e7e52b3e974c9192a5de6e77dce32c upstream.

Commit ef53d9c5e ("kprobes: improve kretprobe scalability with hashed
locking") introduced a bug where we can potentially leak
kretprobe_instances since we initialize a hlist head after having used

Initialize the hlist head before using it.

Reported by: Jim Keniston <>
Acked-by: Jim Keniston <>
Signed-off-by: Ananth N Mavinakayanahalli <>
Acked-by: Masami Hiramatsu <>
Cc: Srinivasa D S <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agocifs: lower default wsize when unix extensions are not used
Jeff Layton [Tue, 17 Jan 2012 21:08:51 +0000 (16:08 -0500)]
cifs: lower default wsize when unix extensions are not used

commit ce91acb3acae26f4163c5a6f1f695d1a1e8d9009 upstream.

We've had some reports of servers (namely, the Solaris in-kernel CIFS
server) that don't deal properly with writes that are "too large" even
though they set CAP_LARGE_WRITE_ANDX. Change the default to better
mirror what windows clients do.

Cc: Pavel Shilovsky <>
Reported-by: Nick Davis <>
Signed-off-by: Jeff Layton <>
Signed-off-by: Steve French <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoscore: fix off-by-one index into syscall table
Dan Rosenberg [Fri, 20 Jan 2012 22:34:27 +0000 (14:34 -0800)]
score: fix off-by-one index into syscall table

commit c25a785d6647984505fa165b5cd84cfc9a95970b upstream.

If the provided system call number is equal to __NR_syscalls, the
current check will pass and a function pointer just after the system
call table may be called, since sys_call_table is an array with total
size __NR_syscalls.

Whether or not this is a security bug depends on what the compiler puts
immediately after the system call table.  It's likely that this won't do
anything bad because there is an additional NULL check on the syscall
entry, but if there happens to be a non-NULL value immediately after the
system call table, this may result in local privilege escalation.

Signed-off-by: Dan Rosenberg <>
Cc: Chen Liqin <>
Cc: Lennox Wu <>
Cc: Eugene Teo <>
Cc: Arnd Bergmann <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoi2c-eg20t: modified the setting of transfer rate.
Toshiharu Okada [Mon, 26 Sep 2011 07:16:23 +0000 (16:16 +0900)]
i2c-eg20t: modified the setting of transfer rate.

commit ff35e8b18984ad2a82cbd259fc07f0be4b34b1aa upstream.

This patch modified the setting value of
I2C Bus Transfer Rate Setting Counter regisrer.

Signed-off-by: Toshiharu Okada <>
Signed-off-by: Ben Dooks <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoxfs: fix endian conversion issue in discard code
Dave Chinner [Wed, 18 Jan 2012 20:41:45 +0000 (14:41 -0600)]
xfs: fix endian conversion issue in discard code

commit b1c770c273a4787069306fc82aab245e9ac72e9d upstream

When finding the longest extent in an AG, we read the value directly
out of the AGF buffer without endian conversion. This will give an
incorrect length, resulting in FITRIM operations potentially not
trimming everything that it should.

Signed-off-by: Dave Chinner <>
Reviewed-by: Christoph Hellwig <>
Signed-off-by: Ben Myers <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agort2800pci: fix spurious interrupts generation
Stanislaw Gruszka [Fri, 13 Jan 2012 11:59:32 +0000 (12:59 +0100)]
rt2800pci: fix spurious interrupts generation

commit dfd00c4c8f3dfa1fd7cec45f83d98b2a49743dcd upstream.

Same devices can generate interrupt without properly setting bit in
INT_SOURCE_CSR register (spurious interrupt), what will cause IRQ line
will be disabled by interrupts controller driver.

We discovered that clearing INT_MASK_CSR stops such behaviour. We
previously first read that register, and then clear all know interrupt
sources bits and do not touch reserved bits. After this patch, we write
to all register content (I believe writing to reserved bits on that
register will not cause any problems, I tested that on my rt2800pci

This fix very bad performance problem, practically making device
unusable (since worked without interrupts), reported in:

We previously tried to workaround that issue in commit
4ba7d9997869d25bd223dea7536fc1ce9fab3b3b "rt2800pci: handle spurious
interrupts", but it was reverted in commit
as thing, that will prevent to detect real spurious interrupts.

Reported-and-tested-by: Amir Hedayaty <>
Signed-off-by: Stanislaw Gruszka <>
Acked-by: Gertjan van Wingerde <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoath9k_hw: fix interpretation of the rx KeyMiss flag
Felix Fietkau [Sat, 14 Jan 2012 14:08:34 +0000 (15:08 +0100)]
ath9k_hw: fix interpretation of the rx KeyMiss flag

commit 7a532fe7131216a02c81a6c1b1f8632da1195a58 upstream.

Documentation states that the KeyMiss flag is only valid if RxFrameOK is
unset, however empirical evidence has shown that this is false.
When KeyMiss is set (and RxFrameOK is 1), the hardware passes a valid frame
which has not been decrypted. The driver then falsely marks the frame
as decrypted, and when using CCMP this corrupts the rx CCMP PN, leading
to connection hangs.

Signed-off-by: Felix Fietkau <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agox86/UV2: Work around BAU bug
Cliff Wickman [Mon, 16 Jan 2012 21:19:47 +0000 (15:19 -0600)]
x86/UV2: Work around BAU bug

commit c5d35d399e685acccc85a675e8765c26b2a9813a upstream.

This patch implements a workaround for a UV2 hardware bug.
The bug is a non-atomic update of a memory-mapped register. When
hardware message delivery and software message acknowledge occur
simultaneously the pending message acknowledge for the arriving
message may be lost.  This causes the sender's message status to
stay busy.

Part of the workaround is to not acknowledge a completed message
until it is verified that no other message is actually using the
resource that is mistakenly recorded in the completed message.

Part of the workaround is to test for long elapsed time in such
a busy condition, then handle it by using a spare sending
descriptor. The stay-busy condition is eventually timed out by
hardware, and then the original sending descriptor can be
re-used. Most of that logic change is in keeping track of the
current descriptor and the state of the spares.

The occurrences of the workaround are added to the BAU

Signed-off-by: Cliff Wickman <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agox86/UV2: Fix BAU destination timeout initialization
Cliff Wickman [Mon, 16 Jan 2012 21:18:48 +0000 (15:18 -0600)]
x86/UV2: Fix BAU destination timeout initialization

commit d059f9fa84a30e04279c6ff615e9e2cf3b260191 upstream.

Move the call to enable_timeouts() forward so that
BAU_MISC_CONTROL is initialized before using it in

Fix the calculation of a BAU destination timeout
for UV2 (in calculate_destination_timeout()).

Signed-off-by: Cliff Wickman <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agox86/UV2: Fix new UV2 hardware by using native UV2 broadcast mode
Cliff Wickman [Mon, 16 Jan 2012 21:17:50 +0000 (15:17 -0600)]
x86/UV2: Fix new UV2 hardware by using native UV2 broadcast mode

commit da87c937e5a2374686edd58df06cfd5050b125fa upstream.

Update the use of the Broadcast Assist Unit on SGI Altix UV2 to
the use of native UV2 mode on new hardware (not the legacy mode).

UV2 native mode has a different format for a broadcast message.
We also need quick differentiaton between UV1 and UV2.

Signed-off-by: Cliff Wickman <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoI2C: OMAP: correct SYSC register offset for OMAP4
Alexander Aring [Thu, 8 Dec 2011 14:43:53 +0000 (15:43 +0100)]
I2C: OMAP: correct SYSC register offset for OMAP4

commit 2727b1753934e154931d6b3bdf20c9b2398457a2 upstream.

Correct OMAP_I2C_SYSC_REG offset in omap4 register map.
Offset 0x20 is reserved and OMAP_I2C_SYSC_REG has 0x10 as offset.

Signed-off-by: Alexander Aring <>
[ minor changelog edits]
Signed-off-by: Kevin Hilman <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotracepoints/module: Fix disabling tracepoints with taint CRAP or OOT
Steven Rostedt [Sat, 14 Jan 2012 02:40:59 +0000 (21:40 -0500)]
tracepoints/module: Fix disabling tracepoints with taint CRAP or OOT

commit c10076c4304083af15a41f6bc5e657e781c1f9a6 upstream.

Tracepoints are disabled for tainted modules, which is usually because the
module is either proprietary or was forced, and we don't want either of them
using kernel tracepoints.

But, a module can also be tainted by being in the staging directory or
compiled out of tree. Either is fine for use with tracepoints, no need
to punish them.  I found this out when I noticed that my sample trace event
module, when done out of tree, stopped working.

Cc: Mathieu Desnoyers <>
Cc: Ben Hutchings <>
Cc: Dave Jones <>
Cc: Greg Kroah-Hartman <>
Cc: Rusty Russell <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotuner: Fix numberspace conflict between xc4000 and pti 5nf05 tuners
Miroslav Slugen [Sun, 11 Dec 2011 21:47:32 +0000 (18:47 -0300)]
tuner: Fix numberspace conflict between xc4000 and pti 5nf05 tuners

commit cd4ca7afc61d3b18fcd635002459fb6b1d701099 upstream.

Update xc4000 tuner definition, number 81 is already in use by

Signed-off-by: Miroslav Slugen <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agocx88: fix: don't duplicate xc4000 entry for radio
Miroslav Slugen [Sun, 11 Dec 2011 22:00:06 +0000 (19:00 -0300)]
cx88: fix: don't duplicate xc4000 entry for radio

commit b6854e3f31402476bcc9d2f41570389fa491de17 upstream.

All radio tuners in cx88 driver using same address for radio and tuner,
so there is no need to probe it twice for same tuner and we can use
radio_type UNSET, this also fix broken radio since kernel 2.6.39-rc1
for those tuners.

Signed-off-by: Miroslav Slugen <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agocx23885-dvb: check if dvb_attach() succeded
Miroslav Slugen [Sun, 11 Dec 2011 21:57:58 +0000 (18:57 -0300)]
cx23885-dvb: check if dvb_attach() succeded

commit a7c8aadad39428b64d26c3971d967f8314e2397d upstream.

Fix possible null dereference for Leadtek DTV 3200H
XC4000 tuner when no firmware file available.

Signed-off-by: Miroslav Slugen <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agobcma: invalidate the mapped core over suspend/resume
Rafał Miłecki [Fri, 13 Jan 2012 22:58:38 +0000 (23:58 +0100)]
bcma: invalidate the mapped core over suspend/resume

commit 28e7d218da975f6ae1751e293aed938952c55c98 upstream.

This clears the currently mapped core when suspending, to force
re-mapping after resume. Without that we were touching default core
registers believing some other core is mapped. Such a behaviour
resulted in lockups on some machines.

Signed-off-by: Rafał Miłecki <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotarget: Set additional sense length field in sense data
Roland Dreier [Tue, 13 Dec 2011 22:55:33 +0000 (14:55 -0800)]
target: Set additional sense length field in sense data

commit 895f3022523361e9b383cf48f51feb1f7d5e7e53 upstream.

The target code was not setting the additional sense length field in the
sense data it returned, which meant that at least the Linux stack
ignored the ASC/ASCQ fields.  For example, without this patch, on a
tcm_loop device:

    # sg_raw -v /dev/sda 2 0 0 0 0 0


        cdb to send: 02 00 00 00 00 00
    SCSI Status: Check Condition

    Sense Information:
     Fixed format, current;  Sense key: Illegal Request
      Raw sense data (in hex):
            70 00 05 00 00 00 00 00

while after the patch we correctly get the following (which matches what
a regular disk returns):

        cdb to send: 02 00 00 00 00 00
    SCSI Status: Check Condition

    Sense Information:
     Fixed format, current;  Sense key: Illegal Request
     Additional sense: Invalid command operation code
     Raw sense data (in hex):
            70 00 05 00 00 00 00 0a  00 00 00 00 20 00 00 00
            00 00

Signed-off-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotarget: Set response format in INQUIRY response
Roland Dreier [Tue, 6 Dec 2011 18:02:09 +0000 (10:02 -0800)]
target: Set response format in INQUIRY response

commit ce136176fea522fc8f4c16dcae7e8ed1d890ca39 upstream.

Current SCSI specs say that the "response format" field in the standard
INQUIRY response should be set to 2, and all the real SCSI devices I
have do put 2 here.  So let's do that too.

Signed-off-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agosym53c8xx: Fix NULL pointer dereference in slave_destroy
Stratos Psomadakis [Sun, 4 Dec 2011 00:23:54 +0000 (02:23 +0200)]
sym53c8xx: Fix NULL pointer dereference in slave_destroy

commit cced5041ed5a2d1352186510944b0ddfbdbe4c0b upstream.

sym53c8xx_slave_destroy unconditionally assumes that sym53c8xx_slave_alloc has
succesesfully allocated a sym_lcb. This can lead to a NULL pointer dereference
(exposed by commit 4e6c82b).

Signed-off-by: Stratos Psomadakis <>
Signed-off-by: James Bottomley <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoACPI: processor: fix acpi_get_cpuid for UP processor
Lin Ming [Tue, 13 Dec 2011 01:36:03 +0000 (09:36 +0800)]
ACPI: processor: fix acpi_get_cpuid for UP processor

commit d640113fe80e45ebd4a5b420b220d3f6bf37f682 upstream.

For UP processor, it is likely that no _MAT method or MADT table defined.
So currently acpi_get_cpuid(...) always return -1 for UP processor.
This is wrong. It should return valid value for CPU0.

In the other hand, BIOS may define multiple CPU handles even for UP
processor, for example

        Scope (_PR)
            Processor (CPU0, 0x00, 0x00000410, 0x06) {}
            Processor (CPU1, 0x01, 0x00000410, 0x06) {}
            Processor (CPU2, 0x02, 0x00000410, 0x06) {}
            Processor (CPU3, 0x03, 0x00000410, 0x06) {}

We should only return valid value for CPU0's acpi handle.
And return invalid value for others.

Signed-off-by: Lin Ming <>
Signed-off-by: Len Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoACPICA: Put back the call to acpi_os_validate_address
Lin Ming [Tue, 29 Nov 2011 14:13:35 +0000 (22:13 +0800)]
ACPICA: Put back the call to acpi_os_validate_address

commit da4d8b287abe783d30e968155614531a0937d090 upstream.

The call to acpi_os_validate_address in acpi_ds_get_region_arguments was
removed by mistake in commit 9ad19ac(ACPICA: Split large dsopcode and
dsload.c files).

Put it back.

Reported-and-bisected-by: Luca Tettamanti <>
Signed-off-by: Lin Ming <>
Signed-off-by: Len Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoACPI, ia64: Use SRAT table rev to use 8bit or 16/32bit PXM fields (ia64)
Kurt Garloff [Tue, 17 Jan 2012 09:21:49 +0000 (04:21 -0500)]
ACPI, ia64: Use SRAT table rev to use 8bit or 16/32bit PXM fields (ia64)

commit 9f10f6a520deb3639fac78d81151a3ade88b4e7f upstream.

In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
32bits for these. The new fields were reserved before.
According to the ACPI spec, the OS must disregrard reserved fields.

ia64 did handle the PXM fields almost consistently, but depending on
sgi's sn2 platform. This patch leaves the sn2 logic in, but does also
use 16/32 bits for PXM if the SRAT has rev 2 or higher.

The patch also adds __init to the two pxm accessor functions, as they
access __initdata now and are called from an __init function only anyway.

Note that the code only uses 16 bits for the PXM field in the processor
proximity field; the patch does not address this as 16 bits are more than

Signed-off-by: Kurt Garloff <>
Signed-off-by: Len Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoACPI, x86: Use SRAT table rev to use 8bit or 32bit PXM fields (x86/x86-64)
Kurt Garloff [Tue, 17 Jan 2012 09:20:31 +0000 (04:20 -0500)]
ACPI, x86: Use SRAT table rev to use 8bit or 32bit PXM fields (x86/x86-64)

commit cd298f60a2451a16e0f077404bf69b62ec868733 upstream.

In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
32bits for these. The new fields were reserved before.
According to the ACPI spec, the OS must disregrard reserved fields.

x86/x86-64 was rather inconsistent prior to this patch; it used 8 bits
for the pxm field in cpu_affinity, but 32 bits in mem_affinity.
This patch makes it consistent: Either use 8 bits consistently (SRAT
rev 1 or lower) or 32 bits (SRAT rev 2 or higher).

Signed-off-by: Kurt Garloff <>
Signed-off-by: Len Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoACPI: Store SRAT table revision
Kurt Garloff [Tue, 17 Jan 2012 09:18:02 +0000 (04:18 -0500)]
ACPI: Store SRAT table revision

commit 8df0eb7c9d96f9e82f233ee8b74e0f0c8471f868 upstream.

In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
32bits for these. The new fields were reserved before.
According to the ACPI spec, the OS must disregrard reserved fields.
In order to know whether or not, we must know what version the SRAT
table has.

This patch stores the SRAT table revision for later consumption
by arch specific __init functions.

Signed-off-by: Kurt Garloff <>
Signed-off-by: Len Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agointel_idle: fix API misuse
Shaohua Li [Tue, 10 Jan 2012 23:48:19 +0000 (15:48 -0800)]
intel_idle: fix API misuse

commit 39a74fdedd1c1461d6fb6d330b5266886513c98f upstream.

smp_call_function() only lets all other CPUs execute a specific function,
while we expect all CPUs do in intel_idle.  Without the fix, we could have
one cpu which has auto_demotion enabled or has no broadcast timer setup.
Usually we don't see impact because auto demotion just harms power and the
intel_idle init is called in CPU 0, where boradcast timer delivers
interrupt, but this still could be a problem.

Signed-off-by: Shaohua Li <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Len Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agointel idle: Make idle driver more robust
Thomas Renninger [Sun, 4 Dec 2011 21:17:29 +0000 (22:17 +0100)]
intel idle: Make idle driver more robust

commit 5c2a9f06a9cd7194f884cdc88144866235dec07d upstream.

kvm -cpu host passes the original cpuid info to the guest.

Latest kvm version seem to return true for mwait_leaf cpuid
function on recent Intel CPUs. But it does not return mwait
C-states (mwait_substates), instead zero is returned.

While real CPUs seem to always return non-zero values, the intel
idle driver should not get active in kvm (mwait_substates == 0)
case and bail out.
Otherwise a Null pointer exception will happen later when the
cpuidle subsystem tries to get active:
[0.984807] BUG: unable to handle kernel NULL pointer dereference at (null)
[0.984807] IP: [<(null)>] (null)
[0.984807][<ffffffff8143cf34>] ? cpuidle_idle_call+0xb4/0x340
[0.984807][<ffffffff8159e7bc>] ? __atomic_notifier_call_chain+0x4c/0x70
[0.984807][<ffffffff81001198>] ? cpu_idle+0x78/0xd0


Signed-off-by: Thomas Renninger <>
CC: Bruno Friedmann <>
Signed-off-by: Len Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoTOMOYO: Accept \000 as a valid character.
Tetsuo Handa [Sun, 15 Jan 2012 02:05:59 +0000 (11:05 +0900)]
TOMOYO: Accept \000 as a valid character.

commit 25add8cf99c9ec8b8dc0acd8b9241e963fc0d29c upstream.

TOMOYO 2.5 in Linux 3.2 and later handles Unix domain socket's address.
Thus, tomoyo_correct_word2() needs to accept \000 as a valid character, or
TOMOYO 2.5 cannot handle Unix domain's abstract socket address.

Reported-by: Steven Allen <>
Signed-off-by: Tetsuo Handa <>
Signed-off-by: James Morris <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
David Henningsson [Mon, 16 Jan 2012 09:52:20 +0000 (10:52 +0100)]
ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645

commit ffe535edb9a9c5b4d5fe03dfa3d89a1495580f1b upstream.

More than one user reports that changing the model from "both" to
"dmic" makes their Internal Mic work.

Tested-by: Martin Ling <>
Signed-off-by: David Henningsson <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoALSA: virtuoso: Xonar DS: fix polarity of front output
Clemens Ladisch [Sat, 14 Jan 2012 15:42:24 +0000 (16:42 +0100)]
ALSA: virtuoso: Xonar DS: fix polarity of front output

commit f0e48b6bd4e407459715240cd241ddb6b89bdf81 upstream.

The two DACs for the front output and the surround/center/LFE/back
outputs are wired up out of phase, so when channels are duplicated,
their sound can cancel out each other and result in a weaker bass
response.  To fix this, reverse the polarity of the neutron flow to
the front output.

Reported-any-tested-by: Daniel Hill <>
Signed-off-by: Clemens Ladisch <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoALSA: HDA: Use LPIB position fix for Macbook Pro 7,1
David Henningsson [Thu, 12 Jan 2012 15:31:14 +0000 (16:31 +0100)]
ALSA: HDA: Use LPIB position fix for Macbook Pro 7,1

commit b01de4fb40137fbda7530550ff0cd37171dafb0c upstream.

Several users have reported "choppy" audio under the 3.2 kernel,
and that changing position_fix to 1 has resolved their problem.
The chip is an nVidia Corporation MCP89 High Definition Audio,
[10de:0d94] (rev a2).

Signed-off-by: David Henningsson <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoproc: clean up and fix /proc/<pid>/mem handling
Linus Torvalds [Tue, 17 Jan 2012 23:21:19 +0000 (15:21 -0800)]
proc: clean up and fix /proc/<pid>/mem handling

commit e268337dfe26dfc7efd422a804dbb27977a3cccc upstream.

Jüri Aedla reported that the /proc/<pid>/mem handling really isn't very
robust, and it also doesn't match the permission checking of any of the
other related files.

This changes it to do the permission checks at open time, and instead of
tracking the process, it tracks the VM at the time of the open.  That
simplifies the code a lot, but does mean that if you hold the file
descriptor open over an execve(), you'll continue to read from the _old_

That is different from our previous behavior, but much simpler.  If
somebody actually finds a load where this matters, we'll need to revert
this commit.

I suspect that nobody will ever notice - because the process mapping
addresses will also have changed as part of the execve.  So you cannot
actually usefully access the fd across a VM change simply because all
the offsets for IO would have changed too.

Reported-by: Jüri Aedla <>
Cc: Al Viro <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodm: do not forward ioctls from logical volumes to the underlying device
Paolo Bonzini [Thu, 12 Jan 2012 15:01:29 +0000 (16:01 +0100)]
dm: do not forward ioctls from logical volumes to the underlying device

commit ec8013beddd717d1740cfefb1a9b900deef85462 upstream.

A logical volume can map to just part of underlying physical volume.
In this case, it must be treated like a partition.

Based on a patch from Alasdair G Kergon.

Cc: Alasdair G Kergon <>
Signed-off-by: Paolo Bonzini <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoblock: fail SCSI passthrough ioctls on partition devices
Paolo Bonzini [Thu, 12 Jan 2012 15:01:28 +0000 (16:01 +0100)]
block: fail SCSI passthrough ioctls on partition devices

commit 0bfc96cb77224736dfa35c3c555d37b3646ef35e upstream.

[ Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl
  and -ENOIOCTLCMD from sd_compat_ioctl. ]

Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
will pass the command to the underlying block device.  This is
well-known, but it is also a large security problem when (via Unix
permissions, ACLs, SELinux or a combination thereof) a program or user
needs to be granted access only to part of the disk.

This patch lets partitions forward a small set of harmless ioctls;
others are logged with printk so that we can see which ioctls are
actually sent.  In my tests only CDROM_GET_CAPABILITY actually occurred.
Of course it was being sent to a (partition on a) hard disk, so it would
have failed with ENOTTY and the patch isn't changing anything in
practice.  Still, I'm treating it specially to avoid spamming the logs.

In principle, this restriction should include programs running with
CAP_SYS_RAWIO.  If for example I let a program access /dev/sda2 and
/dev/sdb, it still should not be able to read/write outside the
boundaries of /dev/sda2 independent of the capabilities.  However, for
now programs with CAP_SYS_RAWIO will still be allowed to send the
ioctls.  Their actions will still be logged.

This patch does not affect the non-libata IDE driver.  That driver
however already tests for bd != bd->bd_contains before issuing some
ioctl; it could be restricted further to forbid these ioctls even for
programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.

Cc: Jens Axboe <>
Cc: James Bottomley <>
Signed-off-by: Paolo Bonzini <>
[ Make it also print the command name when warning - Linus ]
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoblock: add and use scsi_blk_cmd_ioctl
Paolo Bonzini [Thu, 12 Jan 2012 15:01:27 +0000 (16:01 +0100)]
block: add and use scsi_blk_cmd_ioctl

commit 577ebb374c78314ac4617242f509e2f5e7156649 upstream.

Introduce a wrapper around scsi_cmd_ioctl that takes a block device.

The function will then be enhanced to detect partition block devices
and, in that case, subject the ioctls to whitelisting.

Cc: Jens Axboe <>
Cc: James Bottomley <>
Signed-off-by: Paolo Bonzini <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agofix cputime overflow in uptime_proc_show
Martin Schwidefsky [Thu, 15 Dec 2011 13:56:10 +0000 (14:56 +0100)]
fix cputime overflow in uptime_proc_show

commit c3e0ef9a298e028a82ada28101ccd5cf64d209ee upstream.

For 32-bit architectures using standard jiffies the idletime calculation
in uptime_proc_show will quickly overflow. It takes (2^32 / HZ) seconds
of idle-time, or e.g. 12.45 days with no load on a quad-core with HZ=1000.
Switch to 64-bit calculations.

Cc: Michael Abbott <>
Signed-off-by: Martin Schwidefsky <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoHID: hid-multitouch: add support 9 new Xiroku devices
Masatoshi Hoshikawa [Thu, 5 Jan 2012 02:53:46 +0000 (11:53 +0900)]
HID: hid-multitouch: add support 9 new Xiroku devices

commit 11576c6114c3b6505aea2e0c988bedb856a0e20c upstream.

This patch adds support for the Xiroku Inc. panels (SPX/MPX/CSR/etc.).

Signed-off-by: Masatoshi Hoshikawa <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoHID: multitouch: add support for 3M 32"
Benjamin Tissoires [Fri, 23 Dec 2011 14:41:00 +0000 (15:41 +0100)]
HID: multitouch: add support for 3M 32"

commit c4fad877cd0efb51d8180ae2eaa791c99c92051c upstream.

Signed-off-by: Benjamin Tissoires <>
Acked-by: Henrik Rydberg <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoHID: multitouch: add support of Atmel multitouch panels
Benjamin Tissoires [Fri, 23 Dec 2011 14:40:59 +0000 (15:40 +0100)]
HID: multitouch: add support of Atmel multitouch panels

commit b105712469d957cf1ab223c1ea72b7ba88edb926 upstream.

Signed-off-by: Benjamin Tissoires <>
Acked-by: Henrik Rydberg <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoHID: hid-multitouch: add support for new Hanvon panels
Benjamin Tissoires [Tue, 29 Nov 2011 12:13:12 +0000 (13:13 +0100)]
HID: hid-multitouch: add support for new Hanvon panels

commit 545803651da8dde248eeb8ce3ed1e547e9e4ac0a upstream.

Signed-off-by: Benjamin Tissoires <>
Acked-by: Henrik Rydberg <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoHID: multitouch: add support for the MSI Windpad 110W
Benjamin Tissoires [Wed, 23 Nov 2011 09:54:33 +0000 (10:54 +0100)]
HID: multitouch: add support for the MSI Windpad 110W

commit 66f06127f34ad6e8a1b24a2c03144b694d19f99f upstream.

Just another eGalax device.
Please note that adding this device to have_special_driver
in hid-core.c is not required anymore.

Signed-off-by: Benjamin Tissoires <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoHID: multitouch: Add egalax ID for Acer Iconia W500
Marek Vasut [Wed, 23 Nov 2011 09:54:32 +0000 (10:54 +0100)]
HID: multitouch: Add egalax ID for Acer Iconia W500

commit bb9ff21072043634f147c05ac65dbf8185d4af6d upstream.

This patch adds USB ID for the touchpanel in Acer Iconia W500. The panel
supports up to five fingers, therefore the need for a new addition of panel

Signed-off-by: Marek Vasut <>
Signed-off-by: Benjamin Tissoires <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoHID: multitouch: cleanup with eGalax PID definitions
Benjamin Tissoires [Wed, 23 Nov 2011 09:54:31 +0000 (10:54 +0100)]
HID: multitouch: cleanup with eGalax PID definitions

commit e36f690b37945e0a9bb1554e1546eeec93f7d1f6 upstream.

This is just a renaming of USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH{N}

Signed-off-by: Benjamin Tissoires <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoHID: hid-multitouch - add another eGalax id
Chris Bagwell [Wed, 23 Nov 2011 09:54:27 +0000 (10:54 +0100)]
HID: hid-multitouch - add another eGalax id

commit 1fd8f047490dd0ec4e4db710fcbc1bd4798d944c upstream.

This allows ASUS Eee Slate touchscreens to work.

Signed-off-by: Chris Bagwell <>
Reviewed-by: Benjamin Tissoires <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomac80211: revert on-channel work optimisations
Johannes Berg [Tue, 29 Nov 2011 09:20:02 +0000 (10:20 +0100)]
mac80211: revert on-channel work optimisations

commit e76aadc572288a158ae18ae1c10fe395c7bca066 upstream.

Backport note:
This patch it's a full revert of commit b23b025f "mac80211: Optimize
scans on current operating channel.". On upstrem revert e76aadc5 we
keep some bits from that commit, which are needed for upstream version
of mac80211.

The on-channel work optimisations have caused a
number of issues, and the code is unfortunately
very complex and almost impossible to follow.
Instead of attempting to put in more workarounds
let's just remove those optimisations, we can
work on them again later, after we change the
whole auth/assoc design.

This should fix rate_control_send_low() warnings,
see RH bug 731365.

Signed-off-by: Johannes Berg <>
Signed-off-by: John W. Linville <>
Signed-off-by: Stanislaw Gruszka <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agopnfsblock: limit bio page count
Peng Tao [Thu, 12 Jan 2012 15:18:48 +0000 (23:18 +0800)]
pnfsblock: limit bio page count

commit 74a6eeb44ca6174d9cc93b9b8b4d58211c57bc80 upstream.

One bio can have at most BIO_MAX_PAGES pages. We should limit it bec otherwise
bio_alloc will fail when there are many pages in one read/write_pagelist.

Signed-off-by: Peng Tao <>
Signed-off-by: Benny Halevy <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agopnfsblock: don't spinlock when freeing block_dev
Peng Tao [Thu, 12 Jan 2012 15:18:47 +0000 (23:18 +0800)]
pnfsblock: don't spinlock when freeing block_dev

commit 93a3844ee0f843b05a1df4b52e1a19ff26b98d24 upstream.

bl_free_block_dev() may sleep. We can not call it with spinlock held.
Besides, there is no need to take bm_lock as we are last user freeing bm_devlist.

Signed-off-by: Peng Tao <>
Signed-off-by: Benny Halevy <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agopnfsblock: acquire im_lock in _preload_range
Peng Tao [Thu, 12 Jan 2012 15:18:41 +0000 (23:18 +0800)]
pnfsblock: acquire im_lock in _preload_range

commit 39e567ae36fe03c2b446e1b83ee3d39bea08f90b upstream.

When calling _add_entry, we should take the im_lock to protect
agains other modifiers.

Signed-off-by: Peng Tao <>
Signed-off-by: Benny Halevy <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agofix shrink_dcache_parent() livelock
Miklos Szeredi [Tue, 10 Jan 2012 17:22:25 +0000 (18:22 +0100)]
fix shrink_dcache_parent() livelock

commit eaf5f9073533cde21c7121c136f1c3f072d9cf59 upstream.

Two (or more) concurrent calls of shrink_dcache_parent() on the same dentry may
cause shrink_dcache_parent() to loop forever.

Here's what appears to happen:

1 - CPU0: select_parent(P) finds C and puts it on dispose list, returns 1

2 - CPU1: select_parent(P) locks P->d_lock

3 - CPU0: shrink_dentry_list() locks C->d_lock
   dentry_kill(C) tries to lock P->d_lock but fails, unlocks C->d_lock

4 - CPU1: select_parent(P) locks C->d_lock,
         moves C from dispose list being processed on CPU0 to the new
dispose list, returns 1

5 - CPU0: shrink_dentry_list() finds dispose list empty, returns

6 - Goto 2 with CPU0 and CPU1 switched

Basically select_parent() steals the dentry from shrink_dentry_list() and thinks
it found a new one, causing shrink_dentry_list() to think it's making progress
and loop over and over.

One way to trigger this is to make udev calls stat() on the sysfs file while it
is going away.

Having a file in /lib/udev/rules.d/ with only this one rule seems to the trick:

ATTR{vendor}=="0x8086", ATTR{device}=="0x10ca", ENV{PCI_SLOT_NAME}="%k", ENV{MATCHADDR}="$attr{address}", RUN+="/bin/true"

Then execute the following loop:

while true; do
        echo -bond0 > /sys/class/net/bonding_masters
        echo +bond0 > /sys/class/net/bonding_masters
        echo -bond1 > /sys/class/net/bonding_masters
        echo +bond1 > /sys/class/net/bonding_masters

One fix would be to check all callers and prevent concurrent calls to
shrink_dcache_parent().  But I think a better solution is to stop the
stealing behavior.

This patch adds a new dentry flag that is set when the dentry is added to the
dispose list.  The flag is cleared in dentry_lru_del() in case the dentry gets a
new reference just before being pruned.

If the dentry has this flag, select_parent() will skip it and let
shrink_dentry_list() retry pruning it.  With select_parent() skipping those
dentries there will not be the appearance of progress (new dentries found) when
there is none, hence shrink_dcache_parent() will not loop forever.

Set the flag is also set in prune_dcache_sb() for consistency as suggested by

Signed-off-by: Miklos Szeredi <>
Signed-off-by: Al Viro <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodcache: use a dispose list in select_parent
Dave Chinner [Tue, 23 Aug 2011 08:56:24 +0000 (18:56 +1000)]
dcache: use a dispose list in select_parent

commit b48f03b319ba78f3abf9a7044d1f436d8d90f4f9 upstream.

select_parent currently abuses the dentry cache LRU to provide
cleanup features for child dentries that need to be freed. It moves
them to the tail of the LRU, then tells shrink_dcache_parent() to
calls __shrink_dcache_sb to unconditionally move them to a dispose
list (as DCACHE_REFERENCED is ignored). __shrink_dcache_sb() has to
relock the dentries to move them off the LRU onto the dispose list,
but otherwise does not touch the dentries that select_parent() moved
to the tail of the LRU. It then passses the dispose list to
shrink_dentry_list() which tries to free the dentries.

IOWs, the use of __shrink_dcache_sb() is superfluous - we can build
exactly the same list of dentries for disposal directly in
select_parent() and call shrink_dentry_list() instead of calling
__shrink_dcache_sb() to do that. This means that we avoid long holds
on the lru lock walking the LRU moving dentries to the dispose list
We also avoid the need to relock each dentry just to move it off the
LRU, reducing the numebr of times we lock each dentry to dispose of
them in shrink_dcache_parent() from 3 to 2 times.

Further, we remove one of the two callers of __shrink_dcache_sb().
This also means that __shrink_dcache_sb can be moved into back into
prune_dcache_sb() and we no longer have to handle referenced
dentries conditionally, simplifying the code.

Signed-off-by: Dave Chinner <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Al Viro <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agouvcvideo: Fix integer overflow in uvc_ioctl_ctrl_map()
Haogang Chen [Tue, 29 Nov 2011 21:32:25 +0000 (18:32 -0300)]
uvcvideo: Fix integer overflow in uvc_ioctl_ctrl_map()

commit 806e23e95f94a27ee445022d724060b9b45cb64a upstream.

There is a potential integer overflow in uvc_ioctl_ctrl_map(). When a
large xmap->menu_count is passed from the userspace, the subsequent call
to kmalloc() will allocate a buffer smaller than expected.
map->menu_count and map->menu_info would later be used in a loop (e.g.
in uvc_query_v4l2_ctrl), which leads to out-of-bound access.

The patch checks the ioctl argument and returns -EINVAL for zero or too
large values in xmap->menu_count.

Signed-off-by: Haogang Chen <>
[ Prevent excessive memory consumption]
Signed-off-by: Laurent Pinchart <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agorecordmcount: Fix handling of elf64 big-endian objects.
David Daney [Tue, 20 Dec 2011 01:42:42 +0000 (17:42 -0800)]
recordmcount: Fix handling of elf64 big-endian objects.

commit 2e885057b7f75035f0b85e02f737891482815a81 upstream.

In ELF64, the sh_flags field is 64-bits wide.  recordmcount was
erroneously treating it as a 32-bit wide field.  For little endian
objects this works because the flags of interest (SHF_EXECINSTR)
reside in the lower 32 bits of the word, and you get the same result
with either a 32-bit or 64-bit read.  Big endian objects on the
other hand do not work at all with this error.

The fix:  Correctly treat sh_flags as 64-bits wide in elf64 objects.

The symptom I observed was that my
__start_mcount_loc..__stop_mcount_loc was empty even though ftrace
function tracing was enabled.

Signed-off-by: David Daney <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agox86, UV: Update Boot messages for SGI UV2 platform
Jack Steiner [Fri, 6 Jan 2012 19:19:00 +0000 (13:19 -0600)]
x86, UV: Update Boot messages for SGI UV2 platform

commit da517a08ac5913cd80ce3507cddd00f2a091b13c upstream.

SGI UV systems print a message during boot:

UV: Found <num> blades

Due to packaging changes, the blade count is not accurate for
on the next generation of the platform. This patch corrects the

Signed-off-by: Jack Steiner <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agofsnotify: don't BUG in fsnotify_destroy_mark()
Miklos Szeredi [Thu, 12 Jan 2012 16:59:46 +0000 (17:59 +0100)]
fsnotify: don't BUG in fsnotify_destroy_mark()

commit fed474857efbed79cd390d0aee224231ca718f63 upstream.

Removing the parent of a watched file results in "kernel BUG at

To reproduce

  add "-w /tmp/audit/dir/watched_file" to audit.rules
  rm -rf /tmp/audit/dir

This is caused by fsnotify_destroy_mark() being called without an
extra reference taken by the caller.

Reported by Francesco Cosoleto here:

Fix by removing the BUG_ON and adding a comment about not accessing mark after
the iput.

Signed-off-by: Miklos Szeredi <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agonfsd: Fix oops when parsing a 0 length export
Sasha Levin [Fri, 18 Nov 2011 10:14:49 +0000 (12:14 +0200)]
nfsd: Fix oops when parsing a 0 length export

commit b2ea70afade7080360ac55c4e64ff7a5fafdb67b upstream.

expkey_parse() oopses when handling a 0 length export. This is easily
triggerable from usermode by writing 0 bytes into
'/proc/[proc id]/net/rpc/nfsd.fh/channel'.

Below is the log:

[ 1402.286893] BUG: unable to handle kernel paging request at ffff880077c49fff
[ 1402.287632] IP: [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
[ 1402.287632] PGD 2206063 PUD 1fdfd067 PMD 1ffbc067 PTE 8000000077c49160
[ 1402.287632] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 1402.287632] CPU 1
[ 1402.287632] Pid: 20198, comm: trinity Not tainted 3.2.0-rc2-sasha-00058-gc65cd37 #6
[ 1402.287632] RIP: 0010:[<ffffffff812b4b99>]  [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
[ 1402.287632] RSP: 0018:ffff880077f0fd68  EFLAGS: 00010292
[ 1402.287632] RAX: ffff880077c49fff RBX: 00000000ffffffea RCX: 0000000001043400
[ 1402.287632] RDX: 0000000000000000 RSI: ffff880077c4a000 RDI: ffffffff82283de0
[ 1402.287632] RBP: ffff880077f0fe18 R08: 0000000000000001 R09: ffff880000000000
[ 1402.287632] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880077c4a000
[ 1402.287632] R13: ffffffff82283de0 R14: 0000000001043400 R15: ffffffff82283de0
[ 1402.287632] FS:  00007f25fec3f700(0000) GS:ffff88007d400000(0000) knlGS:0000000000000000
[ 1402.287632] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1402.287632] CR2: ffff880077c49fff CR3: 0000000077e1d000 CR4: 00000000000406e0
[ 1402.287632] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1402.287632] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1402.287632] Process trinity (pid: 20198, threadinfo ffff880077f0e000, task ffff880077db17b0)
[ 1402.287632] Stack:
[ 1402.287632]  ffff880077db17b0 ffff880077c4a000 ffff880077f0fdb8 ffffffff810b411e
[ 1402.287632]  ffff880000000000 ffff880077db17b0 ffff880077c4a000 ffffffff82283de0
[ 1402.287632]  0000000001043400 ffffffff82283de0 ffff880077f0fde8 ffffffff81111f63
[ 1402.287632] Call Trace:
[ 1402.287632]  [<ffffffff810b411e>] ? lock_release+0x1af/0x1bc
[ 1402.287632]  [<ffffffff81111f63>] ? might_fault+0x97/0x9e
[ 1402.287632]  [<ffffffff81111f1a>] ? might_fault+0x4e/0x9e
[ 1402.287632]  [<ffffffff81a8bcf2>] cache_do_downcall+0x3e/0x4f
[ 1402.287632]  [<ffffffff81a8c950>] cache_write.clone.16+0xbb/0x130
[ 1402.287632]  [<ffffffff81a8c9df>] ? cache_write_pipefs+0x1a/0x1a
[ 1402.287632]  [<ffffffff81a8c9f8>] cache_write_procfs+0x19/0x1b
[ 1402.287632]  [<ffffffff8118dc54>] proc_reg_write+0x8e/0xad
[ 1402.287632]  [<ffffffff8113fe81>] vfs_write+0xaa/0xfd
[ 1402.287632]  [<ffffffff8114142d>] ? fget_light+0x35/0x9e
[ 1402.287632]  [<ffffffff8113ff8b>] sys_write+0x48/0x6f
[ 1402.287632]  [<ffffffff81bbdb92>] system_call_fastpath+0x16/0x1b
[ 1402.287632] Code: c0 c9 c3 55 48 63 d2 48 89 e5 48 8d 44 32 ff 41 57 41 56 41 55 41 54 53 bb ea ff ff ff 48 81 ec 88 00 00 00 48 89 b5 58 ff ff ff
[ 1402.287632]  38 0a 0f 85 89 02 00 00 c6 00 00 48 8b 3d 44 4a e5 01 48 85
[ 1402.287632] RIP  [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
[ 1402.287632]  RSP <ffff880077f0fd68>
[ 1402.287632] CR2: ffff880077c49fff
[ 1402.287632] ---[ end trace 368ef53ff773a5e3 ]---

Cc: "J. Bruce Fields" <>
Cc: Neil Brown <>
Signed-off-by: Sasha Levin <>
Signed-off-by: J. Bruce Fields <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agonfsd4: fix lockowner matching
J. Bruce Fields [Mon, 7 Nov 2011 21:37:57 +0000 (16:37 -0500)]
nfsd4: fix lockowner matching

commit b93d87c19821ba7d3ee11557403d782e541071ad upstream.

Lockowners are looked up by file as well as by owner, but we were
forgetting to do a comparison on the file.  This could cause an
incorrect result from lockt.

(Note looking up the inode from the lockowner is pretty awkward here.
The data structures need fixing.)

Signed-off-by: J. Bruce Fields <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agosvcrpc: avoid memory-corruption on pool shutdown
J. Bruce Fields [Tue, 29 Nov 2011 22:00:26 +0000 (17:00 -0500)]
svcrpc: avoid memory-corruption on pool shutdown

commit b4f36f88b3ee7cf26bf0be84e6c7fc15f84dcb71 upstream.

Socket callbacks use svc_xprt_enqueue() to add an xprt to a
pool->sp_sockets list.  In normal operation a server thread will later
come along and take the xprt off that list.  On shutdown, after all the
threads have exited, we instead manually walk the sv_tempsocks and
sv_permsocks lists to find all the xprt's and delete them.

So the sp_sockets lists don't really matter any more.  As a result,
we've mostly just ignored them and hoped they would go away.

Which has gotten us into trouble; witness for example ebc63e531cc6
"svcrpc: fix list-corrupting race on nfsd shutdown", the result of Ben
Greear noticing that a still-running svc_xprt_enqueue() could re-add an
xprt to an sp_sockets list just before it was deleted.  The fix was to
remove it from the list at the end of svc_delete_xprt().  But that only
made corruption less likely--I can see nothing that prevents a
svc_xprt_enqueue() from adding another xprt to the list at the same
moment that we're removing this xprt from the list.  In fact, despite
the earlier xpo_detach(), I don't even see what guarantees that
svc_xprt_enqueue() couldn't still be running on this xprt.

So, instead, note that svc_xprt_enqueue() essentially does:
lock sp_lock
if XPT_BUSY unset
add to sp_sockets
unlock sp_lock

So, if we do:

set XPT_BUSY on every xprt.
Empty every sp_sockets list, under the sp_socks locks.

Then we're left knowing that the sp_sockets lists are all empty and will
stay that way, since any svc_xprt_enqueue() will check XPT_BUSY under
the sp_lock and see it set.

And *then* we can continue deleting the xprt's.

(Thanks to Jeff Layton for being correctly suspicious of this code....)

Cc: Ben Greear <>
Cc: Jeff Layton <>
Signed-off-by: J. Bruce Fields <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agosvcrpc: destroy server sockets all at once
J. Bruce Fields [Tue, 29 Nov 2011 16:35:35 +0000 (11:35 -0500)]
svcrpc: destroy server sockets all at once

commit 2fefb8a09e7ed251ae8996e0c69066e74c5aa560 upstream.

There's no reason I can see that we need to call sv_shutdown between
closing the two lists of sockets.

Signed-off-by: J. Bruce Fields <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agosvcrpc: fix double-free on shutdown of nfsd after changing pool mode
J. Bruce Fields [Fri, 23 Dec 2011 01:22:49 +0000 (18:22 -0700)]
svcrpc: fix double-free on shutdown of nfsd after changing pool mode

commit 61c8504c428edcebf23b97775a129c5b393a302b upstream.

The pool_to and to_pool fields of the global svc_pool_map are freed on
shutdown, but are initialized in nfsd startup only in the

They *are* initialized to zero on kernel startup.  So as long as you use
only SVC_POOL_GLOBAL (the default), this will never be a problem.

You're also OK if you only ever use SVC_POOL_PERCPU or SVC_POOL_PERNODE.

However, the following sequence events leads to a double-free:

2. start nfsd: both fields are initialized.
3. shutdown nfsd: both fields are freed.
5. start nfsd: the fields are left untouched.
6. shutdown nfsd: now we try to free them again.

Step 4 is actually unnecessary, since (for some bizarre reason), nfsd
automatically resets the pool mode to SVC_POOL_GLOBAL on shutdown.

Signed-off-by: J. Bruce Fields <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agokconfig/ Fix parsing Makefile with variables
Steven Rostedt [Fri, 13 Jan 2012 22:53:40 +0000 (17:53 -0500)]
kconfig/ Fix parsing Makefile with variables

commit 364212fddaaa60c5a64f67a0f5624ad996ecc8a0 upstream.

Thomas Lange reported that when he did a 'make localmodconfig', his
config was missing the brcmsmac driver, even though he had the module

Looking into this, I found the file:
had the following in the Makefile:

MODULEPFX := brcmsmac


The way works, is parsing all the
 obj-$(CONFIG_FOO) += foo.o
lines to find that CONFIG_FOO belongs to the module foo.ko.

But in this case, the brcmsmac.o was not used, but a variable in its place.

By changing to remember defined variables in Makefiles
and substituting them when they are used in the obj-X lines, allows
Thomas (and others) to have their brcmsmac module stay configured
when it is loaded and running "make localmodconfig".

Reported-by: Thomas Lange <>
Tested-by: Thomas Lange <>
Cc: Arend van Spriel <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agokconfig/ Simplify backslash line concatination
Steven Rostedt [Fri, 13 Jan 2012 22:50:39 +0000 (17:50 -0500)]
kconfig/ Simplify backslash line concatination

commit d060d963e88f3e990cec2fe5214de49de9a49eca upstream.

Simplify the way lines ending with backslashes (continuation) in Makefiles
is parsed. This is needed to implement a necessary fix.

Tested-by: Thomas Lange <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoftrace: Fix unregister ftrace_ops accounting
Jiri Olsa [Mon, 5 Dec 2011 17:22:48 +0000 (18:22 +0100)]
ftrace: Fix unregister ftrace_ops accounting

commit 30fb6aa74011dcf595f306ca2727254d708b786e upstream.

Multiple users of the function tracer can register their functions
with the ftrace_ops structure. The accounting within ftrace will
update the counter on each function record that is being traced.
When the ftrace_ops filtering adds or removes functions, the
function records will be updated accordingly if the ftrace_ops is
still registered.

When a ftrace_ops is removed, the counter of the function records,
that the ftrace_ops traces, are decremented. When they reach zero
the functions that they represent are modified to stop calling the
mcount code.

When changes are made, the code is updated via stop_machine() with
a command passed to the function to tell it what to do. There is an
ENABLE and DISABLE command that tells the called function to enable
or disable the functions. But the ENABLE is really a misnomer as it
should just update the records, as records that have been enabled
and now have a count of zero should be disabled.

The DISABLE command is used to disable all functions regardless of
their counter values. This is the big off switch and is not the
complement of the ENABLE command.

To make matters worse, when a ftrace_ops is unregistered and there
is another ftrace_ops registered, neither the DISABLE nor the
ENABLE command are set when calling into the stop_machine() function
and the records will not be updated to match their counter. A command
is passed to that function that will update the mcount code to call
the registered callback directly if it is the only one left. This
means that the ftrace_ops that is still registered will have its callback
called by all functions that have been set for it as well as the ftrace_ops
that was just unregistered.

Here's a way to trigger this bug. Compile the kernel with


This will force the function profiler to use the function tracer instead
of the function graph tracer.

  # cd /sys/kernel/debug/tracing
  # echo schedule > set_ftrace_filter
  # echo function > current_tracer
  # cat set_ftrace_filter
  # cat trace
 # tracer: nop
 # entries-in-buffer/entries-written: 692/68108025   #P:4
 #                              _-----=> irqs-off
 #                             / _----=> need-resched
 #                            | / _---=> hardirq/softirq
 #                            || / _--=> preempt-depth
 #                            ||| /     delay
 #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
 #              | |       |   ||||       |         |
      kworker/0:2-909   [000] ....   531.235574: schedule <-worker_thread
           <idle>-0     [001] .N..   531.235575: schedule <-cpu_idle
      kworker/0:2-909   [000] ....   531.235597: schedule <-worker_thread
             sshd-2563  [001] ....   531.235647: schedule <-schedule_hrtimeout_range_clock

  # echo 1 > function_profile_enabled
  # echo 0 > function_porfile_enabled
  # cat set_ftrace_filter
  # cat trace
 # tracer: function
 # entries-in-buffer/entries-written: 159701/118821262   #P:4
 #                              _-----=> irqs-off
 #                             / _----=> need-resched
 #                            | / _---=> hardirq/softirq
 #                            || / _--=> preempt-depth
 #                            ||| /     delay
 #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
 #              | |       |   ||||       |         |
           <idle>-0     [002] ...1   604.870655: local_touch_nmi <-cpu_idle
           <idle>-0     [002] d..1   604.870655: enter_idle <-cpu_idle
           <idle>-0     [002] d..1   604.870656: atomic_notifier_call_chain <-enter_idle
           <idle>-0     [002] d..1   604.870656: __atomic_notifier_call_chain <-atomic_notifier_call_chain

The same problem could have happened with the trace_probe_ops,
but they are modified with the set_frace_filter file which does the
update at closure of the file.

The simple solution is to change ENABLE to UPDATE and call it every
time an ftrace_ops is unregistered.

Signed-off-by: Jiri Olsa <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoUnused iocbs in a batch should not be accounted as active.
Gleb Natapov [Sun, 8 Jan 2012 15:07:28 +0000 (17:07 +0200)]
Unused iocbs in a batch should not be accounted as active.

commit 69e4747ee9727d660b88d7e1efe0f4afcb35db1b upstream.

Since commit 080d676de095 ("aio: allocate kiocbs in batches") iocbs are
allocated in a batch during processing of first iocbs.  All iocbs in a
batch are automatically added to ctx->active_reqs list and accounted in

If one (not the last one) of iocbs submitted by an user fails, further
iocbs are not processed, but they are still present in ctx->active_reqs
and accounted in ctx->reqs_active.  This causes process to stuck in a D
state in wait_for_all_aios() on exit since ctx->reqs_active will never
go down to zero.  Furthermore since kiocb_batch_free() frees iocb
without removing it from active_reqs list the list become corrupted
which may cause oops.

Fix this by removing iocb from ctx->active_reqs and updating
ctx->reqs_active in kiocb_batch_free().

Signed-off-by: Gleb Natapov <>
Reviewed-by: Jeff Moyer <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoV4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
Dan Carpenter [Thu, 5 Jan 2012 05:27:57 +0000 (02:27 -0300)]
V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()

commit 6c06108be53ca5e94d8b0e93883d534dd9079646 upstream.

If ctrls->count is too high the multiplication could overflow and
array_size would be lower than expected.  Mauro and Hans Verkuil
suggested that we cap it at 1024.  That comes from the maximum
number of controls with lots of room for expantion.

$ grep V4L2_CID include/linux/videodev2.h | wc -l

Signed-off-by: Dan Carpenter <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agommc: sd: Fix SDR12 timing regression
Alexander Elbs [Wed, 4 Jan 2012 04:26:53 +0000 (23:26 -0500)]
mmc: sd: Fix SDR12 timing regression

commit dd8df17fe83483d7ea06ff229895e35a42071599 upstream.

This patch fixes a failure to recognize SD cards reported on a Dell
Vostro with O2 Micro SD card reader.  Patch 49c468f ("mmc: sd: add
support for uhs bus speed mode selection") caused the problem, by
setting the SDHCI_CTRL_HISPD flag even for legacy timings.

Signed-off-by: Alexander Elbs <>
Acked-by: Philip Rakity <>
Acked-by: Arindam Nath <>
Signed-off-by: Chris Ball <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agommc: sdhci: Fix tuning timer incorrect setting when suspending host
Aaron Lu [Wed, 28 Dec 2011 03:11:12 +0000 (11:11 +0800)]
mmc: sdhci: Fix tuning timer incorrect setting when suspending host

commit c6ced0db08010ed75df221a2946c5228454b38d5 upstream.

When suspending host, the tuning timer shoule be deactivated.
And the HOST_NEEDS_TUNING flag should be set after tuning timer is

Signed-off-by: Philip Rakity <>
Signed-off-by: Aaron Lu <>
Acked-by: Adrian Hunter <>
Signed-off-by: Chris Ball <>
Signed-off-by: Greg Kroah-Hartman <>