13 Jul, 2017
1 commit
-
dm crypt: fix deadlock when async crypto algorithm returns -EBUSY
I suspect this doesn't show up for most anyone because software
algorithms typically don't have a sense of being too busy. However,
when working with the Freescale CAAM driver it will return -EBUSY on
occasion under heavy -- which resulted in dm-crypt deadlock.After checking the logic in some other drivers, the scheme for
crypt_convert() and it's callback, kcryptd_async_done(), were not
correctly laid out to properly handle -EBUSY or -EINPROGRESS.Fix this by using the completion for both -EBUSY and -EINPROGRESS. Now
crypt_convert()'s use of completion is comparable to
af_alg_wait_for_completion(). Similarly, kcryptd_async_done() follows
the pattern used in af_alg_complete().Before this fix dm-crypt would lockup within 1-2 minutes running with
the CAAM driver. Fix was regression tested against software algorithms
on PPC32 and x86_64, and things seem perfectly happy there as well.Signed-off-by: Ben Collins
Signed-off-by: Mike Snitzer
Cc: stable@vger.kernel.orgConflicts:
drivers/md/dm-crypt.cChange-Id: I831ca35950188fb237fc46419a17b4ff95503985
21 Mar, 2017
1 commit
-
dm-android-verity depends on optional kernel command line parameters.
When compiled as module the __setup macro ends up being a no-op
resulting in the following warnings:/work/build/batch/drivers/md/dm-android-verity.c:91:19: warning: 'verity_buildvariant' defined but not used [-Wunused-function]
static int __init verity_buildvariant(char *line)
^~~~~~~~~~~~~~~~~~~
/work/build/batch/drivers/md/dm-android-verity.c:83:19: warning: 'verity_keyid_param' defined but not used [-Wunused-function]
static int __init verity_keyid_param(char *line)
^~~~~~~~~~~~~~~~~~
/work/build/batch/drivers/md/dm-android-verity.c:75:19: warning: 'verity_mode_param' defined but not used [-Wunused-function]
static int __init verity_mode_param(char *line)
^~~~~~~~~~~~~~~~~
/work/build/batch/drivers/md/dm-android-verity.c:67:19: warning: 'verified_boot_state_param' defined but not used [-Wunused-function]
static int __init verified_boot_state_param(char *line)
^~~~~~~~~~~~~~~~~~~~~~~~~
Tested with allmodconfig.Change-Id: Idfe0c97b216bb620cc7264e968b494eb3a765157
Signed-off-by: Badhri Jagan Sridharan
18 Mar, 2017
2 commits
-
am: 21582cd0b6
Change-Id: I23e32d9f39d07a9a6178688aa78f7b0a10718408
-
commit d67a5f4b5947aba4bfe9a80a2b86079c215ca755 upstream.
Commit df2cb6daa4 ("block: Avoid deadlocks with bio allocation by
stacking drivers") created a workqueue for every bio set and code
in bio_alloc_bioset() that tries to resolve some low-memory deadlocks
by redirecting bios queued on current->bio_list to the workqueue if the
system is low on memory. However other deadlocks (see below **) may
happen, without any low memory condition, because generic_make_request
is queuing bios to current->bio_list (rather than submitting them).** the related dm-snapshot deadlock is detailed here:
https://www.redhat.com/archives/dm-devel/2016-July/msg00065.htmlFix this deadlock by redirecting any bios on current->bio_list to the
bio_set's rescue workqueue on every schedule() call. Consequently,
when the process blocks on a mutex, the bios queued on
current->bio_list are dispatched to independent workqueus and they can
complete without waiting for the mutex to be available.The structure blk_plug contains an entry cb_list and this list can contain
arbitrary callback functions that are called when the process blocks.
To implement this fix DM (ab)uses the onstack plug's cb_list interface
to get its flush_current_bio_list() called at schedule() time.This fixes the snapshot deadlock - if the map method blocks,
flush_current_bio_list() will be called and it redirects bios waiting
on current->bio_list to appropriate workqueues.Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1267650
Depends-on: df2cb6daa4 ("block: Avoid deadlocks with bio allocation by stacking drivers")
Signed-off-by: Mikulas Patocka
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman
16 Mar, 2017
1 commit
-
To start Treble VTS test, a single AOSP system.img will be flashed onto
the device. The size of AOSP system.img might be different than the
system partition size on device, making locating verity metadata fail
(at the last fixed size of the partition).This change allows disabling dm-verity on system partition when the
device is unlocked (orange device state) with invalid metadata.BUG: 35603549
Test: boot device with a different-sized system.img, checks verity is
not enabled via:"adb shell getprop | grep partition.system.verified"
Change-Id: Ide78dca4eefde4ab019e4b202d3f590dcb1bb506
Signed-off-by: Bowgo Tsai
12 Mar, 2017
10 commits
-
am: 6f9c02ab9d
Change-Id: I1f96e0d5a2b66b2dd84747d13244abaa4d3a19c3
-
am: 2937e22c23
Change-Id: I3a55981aab612685064716fad5c0e70d021c62bb
-
am: b7f874eedc
Change-Id: I27c857c373193aff5b5699f1e5052a9f95d1762c
-
am: bad6c16b81
Change-Id: I2e0f245f2f4080cd374009a7f5b834b160cfedc4
-
am: 9987feba90
Change-Id: Id78e8b92c942e93784f7c68ef800d0a6f345207c
-
commit 03a9e24ef2aaa5f1f9837356aed79c860521407a upstream.
Recently I receive a bug report that on Linux v3.0 based kerenl, hot add
disk to a md linear device causes kernel crash at linear_congested(). From
the crash image analysis, I find in linear_congested(), mddev->raid_disks
contains value N, but conf->disks[] only has N-1 pointers available. Then
a NULL pointer deference crashes the kernel.There is a race between linear_add() and linear_congested(), RCU stuffs
used in these two functions cannot avoid the race. Since Linuv v4.0
RCU code is replaced by introducing mddev_suspend(). After checking the
upstream code, it seems linear_congested() is not called in
generic_make_request() code patch, so mddev_suspend() cannot provent it
from being called. The possible race still exists.Here I explain how the race still exists in current code. For a machine
has many CPUs, on one CPU, linear_add() is called to add a hard disk to a
md linear device; at the same time on other CPU, linear_congested() is
called to detect whether this md linear device is congested before issuing
an I/O request onto it.Now I use a possible code execution time sequence to demo how the possible
race happens,seq linear_add() linear_congested()
0 conf=mddev->private
1 oldconf=mddev->private
2 mddev->raid_disks++
3 for (i=0; iraid_disks;i++)
4 bdev_get_queue(conf->disks[i].rdev->bdev)
5 mddev->private=newconfIn linear_add() mddev->raid_disks is increased in time seq 2, and on
another CPU in linear_congested() the for-loop iterates conf->disks[i] by
the increased mddev->raid_disks in time seq 3,4. But conf with one more
element (which is a pointer to struct dev_info type) to conf->disks[] is
not updated yet, accessing its structure member in time seq 4 will cause a
NULL pointer deference fault.To fix this race, there are 2 parts of modification in the patch,
1) Add 'int raid_disks' in struct linear_conf, as a copy of
mddev->raid_disks. It is initialized in linear_conf(), always being
consistent with pointers number of 'struct dev_info disks[]'. When
iterating conf->disks[] in linear_congested(), use conf->raid_disks to
replace mddev->raid_disks in the for-loop, then NULL pointer deference
will not happen again.
2) RCU stuffs are back again, and use kfree_rcu() in linear_add() to
free oldconf memory. Because oldconf may be referenced as mddev->private
in linear_congested(), kfree_rcu() makes sure that its memory will not
be released until no one uses it any more.
Also some code comments are added in this patch, to make this modification
to be easier understandable.This patch can be applied for kernels since v4.0 after commit:
3be260cc18f8 ("md/linear: remove rcu protections in favour of
suspend/resume"). But this bug is reported on Linux v3.0 based kernel, for
people who maintain kernels before Linux v4.0, they need to do some back
back port to this patch.Changelog:
- V3: add 'int raid_disks' in struct linear_conf, and use kfree_rcu() to
replace rcu_call() in linear_add().
- v2: add RCU stuffs by suggestion from Shaohua and Neil.
- v1: initial effort.Signed-off-by: Coly Li
Cc: Shaohua Li
Cc: Neil Brown
Signed-off-by: Shaohua Li
Signed-off-by: Greg Kroah-Hartman -
commit d36a19541fe8f392778ac137d60f9be8dfdd8f9d upstream.
The lvm2 sequence to manage dm-raid constructor flags that trigger a
rebuild or a reshape is defined as:1) load table with flags (e.g. rebuild/delta_disks/data_offset)
2) clear out the flags in lvm2 metadata
3) store the lvm2 metadata, reload the table to reset the flags
previously established during the initial load (1) -- in order to
prevent repeatedly requesting a rebuild or a reshape on activationCurrently, loading an inactive table with rebuild/reshape flags
specified will cause dm-raid to rebuild/reshape on resume and thus start
updating the raid metadata (about the progress). When the second table
reload, to reset the flags, occurs the constructor accesses the volatile
progress state kept in the raid superblocks. Because the active mapping
is still processing the rebuild/reshape, that position will be stale by
the time the device is resumed.In the reshape case, this causes data corruption by processing already
reshaped stripes again. In the rebuild case, it does _not_ cause data
corruption but instead involves superfluous rebuilds.Fix by keeping the raid set frozen during the first resume and then
allow the rebuild/reshape during the second resume.Fixes: 9dbd1aa3a ("dm raid: add reshaping support to the target")
Signed-off-by: Heinz Mauelshagen
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit 37a098e9d10db6e2efc05fe61e3a6ff2e9802c53 upstream.
The sloppy nature of lockless access to percpu pointers
(s->current_path) in rr_select_path(), from multiple threads, is
causing some paths to used more than others -- which results in less
IO performance being observed.Revert these upstream commits to restore truly symmetric round-robin
IO submission in DM multipath:b0b477c dm round robin: use percpu 'repeat_count' and 'current_path'
802934b dm round robin: do not use this_cpu_ptr() without having preemption disabledThere is no benefit to all this complexity if repeat_count = 1 (which is
the recommended default).Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit 6085831883c25860264721df15f05bbded45e2a2 upstream.
Fixes: dfcfac3e4cd9 ("dm stats: collect and report histogram of IO latencies")
Signed-off-by: Mikulas Patocka
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit ca763d0a53b264a650342cee206512bc92ac7050 upstream.
A rounding bug due to compiler generated temporary being 32bit was found
in remap_to_cache(). A localized cast in remap_to_cache() fixes the
corruption but this preferred fix (changing from uint32_t to sector_t)
eliminates potential for future rounding errors elsewhere.Signed-off-by: Joe Thornber
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman
03 Mar, 2017
1 commit
-
If table_make_digest() fails, verify_verity_signature() would try to
pass the returned ERR_PTR() to kfree().This fixes the smatch error:
drivers/md/dm-android-verity.c:601 verify_verity_signature() error: 'pks' dereferencing possible ERR_PTR()
Change-Id: I9b9b7764b538cb4a5f94337660e9b0f149b139be
Signed-off-by: Greg Hackmann
24 Feb, 2017
2 commits
-
commit be628be09563f8f6e81929efbd7cf3f45c344416 upstream.
Signed-off-by: Kent Overstreet
Cc: Coly Li
Signed-off-by: Greg Kroah-Hartman
16 Feb, 2017
1 commit
-
This is the 4.9.10 stable release
15 Feb, 2017
1 commit
-
commit 4087a1fffe38106e10646606a27f10d40451862d upstream.
Fixes a crash in dm_table_find_target() due to a NULL struct dm_table
being passed from dm_old_request_fn() that races with DM device
destruction.Reported-by: artem@flashgrid.io
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman
01 Feb, 2017
2 commits
-
This is the 4.9.6 stable release
Change-Id: I318df4b9d706d50c13fe3969d734117c25fc94bc
-
Export the direct_access method of dm_linear target for
dm-android-verity target.Signed-off-by: Badhri Jagan Sridharan
Change-Id: I46556d882305e5194352946264cbc9c06e5038e4
28 Jan, 2017
18 commits
-
- For device like eMMC, it gives better performance to read more hash
blocks at a time.
- For android, set it to default 128.
For other devices, set it to 1 which is the same as now.
- saved boot-up time by 300ms in tested devicebug: 32246564
Change-Id: Ibc0401a0cddba64b862a80445844b4e595213621
Cc: Sami Tolvanen
Signed-off-by: Keun-young Park -
This CL removes the mandate of the fec_header being located right
after the ECC data.(Cherry-picked from https://android-review.googlesource.com/#/c/280401)
Bug: 28865197
Signed-off-by: Badhri Jagan Sridharan
Change-Id: Ie04c8cf2dd755f54d02dbdc4e734a13d6f6507b5 -
Exports the device mapper callbacks of linear and dm-verity-target
methods.Signed-off-by: Badhri Jagan Sridharan
Change-Id: I0358be0615c431dce3cc78575aaac4ccfe3aacd7 -
v4.4 introduced changes to the callbacks used for
dm-linear and dm-verity-target targets. Move to those headers
in dm-android-verity.Verified on hikey while having
BOARD_USES_RECOVERY_AS_BOOT := true
BOARD_BUILD_SYSTEM_ROOT_IMAGE := trueBUG: 27339727
Signed-off-by: Badhri Jagan Sridharan
Change-Id: Ic64950c3b55f0a6eaa570bcedc2ace83bbf3005e -
The fec_header structure is generated build time and stored on disk.
The fec_header might be build on a 64 bits machine while it is read
per a 32 bits device or the other way around. In such situations, the
fec_header fields are not aligned as expected by the device and it
fails to read the fec_header structure.This patch makes the fec_header packed.
Change-Id: Idb84453e70cc11abd5ef3a0adfbb16f8b5feaf06
Signed-off-by: Jeremy Compostella -
Move header validation logic before reading the verity_table as
an invalid header implies the table is invalid as well.(Cherry-picked from:
https://partner-android-review.git.corp.google.com/#/c/625203)BUG: 29940612
Signed-off-by: Badhri Jagan Sridharan
Change-Id: Ib34d25c0854202f3e70df0a6d0ef1d96f0250c8e -
adb disable-verity was allowed when the phone is in the
unlocked state. Since the driver is now aware of the build
variant, honor "adb disable-verity" only in userdebug
builds.(Cherry-picked from
https://partner-android-review.git.corp.google.com/#/c/622117)BUG: 29276559
Signed-off-by: Badhri Jagan Sridharan
Change-Id: I7ce9f38d8c7a62361392c5a8ccebb288f8a3a2ea -
eng builds dont have verity enabled i.e it does even
have verity metadata appended to the parition. Therefore
add rootdev as linear device and map the entire partition
if build variant is "eng".(Cherry-picked based on
https://partner-android-review.git.corp.google.com/#/c/618690/)BUG: 29276559
Signed-off-by: Badhri Jagan Sridharan
Change-Id: I8f5c2289b842b820ca04f5773525e5449bb3f355 -
If the dm-android-verity target does not provide a default
key try using the default public key from the system keyring.
The defualt verity keyid is passed as a kernel command line
argument veritykeyid=.The order of the dm-android-verity params have been reversed
to facilitate the change.Old format example:
dm="system none ro,0 1 android-verity Android:#7e4333f9bba00adfe0ede979e28ed1920492b40f /dev/mmcblk0p43"New formats supported:
dm="system none ro,0 1 android-verity /dev/mmcblk0p43 Android:#7e4333f9bba00adfe0ede979e28ed1920492b40f"(or)
dm="system none ro,0 1 android-verity /dev/mmcblk0p43"
when veritykeyid= is set in the kernel command line.BUG: 28384658
Signed-off-by: Badhri Jagan Sridharan
Change-Id: I506c89b053d835ab579e703eef2bc1f8487250de
(cherry picked from commit c5c74d0327729f35b576564976885596c6d0e7fb) -
The bug was that the signature verification was only
happening when verity was disabled. It should always
happen when verity is enabled.Signed-off-by: Badhri Jagan Sridharan
Change-Id: I2d9354e240d36ea06fc68c2d18d8e87b823a4c2f
(cherry picked from commit 5364b5ca0b1a12a58283b51408e43fc36d4e4fe7) -
This patch makes android_verity_ctr() parse its block device string
parameter with name_to_dev_t(). It allows the use of less hardware
related block device reference like PARTUUID for instance.Change-Id: Idb84453e70cc11abd5ef3a0adfbb16f8b5feaf07
Signed-off-by: Jeremy Compostella -
This keeps linear_target as static variable and just exposes
the linear target methods for android-verityCherry-picked: https://android-review.googlesource.com/#/c/212858
Change-Id: I4a377e417b00afd9ecccdb3e605fea31a7df112e
Signed-off-by: Badhri Jagan Sridharan
(cherry picked from commit a6d1b091f40b25d97849487e29ec097bc5f568dd) -
Compacts the linear device arguments removing the
unnecessary variables.Bug: 27175947
Change-Id: I157170eebe3c0f89a68ae05870a1060f188d0da0
Signed-off-by: Badhri Jagan Sridharan -
This CL makes android-verity target to be added as linear
dm device if when bootloader is unlocked and verity is disabled.Bug: 27175947
Change-Id: Ic41ca4b8908fb2777263799cf3a3e25934d70f18
Signed-off-by: Badhri Jagan Sridharan -
Following CLs in upstream causes minor changes to dm-android-verity target.
1. keys: change asymmetric keys to use common hash definitions
2. block: Abstract out bvec iterator
Rebase dm-android-verity on top of these changes.Bug: 27175947
Signed-off-by: Badhri Jagan Sridharan
Change-Id: Icfdc3e7b3ead5de335a059cade1aca70414db415 -
This device-mapper target is virtually a VERITY target. This
target is setup by reading the metadata contents piggybacked
to the actual data blocks in the block device. The signature
of the metadata contents are verified against the key included
in the system keyring. Upon success, the underlying verity
target is setup.BUG: 27175947
Change-Id: I7e99644a0960ac8279f02c0158ed20999510ea97
Signed-off-by: Badhri Jagan Sridharan -
This is a wrap-up of three patches pending upstream approval.
I'm bundling them because they are interdependent, and it'll be
easier to drop it on rebase later.1. dm: allow a dm-fs-style device to be shared via dm-ioctl
Integrates feedback from Alisdair, Mike, and Kiyoshi.
Two main changes occur here:
- One function is added which allows for a programmatically created
mapped device to be inserted into the dm-ioctl hash table. This binds
the device to a name and, optional, uuid which is needed by udev and
allows for userspace management of the mapped device.- dm_table_complete() was extended to handle all of the final
functional changes required for the table to be operational once
called.2. init: boot to device-mapper targets without an initr*
Add a dm= kernel parameter modeled after the md= parameter from
do_mounts_md. It allows for device-mapper targets to be configured at
boot time for use early in the boot process (as the root device or
otherwise). It also replaces /dev/XXX calls with major:minor opportunistically.The format is dm="name uuid ro,table line 1,table line 2,...". The
parser expects the comma to be safe to use as a newline substitute but,
otherwise, uses the normal separator of space. Some attempt has been
made to make it forgiving of additional spaces (using skip_spaces()).A mapped device created during boot will be assigned a minor of 0 and
may be access via /dev/dm-0.An example dm-linear root with no uuid may look like:
root=/dev/dm-0 dm="lroot none ro, 0 4096 linear /dev/ubdb 0, 4096 4096 linear /dv/ubdc 0"
Once udev is started, /dev/dm-0 will become /dev/mapper/lroot.
Older upstream threads:
http://marc.info/?l=dm-devel&m=127429492521964&w=2
http://marc.info/?l=dm-devel&m=127429499422096&w=2
http://marc.info/?l=dm-devel&m=127429493922000&w=2Latest upstream threads:
https://patchwork.kernel.org/patch/104859/
https://patchwork.kernel.org/patch/104860/
https://patchwork.kernel.org/patch/104861/Bug: 27175947
Signed-off-by: Will Drewry
Review URL: http://codereview.chromium.org/2020011
Change-Id: I92bd53432a11241228d2e5ac89a3b20d19b05a31
-
Explicitly initialize recursion level to zero at the beginning of each
I/O operation.Bug: 28943429
Change-Id: I00c612be2b8c22dd5afb65a739551df91cb324fc
Signed-off-by: Sami Tolvanen
(cherry picked from commit 32ffb3a22d7fd269b2961323478ece92c06a8334)
