aboutsummaryrefslogtreecommitdiff
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
...
* AEE: disable aee_kernel_dal_api.Shangbing Hu2018-05-161-3/+2
| | | | | | | | | | | | | | [Detail] the red screen feature should be available only for AEE, or it would make users confused about whether AEE workes well. [Solution] Disable this api. MTK-Commit-Id: 47ccf5e37ed8b58b51c90d29cb1f3fc644032af8 Change-Id: Ia85f398e367e062c89bcb751a8887fdae44d55f3 Signed-off-by: Shangbing Hu <shangbing.hu@mediatek.com> CR-Id: ALPS02530766 Feature: Android Exception Engine(AEE)
* mediatek: mmc: disable all proc entriesfire8552018-05-161-1/+3
| | | | They are not used anywhere and are creating a higher security risk
* mediatek: force USER_BUILD_KERNEL flagfire8552018-05-163-5/+5
| | | | this was never set but it should be enabled
* BACKPORT: USB: core: harden cdc_parse_cdc_headerMarissa Wall2018-05-165-5/+26
| | | | | | | | | | | | | | | | | | | | | | | | | Andrey Konovalov reported a possible out-of-bounds problem for the cdc_parse_cdc_header function. He writes: It looks like cdc_parse_cdc_header() doesn't validate buflen before accessing buffer[1], buffer[2] and so on. The only check present is while (buflen > 0). So fix this issue up by properly validating the buffer length matches what the descriptor says it is. (cherry picked from commit 2e1c42391ff2556387b3cb6308b24f6f65619feb) (The original patch fixed the generic cdc_parser_cdc_header function. That generic function did not exist in 3.10 but there are a couple cdc parsers that suffer from the same underlying problem.) Bug: 69052594 Change-Id: Ib251469de39e51b0ed7c1a1b88873270afccd90f Reported-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Andrey Konovalov <andreyknvl@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Marissa Wall <marissaw@google.com>
* UPSTREAM: loop: fix concurrent lo_open/lo_releaseMarissa Wall2018-02-121-2/+8
| | | | | | | | | | | | | | | | | | 范龙飞 reports that KASAN can report a use-after-free in __lock_acquire. The reason is due to insufficient serialization in lo_release(), which will continue to use the loop device even after it has decremented the lo_refcnt to zero. In the meantime, another process can come in, open the loop device again as it is being shut down. Confusion ensues. (cherry-picked from ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5) Change-Id: Iada5ceba515f0137db8c95d0746e8ffc753037f3 Reported-by: 范龙飞 <long7573@126.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Marissa Wall <marissaw@google.com>
* ANDROID: Skip building uid_sys_stats and keyreset drivers as modulesAmit Pundir2018-01-202-5/+2
| | | | | | | | | | | | | | | | | | | | | Few Android drivers viz. uid_sys_stats and keyreset/combo fail to build as kernel modules. uid_sys_stats.ko failed for undefined "tasklist_lock", which got un-exported in commit c59923a15 ("remove the tasklist_lock export"). Quoting from the commit, "Modules have no business looking at it, and all instances in drivers have been due to use of too-lowlevel APIs. Having this symbol exported prevents moving to more scalable locking schemes for the task list.". So instead of exporting tasklist_lock again, lets not build uid_sys_stats driver as module. Similarly skip building keyreset driver as module which call sys_sync() syscall. To keep things in perspective we don't build these drivers as modules in later kernels (android-4.4/4.9) as well. Change-Id: I6371df72d79c7ad0f0c08e6ebf7e16f1b0970761 Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
* ANDROID: uid_sys_stats: fix the commentArtem Borisov2018-01-201-1/+1
| | | | | | | It is not uid_cputime.c anymore. Change-Id: I7effc2a449c1f9cba9d86a7b122a9c05fc266405 Signed-off-by: Artem Borisov <dedsa2002@gmail.com>
* debug: remove debug 1 hard defineMister Oyster2018-01-1447-47/+47
|
* leds: create timer sysfs on bootfire8552018-01-133-10/+13
| | | | | | | | create delay_on and delay_off from timer trigger on boot BaCkPoRtEd By YoU kNoW wHo Signed-off-by: Mister Oyster <oysterized@gmail.com>
* mtk: turn unneeded MTK_WFD_SUPPORTMister Oyster2018-01-131-5/+0
|
* ANDROID: dm verity: add minimum prefetch sizeKeun-young Park2018-01-052-1/+24
| | | | | | | | | | | | | - 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 device bug: 32246564 Cc: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Keun-young Park <keunyoung@google.com>
* ANDROID: scsi: sg: Fix build breakageDaniel Rosenberg2018-01-051-1/+1
| | | | | | | | | Fixes "UPSTREAM: scsi: sg: check length passed to SG_NEXT_CMD_LEN" SG_MAX_CDB_SIZE used to be MAX_COMMAND_SIZE. Signed-off-by: Daniel Rosenberg <drosen@google.com> Change-Id: I89454d03eea442eb749a1ce9ee002fa5f344db69 Bug: 63666227
* mlog: revert mlog without zram support Revert "drivers: mtk: remove mlog driver"Mister Oyster2018-01-056-0/+986
| | | | This reverts commit 2ec05e320a34076ae4e5b234d49313df5877071b.
* don't make cpu hotplug run too frequentlyDidntRead2018-01-031-1/+1
|
* dm mpath: fix stalls when handling invalid ioctlsHannes Reinecke2018-01-021-2/+5
| | | | | | | | | | | | | | | | An invalid ioctl will never be valid, irrespective of whether multipath has active paths or not. So for invalid ioctls we do not have to wait for multipath to activate any paths, but can rather return an error code immediately. This fix resolves numerous instances of: udevd[]: worker [] unexpectedly returned with status 0x0100 that have been seen during testing. Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Joe Maples <joe@frap129.org>
* md: be careful not lot leak internal curr_resync value into metadata. -- (all)NeilBrown2018-01-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mddev->curr_resync usually records where the current resync is up to, but during the starting phase it has some "magic" values. 1 - means that the array is trying to start a resync, but has yielded to another array which shares physical devices, and also needs to start a resync 2 - means the array is trying to start resync, but has found another array which shares physical devices and has already started resync. 3 - means that resync has commensed, but it is possible that nothing has actually been resynced yet. It is important that this value not be visible to user-space and particularly that it doesn't get written to the metadata, as the resync or recovery checkpoint. In part, this is because it may be slightly higher than the correct value, though this is very rare. In part, because it is not a multiple of 4K, and some devices only support 4K aligned accesses. There are two places where this value is propagates into either ->curr_resync_completed or ->recovery_cp or ->recovery_offset. These currently avoid the propagation of values 1 and 3, but will allow 3 to leak through. Change them to only propagate the value if it is > 3. As this can cause an array to fail, the patch is suitable for -stable. Cc: stable@vger.kernel.org (v3.7+) Reported-by: Viswesh <viswesh.vichu@gmail.com> Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Shaohua Li <shli@fb.com> Signed-off-by: Joe Maples <joe@frap129.org>
* dm: take care to copy the space map roots before locking the superblockJoe Thornber2018-01-022-55/+85
| | | | | | | | | | | | | In theory copying the space map root can fail, but in practice it never does because we're careful to check what size buffer is needed. But make certain we're able to copy the space map roots before locking the superblock. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org # drop dm-era and dm-cache changes as needed Signed-off-by: Joe Maples <joe@frap129.org>
* dm thin: grab a virtual cell before looking up the mappingJoe Thornber2018-01-021-4/+12
| | | | | | | | | Avoids normal IO racing with discard. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Joe Maples <joe@frap129.org>
* dm thin: requeue bios to DM core if no_free_space and in read-only modeMike Snitzer2018-01-021-6/+20
| | | | | | | | | | | | | | | | | | | | | | | Now that we switch the pool to read-only mode when the data device runs out of space it causes active writers to get IO errors once we resume after resizing the data device. If no_free_space is set, save bios to the 'retry_on_resume_list' and requeue them on resume (once the data or metadata device may have been resized). With this patch the resize_io test passes again (on slower storage): dmtest run --suite thin-provisioning -n /resize_io/ Later patches fix some subtle races associated with the pool mode transitions done as part of the pool's -ENOSPC handling. These races are exposed on fast storage (e.g. PCIe SSD). Signed-off-by: Mike Snitzer <snitzer@redhat.com> Acked-by: Joe Thornber <ejt@redhat.com> [@nathanchance: fixed conflicts] Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Joe Maples <joe@frap129.org>
* dm cache: fix a lock-inversionJoe Thornber2018-01-023-52/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When suspending a cache the policy is walked and the individual policy hints written to the metadata via sync_metadata(). This led to this lock order: policy->lock cache_metadata->root_lock When loading the cache target the policy is populated while the metadata lock is held: cache_metadata->root_lock policy->lock Fix this potential lock-inversion (ABBA) deadlock in sync_metadata() by ensuring the cache_metadata root_lock is held whilst all the hints are written, rather than being repeatedly locked while policy->lock is held (as was the case with each callout that policy_walk_mappings() made to the old save_hint() method). Found by turning on the CONFIG_PROVE_LOCKING ("Lock debugging: prove locking correctness") build option. However, it is not clear how the LOCKDEP reported paths can lead to a deadlock since the two paths, suspending a target and loading a target, never occur at the same time. But that doesn't mean the same lock-inversion couldn't have occurred elsewhere. Reported-by: Marian Csontos <mcsontos@redhat.com> Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Joe Maples <joe@frap129.org>
* dm cache: prevent corruption caused by discard_block_size > cache_block_sizeMike Snitzer2018-01-021-34/+3
| | | | | | | | | | | | | | | | | | | | | | | | If the discard block size is larger than the cache block size we will not properly quiesce IO to a region that is about to be discarded. This results in a race between a cache migration where no copy is needed, and a write to an adjacent cache block that's within the same large discard block. Workaround this by limiting the discard_block_size to cache_block_size. Also limit the max_discard_sectors to cache_block_size. A more comprehensive fix that introduces range locking support in the bio_prison and proper quiescing of a discard range that spans multiple cache blocks is already in development. Reported-by: Morgan Mears <Morgan.Mears@netapp.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Acked-by: Joe Thornber <ejt@redhat.com> Acked-by: Heinz Mauelshagen <heinzm@redhat.com> Cc: stable@vger.kernel.org [@nathanchance: fixed conflicts] Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Joe Maples <joe@frap129.org>
* dm cache: fix race causing dirty blocks to be marked as cleanAnssi Hannula2018-01-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a writeback or a promotion of a block is completed, the cell of that block is removed from the prison, the block is marked as clean, and the clear_dirty() callback of the cache policy is called. Unfortunately, performing those actions in this order allows an incoming new write bio for that block to come in before clearing the dirty status is completed and therefore possibly causing one of these two scenarios: Scenario A: Thread 1 Thread 2 cell_defer() . - cell removed from prison . - detained bios queued . . incoming write bio . remapped to cache . set_dirty() called, . but block already dirty . => it does nothing clear_dirty() . - block marked clean . - policy clear_dirty() called . Result: Block is marked clean even though it is actually dirty. No writeback will occur. Scenario B: Thread 1 Thread 2 cell_defer() . - cell removed from prison . - detained bios queued . clear_dirty() . - block marked clean . . incoming write bio . remapped to cache . set_dirty() called . - block marked dirty . - policy set_dirty() called - policy clear_dirty() called . Result: Block is properly marked as dirty, but policy thinks it is clean and therefore never asks us to writeback it. This case is visible in "dmsetup status" dirty block count (which normally decreases to 0 on a quiet device). Fix these issues by calling clear_dirty() before calling cell_defer(). Incoming bios for that block will then be detained in the cell and released only after clear_dirty() has completed, so the race will not occur. Found by inspecting the code after noticing spurious dirty counts (scenario B). Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Acked-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org [@nathanchance: fixed conflicts] Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Joe Maples <joe@frap129.org>
* dm cache: fix truncation bug when mapping I/O to >2TB fast deviceHeinz Mauelshagen2018-01-021-2/+3
| | | | | | | | | | | | | | | | | When remapping a block to the cache's fast device that is larger than 2TB we must not truncate the destination sector to 32bits. The 32bit temporary result of from_cblock() was being overflowed in remap_to_cache() due to the logical left shift. Use an intermediate 64bit type to store the 32bit from_cblock() result to fix the overflow. Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org [@nathanchance: fixed conflicts since no iters in 3.10] Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Joe Maples <joe@frap129.org>
* dm cache: fix race affecting dirty block countAnssi Hannula2018-01-021-7/+6
| | | | | | | | | | | | | | | | | | | | nr_dirty is updated without locking, causing it to drift so that it is non-zero (either a small positive integer, or a very large one when an underflow occurs) even when there are no actual dirty blocks. This was due to a race between the workqueue and map function accessing nr_dirty in parallel without proper protection. People were seeing under runs due to a race on increment/decrement of nr_dirty, see: https://lkml.org/lkml/2014/6/3/648 Fix this by using an atomic_t for nr_dirty. Reported-by: roma1390@gmail.com Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Joe Maples <joe@frap129.org>
* dm cache: add block sizes and total cache blocks to status outputMike Snitzer2018-01-021-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Improve cache_status to emit: <metadata block size> <#used metadata blocks>/<#total metadata blocks> <cache block size> <#used cache blocks>/<#total cache blocks> ... Adding the block sizes allows for easier calculation of the overall size of both the metadata and cache devices. Adding <#total cache blocks> provides useful context for how much of the cache is used. Unfortunately these additions to the status will require updates to users' scripts that monitor the cache status. But these changes help provide more comprehensive information about the cache device and will simplify tools that are being developed to manage dm-cache devices -- because they won't need to issue 3 operations to cobble together the information that we can easily provide via a single status ioctl. While updating the status documentation in cache.txt spaces were tabify'd. Requested-by: Jonathan Brassow <jbrassow@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Acked-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Joe Maples <joe@frap129.org>
* dm ioctl: remove double parenthesesMatthias Kaehlcke2018-01-021-2/+2
| | | | | | | | | | | The extra pair of parantheses is not needed and causes clang to generate warnings about the DM_DEV_CREATE_CMD comparison in validate_params(). Also remove another double parentheses that doesn't cause a warning. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Joe Maples <joe@frap129.org>
* WDT: Remove debug logAnmin Hsu2017-12-301-2/+2
| | | | | | | | | | | | | | | | | [Detail] Remove debug log while cpu hotplug to avoid the printk too much issue. [Solution] Remove debug log. [Feature] WDT MTK-Commit-Id: 7bb0f208667ef75ccda19c929dc2f2c4247f29f1 Change-Id: I381179bd043b33baeacc0ff3b3bb69f9167a1a43 Signed-off-by: Mac Lu <mac.lu@mediatek.com> CR-Id: ALPS02108996
* ANDROID: dm verity fec: initialize recursion levelSami Tolvanen2017-12-271-0/+1
| | | | | | | | | | Explicitly initialize recursion level to zero at the beginning of each I/O operation. Bug: 28943429 Change-Id: I00c612be2b8c22dd5afb65a739551df91cb324fc Signed-off-by: Sami Tolvanen <samitolvanen@google.com> (cherry picked from commit 32ffb3a22d7fd269b2961323478ece92c06a8334)
* ANDROID: dm verity fec: limit error correction recursionSami Tolvanen2017-12-272-1/+14
| | | | | | | | | | | | | | | | | | | | | | If verity tree itself is sufficiently corrupted in addition to data blocks, it's possible for error correction to end up in a deep recursive error correction loop that eventually causes a kernel panic as follows: [ 14.728962] [<ffffffc0008c1a14>] verity_fec_decode+0xa8/0x138 [ 14.734691] [<ffffffc0008c3ee0>] verity_verify_level+0x11c/0x180 [ 14.740681] [<ffffffc0008c482c>] verity_hash_for_block+0x88/0xe0 [ 14.746671] [<ffffffc0008c1508>] fec_decode_rsb+0x318/0x75c [ 14.752226] [<ffffffc0008c1a14>] verity_fec_decode+0xa8/0x138 [ 14.757956] [<ffffffc0008c3ee0>] verity_verify_level+0x11c/0x180 [ 14.763944] [<ffffffc0008c482c>] verity_hash_for_block+0x88/0xe0 This change limits the recursion to a reasonable level during a single I/O operation. Bug: 28943429 Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Change-Id: I0a7ebff331d259c59a5e03c81918cc1613c3a766 (cherry picked from commit f4b9e40597e73942d2286a73463c55f26f61bfa7)
* ANDROID: dm verity fec: add missing release from fec_ktypeSami Tolvanen2017-12-271-1/+2
| | | | | | | | | Add a release function to allow destroying the dm-verity device. Bug: 27928374 Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Change-Id: Ic0f7c17e4889c5580d70b52d9a709a37165a5747 (cherry picked from commit 0039ccf47c8f99888f7b71b2a36a68a027fbe357)
* ANDROID: dm: Mounting root as linear device when verity disabledBadhri Jagan Sridharan2017-12-273-23/+113
| | | | | | | | | 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 <Badhri@google.com>
* ANDROID: dm verity fec: add sysfs attribute fec/correctedSami Tolvanen2017-12-272-1/+47
| | | | | | | | | | | Add a sysfs entry that allows user space to determine whether dm-verity has come across correctable errors on the underlying block device. Bug: 22655252 Bug: 27928374 Change-Id: I80547a2aa944af2fb9ffde002650482877ade31b Signed-off-by: Sami Tolvanen <samitolvanen@google.com> (cherry picked from commit 7911fad5f0a2cf5afc2215657219a21e6630e001)
* ANDROID: dm: Add android verity targetBadhri Jagan Sridharan2017-12-276-8/+903
| | | | | | | | | | | | | | 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 <Badhri@google.com>
* CHROMIUM: dm: boot time specification of dm=Will Drewry2017-12-272-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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=2 Latest 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 <wad@chromium.org> Review URL: http://codereview.chromium.org/2020011 Change-Id: I92bd53432a11241228d2e5ac89a3b20d19b05a31
* dm verity: add ignore_zero_blocks featureSami Tolvanen2017-12-273-10/+89
| | | | | | | | | | | If ignore_zero_blocks is enabled dm-verity will return zeroes for blocks matching a zero hash without validating the content. Bug: 21893453 Change-Id: Ib9552f872bd82b1ba6a090686d2934a9551a3b48 Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> (cherry picked from commit 0b7462a60aad0c0819a138608c43998f3c46d6a8)
* dm verity: add support for forward error correctionSami Tolvanen2017-12-276-6/+1050
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for correcting corrupted blocks using Reed-Solomon. This code uses RS(255, N) interleaved across data and hash blocks. Each error-correcting block covers N bytes evenly distributed across the combined total data, so that each byte is a maximum distance away from the others. This makes it possible to recover from several consecutive corrupted blocks with relatively small space overhead. In addition, using verity hashes to locate erasures nearly doubles the effectiveness of error correction. Being able to detect corrupted blocks also improves performance, because only corrupted blocks need to corrected. For a 2 GiB partition, RS(255, 253) (two parity bytes for each 253-byte block) can correct up to 16 MiB of consecutive corrupted blocks if erasures can be located, and 8 MiB if they cannot, with 16 MiB space overhead. Bug: 21893453 Change-Id: Ib0372f49f45127e33bfe6b7182b0d608f56f3c7e Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> (cherry picked from commit a431c56bf1764448c12fd2d545b15466d552460c)
* dm verity: factor out verity_for_bv_block()Sami Tolvanen2017-12-272-27/+64
| | | | | | | | | | verity_for_bv_block() will be re-used by optional dm-verity object. Bug: 21893453 Change-Id: I82a3e6efdd95a488770a2fea6794befa8f5a35ce Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> (cherry picked from commit cce43a8a989fb5e245f5ca457e39edc22941c42e)
* dm verity: factor out structures and functions useful to separate objectSami Tolvanen2017-12-272-109/+134
| | | | | | | | | | | Prepare for an optional verity object to make use of existing dm-verity structures and functions. Bug: 21893453 Change-Id: I68b32d2a2ba044b73074410d9c8d916f44fb638d Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> (cherry picked from commit 212032ee8b4123dd001861e87fbde57084c3494e)
* dm verity: move dm-verity.c to dm-verity-target.cSami Tolvanen2017-12-272-0/+1
| | | | | | | | | | | Prepare for extending dm-verity with an optional object. Follows the naming convention used by other DM targets (e.g. dm-cache and dm-era). Bug: 21893453 Change-Id: If5e416de81b7f8e7a7e20fb9fcc723af19b8067d Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> (cherry picked from commit 13e0ef92e4308e5541d1abf462bf12d80545a516)
* dm verity: separate function for parsing opt argsSami Tolvanen2017-12-271-28/+43
| | | | | | | | | | | | Move optional argument parsing into a separate function to make it easier to add more of them without making verity_ctr even longer. Bug: 21893453 Change-Id: Iccc8d9de46674dedbcfbd8362a6048562af80be3 Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Mike Snitzer <snitzer@redhat.com> (cherry picked from commit e7f44b0ea4feabc1db477a8076553bea0969d7d4)
* dm verity: clean up duplicate hashing codeSami Tolvanen2017-12-271-116/+147
| | | | | | | | | | | Handle dm-verity salting in one place to simplify the code. Bug: 21893453 Change-Id: I09c5e81f88ba6a3bce0627f80458ad5571c724d0 Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Mike Snitzer <snitzer@redhat.com> (cherry picked from commit bbdba4c572104388ef687eb75f9655426a76d338)
* dm verity: port upstream changes to 3.10Sami Tolvanen2017-12-271-29/+73
| | | | | | | | | | Upstream dm-verity has different optional parameters. Port back the relevant changes. Bug: 21893453 Change-Id: I5431388e041d6829ad60d2c86dd113210ba6aff7 Signed-off-by: Sami Tolvanen <samitolvanen@google.com> (cherry picked from commit 82cdd95a61c921c3c3063178c272b251573b596f)
* dm-verity: Add modes and emit uevent on corrupted blocksSami Tolvanen2017-12-271-9/+89
| | | | | | | | | | | | | | | | | | | | | | | Add a device specific mode to dm-verity for handling corrupted blocks: DM_VERITY_MODE_EIO is the default behavior, where reading a corrupted block results in -EIO. DM_VERITY_MODE_LOGGING only logs corrupted blocks, but does not block the read. DM_VERITY_MODE_RESTART calls kernel_restart when a corrupted block is discovered. Each mode sends a uevent to notify userspace of corruption and allow further recovery actions. Defaults to previous behavior, other modes can be enabled with an optional parameter added to the verity table. Change-Id: Ib72ae6ccb865594d28f3553bdcc5a40b1d7af390 Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
* dm: Stop the dm_request calls in idleAnilKumar Chimata2017-12-271-1/+1
| | | | | | | | | Even if there are no pending peek work, dm layer trying to schedule the work with 10ms time delay. This patch fixes the issue by putting back the table entry. Change-Id: I0e5df117fae74ae37a621862f254220706f0d840 Signed-off-by: AnilKumar Chimata <anilc@codeaurora.org>
* UPSTREAM: block: disable entropy contributions for nonrot devicesMike Snitzer2017-12-2711-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | (cherry picked from commit b277da0a8a594308e17881f4926879bd5fca2a2d) Clear QUEUE_FLAG_ADD_RANDOM in all block drivers that set QUEUE_FLAG_NONROT. Historically, all block devices have automatically made entropy contributions. But as previously stated in commit e2e1a148 ("block: add sysfs knob for turning off disk entropy contributions"): - On SSD disks, the completion times aren't as random as they are for rotational drives. So it's questionable whether they should contribute to the random pool in the first place. - Calling add_disk_randomness() has a lot of overhead. There are more reliable sources for randomness than non-rotational block devices. From a security perspective it is better to err on the side of caution than to allow entropy contributions from unreliable "random" sources. Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Mister Oyster <oysterized@gmail.com>
* dm-crypt: remove io_poolMikulas Patocka2017-12-271-20/+1
| | | | | | | | | | Remove io_pool and _crypt_io_pool because they are unused. CRs-fixed: 670391 Change-Id: I71400ecda66902c56c3af981e8b739f156db1e27 Signed-off-by: Mikulas Patocka <mpatock@redhat.com> Patch-mainline: dm-devel @ 04/05/14, 14:08 Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
* dm-crypt: sort writesMikulas Patocka2017-12-271-15/+35
| | | | | | | | | | | | | | | Write requests are sorted in a red-black tree structure and are submitted in the sorted order. In theory the sorting should be performed by the underlying disk scheduler, however, in practice the disk scheduler accepts and sorts only 128 requests. In order to sort more requests, we need to implement our own sorting. CRs-fixed: 670391 Change-Id: Iffd9345fa1253f5cf2a556893ed36e08f1ac51aa Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Patch-mainline: dm-devel @ 04/05/14, 14:09 Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
* dm-crypt: offload writes to threadMikulas Patocka2017-12-271-23/+97
| | | | | | | | | | | | | | | | | | | | | | | Submitting write bios directly in the encryption thread caused serious performance degradation. On multiprocessor machine encryption requests finish in a different order than they were submitted in. Consequently, write requests would be submitted in a different order and it could cause severe performance degradation. This patch moves submitting write requests to a separate thread so that the requests can be sorted before submitting. Sorting is implemented in the next patch. Note: it is required that a previous patch "dm-crypt: don't allocate pages for a partial request." is applied before applying this patch. Without that, this patch could introduce a crash. CRs-fixed: 670391 Change-Id: I886ed2da0ff174d3539ea18e27170d7fd1062680 Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Patch-mainline: dm-devel @ 04/05/14, 14:08 Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
* dm-crypt: avoid deadlock in mempoolsMikulas Patocka2017-12-271-5/+36
| | | | | | | | | | | | | | | | | | | | | | This patch fixes a theoretical deadlock introduced in the previous patch. The function crypt_alloc_buffer may be called concurrently. If we allocate from the mempool concurrently, there is a possibility of deadlock. For example, if we have mempool of 256 pages, two processes, each wanting 256, pages allocate from the mempool concurrently, it may deadlock in a situation where both processes have allocated 128 pages and the mempool is exhausted. In order to avoid this scenarios, we allocate the pages under a mutex. In order to not degrade performance with excessive locking, we try non-blocking allocations without a mutex first and if it fails, we fallback to a blocking allocation with a mutex. CRs-fixed: 670391 Change-Id: I6c391dece4ba44fe0b2e9b75ea2b9235bf1b525b Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Patch-mainline: dm-devel @ 04/05/14, 14:07 Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
* dm-crypt: don't allocate pages for a partial requestMikulas Patocka2017-12-271-110/+29
| | | | | | | | | | | | | | | | | This patch changes crypt_alloc_buffer so that it always allocates pages for a full request. This change enables further simplification and removing of one refcounts in the next patches. Note: the next patch is needed to fix a theoretical deadlock CRs-fixed: 670391 Change-Id: I7bcadac8b3450976366c701fceb1fee7cb18df85 Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> [joonwoop@codeaurora.org: resolve trivial merge conflicts] Patch-mainline: dm-devel @ 04/05/14, 14:07 Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-03-15 08:04:56 +0000