- 13 Feb, 2014 40 commits
-
-
Borislav Petkov authored
commit d5a1c7e3 upstream. 41c7f742 ("rtc: Disable the alarm in the hardware (v2)") added the functionality to disable the RTC wake alarm when shutting down the box. However, there are at least two b0rked BIOSes we know about: https://bugzilla.novell.com/show_bug.cgi?id=812592 https://bugzilla.novell.com/show_bug.cgi?id=805740 where, when wakeup alarm is enabled in the BIOS, the machine reboots automatically right after shutdown, regardless of what wakeup time is programmed. Bisecting the issue lead to this patch so disable its functionality with a DMI quirk only for those boxes. Cc: Brecht Machiels <brecht@mos6581.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: John Stultz <john.stultz@linaro.org> Cc: Rabin Vincent <rabin.vincent@stericsson.com> Signed-off-by:
Borislav Petkov <bp@suse.de> [jstultz: Changed variable name for clarity, added extra dmi entry] Tested-by:
Brecht Machiels <brecht@mos6581.org> Tested-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
John Stultz authored
commit 330a1617 upstream. Since 48cdc135 (Implement a shadow timekeeper), we have to call timekeeping_update() after any adjustment to the timekeeping structure in order to make sure that any adjustments to the structure persist. In the timekeeping suspend path, we udpate the timekeeper structure, so we should be sure to update the shadow-timekeeper before releasing the timekeeping locks. Currently this isn't done. In most cases, the next time related code to run would be timekeeping_resume, which does update the shadow-timekeeper, but in an abundence of caution, this patch adds the call to timekeeping_update() in the suspend path. Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
John Stultz authored
commit 04005f60 upstream. A think-o in the calculation of the monotonic -> tai time offset results in CLOCK_TAI timers and nanosleeps to expire late (the latency is ~2x the tai offset). Fix this by adding the tai offset from the realtime offset instead of subtracting. Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
John Stultz authored
commit f55c0760 upstream. Since 48cdc135 (Implement a shadow timekeeper), we have to call timekeeping_update() after any adjustment to the timekeeping structure in order to make sure that any adjustments to the structure persist. Unfortunately, the updates to the tai offset via adjtimex do not trigger this update, causing adjustments to the tai offset to be made and then over-written by the previous value at the next update_wall_time() call. This patch resovles the issue by calling timekeeping_update() right after setting the tai offset. Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Steven Rostedt authored
commit 23a8e844 upstream. Doing some different tests, I discovered that function graph tracing, when filtered via the set_ftrace_filter and set_ftrace_notrace files, does not always keep with them if another function ftrace_ops is registered to trace functions. The reason is that function graph just happens to trace all functions that the function tracer enables. When there was only one user of function tracing, the function graph tracer did not need to worry about being called by functions that it did not want to trace. But now that there are other users, this becomes a problem. For example, one just needs to do the following: # cd /sys/kernel/debug/tracing # echo schedule > set_ftrace_filter # echo function_graph > current_tracer # cat trace [..] 0) | schedule() { ------------------------------------------ 0) <idle>-0 => rcu_pre-7 ------------------------------------------ 0) ! 2980.314 us | } 0) | schedule() { ------------------------------------------ 0) rcu_pre-7 => <idle>-0 ------------------------------------------ 0) + 20.701 us | } # echo 1 > /proc/sys/kernel/stack_tracer_enabled # cat trace [..] 1) + 20.825 us | } 1) + 21.651 us | } 1) + 30.924 us | } /* SyS_ioctl */ 1) | do_page_fault() { 1) | __do_page_fault() { 1) 0.274 us | down_read_trylock(); 1) 0.098 us | find_vma(); 1) | handle_mm_fault() { 1) | _raw_spin_lock() { 1) 0.102 us | preempt_count_add(); 1) 0.097 us | do_raw_spin_lock(); 1) 2.173 us | } 1) | do_wp_page() { 1) 0.079 us | vm_normal_page(); 1) 0.086 us | reuse_swap_page(); 1) 0.076 us | page_move_anon_rmap(); 1) | unlock_page() { 1) 0.082 us | page_waitqueue(); 1) 0.086 us | __wake_up_bit(); 1) 1.801 us | } 1) 0.075 us | ptep_set_access_flags(); 1) | _raw_spin_unlock() { 1) 0.098 us | do_raw_spin_unlock(); 1) 0.105 us | preempt_count_sub(); 1) 1.884 us | } 1) 9.149 us | } 1) + 13.083 us | } 1) 0.146 us | up_read(); When the stack tracer was enabled, it enabled all functions to be traced, which now the function graph tracer also traces. This is a side effect that should not occur. To fix this a test is added when the function tracing is changed, as well as when the graph tracer is enabled, to see if anything other than the ftrace global_ops function tracer is enabled. If so, then the graph tracer calls a test trampoline that will look at the function that is being traced and compare it with the filters defined by the global_ops. As an optimization, if there's no other function tracers registered, or if the only registered function tracers also use the global ops, the function graph infrastructure will call the registered function graph callback directly and not go through the test trampoline. Fixes: d2d45c7a "tracing: Have stack_tracer use a separate list of functions" Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Steven Rostedt authored
commit a4c35ed2 upstream. The synchronization needed after ftrace_ops are unregistered must happen after the callback is disabled from becing called by functions. The current location happens after the function is being removed from the internal lists, but not after the function callbacks were disabled, leaving the functions susceptible of being called after their callbacks are freed. This affects perf and any externel users of function tracing (LTTng and SystemTap). Fixes: cdbe61bf "ftrace: Allow dynamically allocated function tracers" Signed-off-by:
-
Steven Rostedt authored
commit 405e1d83 upstream. ftrace_trace_function is a variable that holds what function will be called directly by the assembly code (mcount). If just a single function is registered and it handles recursion itself, then the assembly will call that function directly without any helper function. It also passes in the ftrace_op that was registered with the callback. The ftrace_op to send is stored in the function_trace_op variable. The ftrace_trace_function and function_trace_op needs to be coordinated such that the called callback wont be called with the wrong ftrace_op, otherwise bad things can happen if it expected a different op. Luckily, there's no callback that doesn't use the helper functions that requires this. But there soon will be and this needs to be fixed. Use a set_function_trace_op to store the ftrace_op to set the function_trace_op to when it is safe to do so (during the update function within the breakpoint or stop machine calls). Or if dynamic ftrace is not being used (static tracing) then we have to do a bit more synchronization when the ftrace_trace_function is set as that takes affect immediately (as oppose to dynamic ftrace doing it with the modification of the trampoline). Signed-off-by:
-
Seth Heasley authored
commit f39901c1 upstream. This patch adds the i801 SMBus Controller DeviceIDs for the Intel Coleto Creek PCH. Signed-off-by:
Seth Heasley <seth.heasley@intel.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Cc: "Chan, Wei Sern" <wei.sern.chan@intel.com> Signed-off-by:
-
Seth Heasley authored
commit 283aae8a upstream. This patch adds the LPC Controller DeviceIDs for iTCO Watchdog for the Intel Coleto Creek PCH. Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Cc: "Chan, Wei Sern" <wei.sern.chan@intel.com> Signed-off-by:
-
James Ralston authored
commit 8477128f upstream. This patch adds the LPC Controller Device IDs for Watchdog and GPIO for Intel Avoton SoC, to the lpc_ich driver. Signed-off-by:
James Ralston <james.d.ralston@intel.com> Signed-off-by:
-
Dave Airlie authored
commit ec22b4aa upstream. mode->mdev otherwise the bw limits never kick in. Reported in RHEL testing. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Takashi Iwai authored
commit 2510538f upstream. When the mode is set with 16bpp on QEMU, the output gets totally broken. The culprit is the bogus register values set for 16bpp, which was likely copied from from a wrong place. Addresses https://bugzilla.novell.com/show_bug.cgi?id=799216Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: David Airlie <airlied@linux.ie> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Stanislaw Gruszka authored
commit 22accca0 upstream. Not removing pm qos request and free memory for it can cause crash, when some other driver use pm qos. For example, this oops: BUG: unable to handle kernel paging request at fffffffffffffff8 IP: [<ffffffff81307a6b>] plist_add+0x5b/0xd0 Call Trace: [<ffffffff810acf25>] pm_qos_update_target+0x125/0x1e0 [<ffffffff810ad071>] pm_qos_add_request+0x91/0x100 [<ffffffffa053ec14>] e1000_open+0xe4/0x5b0 [e1000e] was caused by earlier i915 probe failure: [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 00003004 tail 00000000 start 00003000 [drm:i915_driver_load] *ERROR* failed to init modeset i915: probe of 0000:00:02.0 failed with error -5 Bug report: http://bugzilla.redhat.com/show_bug.cgi?id=1057533Reported-by:
Giandomenico De Tullio <ghisha@gmail.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> [danvet: Drop unnecessary code movement.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Todd Previte authored
commit 232a6ee9 upstream. Add new definitions for hotplug live status bits for VLV2 since they're in reverse order from the gen4x ones. Changelog: - Restored gen4 bit definitions - Added new definitions for VLV2 - Added platform check for IS_VALLEYVIEW() in dp_detect to use the correct bit defintions - Replaced a lost trailing brace for the added switch() Signed-off-by:
Todd Previte <tprevite@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73951 [danvet: Switch to _VLV postfix instead of prefix and regroupg comments again so that the g4x warning is right next to those defines. Also add a _G4X suffix for those special ones. Also cc stable.] Signed-off-by:
-
Akash Goel authored
commit ec14ba47 upstream. The 'offset' field of the 'scatterlist' structure was wrongly programmed with the offset value from the base of stolen area, whereas this field indicates the offset from where the interested data starts within the first PAGE pointed to by 'scattterlist' structure. As a result when a new GEM object allocated from stolen area is mapped to GTT, it could lead to an overwrite of GTT entries as the page count calculation will go wrong, refer the function 'sg_page_count'. v2: Modified the commit message. (Chris) Signed-off-by:
Akash Goel <akash.goel@intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71908 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69104Signed-off-by:
-
Chris Wilson authored
commit 304d695c upstream. In very rare cases (such as a memory failure stress test) it is possible to fill the entire ring without emitting a request. Under this circumstance, the outstanding request is flushed and waited upon. After space on the ring is cleared, we return to emitting the new command - except that we just cleared the seqno allocated for this operation and trigger the sanity check that a request is only ever emitted with a valid seqno. The fix is to rearrange the code to make sure the allocation of the seqno for this operation is after any required flushes of outstanding operations. The bug exists since the preallocation was introduced in commit 9d773091 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Nov 27 16:22:52 2012 +0000 drm/i915: Preallocate next seqno before touching the ring Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
commit ce8f7699 upstream. Commit de7b7d59 introduced tiled GART, but a linear copy is still performed. This may result in errors on eviction, fix it by checking tiling from memtype. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Mikulas Patocka authored
commit 2995fa78 upstream. This reverts commit be35f486 ("dm: wait until embedded kobject is released before destroying a device") and provides an improved fix. The kobject release code that calls the completion must be placed in a non-module file, otherwise there is a module unload race (if the process calling dm_kobject_release is preempted and the DM module unloaded after the completion is triggered, but before dm_kobject_release returns). To fix this race, this patch moves the completion code to dm-builtin.c which is always compiled directly into the kernel if BLK_DEV_DM is selected. The patch introduces a new dm_kobject_holder structure, its purpose is to keep the completion and kobject in one place, so that it can be accessed from non-module code without the need to export the layout of struct mapped_device to that code. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Alex Deucher authored
commit 6802d4ba upstream. The BlankCrtc table in some DCE8 boards has some logic shortcuts for the vbios when this bit is set. Clear it for driver use. v2: fix typo Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73420Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit e9a321c6 upstream. DCE5 and newer hardware only has 1 DAC. Use the correct offset. This may fix display problems on certain board configurations. Signed-off-by:
-
Alex Deucher authored
commit d45b964a upstream. Needed to properly flush the read caches for fences. Signed-off-by:
-
Alex Deucher authored
commit 10e9ffae upstream. We need to set the engine bit to select the ME and also set the full cache bit. Should help stability on TN and cayman. V2: fix up surface sync in ib execute as well Signed-off-by:
-
Alex Deucher authored
commit d8e24525 upstream. Seems to cause problems with certain DP monitors. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=40699Signed-off-by:
-
Marek Olšák authored
commit 56492e0f upstream. This fixes a bug which was causing rejections of valid GPU commands from userspace. Signed-off-by:
Marek Olšák <marek.olsak@amd.com> Signed-off-by:
-
Malcolm Priestley authored
commit dd4491df upstream. Current setting of symbol rate is not very actuate causing loss of lock. Covert temp to u64 and use mclk to calculate from big number. Calculate symbol rate by dividing symbol rate by 1000 times 1 << 24 and dividing sum by mclk. Add other symbol rate settings to function registers 0xa0-0xa3. In set_frontend add changes to register 0xf1 this must be done prior call to fe_reset. Register 0x00 doesn't need a second write of 0x1 Applied after patch m88rs2000: add m88rs2000_set_carrieroffset Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by:
-
Malcolm Priestley authored
commit 06af15d1 upstream. Set the carrier offset correctly using the default mclk values. Add function m88rs2000_get_mclk to calculate the mclk value against crystal frequency which will later be used for other functions. Add function m88rs2000_set_carrieroffset to calculate and set the offset value. variable offset becomes a signed value. Register 0x86 is set the appropriate value according to remainder value of frequency % 192857 calculation as shown. Signed-off-by:
-
Olivier Grenie authored
commit d67350f8 upstream. Commit 173a64cb broke support for some dib807x versions. Fix it by providing backward compatibility with the older versions. [mkrufky@linuxtv.org: conflict handling and CodingStyle fixes] Signed-off-by:
Olivier Grenie <olivier.grenie@parrot.com> Acked-by:
Patrick Boettcher <pboettcher@kernellabs.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit fa1e1de6 upstream. The buffer size on nxt200x is not enough: ... > Dec 20 10:52:04 rich kernel: [ 31.747949] nxt200x: nxt200x_writebytes: i2c wr reg=002c: len=255 is too big! ... Increase it to 256 bytes. Reported-by:
Rich Freeman <rich0@gentoo.org> Signed-off-by:
-
Marek Szyprowski authored
commit b80cb8dc upstream. s5p_mfc_get_node_type() relies on get_index() helper function, which in turn relies on video_device index numbers assigned on driver registration. All this code is not really needed, because there is already access to respective video_device structures via common s5p_mfc_dev structure. This fixes the issues introduced by patch 1056e438 ("v4l2-dev: Fix race condition on __video_register_device"), which has been merged in v3.12-rc1. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Kamil Debski <k.debski@samsung.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 5ac64ba1 upstream. As the dvb-frontend kthread can be called anytime, it can race with some get status ioctl. So, it seems better to avoid one to race with the other while reading a 32 bits register. I can't see any other reason for having a mutex there at I2C, except to provide such kind of protection, as the I2C core already has a mutex to protect I2C transfers. Note: instead of this approach, it could eventually remove the dib8000 specific mutex for it, and either group the 4 ops into one xfer or to manually control the I2C mutex. The main advantage of the current approach is that the changes are smaller and more puntual. Signed-off-by:
-
Antti Palosaari authored
commit c57f87e6 upstream. PLL was attached twice to frontend0 leaving frontend1 without a tuner. frontend0 is DVB-C and frontend1 is DVB-T. Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
David Rientjes authored
commit 778c14af upstream. A 3% of system memory bonus is sometimes too excessive in comparison to other processes. With commit a63d83f4 ("oom: badness heuristic rewrite"), the OOM killer tries to avoid killing privileged tasks by subtracting 3% of overall memory (system or cgroup) from their per-task consumption. But as a result, all root tasks that consume less than 3% of overall memory are considered equal, and so it only takes 33+ privileged tasks pushing the system out of memory for the OOM killer to do something stupid and kill dhclient or other root-owned processes. For example, on a 32G machine it can't tell the difference between the 1M agetty and the 10G fork bomb member. The changelog describes this 3% boost as the equivalent to the global overcommit limit being 3% higher for privileged tasks, but this is not the same as discounting 3% of overall memory from _every privileged task individually_ during OOM selection. Replace the 3% of system memory bonus with a 3% of current memory usage bonus. By giving root tasks a bonus that is proportional to their actual size, they remain comparable even when relatively small. In the example above, the OOM killer will discount the 1M agetty's 256 badness points down to 179, and the 10G fork bomb's 262144 points down to 183500 points and make the right choice, instead of discounting both to 0 and killing agetty because it's first in the task list. Signed-off-by:
David Rientjes <rientjes@google.com> Reported-by:
Johannes Weiner <hannes@cmpxchg.org> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Michel Dänzer authored
commit 37016951 upstream. It's never allocated on systems without an ATOMBIOS or COMBIOS ROM. Should fix an oops I encountered while resetting the GPU after a lockup on my PowerBook with an RV350. Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Alex Deucher authored
commit d1951782 upstream. The hw i2c engines are disabled by default as the current implementation is still experimental. Print a warning when users enable it so that it's obvious when the option is enabled. v2: check for non-0 rather than 1 Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Joe Thornber authored
commit fca02843 upstream. This bug was introduced in commit 7e664b3d ("dm space map metadata: fix extending the space map"). When extending a dm-thin metadata volume we: - Switch the space map into a simple bootstrap mode, which allocates all space linearly from the newly added space. - Add new bitmap entries for the new space - Increment the reference counts for those newly allocated bitmap entries - Commit changes to disk - Switch back out of bootstrap mode. But, the disk commit may allocate space itself, if so this fact will be lost when switching out of bootstrap mode. The bug exhibited itself as an error when the bitmap_root, with an erroneous ref count of 0, was subsequently decremented as part of a later disk commit. This would cause the disk commit to fail, and thinp to enter read_only mode. The metadata was not damaged (thin_check passed). The fix is to put the increments + commit into a loop, running until the commit has not allocated extra space. In practise this loop only runs twice. With this fix the following device mapper testsuite test passes: dmtest run --suite thin-provisioning -n thin_remove_works_after_resize Signed-off-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
-
Joe Thornber authored
commit 7e664b3d upstream. When extending a metadata space map we should do the first commit whilst still in bootstrap mode -- a mode where all blocks get allocated in the new area. That way the commit overhead is allocated from the newly added space. Otherwise we risk running out of space. With this fix, and the previous commit "dm space map common: make sure new space is used during extend", the following device mapper testsuite test passes: dmtest run --suite thin-provisioning -n /resize_metadata_no_io/ Signed-off-by:
-
Joe Thornber authored
commit 12c91a5c upstream. When extending a low level space map we should update nr_blocks at the start so the new space is used for the index entries. Otherwise extend can fail, e.g.: sm_metadata_extend call sequence that fails: -> sm_ll_extend -> dm_tm_new_block -> dm_sm_new_block -> sm_bootstrap_new_block => returns -ENOSPC because smm->begin == smm->ll.nr_blocks Signed-off-by:
-
Mikulas Patocka authored
commit be35f486 upstream. There may be other parts of the kernel holding a reference on the dm kobject. We must wait until all references are dropped before deallocating the mapped_device structure. The dm_kobject_release method signals that all references are dropped via completion. But dm_kobject_release doesn't free the kobject (which is embedded in the mapped_device structure). This is the sequence of operations: * when destroying a DM device, call kobject_put from dm_sysfs_exit * wait until all users stop using the kobject, when it happens the release method is called * the release method signals the completion and should return without delay * the dm device removal code that waits on the completion continues * the dm device removal code drops the dm_mod reference the device had * the dm device removal code frees the mapped_device structure that contains the kobject Using kobject this way should avoid the module unload race that was mentioned at the beginning of this thread: https://lkml.org/lkml/2014/1/4/83Signed-off-by:
-
Mike Snitzer authored
commit 16961b04 upstream. As additional members are added to the dm_thin_new_mapping structure care should be taken to make sure they get initialized before use. Signed-off-by:
-
Joe Thornber authored
commit 19fa1a67 upstream. If a snapshot is created and later deleted the origin dm_thin_device's snapshotted_time will have been updated to reflect the snapshot's creation time. The 'shared' flag in the dm_thin_lookup_result struct returned from dm_thin_find_block() is an approximation based on snapshotted_time -- this is done to avoid 0(n), or worse, time complexity. In this case, the shared flag would be true. But because the 'shared' flag reflects an approximation a block can be incorrectly assumed to be shared (e.g. false positive for 'shared' because the snapshot no longer exists). This could result in discards issued to a thin device not being passed down to the pool's underlying data device. To fix this we double check that a thin block is really still in-use after a mapping is removed using dm_pool_block_is_used(). If the reference count for a block is now zero the discard is allowed to be passed down. Also add a 'definitely_not_shared' member to the dm_thin_new_mapping structure -- reflects that the 'shared' flag in the response from dm_thin_find_block() can only be held as definitive if false is returned. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1043527Signed-off-by:
-
