04 Aug, 2013
40 commits
-
commit 3964acd0dbec123aa0a621973a2a0580034b4788 upstream.
vma_adjust() does vma_set_policy(vma, vma_policy(next)) and this
is doubly wrong:1. This leaks vma->vm_policy if it is not NULL and not equal to
next->vm_policy.This can happen if vma_merge() expands "area", not prev (case 8).
2. This sets the wrong policy if vma_merge() joins prev and area,
area is the vma the caller needs to update and it still has the
old policy.Revert commit 1444f92c8498 ("mm: merging memory blocks resets
mempolicy") which introduced these problems.Change mbind_range() to recheck mpol_equal() after vma_merge() to fix
the problem that commit tried to address.Signed-off-by: Oleg Nesterov
Acked-by: KOSAKI Motohiro
Cc: Steven T Hampson
Cc: Mel Gorman
Cc: KOSAKI Motohiro
Cc: Rik van Riel
Cc: Andi Kleen
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 1894870eb4240399fabc6f0cb8c6fff4e6edbe83 upstream.
The name of udc state attribute file under sysfs is registered as
"state", while usb_gadget_set_state take it as "status" when it's
going to update. This patch fixes the typo.Signed-off-by: Rong Wang
Signed-off-by: Barry Song
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit fed1f1ed90bce42ea010e2904cbc04e7b8304940 upstream.
RT Systems makes many usb serial cables based on the ftdi_sio driver for
programming various amateur radios. This patch is a full listing of
their current product offerings and should allow these cables to all
be recognized.Signed-off-by: Rick Farina (Zero_Chaos)
Signed-off-by: Greg Kroah-Hartman -
commit bcfb879432094c267c35a7ff75d953d3a66c193a upstream.
Commit a269913c5 entitled "rtlwifi: Rework rtl_lps_leave() and
rtl_lps_enter() to use work queue" has two bugs for USB drivers.
Firstly, the work queue in question was not initialized. Secondly,
the callback routine used by this queue is contained within the
file used for PCI devices. As a result, it is not available for
architectures without PCI hardware.Signed-off-by: Larry Finger
Reported-by: Richard Genoud
Tested-by: Richard Genoud
Cc: Richard Genoud
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 42a21826dc54583cdb79cc8477732e911ac9c376 upstream.
The ProcessAuxChannel table on some rv635 boards assumes
the divmul members are initialized to 0 otherwise we get
an invalid fb offset since it has a bad mask set when
setting the fb base. While here initialize all the
atom interpretor elements to 0.Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60639Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 7d61d835824f73dc4097b51f800382467c8049c5 upstream.
We need to set the dto source before setting the
dividers otherwise we may get stability problems
with the dto leading to audio playback problems.Signed-off-by: Alex Deucher
Reviewed-by: Christian König
Signed-off-by: Greg Kroah-Hartman -
commit 7a7da592cbb22a1d360638dbecc393470c5effe3 upstream.
Fixes some dmabuf object errors on nv50 chipset and below.
Signed-off-by: Maarten Lankhorst
Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman -
commit e1b4d3036c07ff137955fb1c0197ab62534f46ec upstream.
Upon some code refactoring, a hunk was missed. This was fixed for
next, but missed the current trees, and hasn't yet been merged by Dave
Airlie. It is fixed in:
commit 907b28c56ea40629aa6595ddfa414ec2fc7da41c
Author: Chris Wilson
Date: Fri Jul 19 20:36:52 2013 +0100drm/i915: Colocate all GT access routines in the same file
It is introduced by:
commit 181d1b9e31c668259d3798c521672afb8edd355c
Author: Daniel Vetter
Date: Sun Jul 21 13:16:24 2013 +0200drm/i915: fix up gt init sequence fallout
Reported-by: Dave Jones
Signed-off-by: Ben Widawsky
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 181d1b9e31c668259d3798c521672afb8edd355c upstream.
The regression fix for gen6+ rps fallout
commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505
Author: Konstantin Khlebnikov
Date: Wed Jul 17 10:22:58 2013 +0400drm/i915: fix long-standing SNB regression in power consumption after resume
unintentionally also changed the init sequence ordering between
gt_init and gt_reset - we need to reset BIOS damage like leftover
forcewake references before we run our own code. Otherwise we can get
nasty dmesg noise like[drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear.
again. Since _reset suggests that we first need to have stuff
initialized (which isn't the case here) call it sanitze instead.While at it also block out the rps disable introduced by the above
commit on ilk: We don't have any knowledge of ilk rps being broken in
similar ways. And the disable functions uses the default hw state
which is only read out when we're enabling rps. So essentially we've
been writing random grabage into that register.Reported-by: Chris Wilson
Cc: Chris Wilson
Cc: Konstantin Khlebnikov
Cc: Jesse Barnes
Tested-by: Chris Wilson
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a upstream.
In theory, the different register blocks were meant to be only ever
touched when holding either the struct_mutex, mode_config.lock or even a
specific localised lock. This does not seem to be the case, and the
hardware reacts extremely badly if we attempt to concurrently access two
registers within the same cacheline.The HSD suggests that we only need to do this workaround for display
range registers. However, upon review we need to serialize the multiple
stages in our register write functions - if only for preemption
protection.Irrespective of the hardware requirements, the current io functions are
a little too loose with respect to the combination of pre- and
post-condition testing that we do in conjunction with the actual io. As
a result, we may be pre-empted and generate both false-postive and
false-negative errors.Note well that this is a "90%" solution, there remains a few direct
users of ioread/iowrite which will be fixed up in the next few patches.
Since they are more invasive and that this simple change will prevent
almost all lockups on Haswell, we kept this patch simple to facilitate
backporting to stable.Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63914
Signed-off-by: Chris Wilson
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit e85843bec6c2ea7c10ec61238396891cc2b753a9 upstream.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
BugLink: https://bugs.launchpad.net/bugs/1163720
BugLink: https://bugs.launchpad.net/bugs/1162026Some machines suffer from non-functional backlight controls if
BLM_PCH_PWM_ENABLE is set, so provide a quirk to avoid doing so.
Apply this quirk to Dell XPS 13 models.Tested-by: Eric Griffith
Tested-by: Kent Baxley
Signed-off-by: Kamal Mostafa
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 94a335dba34ff47cad3d6d0c29b452d43a1be3c8 upstream.
To avoid stalls we delay tiling changes and especially hold of
committing the new fence state for as long as possible.
Synchronization points are in the execbuf code and in our gtt fault
handler.Unfortunately we've missed that tricky detail when adding proper fence
restore code incommit 19b2dbde5732170a03bd82cc8bd442cf88d856f7
Author: Chris Wilson
Date: Wed Jun 12 10:15:12 2013 +0100drm/i915: Restore fences after resume and GPU resets
The result was that we've restored fences for objects with no tiling,
since the objectfence link still existed after resume. Now that
wouldn't have been too bad since any subsequent access would have
fixed things up, but if we've changed from tiled to untiled real havoc
happened:The tiling stride is stored -1 in the fence register, so a stride of 0
resulted in all 1s in the top 32bits, and so a completely bogus fence
spanning everything from the start of the object to the top of the
GTT. The tell-tale in the register dumps looks like:FENCE START 2: 0x0214d001
FENCE END 2: 0xfffff3ffBit 11 isn't set since the hw doesn't store it, even when writing all
1s (at least on my snb here).To prevent such a gaffle in the future add a sanity check for fences
with an untiled object attached in i915_gem_write_fence.v2: Fix the WARN, spotted by Chris.
v3: Trying to reuse get_fences looked ugly and obfuscated the code.
Instead reuse update_fence and to make it really dtrt also move the
fence dirty state clearing into update_fence.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60530
Cc: Chris Wilson
Cc: Stéphane Marchesin
Reviewed-by: Chris Wilson
Tested-by: Matthew Garrett
Tested-by: Björn Bidar
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 2e57f47d317dd035b18634b0c602272529368fcc upstream.
In commit e3de42b68478a8c95dd27520e9adead2af9477a5
Author: Imre Deak
Date: Fri May 3 19:44:07 2013 +0200drm/i915: force full modeset if the connector is in DPMS OFF mode
a new function was added that walked over the set of connectors to see
if any of the currently associated CRTC was switched off. This function
walked an array of connectors, rather than the array of pointers to
connectors contained in the drm_mode_set - i.e. it was dereferencing far
past the end of the first connector. This only becomes an issue if we
attempt to use a clone mode (i.e. more than one connector per CRTC) such
that set->num_connectors > 1.Reported-by: Timo Aaltonen
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65927
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: Egbert Eich
Cc: Jesse Barnes
Cc: Daniel Vetter
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505 upstream.
This patch fixes regression in power consumtion of sandy bridge gpu, which
exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that
it's extremely busy. After that it never reaches rc6 state.Bug exists since kernel v3.6:
commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
Author: Jesse Barnes
Date: Thu Jun 14 11:04:48 2012 -0700drm/i915: load boot context at driver init time
For some reason RC6 is already enabled at the beginning of resuming process.
Following initliaztion breaks some internal state and confuses RPS engine.
This patch disables RC6 at the beginnig of resume and initialization.I've rearranged initialization sequence, because intel_disable_gt_powersave()
needs initialized force_wake_get/put and some locks from the dev_priv.Note: The culprit in the initialization sequence seems to be the write
to MBCTL added in the above mentioned commit. The first version of
this patch just held a forcewake reference across the clock gating
init functions, which seems to have been enought to gather quite a few
positive test reports. But since that smelled a bit like ad-hoc
duct-tape v2 now just disables rps/rc6 across the entire hw setup.[danvet: Add note about v1 vs. v2 of this patch and use standard
layout for the commit citation. Also add the tested-bys from v1 and a cc:
stable.]References https://bugs.freedesktop.org/show_bug.cgi?id=54089
References https://bugzilla.kernel.org/show_bug.cgi?id=58971
References https://patchwork.kernel.org/patch/2827634/ (patch v1)Signed-off-by: Konstantin Khlebnikov
Tested-by: Alexander Kaltsas (v1)
Tested-by: rocko (v1)
Tested-by: JohnMB (v1)
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit d18b9619034230b6f945e215276425636ca401fe upstream.
This hopefully fixes the root cause behind the workaround added in
commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
Author: Chris Wilson
Date: Thu Apr 4 21:31:03 2013 +0100drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
Thanks to further investigation by Jon Bloomfield, he realised that
the 64-bit register might be broken up by the hardware into two 32-bit
writes (a problem we have encountered elsewhere). This non-atomicity
would then cause an issue where a second thread would see an
intermediate register state (new high dword, old low dword), and this
register would randomly be used in preference to its own thread register.
This would cause the second thread to read from and write into a fairly
random tiled location. Breaking the operation into 3 explicit 32-bit
updates (first disable the fence, poke the upper bits, then poke the lower
bits and enable) ensures that, given proper serialisation between the
32-bit register write and the memory transfer, that the fence value is
always consistent.Armed with this knowledge, we can explain how the previous workaround
work. The key to the corruption is that a second thread sees an
erroneous fence register that conflicts and overrides its own. By
serialising the fence update across all CPUs, we have a small window
where no GTT access is occurring and so hide the potential corruption.
This also leads to the conclusion that the earlier workaround was
incomplete.v2: Be overly paranoid about the order in which fence updates become
visible to the GPU to make really sure that we turn the fence off before
doing the update, and then only switch the fence on afterwards.Signed-off-by: Jon Bloomfield
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Carsten Emde
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit c11e5f35ab490bd30591563816fbc83526521777 upstream.
This patch partially reverts commit 36ec8f877481449bdfa072e6adf2060869e2b970 for
IvyBridge CPUs.The original commit results in repeated 'Timed out waiting for forcewake old
ack to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b)
with i7-3770K CPU. It ultimately results in a hangup if the system is highly
loaded. Reverting the commit for IvyBridge CPUs fixes the issue.Issue a warning if the CPU is IvyBridge and mt forcewake is disabled, since
this condition can result in secondary issues.v2: Only revert patch for Ivybridge CPUs
Issue info message if mt forcewake is disabled on IvybridgeBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60541
Cc: Jesse Barnes
Cc: Daniel Vetter
Cc: Mika Kuoppala
Signed-off-by: Guenter Roeck
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66139
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 02978ff57a5bdfbf703d2bc5a4d933a53ede3144 upstream.
Daniel noticed a problem where is we wrote to an object with ring A in
the middle of a very long running batch, then executed a quick batch on
ring B before a batch that reads from the same object, its obj->ring would
now point to ring B, but its last_write_seqno would be still relative to
ring A. This would allow for the user to read from the object before the
GPU had completed the write, as set_domain would only check that ring B
had passed the last_write_seqno.To fix this simply (and inelegantly), we bump the last_write_seqno when
switching rings so that the last_write_seqno is always relative to the
current obj->ring.This fixes igt/tests/gem_write_read_ring_switch.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
[danvet: Add note about the newly created igt which exercises this bug.]
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit aaf8a5167291b65e9116cb8736d862965b57c13a upstream.
It's not a good idea to also run the pipe_control cleanup.
This regression has been introduced whith the original cs tlb w/a in
commit b45305fce5bb1abec263fcff9d81ebecd6306ede
Author: Daniel Vetter
Date: Mon Dec 17 16:21:27 2012 +0100drm/i915: Implement workaround for broken CS tlb on i830/845
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64610
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 03ed8cf9b28d886c64c7e705c7bb1a365fd8fb95 upstream.
Hopefully avoid more quirks in the future due to bogus
vbios dac data.Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit cef1d00cd56f600121ad121875655ad410a001b8 upstream.
Noticed that my old Radeon 7500 hung after printing
drm: GPU not posted. posting now...
when it wasn't selected as the primary card the BIOS. Some digging
revealed that it was hanging in combios_parse_mmio_table() while
parsing the ASIC INIT 3 table. Looking at the BIOS ROM for the card,
it becomes obvious that there is no ASIC INIT 3 table in the BIOS.
The code is just processing random garbage. No surprise it hangs!Why do I say that there is no ASIC INIT 3 table is the BIOS? This
table is found through the MISC INFO table. The MISC INFO table can
be found at offset 0x5e in the COMBIOS header. But the header is
smaller than that. The COMBIOS header starts at offset 0x126. The
standard PCI Data Structure (the bit that starts with 'PCIR') lives at
offset 0x180. That means that the COMBIOS header can not be larger
than 0x5a bytes and therefore cannot contain a MISC INFO table.I looked at a dozen or so BIOS images, some my own, some downloaded from:
It is fairly obvious that the size of the COMBIOS header can be found
at offset 0x6 of the header. Not sure if it is a 16-bit number or
just an 8-bit number, but that doesn't really matter since the tables
seems to be always smaller than 256 bytes.So I think combios_get_table_offset() should check if the requested
table is present. This can be done by checking the offset against the
size of the header. See the diff below. The diff is against the WIP
OpenBSD codebase that roughly corresponds to Linux 3.8.13 at this
point. But I don't think this bit of the code changed much since
then.For what it is worth:
Signed-off-by: Mark Kettenis
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit f7929f34fa0e0bb6736a2484fdc07d77a1653081 upstream.
Hello,
got another card with "too bright" problem:
Sapphire Radeon VE 7000 DDR (VGA+S-Video)lspci -vnn:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] [1002:5159] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited Sapphire Radeon VE 7000 DDR [174b:7c28]The patch below fixes the problem for this card.
But I don't like the blacklist, couldn't some heuristic be used instead?
The interesting thing is that the manufacturer is the same as the other card
needing the same quirk. I wonder how many different types are broken this way.The "wrong" ps2_pdac_adj value that comes from BIOS on this card is 0x300.
====================
drm/radeon: Add primary dac adj quirk for Sapphire Radeon VE 7000 DDRValues from BIOS are wrong, causing too bright colors.
Use default values instead.Signed-off-by: Ondrej Zary
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 34be8c9af7b8728465963740fc11136ae90dfc36 upstream.
The atom interpreter expects data in LE format, so
swap the message buffer as apprioriate.v2: properly handle non-dw aligned byte counts.
v3: properly handle remainderSigned-off-by: Alex Deucher
Cc: Dong He
Signed-off-by: Greg Kroah-Hartman -
commit 6c4f978b357bc779c703fda1f200e9179623d3e9 upstream.
There are cases where we need more than 4k alignment. No
functional change with this commit.Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit c9a6ca4abd5f1978ef15b3ece3474f4372ae5fe7 upstream.
Currently doesn't matter cause we allocate the fence in the
lower 265MB anyway.Reported-by: Frank Huang
Signed-off-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit c2b4cacfe9816c1fe378c785ce8a678cf0635ec6 upstream.
Prevents a segfault if an afmt block is not assigned to the
encoder such as in the LVDS or eDP case.Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=66714Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit b1bf2de07271932326af847a3c6a01fdfd29d4be upstream.
Fix a boundary condition that caused failure for certain device sizes.
The problem is reported at
http://code.google.com/p/cryptsetup/issues/detail?id=160For certain device sizes the number of hashes at a specific level was
calculated incorrectly.It happens for example for a device with data and metadata block size 4096
that has 16385 blocks and algorithm sha256.The user can test if he is affected by this bug by running the
"veritysetup verify" command and also by activating the dm-verity kernel
driver and reading the whole block device. If it passes without an error,
then the user is not affected.The condition for the bug is:
Split the total number of data blocks (data_block_bits) into bit strings,
each string has hash_per_block_bits bits. hash_per_block_bits is
rounddown(log2(metadata_block_size/hash_digest_size)). Equivalently, you
can say that you convert data_blocks_bits to 2^hash_per_block_bits base.If there some zero bit string below the most significant bit string and at
least one bit below this zero bit string is set, then the bug happens.The same bug exists in the userspace veritysetup tool, so you must use
fixed veritysetup too if you want to use devices that are affected by
this boundary condition.Signed-off-by: Mikulas Patocka
Cc: Milan Broz
Signed-off-by: Alasdair G Kergon
Signed-off-by: Greg Kroah-Hartman -
commit 1c0e883e86ece31880fac2f84b260545d66a39e0 upstream.
Set noio flag while calling __vmalloc() because it doesn't fully respect
gfp flags to avoid a possible deadlock (see commit
502624bdad3dba45dfaacaf36b7d83e39e74b2d2).This should be backported to stable kernels 3.8 and newer. The kernel 3.8
doesn't have memalloc_noio_save(), so we should set and restore process
flag PF_MEMALLOC instead.Signed-off-by: Mikulas Patocka
Signed-off-by: Alasdair G Kergon
Signed-off-by: Greg Kroah-Hartman -
commit 6c182cd88d179cbbd06f4f8a8a19b6977940753f upstream.
When multipath needs to retry an ioctl the reference to the
current live table needs to be dropped. Otherwise a deadlock
occurs when all paths are down:
- dm_blk_ioctl takes a reference to the current table
and spins in multipath_ioctl().
- A new table is being loaded, but upon resume the process
hangs in dm_table_destroy() waiting for references to
drop to zero.With this patch the reference to the old table is dropped
prior to retry, thereby avoiding the deadlock.Signed-off-by: Hannes Reinecke
Cc: Mike Snitzer
Signed-off-by: Alasdair G Kergon
Signed-off-by: Greg Kroah-Hartman -
commit 9657a565a476d517451c10b0bcc106e300785aff upstream.
The BIOS of FUjitsu E753 reports an incorrect initial backlight value
for WIN8 compatible OS, causing backlight to be dark during startup.
This change causes the incorrect initial value from BIOS to be ignored.References: https://bugzilla.kernel.org/show_bug.cgi?id=60161
Reported-and-tested-by: Jan Hinnerk Stosch
Signed-off-by: Lan Tianyu
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit d19f503e22316a84c39bc19445e0e4fdd49b3532 upstream.
device->driver_data needs to be cleared when releasing its data,
mem_device, in an error path of acpi_memory_device_add().The function evaluates the _CRS of memory device objects, and fails
when it gets an unexpected resource or cannot allocate memory. A
kernel crash or data corruption may occur when the kernel accesses
the stale pointer.Signed-off-by: Toshi Kani
Reviewed-by: Yasuaki Ishimatsu
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 3a391a39593b48341f0908511590a6c0e55cc069 upstream.
In acpi_bus_device_attach(), if there is an ACPI device object
for the given handle and that device object has a scan handler
attached to it already, there's nothing more to do for that handle.
Moreover, if acpi_scan_attach_handler() is called then, it may
execute the .attach() callback of the ACPI scan handler already
attached to the device object and that may lead to interesting
breakage.For this reason, make acpi_bus_device_attach() return success
immediately when the handle's device object has a scan handler
attached to it.Reported-by: Toshi Kani
Signed-off-by: Rafael J. Wysocki
Acked-by: Toshi Kani
Signed-off-by: Greg Kroah-Hartman -
commit 8832f7e43fa7f0f19bd54e13766a825dd1ed4d6f upstream.
An ACPI_NOTIFY_BUS_CHECK notification means that we should scan the
entire namespace starting from the given handle even if the device
represented by that handle is present (other devices below it may
just have appeared).For this reason, modify acpi_scan_bus_device_check() to always run
acpi_bus_scan() if the notification being handled is of type
ACPI_NOTIFY_BUS_CHECK.Signed-off-by: Rafael J. Wysocki
Acked-by: Toshi Kani
Signed-off-by: Greg Kroah-Hartman -
commit f2e055e7c9c6084bfbaa68701e52562acf96419e upstream.
Commit f8bd822cb ("regmap: cache: Factor out block sync") made
regcache_rbtree_sync() call regmap_async_complete(), which in turn does
not check for map->bus before dereferencing it.This causes a NULL pointer dereference on bus-less maps.
Signed-off-by: Daniel Mack
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit c5e2254f8d63a6654149aa32ac5f2b7dd66a976d upstream.
When we are posting pressure status, we may get interrupted and handle
the un-balloon operation. In this case just don't post the status as we
know the pressure status is stale.Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
commit ed07ec93e83ec471d365ce084e43ad90fd205903 upstream.
As we hot-add 128 MB chunks of memory, we wait to ensure that the memory
is onlined before attempting to hot-add the next chunk. If the udev rule for
memory hot-add is not executed within the allowed time, we would rollback the
state and abort further hot-add. Since the hot-add has succeeded and the only
failure is that the memory is not onlined within the allowed time, we should not
be rolling back the state. Fix this bug.Signed-off-by: K. Y. Srinivasan
Acked-by: Jason Wang
Signed-off-by: Greg Kroah-Hartman -
commit ed4bb9744b41d39ba35080c2390e201575121dc7 upstream.
Each subnet string needs to be separated with a semicolon. Fix this bug.
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
commit e4daf1ffbe6cc3b12aab4d604e627829e93e9914 upstream.
The following call chain:
------------------------------------------------------------
nfs4_get_vfs_file
- nfsd_open
- dentry_open
- do_dentry_open
- __get_file_write_access
- get_write_access
- return atomic_inc_unless_negative(&inode->i_writecount) ? 0 : -ETXTBSY;
------------------------------------------------------------can result in the following state:
------------------------------------------------------------
struct nfs4_file {
...
fi_fds = {0xffff880c1fa65c80, 0xffffffffffffffe6, 0x0},
fi_access = {{
counter = 0x1
}, {
counter = 0x0
}},
...
------------------------------------------------------------1) First time around, in nfs4_get_vfs_file() fp->fi_fds[O_WRONLY] is
NULL, hence nfsd_open() is called where we get status set to an error
and fp->fi_fds[O_WRONLY] to -ETXTBSY. Thus we do not reach
nfs4_file_get_access() and fi_access[O_WRONLY] is not incremented.2) Second time around, in nfs4_get_vfs_file() fp->fi_fds[O_WRONLY] is
NOT NULL (-ETXTBSY), so nfsd_open() is NOT called, but
nfs4_file_get_access() IS called and fi_access[O_WRONLY] is incremented.
Thus we leave a landmine in the form of the nfs4_file data structure in
an incorrect state.3) Eventually, when __nfs4_file_put_access() is called it finds
fi_access[O_WRONLY] being non-zero, it decrements it and calls
nfs4_file_put_fd() which tries to fput -ETXTBSY.
------------------------------------------------------------
...
[exception RIP: fput+0x9]
RIP: ffffffff81177fa9 RSP: ffff88062e365c90 RFLAGS: 00010282
RAX: ffff880c2b3d99cc RBX: ffff880c2b3d9978 RCX: 0000000000000002
RDX: dead000000100101 RSI: 0000000000000001 RDI: ffffffffffffffe6
RBP: ffff88062e365c90 R8: ffff88041fe797d8 R9: ffff88062e365d58
R10: 0000000000000008 R11: 0000000000000000 R12: 0000000000000001
R13: 0000000000000007 R14: 0000000000000000 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#9 [ffff88062e365c98] __nfs4_file_put_access at ffffffffa0562334 [nfsd]
#10 [ffff88062e365cc8] nfs4_file_put_access at ffffffffa05623ab [nfsd]
#11 [ffff88062e365ce8] free_generic_stateid at ffffffffa056634d [nfsd]
#12 [ffff88062e365d18] release_open_stateid at ffffffffa0566e4b [nfsd]
#13 [ffff88062e365d38] nfsd4_close at ffffffffa0567401 [nfsd]
#14 [ffff88062e365d88] nfsd4_proc_compound at ffffffffa0557f28 [nfsd]
#15 [ffff88062e365dd8] nfsd_dispatch at ffffffffa054543e [nfsd]
#16 [ffff88062e365e18] svc_process_common at ffffffffa04ba5a4 [sunrpc]
#17 [ffff88062e365e98] svc_process at ffffffffa04babe0 [sunrpc]
#18 [ffff88062e365eb8] nfsd at ffffffffa0545b62 [nfsd]
#19 [ffff88062e365ee8] kthread at ffffffff81090886
#20 [ffff88062e365f48] kernel_thread at ffffffff8100c14a
------------------------------------------------------------Signed-off-by: Harshula Jayasuriya
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit 0e0ed6406e61434d3f38fb58aa8464ec4722b77e upstream.
Module CRCs are implemented as absolute symbols that get resolved by
a linker script. We build an intermediate .o that contains an
unresolved symbol for each CRC. genksysms parses this .o, calculates
the CRCs and writes a linker script that "resolves" the symbols to
the calculated CRC.Unfortunately the ppc64 relocatable kernel sees these CRCs as symbols
that need relocating and relocates them at boot. Commit d4703aef
(module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y)
added a hook to reverse the bogus relocations. Part of this patch
created a symbol at 0x0:# head -2 /proc/kallsyms
0000000000000000 T reloc_start
c000000000000000 T .__startThis reloc_start symbol is causing lots of confusion to perf. It
thinks reloc_start is a massive function that stretches from 0x0 to
0xc000000000000000 and we get various cryptic errors out of perf,
including:problem incrementing symbol count, skipping event
This patch removes the reloc_start linker script label and instead
defines it as PHYSICAL_START. We also need to wrap it with
CONFIG_PPC64 because the ppc32 kernel can set a non zero
PHYSICAL_START at compile time and we wouldn't want to subtract
it from the CRCs in that case.Signed-off-by: Anton Blanchard
Acked-by: Rusty Russell
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 9c23b7d3d6bda41e2a27375df705485523a96dc8 upstream.
When kernel is compiled with CONFIG_SLUB_DEBUG=y and
CRYPTO_MANAGER_DISABLE_TESTS=n, during kernel bootup, the kernel
reports error given below. The root cause is that in function
hash_digest_key(), for allocating descriptor, insufficient memory was
being allocated. The required number of descriptor words apart from
input and output pointers are 8 (instead of 6).=============================================================================
BUG dma-kmalloc-32 (Not tainted): Redzone overwritten
-----------------------------------------------------------------------------Disabling lock debugging due to kernel taint
INFO: 0xdec5dec0-0xdec5dec3. First byte 0x0 instead of 0xcc
INFO: Allocated in ahash_setkey+0x60/0x594 age=7 cpu=1 pid=1257
__kmalloc+0x154/0x1b4
ahash_setkey+0x60/0x594
test_hash+0x260/0x5a0
alg_test_hash+0x48/0xb0
alg_test+0x84/0x228
cryptomgr_test+0x4c/0x54
kthread+0x98/0x9c
ret_from_kernel_thread+0x64/0x6c
INFO: Slab 0xc0bd0ba0 objects=19 used=2 fp=0xdec5d0d0 flags=0x0081
INFO: Object 0xdec5dea0 @offset=3744 fp=0x5c200014Bytes b4 dec5de90: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a
........ZZZZZZZZ
Object dec5dea0: b0 80 00 0a 84 41 00 0d f0 40 00 00 00 67 3f c0
.....A...@...g?.
Object dec5deb0: 00 00 00 50 2c 14 00 50 f8 40 00 00 1e c5 d0 00
...P,..P.@......
Redzone dec5dec0: 00 00 00 14 ....
Padding dec5df68: 5a 5a 5a 5a 5a 5a 5a 5a
ZZZZZZZZ
Call Trace:
[dec65b60] [c00071b4] show_stack+0x4c/0x168 (unreliable)
[dec65ba0] [c00d4ec8] check_bytes_and_report+0xe4/0x11c
[dec65bd0] [c00d507c] check_object+0x17c/0x23c
[dec65bf0] [c0550a00] free_debug_processing+0xf4/0x294
[dec65c20] [c0550bdc] __slab_free+0x3c/0x294
[dec65c80] [c03f0744] ahash_setkey+0x4e0/0x594
[dec65cd0] [c01ef138] test_hash+0x260/0x5a0
[dec65e50] [c01ef4c0] alg_test_hash+0x48/0xb0
[dec65e70] [c01eecc4] alg_test+0x84/0x228
[dec65ee0] [c01ec640] cryptomgr_test+0x4c/0x54
[dec65ef0] [c005adc0] kthread+0x98/0x9c
[dec65f40] [c000e1ac] ret_from_kernel_thread+0x64/0x6c
FIX dma-kmalloc-32: Restoring 0xdec5dec0-0xdec5dec3=0xccChange-Id: I0c7a1048053e811025d1c3b487940f87345c8f5d
Signed-off-by: Vakul Garg
Reviewed-by: Geanta Neag Horia Ioan-B05471
Reviewed-by: Fleming Andrew-AFLEMING
Tested-by: Fleming Andrew-AFLEMING
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit b2781e1021525649c0b33fffd005ef219da33926 upstream.
My static checker marks everything from ntohl() as untrusted and it
complains we could have an underflow problem doing:return (u32 *)&ary->wc_array[nchunks];
Also on 32 bit systems the upper bound check could overflow.
Signed-off-by: Dan Carpenter
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman
