aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* ext4: fix deadlock between inline_data and ext4_expand_extra_isize_ea()Theodore Ts'o2017-12-313-54/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The xattr_sem deadlock problems fixed in commit 2e81a4eeedca: "ext4: avoid deadlock when expanding inode size" didn't include the use of xattr_sem in fs/ext4/inline.c. With the addition of project quota which added a new extra inode field, this exposed deadlocks in the inline_data code similar to the ones fixed by 2e81a4eeedca. The deadlock can be reproduced via: dmesg -n 7 mke2fs -t ext4 -O inline_data -Fq -I 256 /dev/vdc 32768 mount -t ext4 -o debug_want_extra_isize=24 /dev/vdc /vdc mkdir /vdc/a umount /vdc mount -t ext4 /dev/vdc /vdc echo foo > /vdc/a/foo and looks like this: [ 11.158815] [ 11.160276] ============================================= [ 11.161960] [ INFO: possible recursive locking detected ] [ 11.161960] 4.10.0-rc3-00015-g011b30a8a3cf #160 Tainted: G W [ 11.161960] --------------------------------------------- [ 11.161960] bash/2519 is trying to acquire lock: [ 11.161960] (&ei->xattr_sem){++++..}, at: [<c1225a4b>] ext4_expand_extra_isize_ea+0x3d/0x4cd [ 11.161960] [ 11.161960] but task is already holding lock: [ 11.161960] (&ei->xattr_sem){++++..}, at: [<c1227941>] ext4_try_add_inline_entry+0x3a/0x152 [ 11.161960] [ 11.161960] other info that might help us debug this: [ 11.161960] Possible unsafe locking scenario: [ 11.161960] [ 11.161960] CPU0 [ 11.161960] ---- [ 11.161960] lock(&ei->xattr_sem); [ 11.161960] lock(&ei->xattr_sem); [ 11.161960] [ 11.161960] *** DEADLOCK *** [ 11.161960] [ 11.161960] May be due to missing lock nesting notation [ 11.161960] [ 11.161960] 4 locks held by bash/2519: [ 11.161960] #0: (sb_writers#3){.+.+.+}, at: [<c11a2414>] mnt_want_write+0x1e/0x3e [ 11.161960] #1: (&type->i_mutex_dir_key){++++++}, at: [<c119508b>] path_openat+0x338/0x67a [ 11.161960] #2: (jbd2_handle){++++..}, at: [<c123314a>] start_this_handle+0x582/0x622 [ 11.161960] #3: (&ei->xattr_sem){++++..}, at: [<c1227941>] ext4_try_add_inline_entry+0x3a/0x152 [ 11.161960] [ 11.161960] stack backtrace: [ 11.161960] CPU: 0 PID: 2519 Comm: bash Tainted: G W 4.10.0-rc3-00015-g011b30a8a3cf #160 [ 11.161960] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1 04/01/2014 [ 11.161960] Call Trace: [ 11.161960] dump_stack+0x72/0xa3 [ 11.161960] __lock_acquire+0xb7c/0xcb9 [ 11.161960] ? kvm_clock_read+0x1f/0x29 [ 11.161960] ? __lock_is_held+0x36/0x66 [ 11.161960] ? __lock_is_held+0x36/0x66 [ 11.161960] lock_acquire+0x106/0x18a [ 11.161960] ? ext4_expand_extra_isize_ea+0x3d/0x4cd [ 11.161960] down_write+0x39/0x72 [ 11.161960] ? ext4_expand_extra_isize_ea+0x3d/0x4cd [ 11.161960] ext4_expand_extra_isize_ea+0x3d/0x4cd [ 11.161960] ? _raw_read_unlock+0x22/0x2c [ 11.161960] ? jbd2_journal_extend+0x1e2/0x262 [ 11.161960] ? __ext4_journal_get_write_access+0x3d/0x60 [ 11.161960] ext4_mark_inode_dirty+0x17d/0x26d [ 11.161960] ? ext4_add_dirent_to_inline.isra.12+0xa5/0xb2 [ 11.161960] ext4_add_dirent_to_inline.isra.12+0xa5/0xb2 [ 11.161960] ext4_try_add_inline_entry+0x69/0x152 [ 11.161960] ext4_add_entry+0xa3/0x848 [ 11.161960] ? __brelse+0x14/0x2f [ 11.161960] ? _raw_spin_unlock_irqrestore+0x44/0x4f [ 11.161960] ext4_add_nondir+0x17/0x5b [ 11.161960] ext4_create+0xcf/0x133 [ 11.161960] ? ext4_mknod+0x12f/0x12f [ 11.161960] lookup_open+0x39e/0x3fb [ 11.161960] ? __wake_up+0x1a/0x40 [ 11.161960] ? lock_acquire+0x11e/0x18a [ 11.161960] path_openat+0x35c/0x67a [ 11.161960] ? sched_clock_cpu+0xd7/0xf2 [ 11.161960] do_filp_open+0x36/0x7c [ 11.161960] ? _raw_spin_unlock+0x22/0x2c [ 11.161960] ? __alloc_fd+0x169/0x173 [ 11.161960] do_sys_open+0x59/0xcc [ 11.161960] SyS_open+0x1d/0x1f [ 11.161960] do_int80_syscall_32+0x4f/0x61 [ 11.161960] entry_INT80_32+0x2f/0x2f [ 11.161960] EIP: 0xb76ad469 [ 11.161960] EFLAGS: 00000286 CPU: 0 [ 11.161960] EAX: ffffffda EBX: 08168ac8 ECX: 00008241 EDX: 000001b6 [ 11.161960] ESI: b75e46bc EDI: b7755000 EBP: bfbdb108 ESP: bfbdafc0 [ 11.161960] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b Cc: stable@vger.kernel.org # 3.10 (requires 2e81a4eeedca as a prereq) Reported-by: George Spelvin <linux@sciencehorizons.net> Signed-off-by: Theodore Ts'o <tytso@mit.edu> 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
* BACKPORT: audit: consistently record PIDs with task_tgid_nr()Paul Moore2017-12-283-9/+15
| | | | | | | | | | | | | | | | | Unfortunately we record PIDs in audit records using a variety of methods despite the correct way being the use of task_tgid_nr(). This patch converts all of these callers, except for the case of AUDIT_SET in audit_receive_msg() (see the comment in the code). Reported-by: Jeff Vander Stoep <jeffv@google.com> Signed-off-by: Paul Moore <paul@paul-moore.com> Bug: 28952093 (cherry picked from commit fa2bea2f5cca5b8d4a3e5520d2e8c0ede67ac108) Signed-off-by: Jeff Vander Stoep <jeffv@google.com> Change-Id: I36508a25c957f5108299e68a3b0f627c94eb27eb Signed-off-by: Joe Maples <joe@frap129.org>
* crypto: remove duplicate impl.Mister Oyster2017-12-279-4232/+0
| | | | | | | | | | Revert "crypto: arm64/sha2 - add generated .S files to .gitignore" This reverts commit 9345ccbf273209e3946c3981122d068221a135d2. Revert "crypto: arm64/sha2 - integrate OpenSSL implementations of SHA256/SHA512" This reverts commit 02ea19edc643061fab3b6ea8bd54b96110a9f43b.
* defconfig: enable CRC32_ARM64 algoMister Oyster2017-12-271-1/+1
|
* 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-279-0/+516
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-274-10/+94
| | | | | | | | | | | 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-277-6/+1075
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-272-38/+89
| | | | | | | | | | 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-272-10/+100
| | | | | | | | | | | | | | | | | | | | | | | 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>
* dm-crypt: use per-bio dataMikulas Patocka2017-12-271-14/+26
| | | | | | | | | | | | | | | | | | | | | | | This patch changes dm-crypt so that it uses auxiliary data allocated with the bio. Dm-crypt requires two allocations per request - struct dm_crypt_io and struct ablkcipher_request (with other data appended to it). It used mempool for the allocation. Some requests may require more dm_crypt_ios and ablkcipher_requests, however most requests need just one of each of these two structures to complete. This patch changes it so that the first dm_crypt_io and ablkcipher_request and allocated with the bio (using target per_bio_data_size option). If the request needs additional values, they are allocated from the mempool. CRs-fixed: 670391 Change-Id: I8abc48a021391398f3b35bdd4ac9efbbec3a9fa5 Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Patch-mainline: dm-devel @ 04/05/14, 14:05 Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
* dm-crypt: run in a WQ_HIGHPRI workqueueTim Murray2017-12-271-1/+3
| | | | | | | | | | | Running dm-crypt in a standard workqueue results in IO competing for CPU time with standard user apps, which can lead to pipeline bubbles and seriously degraded performance. Move to a WQ_HIGHPRI workqueue to protect against that. bug 25392275 Change-Id: I589149a31c7b5d322fe2ed5b2476b1f6e3d5ee6f
* dm-crypt: use unbound workqueue for request processingMikulas Patocka2017-12-271-4/+2
| | | | | | | | | | | | Use unbound workqueue so that work is automatically ballanced between available CPUs. CRs-fixed: 670391 Change-Id: I169099d0b5b27535633c9d3aaab2037b5fea6aa9 Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> [joonwoop@codeaurora.org: resolve trivial merge conflict] Patch-mainline: dm-devel @ 04/05/14, 14:06 Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
* arm64: dts: add DT entry to mount /system early during bootfire8552017-12-273-0/+51
| | | | | | BaCkPoRtEd To 3.10 By ThE BigGeSt MidGeT iN tHe GaMe Signed-off-by: Mister Oyster <oysterized@gmail.com>
* defconfig: regen and disable MTK_PASSPOINT_R1_SUPPORTMister Oyster2017-12-271-2/+1
|
* fsync: __FUNCTION__ > __func__ & indentation cleanupMister Oyster2017-12-261-19/+17
|
* scripts/recordmcount.pl: There is no -m32 gcc option on Super-H anymoreMichael Karcher2017-12-261-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | commit 1caf6aaaa47471831d77c75f094d4e00ad1ec808 upstream. Compiling SH with gcc-4.8 fails due to the -m32 option not being supported. From http://buildd.debian-ports.org/status/fetch.php?pkg=linux&arch=sh4&ver=3.16.7-ckt4-1&stamp=1421425783 CC init/main.o gcc-4.8: error: unrecognized command line option '-m32' ld: cannot find init/.tmp_mc_main.o: No such file or directory objcopy: 'init/.tmp_mx_main.o': No such file rm: cannot remove 'init/.tmp_mx_main.o': No such file or directory rm: cannot remove 'init/.tmp_mc_main.o': No such file or directory Link: http://lkml.kernel.org/r/1421537778-29001-1-git-send-email-kernel@mkarcher.dialup.fu-berlin.de Link: http://lkml.kernel.org/r/54BCBDD4.10102@physik.fu-berlin.de Cc: Matt Fleming <matt@console-pimps.org> Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* modpost: remove all traces of cpuinit/cpuexit sectionsPaul Gortmaker2017-12-262-55/+9
| | | | | | | | | | | | | | Delete all audit rules that were checking how the .cpuXYZ related sections were inter-operating with other __init like sections, now that __cpuinit is gone. Update the linker script to not have any knowledge of .cpuinit sections. [lds.h update courtesy of Ralf Baechle <ralf@linux-mips.org>] Cc: Arnd Bergmann <arnd@arndb.de> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Joe Maples <joe@frap129.org>
* vfs: conditionally clear close-on-exec flagLinus Torvalds2017-12-261-1/+2
| | | | | | | | | | | | | | | | | We clear the close-on-exec flag when opening and closing files, and the bit was almost always already clear before. Avoid dirtying the cacheline if the clearning isn't necessary. That avoids unnecessary cacheline dirtying and bouncing in multi-socket environments. Eric Dumazet has a file descriptor benchmark that goes 4% faster from this on his two-socket machine. It's probably partly superlinear improvement due to getting slightly less spinlock contention on the file_lock spinlock due to less work in the critical section. Tested-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com> Signed-off-by: Joe Maples <joe@frap129.org>
* vfs: Fix pathological performance case for __alloc_fd()Linus Torvalds2017-12-262-4/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | Al Viro points out that: > > * [Linux-specific aside] our __alloc_fd() can degrade quite badly > > with some use patterns. The cacheline pingpong in the bitmap is probably > > inevitable, unless we accept considerably heavier memory footprint, > > but we also have a case when alloc_fd() takes O(n) and it's _not_ hard > > to trigger - close(3);open(...); will have the next open() after that > > scanning the entire in-use bitmap. And Eric Dumazet has a somewhat realistic multithreaded microbenchmark that opens and closes a lot of sockets with minimal work per socket. This patch largely fixes it. We keep a 2nd-level bitmap of the open file bitmaps, showing which words are already full. So then we can traverse that second-level bitmap to efficiently skip already allocated file descriptors. On his benchmark, this improves performance by up to an order of magnitude, by avoiding the excessive open file bitmap scanning. Tested-and-acked-by: Eric Dumazet <edumazet@google.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com> Signed-off-by: Joe Maples <joe@frap129.org>
* perf: Use hrtimers for event multiplexingStephane Eranian2017-12-263-9/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current scheme of using the timer tick was fine for per-thread events. However, it was causing bias issues in system-wide mode (including for uncore PMUs). Event groups would not get their fair share of runtime on the PMU. With tickless kernels, if a core is idle there is no timer tick, and thus no event rotation (multiplexing). However, there are events (especially uncore events) which do count even though cores are asleep. This patch changes the timer source for multiplexing. It introduces a per-PMU per-cpu hrtimer. The advantage is that even when a core goes idle, it will come back to service the hrtimer, thus multiplexing on system-wide events works much better. The per-PMU implementation (suggested by PeterZ) enables adjusting the multiplexing interval per PMU. The preferred interval is stashed into the struct pmu. If not set, it will be forced to the default interval value. In order to minimize the impact of the hrtimer, it is turned on and off on demand. When the PMU on a CPU is overcommited, the hrtimer is activated. It is stopped when the PMU is not overcommitted. In order for this to work properly, we had to change the order of initialization in start_kernel() such that hrtimer_init() is run before perf_event_init(). The default interval in milliseconds is set to a timer tick just like with the old code. We will provide a sysctl to tune this in another patch. Signed-off-by: Stephane Eranian <eranian@google.com> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Link: http://lkml.kernel.org/r/1364991694-5876-2-git-send-email-eranian@google.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: mydongistiny <jaysonedson@gmail.com> Signed-off-by: Joe Maples <joe@frap129.org>
* cpu: Defer smpboot kthread unparking until CPU known to schedulerPaul E. McKenney2017-12-263-3/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, smpboot_unpark_threads() is invoked before the incoming CPU has been added to the scheduler's runqueue structures. This might potentially cause the unparked kthread to run on the wrong CPU, since the correct CPU isn't fully set up yet. That causes a sporadic, hard to debug boot crash triggering on some systems, reported by Borislav Petkov, and bisected down to: 2a442c9c6453 ("x86: Use common outgoing-CPU-notification code") This patch places smpboot_unpark_threads() in a CPU hotplug notifier with priority set so that these kthreads are unparked just after the CPU has been added to the runqueues. Change-Id: I8921987de9c2a2f475cc63dc82662d6ebf6e8725 Reported-and-tested-by: Borislav Petkov <bp@suse.de> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> Git-commit: 00df35f991914db6b8bde8cf09808e19a9cffc3d Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Signed-off-by: Matt Wagantall <mattw@codeaurora.org> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com> Signed-off-by: Joe Maples <joe@frap129.org>
* fs: xattr: Use kvfree()Richard Weinberger2017-12-261-24/+14
| | | | | | | | ... instead of open coding it. Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Joe Maples <joe@frap129.org>
* fs/xattr.c: zero out memory copied to userspace in getxattrMichal Hocko2017-12-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | commit 81be3dee96346fbe08c31be5ef74f03f6b63cf68 upstream. getxattr uses vmalloc to allocate memory if kzalloc fails. This is filled by vfs_getxattr and then copied to the userspace. vmalloc, however, doesn't zero out the memory so if the specific implementation of the xattr handler is sloppy we can theoretically expose a kernel memory. There is no real sign this is really the case but let's make sure this will not happen and use vzalloc instead. Fixes: 779302e67835 ("fs/xattr.c:getxattr(): improve handling of allocation failures") Link: http://lkml.kernel.org/r/20170306103327.2766-1-mhocko@kernel.org Acked-by: Kees Cook <keescook@chromium.org> Reported-by: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com> Signed-off-by: Joe Maples <joe@frap129.org>
* initramfs: avoid "label at end of compound statement" errorLinus Torvalds2017-12-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Commit 17a9be317475 ("initramfs: Always do fput() and load modules after rootfs populate") introduced an error for the CONFIG_BLK_DEV_RAM=y case, because even though the code looks fine, the compiler really wants a statement after a label, or you'll get complaints: init/initramfs.c: In function 'populate_rootfs': init/initramfs.c:644:2: error: label at end of compound statement That commit moved the subsequent statements to outside the compound statement, leaving the label without any associated statements. Reported-by: Jörg Otte <jrg.otte@gmail.com> Fixes: 17a9be317475 ("initramfs: Always do fput() and load modules after rootfs populate") Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Stafford Horne <shorne@gmail.com> Cc: stable@vger.kernel.org # if 17a9be317475 gets backported Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Joe Maples <joe@frap129.org>
* init: Move stack canary initialization after setup_archLaura Abbott2017-12-261-5/+4
| | | | | | | | | | | Stack canary intialization involves getting a random number. Getting this random number may involve accessing caches or other architectural specific features which are not available until after the architecture is setup. Move the stack canary initialization later to accomodate this. Change-Id: I00b564a2c3172229a44339c061fa380c17fe7d8e Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
* init: apply SCHED_FIFO to kthreaddSteve Muckle2017-12-261-0/+2
| | | | | | | | | | | | | | | | | | Hotplug (cpu_up) latency currently suffers because the system must wait for kthreadd to spawn certain kthreads (such as the migration and workqueue kthreads) and for them to run for the first time. Setting SCHED_FIFO will cause kthreadd to run immediately. The newly created kthreads will inherit the scheduler policy and run immediately also. The scheduling policy of newly created kthreads is already set back to SCHED_NORMAL in kthread_create_on_node, so nothing needs to be done to restore normal scheduling behavior for the kthreads once spawned. Change-Id: I236ceb29845cf58ea1ea886fc3210ccaab2dd792 Signed-off-by: Steve Muckle <smuckle@codeaurora.org> (cherry picked from commit 82440737eef236077e5781061b4c8de2c0b013fb)
* readahead: Fix an error (thx ramgear)hellsgod2017-12-261-2/+2
| | | | Signed-off-by: Joe Maples <joe@frap129.org>
* Readahead: Optimize divide/multiply by power of 2 using L/R shift (thx ramgear)hellsgod2017-12-261-10/+10
| | | | Signed-off-by: Joe Maples <joe@frap129.org>
* UPSTREAM: arm64: jump labels: NOP out NOP -> NOP replacementMark Rutland2017-12-251-14/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the arm64 arch_static_branch implementation we place an A64 NOP into the instruction stream and log relevant details to a jump_entry in a __jump_table section. Later this may be replaced with an immediate branch without link to the code for the unlikely case. At init time, the core calls arch_jump_label_transform_static to initialise the NOPs. On x86 this involves inserting the optimal NOP for a given microarchitecture, but on arm64 we only use the architectural NOP, and hence replace each NOP with the exact same NOP. This is somewhat pointless. Additionally, at module load time we don't call jump_label_apply_nops to patch the optimal NOPs in, unlike other architectures, but get away with this because we only use the architectural NOP anyway. A later notifier will patch NOPs with branches as required. Similarly to x86 commit 11570da1c5b1dee1 (x86/jump-label: Do not bother updating NOPs if they are correct), we can avoid patching NOPs with identical NOPs. Given that we only use a single NOP encoding, this means we can NOP-out the body of arch_jump_label_transform_static entirely. As the default __weak arch_jump_label_transform_static implementation performs a patch, we must use an empty function to achieve this. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Jiang Liu <liuj97@gmail.com> Cc: Laura Abbott <lauraa@codeaurora.org> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit 6ddae4186886a81e22ad78ad7c6936ed36bc8225) Signed-off-by: Tomasz Figa <tfiga@chromium.org> Bug: 24475017 Change-Id: I9ef07c3a5a7f91418b30006850fcc0c421e147e2 Signed-off-by: Kees Cook <keescook@google.com> Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com> Signed-off-by: Joe Maples <joe@frap129.org>
* arm64: use the new *_relaxed macros for lower power usagefranciscofranco2017-12-2517-39/+42
| | | | | | Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com> Signed-off-by: Joe Maples <joe@frap129.org> Signed-off-by: Mister Oyster <oysterized@gmail.com>
* lib: clean up put_cpu_var usageShaohua Li2017-12-251-2/+2
| | | | | | | | | | | | | put_cpu_var takes the percpu data, not the data returned from get_cpu_var. This doesn't change the behavior. Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Shaohua Li <shli@fb.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Joe Maples <joe@frap129.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-03-17 05:54:27 +0000