- 28 Dec, 2018 40 commits
-
-
Sean Christopherson authored
Contrary to its name, mmu_notifier_synchronize() does not synchronize the notifier's SRCU instance, but rather waits for RCU callbacks to finish. i.e. it invokes rcu_barrier(). The RCU documentation is quite clear on this matter, explicitly calling out that rcu_barrier() does not imply synchronize_rcu(). As there are no callers of mmu_notifier_synchronize() and it's unclear whether any user of mmu_notifier_call_srcu() will ever want to barrier on their callbacks, simply remove the function. Link: http://lkml.kernel.org/r/20181106134705.14197-1-sean.j.christopherson@intel.comSigned-off-by:
Sean Christopherson <sean.j.christopherson@intel.com> Reviewed-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Jérôme Glisse <jglisse@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Balbir Singh authored
In hot remove, we try to clear poisoned pages, but a small optimization to check if num_poisoned_pages is 0 helps remove the iteration through nr_pages. [akpm@linux-foundation.org: tweak comment text] Link: http://lkml.kernel.org/r/20181102120001.4526-1-bsingharora@gmail.comSigned-off-by:
Balbir Singh <bsingharora@gmail.com> Acked-by:
Michal Hocko <mhocko@suse.com> Acked-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Signed-off-by:
-
Miles Chen authored
The (root-only) page owner read might allocate a large size of memory with a large read count. Allocation fails can easily occur when doing high order allocations. Clamp buffer size to PAGE_SIZE to avoid arbitrary size allocation and avoid allocation fails due to high order allocation. [akpm@linux-foundation.org: use min_t()] Link: http://lkml.kernel.org/r/1541091607-27402-1-git-send-email-miles.chen@mediatek.comSigned-off-by:
Miles Chen <miles.chen@mediatek.com> Acked-by:
-
Vlastimil Babka authored
Multiple people have reported the following sparse warning: ./include/linux/slab.h:332:43: warning: dubious: x & !y The minimal fix would be to change the logical & to boolean &&, which emits the same code, but Andrew has suggested that the branch-avoiding tricks are maybe not worthwile. David Laight provided a nice comparison of disassembly of multiple variants, which shows that the current version produces a 4 deep dependency chain, and fixing the sparse warning by changing logical and to multiplication emits an IMUL, making it even more expensive. The code as rewritten by this patch yielded the best disassembly, with a single predictable branch for the most common case, and a ternary operator for the rest, which gcc seems to compile without a branch or cmov by itself. The result should be more readable, without a sparse warning and probably also faster for the common case. Link: http://lkml.kernel.org/r/80340595-d7c5-97b9-4f6c-23fa893a91e9@suse.cz Fixes: 1291523f ("mm, slab/slub: introduce kmalloc-reclaimable caches") Reviewed-by:
Vlastimil Babka <vbabka@suse.cz> Reported-by:
Bart Van Assche <bvanassche@acm.org> Reported-by:
Darryl T. Agostinelli <dagostinelli@gmail.com> Reported-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Suggested-by:
David Laight <David.Laight@ACULAB.COM> Signed-off-by:
-
Wei Yang authored
If __cmpxchg_double_slab() fails and (l != m), current code records transition states of slub action. Update the action after __cmpxchg_double_slab() success to record the final state. [akpm@linux-foundation.org: more whitespace cleanup] Link: http://lkml.kernel.org/r/20181107013119.3816-1-richard.weiyang@gmail.comSigned-off-by:
Wei Yang <richard.weiyang@gmail.com> Reviewed-by:
-
Wei Yang authored
node_match() is a static function and is only invoked in slub.c. In all three places, `page' is ensured to be valid. Link: http://lkml.kernel.org/r/20181106150245.1668-1-richard.weiyang@gmail.comSigned-off-by:
Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Signed-off-by:
-
Wei Yang authored
cpu_slab is a per cpu variable which is allocated in all or none. If a cpu_slab failed to be allocated, the slub is not usable. We could use cpu_slab without validation in __flush_cpu_slab(). Link: http://lkml.kernel.org/r/20181103141218.22844-1-richard.weiyang@gmail.comSigned-off-by:
-
Yangtao Li authored
WARN_ON() already contains an unlikely(), so it's not necessary to use unlikely. Also change WARN_ON() back to WARN_ON_ONCE() to avoid potentially spamming dmesg with user-triggerable large allocations. [akpm@linux-foundation.org: s/WARN_ON/WARN_ON_ONCE/, per Vlastimil] Link: http://lkml.kernel.org/r/20181104125028.3572-1-tiny.windzz@gmail.comSigned-off-by:
Yangtao Li <tiny.windzz@gmail.com> Acked-by:
David Rientjes <rientjes@google.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
Junxiao Bi authored
For sync io read in ocfs2_read_blocks_sync(), first clear bh uptodate flag and submit the io, second wait io done, last check whether bh uptodate, if not return io error. If two sync io for the same bh were issued, it could be the first io done and set uptodate flag, but just before check that flag, the second io came in and cleared uptodate, then ocfs2_read_blocks_sync() for the first io will return IO error. Indeed it's not necessary to clear uptodate flag, as the io end handler end_buffer_read_sync() will set or clear it based on io succeed or failed. The following message was found from a nfs server but the underlying storage returned no error. [4106438.567376] (nfsd,7146,3):ocfs2_get_suballoc_slot_bit:2780 ERROR: read block 1238823695 failed -5 [4106438.567569] (nfsd,7146,3):ocfs2_get_suballoc_slot_bit:2812 ERROR: status = -5 [4106438.567611] (nfsd,7146,3):ocfs2_test_inode_bit:2894 ERROR: get alloc slot and bit failed -5 [4106438.567643] (nfsd,7146,3):ocfs2_test_inode_bit:2932 ERROR: status = -5 [4106438.567675] (nfsd,7146,3):ocfs2_get_dentry:94 ERROR: test inode bit failed -5 Same issue in non sync read ocfs2_read_blocks(), fixed it as well. Link: http://lkml.kernel.org/r/20181121020023.3034-4-junxiao.bi@oracle.comSigned-off-by:
Junxiao Bi <junxiao.bi@oracle.com> Reviewed-by:
Changwei Ge <ge.changwei@h3c.com> Reviewed-by:
Yiwen Jiang <jiangyiwen@huawei.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Joseph Qi <jiangqi903@gmail.com> Cc: Jun Piao <piaojun@huawei.com> Cc: Mark Fasheh <mfasheh@versity.com> Signed-off-by:
-
Junxiao Bi authored
Dirty flag of the journal should be cleared at the last stage of umount, if do it before jbd2_journal_destroy(), then some metadata in uncommitted transaction could be lost due to io error, but as dirty flag of journal was already cleared, we can't find that until run a full fsck. This may cause system panic or other corruption. Link: http://lkml.kernel.org/r/20181121020023.3034-3-junxiao.bi@oracle.comSigned-off-by:
Joseph Qi <jiangqi903@gmail.com> Cc: Jun Piao <piaojun@huawei.com> Cc: Changwei Ge <ge.changwei@h3c.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Mark Fasheh <mfasheh@versity.com> Signed-off-by:
-
Junxiao Bi authored
mount.ocfs2 ignore the inconsistent error that journal is clean but local alloc is unrecovered. After mount, local alloc not empty, then reserver cluster didn't alloc a new local alloc window, reserveration map is empty(ocfs2_reservation_map.m_bitmap_len = 0), that triggered the following panic. This issue was reported at https://oss.oracle.com/pipermail/ocfs2-devel/2015-May/010854.html and was advised to fixed during mount. But this is a very unusual inconsistent state, usually journal dirty flag should be cleared at the last stage of umount until every other things go right. We may need do further debug to check that. Any way to avoid possible futher corruption, mount should be abort and fsck should be run. (mount.ocfs2,1765,1):ocfs2_load_local_alloc:353 ERROR: Local alloc hasn't been recovered! found = 6518, set = 6518, taken = 8192, off = 15912372 ocfs2: Mounting device (202,64) on (node 0, slot 3) with ordered data mode. o2dlm: Joining domain 89CEAC63CC4F4D03AC185B44E0EE0F3F ( 0 1 2 3 4 5 6 8 ) 8 nodes ocfs2: Mounting device (202,80) on (node 0, slot 3) with ordered data mode. o2hb: Region 89CEAC63CC4F4D03AC185B44E0EE0F3F (xvdf) is now a quorum device o2net: Accepted connection from node yvwsoa17p (num 7) at 172.22.77.88:7777 o2dlm: Node 7 joins domain 64FE421C8C984E6D96ED12C55FEE2435 ( 0 1 2 3 4 5 6 7 8 ) 9 nodes o2dlm: Node 7 joins domain 89CEAC63CC4F4D03AC185B44E0EE0F3F ( 0 1 2 3 4 5 6 7 8 ) 9 nodes ------------[ cut here ]------------ kernel BUG at fs/ocfs2/reservations.c:507! invalid opcode: 0000 [#1] SMP Modules linked in: ocfs2 rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs fscache lockd grace ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sunrpc ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 ovmapi ppdev parport_pc parport xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea acpi_cpufreq pcspkr i2c_piix4 i2c_core sg ext4 jbd2 mbcache2 sr_mod cdrom xen_blkfront pata_acpi ata_generic ata_piix floppy dm_mirror dm_region_hash dm_log dm_mod CPU: 0 PID: 4349 Comm: startWebLogic.s Not tainted 4.1.12-124.19.2.el6uek.x86_64 #2 Hardware name: Xen HVM domU, BIOS 4.4.4OVM 09/06/2018 task: ffff8803fb04e200 ti: ffff8800ea4d8000 task.ti: ffff8800ea4d8000 RIP: 0010:[<ffffffffa05e96a8>] [<ffffffffa05e96a8>] __ocfs2_resv_find_window+0x498/0x760 [ocfs2] Call Trace: ocfs2_resmap_resv_bits+0x10d/0x400 [ocfs2] ocfs2_claim_local_alloc_bits+0xd0/0x640 [ocfs2] __ocfs2_claim_clusters+0x178/0x360 [ocfs2] ocfs2_claim_clusters+0x1f/0x30 [ocfs2] ocfs2_convert_inline_data_to_extents+0x634/0xa60 [ocfs2] ocfs2_write_begin_nolock+0x1c6/0x1da0 [ocfs2] ocfs2_write_begin+0x13e/0x230 [ocfs2] generic_perform_write+0xbf/0x1c0 __generic_file_write_iter+0x19c/0x1d0 ocfs2_file_write_iter+0x589/0x1360 [ocfs2] __vfs_write+0xb8/0x110 vfs_write+0xa9/0x1b0 SyS_write+0x46/0xb0 system_call_fastpath+0x18/0xd7 Code: ff ff 8b 75 b8 39 75 b0 8b 45 c8 89 45 98 0f 84 e5 fe ff ff 45 8b 74 24 18 41 8b 54 24 1c e9 56 fc ff ff 85 c0 0f 85 48 ff ff ff <0f> 0b 48 8b 05 cf c3 de ff 48 ba 00 00 00 00 00 00 00 10 48 85 RIP __ocfs2_resv_find_window+0x498/0x760 [ocfs2] RSP <ffff8800ea4db668> ---[ end trace 566f07529f2edf3c ]--- Kernel panic - not syncing: Fatal exception Kernel Offset: disabled Link: http://lkml.kernel.org/r/20181121020023.3034-2-junxiao.bi@oracle.comSigned-off-by:
-
Larry Chen authored
Included file path was hard-wired in the ocfs2 makefile, which might causes some confusion when compiling ocfs2 as an external module. Say if we compile ocfs2 module as following. cp -r /kernel/tree/fs/ocfs2 /other/dir/ocfs2 cd /other/dir/ocfs2 make -C /path/to/kernel_source M=`pwd` modules Acutally, the compiler wil try to find included file in /kernel/tree/fs/ocfs2, rather than the directory /other/dir/ocfs2. To fix this little bug, we introduce the var $(src) provided by kbuild. $(src) means the absolute path of the running kbuild file. Link: http://lkml.kernel.org/r/20181108085546.15149-1-lchen@suse.comSigned-off-by:
Larry Chen <lchen@suse.com> Reviewed-by:
-
zhong jiang authored
lastzero is not used after setting its value. It is safe to remove the unused variable. Link: http://lkml.kernel.org/r/1540296942-24533-1-git-send-email-zhongjiang@huawei.comSigned-off-by:
zhong jiang <zhongjiang@huawei.com> Reviewed-by:
-
zhong jiang authored
status is not used after setting its value. It is safe to remove the unused variable. Link: http://lkml.kernel.org/r/1540300179-26697-1-git-send-email-zhongjiang@huawei.comSigned-off-by:
Jun Piao <piaojun@huawei.com> Acked-by:
-
Jia Guo authored
Reading heartbeat data from lowest node rather than from zero, in cases where the node is not defined from zero, can reduce the number of sectors read. Here is a simple test data obtained with 'iostat -dmx dm-5 2', with two nodes in the cluster, node number 10, 20, respectively. Before optimization: Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util dm-5 0.00 0.00 0.50 0.50 0.01 0.00 11.00 0.00 1.00 1.00 1.00 1.50 0.15 After the optimization: Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util dm-5 0.00 0.00 0.50 0.50 0.00 0.00 6.00 0.00 0.50 1.00 0.00 0.50 0.05 Link: http://lkml.kernel.org/r/99fe4988-69ac-3615-a218-3042fe6fbe72@huawei.comSigned-off-by:
Jia Guo <guojia12@huawei.com> Reviewed-by:
-
Qian Cai authored
The current value of the early boot static pool size, 1024 is not big enough for systems with large number of CPUs with timer or/and workqueue objects selected. As the results, systems have 60+ CPUs with both timer and workqueue objects enabled could trigger "ODEBUG: Out of memory. ODEBUG disabled". Some debug objects are allocated during the early boot. Enabling some options like timers or workqueue objects may increase the size required significantly with large number of CPUs. For example, CONFIG_DEBUG_OBJECTS_TIMERS: No. CPUs x 2 (worker pool) objects: start_kernel workqueue_init_early init_worker_pool init_timer_key debug_object_init plus No. CPUs objects (CONFIG_HIGH_RES_TIMERS): sched_init hrtick_rq_init hrtimer_init CONFIG_DEBUG_OBJECTS_WORK: No. CPUs objects: vmalloc_init __init_work plus No. CPUs x 6 (workqueue) objects: workqueue_init_early alloc_workqueue __alloc_workqueue_key alloc_and_link_pwqs init_pwq Also, plus No. CPUs objects: perf_event_init __init_srcu_struct init_srcu_struct_fields init_srcu_struct_nodes __init_work However, none of the things are actually used or required before debug_objects_mem_init() is invoked, so just move the call right before vmalloc_init(). According to tglx, "the reason why the call is at this place in start_kernel() is historical. It's because back in the days when debugobjects were added the memory allocator was enabled way later than today." Link: http://lkml.kernel.org/r/20181126102407.1836-1-cai@gmx.usSigned-off-by:Qian Cai <cai@gmx.us> Suggested-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Waiman Long <longman@redhat.com> Cc: Yang Shi <yang.shi@linux.alibaba.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Kuninori Morimoto authored
Update license to use SPDX-License-Identifier instead of verbose license text. Link: http://lkml.kernel.org/r/871s6wcswb.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Rich Felker <dalias@libc.org> Signed-off-by:
-
Kuninori Morimoto authored
Update license to use SPDX-License-Identifier instead of verbose license text. Link: http://lkml.kernel.org/r/8736rccswn.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
Kuninori Morimoto authored
Update license to use SPDX-License-Identifier instead of verbose license text. Link: http://lkml.kernel.org/r/874lbscswy.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
Kuninori Morimoto authored
Update license to use SPDX-License-Identifier instead of verbose license text. Link: http://lkml.kernel.org/r/875zw8csxa.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
Kuninori Morimoto authored
Update license to use SPDX-License-Identifier instead of verbose license text. Link: http://lkml.kernel.org/r/877egocsxl.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
Kuninori Morimoto authored
Update license to use SPDX-License-Identifier instead of verbose license text. Link: http://lkml.kernel.org/r/878t14csxy.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
Kuninori Morimoto authored
Update license to use SPDX-License-Identifier instead of verbose license text, excepting ${LINUX}/arch/sh/kernel/cpu/sh4/softfloat.c which is not GPL license Link: http://lkml.kernel.org/r/87a7lkcsya.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: -
Kuninori Morimoto authored
Update license to use SPDX-License-Identifier instead of verbose license text. Link: http://lkml.kernel.org/r/87bm60csyl.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
Kuninori Morimoto authored
Update license to use SPDX-License-Identifier instead of verbose license text. Link: http://lkml.kernel.org/r/87d0qgcsz8.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
Kuninori Morimoto authored
Update license to use SPDX-License-Identifier instead of verbose license text. Link: http://lkml.kernel.org/r/87efawcszk.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
Kuninori Morimoto authored
Update license to use SPDX-License-Identifier instead of verbose license text. Link: http://lkml.kernel.org/r/87ftvccszx.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
Kuninori Morimoto authored
Update license to use SPDX-License-Identifier instead of verbose license text. As original license mentioned, it is GPL-2.0 in SPDX. Then, MODULE_LICENSE() should be "GPL v2" instead of "GPL". See ${LINUX}/include/linux/module.h "GPL" [GNU Public License v2 or later] "GPL v2" [GNU Public License v2] Link: http://lkml.kernel.org/r/87h8fsct0a.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: -
Kuninori Morimoto authored
Update license to use SPDX-License-Identifier instead of verbose license text. Link: http://lkml.kernel.org/r/87in08ct0n.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
YueHaibing authored
There is no need to have the 'struct clk *camera_clk' variable static since a new value is always assigned before use. Link: http://lkml.kernel.org/r/1543628631-99957-1-git-send-email-yuehaibing@huawei.comSigned-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
-
Randy Dunlap authored
arch/sh/boards/mach-kfr2r09/setup.c does not need to #include <mtd/onenand.h>, and doing so causes a build warning, so drop that header file. In file included from ../arch/sh/boards/mach-kfr2r09/setup.c:28: ../include/linux/mtd/onenand.h:225:12: warning: 'struct mtd_oob_ops' declared inside parameter list will not be visible outside of this definition or declaration struct mtd_oob_ops *ops); Link: http://lkml.kernel.org/r/702f0a25-c63e-6912-4640-6ab0f00afbc7@infradead.org Fixes: f3590dc3 ("media: arch: sh: kfr2r09: Use new renesas-ceu camera driver") Signed-off-by:Randy Dunlap <rdunlap@infradead.org> Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Suggested-by:
Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by:
-
Kirill Tkhai authored
New declarations and identifier (__always_inline). Link: http://lkml.kernel.org/r/154505048571.504.18330420599768007443.stgit@localhost.localdomainSigned-off-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Constantine Shulyupin <const@MakeLinux.com> Cc: Kirill Tkhai <ktkhai@virtuozzo.com> Cc: Joey Pabalinas <joeypabalinas@gmail.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
Thierry Reding authored
Add a script that will run spdxcheck.py through a couple of self tests to simplify validation in the future. The tests are run for both Python 2 and Python 3 to make sure all changes to the script remain compatible across both versions. The script tests a regular text file (Makefile) for basic sanity checks and then runs it on a binary file (Documentation/logo.gif) to make sure it works in both cases. It also tests opening files passed on the command line as well as piped files read from standard input. Finally a run on the complete tree will be performed to catch any other potential issues. Link: http://lkml.kernel.org/r/20181212131210.28024-2-thierry.reding@gmail.comSigned-off-by:
Thierry Reding <treding@nvidia.com> Thomas Gleixner <tglx@linutronix.de> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Joe Perches <joe@perches.com> Cc: Jeremy Cline <jcline@redhat.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Qian Cai authored
This is to track dynamic amount of stack growth for aarch64, so it is possible to print out offensive functions that may consume too much stack. For example, 0xffff2000084d1270 try_to_unmap_one [vmlinux]: Dynamic (0xcf0) 0xffff200008538358 migrate_page_move_mapping [vmlinux]: Dynamic (0xc60) 0xffff2000081276c8 copy_process.isra.2 [vmlinux]: Dynamic (0xb20) 0xffff200008424958 show_free_areas [vmlinux]: Dynamic (0xb40) 0xffff200008545178 __split_huge_pmd_locked [vmlinux]: Dynamic (0xb30) 0xffff200008555120 collapse_shmem [vmlinux]: Dynamic (0xbc0) 0xffff20000862e0d0 do_direct_IO [vmlinux]: Dynamic (0xb70) 0xffff200008cc0aa0 md_do_sync [vmlinux]: Dynamic (0xb90) Link: http://lkml.kernel.org/r/20181208025143.39363-1-cai@lca.pwSigned-off-by:
Qian Cai <cai@lca.pw> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Marc Zyngier authored
Running something like: decodecode vmlinux . leads to interested results where not only the leading "." gets stripped from the displayed paths, but also anywhere in the string, displaying something like: kvm_vcpu_check_block (arch/arm64/kvm/virt/kvm/kvm_mainc:2141) which doesn't help further processing. Fix it by only stripping the base path if it is a prefix of the path. Link: http://lkml.kernel.org/r/20181210174659.31054-3-marc.zyngier@arm.comSigned-off-by:
Marc Zyngier <marc.zyngier@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Marc Zyngier authored
When running decodecode natively on arm64, ARCH is likely not to be set, and we end-up with .4byte instead of .inst when generating the disassembly. Similar effects would occur if running natively on a 32bit ARM platform, although that's even less popular. A simple workaround is to populate ARCH when it is not set and that we're running on an arm/arm64 system. Link: http://lkml.kernel.org/r/20181210174659.31054-2-marc.zyngier@arm.comSigned-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Rasmus Villemoes authored
Since __LINE__ is part of the symbol created by __ADDRESSABLE, almost any change causes those symbols to disappear and get reincarnated, e.g. add/remove: 4/4 grow/shrink: 0/3 up/down: 32/-171 (-139) Function old new delta __addressable_tracing_set_default_clock8649 - 8 +8 __addressable_tracer_init_tracefs8631 - 8 +8 __addressable_ftrace_dump8383 - 8 +8 __addressable_clear_boot_tracer8632 - 8 +8 __addressable_tracing_set_default_clock8650 8 - -8 __addressable_tracer_init_tracefs8632 8 - -8 __addressable_ftrace_dump8384 8 - -8 __addressable_clear_boot_tracer8633 8 - -8 trace_default_header 663 642 -21 tracing_mark_raw_write 406 355 -51 tracing_mark_write 624 557 -67 Total: Before=63889, After=63750, chg -0.22% They're small and in .discard, so ignore them, leading to more useful add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-139 (-139) Function old new delta trace_default_header 663 642 -21 tracing_mark_raw_write 406 355 -51 tracing_mark_write 624 557 -67 Total: Before=63721, After=63582, chg -0.22% Link: http://lkml.kernel.org/r/20181102210030.8383-1-linux@rasmusvillemoes.dkSigned-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Maninder Singh <maninder1.s@samsung.com> Cc: Matteo Croce <mcroce@redhat.com> Signed-off-by:
-
Andrey Konovalov authored
This patch adds a "SPDX-License-Identifier: GPL-2.0" mark to all source files under mm/kasan. Link: http://lkml.kernel.org/r/bce2d1e618afa5142e81961ab8fa4b4165337380.1544099024.git.andreyknvl@google.comSigned-off-by:
Andrey Konovalov <andreyknvl@google.com> Reviewed-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com> Cc: Christoph Lameter <cl@linux.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Andrey Konovalov authored
This patch updates KASAN documentation to reflect the addition of the new tag-based mode. Link: http://lkml.kernel.org/r/aabef9de317c54b8a3919a4946ce534c6576726a.1544099024.git.andreyknvl@google.comSigned-off-by:
-
Andrey Konovalov authored
Now, that all the necessary infrastructure code has been introduced, select HAVE_ARCH_KASAN_SW_TAGS for arm64 to enable software tag-based KASAN mode. Link: http://lkml.kernel.org/r/25abce9a21d0c1df2d9d72488aced418c3465d7b.1544099024.git.andreyknvl@google.comSigned-off-by:
-
