26 Jan, 2012
40 commits
-
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 -
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 -
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: 15.32.2.9
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
channels.Reported-and-debugged-by: Pedro Francisco
Signed-off-by: Stanislaw Gruszka
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit b2ccccdca46273c7b321ecf5041c362cd950da20 upstream.
Check and report WARN only when its invalid
Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=42621
https://bugzilla.redhat.com/show_bug.cgi?id=766071Signed-off-by: Wey-Yi Guy
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
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:
is_pageblock_removable_nolock+0x34/0x40
is_mem_section_removable+0x74/0xf0
show_mem_removable+0x41/0x70
sysfs_read_file+0xfe/0x1c0
vfs_read+0xc7/0x130
sys_read+0x53/0xa0
system_call_fastpath+0x16/0x1bWe 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 -> 0x00240000The 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 -
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.37This 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 -
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
it.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 -
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 -
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 -
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 -
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 -
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
device).This fix very bad performance problem, practically making device
unusable (since worked without interrupts), reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=658451We previously tried to workaround that issue in commit
4ba7d9997869d25bd223dea7536fc1ce9fab3b3b "rt2800pci: handle spurious
interrupts", but it was reverted in commit
82e5fc2a34fa9ffea38f00c4066b7e600a0ca5e6
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 -
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 -
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
statistics.Signed-off-by: Cliff Wickman
Link: http://lkml.kernel.org/r/20120116211947.GC5767@sgi.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit d059f9fa84a30e04279c6ff615e9e2cf3b260191 upstream.
Move the call to enable_timeouts() forward so that
BAU_MISC_CONTROL is initialized before using it in
calculate_destination_timeout().Fix the calculation of a BAU destination timeout
for UV2 (in calculate_destination_timeout()).Signed-off-by: Cliff Wickman
Link: http://lkml.kernel.org/r/20120116211848.GB5767@sgi.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
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
Link: http://lkml.kernel.org/r/20120116211750.GA5767@sgi.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
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
[khilman@ti.com: minor changelog edits]
Signed-off-by: Kevin Hilman
Signed-off-by: Greg Kroah-Hartman -
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 -
commit cd4ca7afc61d3b18fcd635002459fb6b1d701099 upstream.
Update xc4000 tuner definition, number 81 is already in use by
TUNER_PARTSNIC_PTI_5NF05.Signed-off-by: Miroslav Slugen
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
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 -
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 -
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 -
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
gives
cdb to send: 02 00 00 00 00 00
SCSI Status: Check ConditionSense Information:
Fixed format, current; Sense key: Illegal Request
Raw sense data (in hex):
70 00 05 00 00 00 00 00while 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 ConditionSense 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 00Signed-off-by: Roland Dreier
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
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 -
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 -
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 exampleScope (_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.http://marc.info/?t=132329819900003&r=1&w=2
Reported-and-tested-by: wallak@free.fr
Signed-off-by: Lin Ming
Signed-off-by: Len Brown
Signed-off-by: Greg Kroah-Hartman -
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 -
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
enough.Signed-off-by: Kurt Garloff
Signed-off-by: Len Brown
Signed-off-by: Greg Kroah-Hartman -
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).cc: x86@kernel.org
Signed-off-by: Kurt Garloff
Signed-off-by: Len Brown
Signed-off-by: Greg Kroah-Hartman -
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 -
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 -
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)
...
[0.984807][] ? cpuidle_idle_call+0xb4/0x340
[0.984807][] ? __atomic_notifier_call_chain+0x4c/0x70
[0.984807][] ? cpu_idle+0x78/0xd0Reference:
https://bugzilla.novell.com/show_bug.cgi?id=726296Signed-off-by: Thomas Renninger
CC: Bruno Friedmann
Signed-off-by: Len Brown
Signed-off-by: Greg Kroah-Hartman -
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 -
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
BugLink: https://bugs.launchpad.net/bugs/795823
Signed-off-by: David Henningsson
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
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 -
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).BugLink: https://bugs.launchpad.net/bugs/909419
Signed-off-by: David Henningsson
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit e268337dfe26dfc7efd422a804dbb27977a3cccc upstream.
Jüri Aedla reported that the /proc//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_
VM.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 -
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
Cc: dm-devel@redhat.com
Signed-off-by: Paolo Bonzini
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
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: linux-scsi@vger.kernel.org
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
