- 24 Nov, 2020 40 commits
-
-
Andrey Konovalov authored
This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode. Group shadow-related KASAN function declarations and only define them for the two existing software modes. No functional changes for software modes. Link: https://lkml.kernel.org/r/e88d94eff94db883a65dca52e1736d80d28dd9bc.1606161801.git.andreyknvl@google.com Signed-off-by:
Andrey Konovalov <andreyknvl@google.com> Signed-off-by:
Vincenzo Frascino <vincenzo.frascino@arm.com> Reviewed-by:
Marco Elver <elver@google.com> Reviewed-by:
Alexander Potapenko <glider@google.com> Tested-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au>
-
Andrey Konovalov authored
This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode. Group all vmalloc-related function declarations in include/linux/kasan.h, and their implementations in mm/kasan/common.c. No functional changes. Link: https://lkml.kernel.org/r/80a6fdd29b039962843bd6cf22ce2643a7c8904e.1606161801.git.andreyknvl@google.com Signed-off-by:
-
Andrey Konovalov authored
Currently only generic KASAN mode supports vmalloc, reflect that in the config. Link: https://lkml.kernel.org/r/0c493d3a065ad95b04313d00244e884a7e2498ff.1606161801.git.andreyknvl@google.com Signed-off-by:
-
Andrey Konovalov authored
Patch series "kasan: add hardware tag-based mode for arm64", v11. This patchset adds a new hardware tag-based mode to KASAN [1]. The new mode is similar to the existing software tag-based KASAN, but relies on arm64 Memory Tagging Extension (MTE) [2] to perform memory and pointer tagging (instead of shadow memory and compiler instrumentation). This patchset is co-developed and tested by Vincenzo Frascino <vincenzo.frascino@arm.com>. This patchset is available here: https://github.com/xairy/linux/tree/up-kasan-mte-v11 For testing in QEMU hardware tag-based KASAN requires: 1. QEMU built from master [4] (use "-machine virt,mte=on -cpu max" arguments to run). 2. GCC version 10. [1] https://www.kernel.org/doc/html/latest/dev-tools/kasan.html [2] https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety [3] git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux for-next/mte [4] https://github.com/qemu/qemu ====== Overview The underlying ideas of the approach used by hardware tag-based KASAN are: 1. By relying on the Top Byte Ignore (TBI) arm64 CPU feature, pointer tags are stored in the top byte of each kernel pointer. 2. With the Memory Tagging Extension (MTE) arm64 CPU feature, memory tags for kernel memory allocations are stored in a dedicated memory not accessible via normal instuctions. 3. On each memory allocation, a random tag is generated, embedded it into the returned pointer, and the corresponding memory is tagged with the same tag value. 4. With MTE the CPU performs a check on each memory access to make sure that the pointer tag matches the memory tag. 5. On a tag mismatch the CPU generates a tag fault, and a KASAN report is printed. Same as other KASAN modes, hardware tag-based KASAN is intended as a debugging feature at this point. ====== Rationale There are two main reasons for this new hardware tag-based mode: 1. Previously implemented software tag-based KASAN is being successfully used on dogfood testing devices due to its low memory overhead (as initially planned). The new hardware mode keeps the same low memory overhead, and is expected to have significantly lower performance impact, due to the tag checks being performed by the hardware. Therefore the new mode can be used as a better alternative in dogfood testing for hardware that supports MTE. 2. The new mode lays the groundwork for the planned in-kernel MTE-based memory corruption mitigation to be used in production. ====== Technical details Considering the implementation perspective, hardware tag-based KASAN is almost identical to the software mode. The key difference is using MTE for assigning and checking tags. Compared to the software mode, the hardware mode uses 4 bits per tag, as dictated by MTE. Pointer tags are stored in bits [56:60), the top 4 bits have the normal value 0xF. Having less distict tags increases the probablity of false negatives (from ~1/256 to ~1/16) in certain cases. Only synchronous exceptions are set up and used by hardware tag-based KASAN. ====== Benchmarks Note: all measurements have been performed with software emulation of Memory Tagging Extension, performance numbers for hardware tag-based KASAN on the actual hardware are expected to be better. Boot time [1]: * 2.8 sec for clean kernel * 5.7 sec for hardware tag-based KASAN * 11.8 sec for software tag-based KASAN * 11.6 sec for generic KASAN Slab memory usage after boot [2]: * 7.0 kb for clean kernel * 9.7 kb for hardware tag-based KASAN * 9.7 kb for software tag-based KASAN * 41.3 kb for generic KASAN Measurements have been performed with: * defconfig-based configs * Manually built QEMU master * QEMU arguments: -machine virt,mte=on -cpu max * CONFIG_KASAN_STACK_ENABLE disabled * CONFIG_KASAN_INLINE enabled * clang-10 as the compiler and gcc-10 as the assembler [1] Time before the ext4 driver is initialized. [2] Measured as `cat /proc/meminfo | grep Slab`. ====== Notes The cover letter for software tag-based KASAN patchset can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0116523cfffa62aeb5aa3b85ce7419f3dae0c1b8 ===== Tags Tested-by:
-
Stephen Rothwell authored
Link: https://lkml.kernel.org/r/20201111221254.7f6a3658@canb.auug.org.au Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Christoph Hellwig authored
Merge __follow_pte_pmd, follow_pte_pmd and follow_pte into a single follow_pte function and just pass two additional NULL arguments for the two previous follow_pte callers. Link: https://lkml.kernel.org/r/20201029101432.47011-3-hch@lst.de Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Christoph Hellwig authored
Patch series "simplify follow_pte a bit". This small series drops the not needed follow_pte_pmd exports, and simplifies the follow_pte family of functions a bit. This patch (of 2): follow_pte_pmd() is only used by the DAX code, which can't be modular. Link: https://lkml.kernel.org/r/20201029101432.47011-2-hch@lst.de Signed-off-by:
-
Soheil Hassas Yeganeh authored
We call ep_events_available() under lock when timeout is 0, and then call it without locks in the loop for the other cases. Instead, call ep_events_available() without lock for all cases. For non-zero timeouts, we will recheck after adding the thread to the wait queue. For zero timeout cases, by definition, user is opportunistically polling and will have to call epoll_wait again in the future. Note that this lock was kept in c5a282e9 because the whole loop was historically under lock. This patch results in a 1% CPU/RPC reduction in RPC benchmarks. Link: https://lkml.kernel.org/r/20201106231635.3528496-9-soheil.kdev@gmail.com Signed-off-by:
Soheil Hassas Yeganeh <soheil@google.com> Suggested-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Reviewed-by:
Khazhismel Kumykov <khazhy@google.com> Cc: Guantao Liu <guantaol@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Soheil Hassas Yeganeh authored
The existing loop is pointless, and the labels make it really hard to follow the structure. Replace that control structure with a simple loop that returns when there are new events, there is a signal, or the thread has timed out. Link: https://lkml.kernel.org/r/20201106231635.3528496-8-soheil.kdev@gmail.com Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by:
-
Soheil Hassas Yeganeh authored
This is a no-op change which simplifies the follow up patches. Link: https://lkml.kernel.org/r/20201106231635.3528496-7-soheil.kdev@gmail.com Signed-off-by:
-
Soheil Hassas Yeganeh authored
ep_events_available() is called multiple times around the busy loop logic, even though the logic is generally not used. ep_reset_busy_poll_napi_id() is similarly always called, even when busy loop is not used. Eliminate ep_reset_busy_poll_napi_id() and inline it inside ep_busy_loop(). Make ep_busy_loop() return whether there are any events available after the busy loop. This will eliminate unnecessary loads and branches, and simplifies the loop. Link: https://lkml.kernel.org/r/20201106231635.3528496-6-soheil.kdev@gmail.com Signed-off-by:
-
Soheil Hassas Yeganeh authored
This is a no-op change and simply to make the code more coherent. Link: https://lkml.kernel.org/r/20201106231635.3528496-5-soheil.kdev@gmail.com Signed-off-by:
-
Soheil Hassas Yeganeh authored
To simplify the code, pull in checking the fatal signals into ep_send_events(). ep_send_events() is called only from ep_poll(). Note that, previously, we were always checking fatal events, but it is checked only if eavail is true. This should be fine because the goal of that check is to quickly return from epoll_wait() when there is a pending fatal signal. Link: https://lkml.kernel.org/r/20201106231635.3528496-4-soheil.kdev@gmail.com Signed-off-by:
-
Soheil Hassas Yeganeh authored
Check signals before locking ep->lock, and immediately return -EINTR if there is any signal pending. This saves a few loads, stores, and branches from the hot path and simplifies the loop structure for follow up patches. Link: https://lkml.kernel.org/r/20201106231635.3528496-3-soheil.kdev@gmail.com Signed-off-by:
-
Soheil Hassas Yeganeh authored
Patch series "simplify ep_poll". This patch series is a followup based on the suggestions and feedback by Linus: https://lkml.kernel.org/r/CAHk-=wizk=OxUyQPbO8MS41w2Pag1kniUV5WdD5qWL-gq1kjDA@mail.gmail.com The first patch in the series is a fix for the epoll race in presence of timeouts, so that it can be cleanly backported to all affected stable kernels. The rest of the patch series simplify the ep_poll() implementation. Some of these simplifications result in minor performance enhancements as well. We have kept these changes under self tests and internal benchmarks for a few days, and there are minor (1-2%) performance enhancements as a result. This patch (of 8): After abc610e0 ("fs/epoll: avoid barrier after an epoll_wait(2) timeout"), we break out of the ep_poll loop upon timeout, without checking whether there is any new events available. Prior to that patch-series we always called ep_events_available() after exiting the loop. This can cause races and missed wakeups. For example, consider the following scenario reported by Guantao Liu: Suppose we have an eventfd added using EPOLLET to an epollfd. Thread 1: Sleeps for just below 5ms and then writes to an eventfd. Thread 2: Calls epoll_wait with a timeout of 5 ms. If it sees an event of the eventfd, it will write back on that fd. Thread 3: Calls epoll_wait with a negative timeout. Prior to abc610e0, it is guaranteed that Thread 3 will wake up either by Thread 1 or Thread 2. After abc610e0, Thread 3 can be blocked indefinitely if Thread 2 sees a timeout right before the write to the eventfd by Thread 1. Thread 2 will be woken up from schedule_hrtimeout_range and, with evail 0, it will not call ep_send_events(). To fix this issue: 1) Simplify the timed_out case as suggested by Linus. 2) while holding the lock, recheck whether the thread was woken up after its time out has reached. Note that (2) is different from Linus' original suggestion: It do not set "eavail = ep_events_available(ep)" to avoid unnecessary contention (when there are too many timed-out threads and a small number of events), as well as races mentioned in the discussion thread. This is the first patch in the series so that the backport to stable releases is straightforward. Link: https://lkml.kernel.org/r/20201106231635.3528496-1-soheil.kdev@gmail.com Link: https://lkml.kernel.org/r/CAHk-=wizk=OxUyQPbO8MS41w2Pag1kniUV5WdD5qWL-gq1kjDA@mail.gmail.com Link: https://lkml.kernel.org/r/20201106231635.3528496-2-soheil.kdev@gmail.com Fixes: abc610e0 ("fs/epoll: avoid barrier after an epoll_wait(2) timeout") Signed-off-by:
Guantao Liu <guantaol@google.com> Suggested-by:
Davidlohr Bueso <dbueso@suse.de> Signed-off-by:
-
Nathan Chancellor authored
Patch "treewide: Remove stringification from __alias macro definition" causes arguments to __alias to no longer be quoted automatically, which breaks CONFIG_KASAN on ARM after commit d6d51a96 ("ARM: 9014/2: Replace string mem* functions for KASan"): arch/arm/boot/compressed/string.c:24:1: error: attribute 'alias' argument not a string 24 | void *__memcpy(void *__dest, __const void *__src, size_t __n) __alias(memcpy); | ^~~~ arch/arm/boot/compressed/string.c:25:1: error: attribute 'alias' argument not a string 25 | void *__memmove(void *__dest, __const void *__src, size_t count) __alias(memmove); | ^~~~ arch/arm/boot/compressed/string.c:26:1: error: attribute 'alias' argument not a string 26 | void *__memset(void *s, int c, size_t count) __alias(memset); | ^~~~ make[3]: *** [scripts/Makefile.build:283: arch/arm/boot/compressed/string.o] Error 1 Quote the names like the treewide patch does so there is no more error. Link: https://lkml.kernel.org/r/20201109001712.3384097-1-natechancellor@gmail.com Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Reported-by:
Naresh Kamboju <naresh.kamboju@linaro.org> Reported-by:
Valdis Klētnieks <valdis.kletnieks@vt.edu> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Joe Perches authored
Like the old __section macro, the __alias macro uses macro # stringification to create quotes around the symbol name used in the __attribute__. This can cause differences between gcc and clang when the stringification itself contains a quote character. So avoid these differences by always using quotes to define the aliased symbol. Remove the stringification and add quotes and when necessary a stringification when existing uses have a ## concatenation. Unlike the __section macro conversion in commit 33def849 ("treewide: Convert macro and uses of __section(foo) to __section("foo")") this one was done by hand. No other use of __alias exists in the kernel. This patch does _not_ convert any uses of __attribute__((alias("<foo>"))) so it should not cause any compilation issues. Link: https://lkml.kernel.org/r/8451df41359b52f048780d19e07b6fa4445b6392.1604026698.git.joe@perches.com Signed-off-by:
Joe Perches <joe@perches.com> Reviewed-by:
-
Alex Shi authored
commit "(mm/memcontrol:rewrite mem_cgroup_page_lruvec())" on mm tree use mem_cgroup_lruvec to rewrite mem_cgroup_page_lruvec, but it missed a DEBUG_VM warning as following, since we always charge a page before return from allocation. Add back this warning is helpful: VM_WARN_ON_ONCE(!memcg); Link: https://lkml.kernel.org/r/94f17bb7-ec61-5b72-3555-fabeb5a4d73b@linux.alibaba.com Signed-off-by:
Alex Shi <alex.shi@linux.alibaba.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Shakeel Butt <shakeelb@google.com> Cc: Roman Gushchin <guro@fb.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Yafang Shao <laoar.shao@gmail.com> Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com> Cc: Hui Su <sh_def@163.com> Cc: Wei Yang <richard.weiyang@gmail.com> Signed-off-by:
-
Hui Su authored
mem_cgroup_page_lruvec() in memcontrol.c and mem_cgroup_lruvec() in memcontrol.h is very similar except for the param(page and memcg) which also can be convert to each other. So rewrite mem_cgroup_page_lruvec() with mem_cgroup_lruvec(). Link: https://lkml.kernel.org/r/20201108143731.GA74138@rlk Signed-off-by:
Hui Su <sh_def@163.com> Acked-by:
Michal Hocko <mhocko@suse.com> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Reviewed-by:
Shakeel Butt <shakeelb@google.com> Acked-by:
Roman Gushchin <guro@fb.com> Cc: Vladimir Davydov <vdavydov.dev@gmail.com> Cc: Yafang Shao <laoar.shao@gmail.com> Cc: Chris Down <chris@chrisdown.name> Signed-off-by:
-
Roman Gushchin authored
open-code set_page_objcgs() and add some comments, by Johannes Link: https://lkml.kernel.org/r/20201113001926.GA2934489@carbon.dhcp.thefacebook.com Signed-off-by:
-
Roman Gushchin authored
In general it's unknown in advance if a slab page will contain accounted objects or not. In order to avoid memory waste, an obj_cgroup vector is allocated dynamically when a need to account of a new object arises. Such approach is memory efficient, but requires an expensive cmpxchg() to set up the memcg/objcgs pointer, because an allocation can race with a different allocation on another cpu. But in some common cases it's known for sure that a slab page will contain accounted objects: if the page belongs to a slab cache with a SLAB_ACCOUNT flag set. It includes such popular objects like vm_area_struct, anon_vma, task_struct, etc. In such cases we can pre-allocate the objcgs vector and simple assign it to the page without any atomic operations, because at this early stage the page is not visible to anyone else. A very simplistic benchmark (allocating 10000000 64-bytes objects in a row) shows ~15% win. In the real life it seems that most workloads are not very sensitive to the speed of (accounted) slab allocations. Link: https://lkml.kernel.org/r/20201110195753.530157-2-guro@fb.com Signed-off-by:
-
Roman Gushchin authored
It's convenient to have page->objects initialized before calling into account_slab_page(). In particular, this information can be used to pre-alloc the obj_cgroup vector. Let's call account_slab_page() a bit later, after the initialization of page->objects. This commit doesn't bring any functional change, but is required for further optimizations. Link: https://lkml.kernel.org/r/20201110195753.530157-1-guro@fb.com Signed-off-by:
-
Shakeel Butt authored
A VCPU of a VM can allocate couple of pages which can be mmap'ed by the user space application. At the moment this memory is not charged to the memcg of the VMM. On a large machine running large number of VMs or small number of VMs having large number of VCPUs, this unaccounted memory can be very significant. So, charge this memory to the memcg of the VMM. Please note that lifetime of these allocations corresponds to the lifetime of the VMM. Link: https://lkml.kernel.org/r/20201106202923.2087414-1-shakeelb@google.com Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.com> Signed-off-by:
-
Wei Yang authored
Some definitions are left unused, just clean them. Link: https://lkml.kernel.org/r/20201108003834.12669-1-richard.weiyang@gmail.com Signed-off-by:
Wei Yang <richard.weiyang@gmail.com> Acked-by:
-
Alex Shi authored
Add VM_WARN_ON_ONCE_PAGE() macro. Since readahead page is charged on memcg too, in theory we don't have to check this exception now. Before safely remove them all, add a warning for the unexpected !memcg. Link: https://lkml.kernel.org/r/1604283436-18880-3-git-send-email-alex.shi@linux.alibaba.com Signed-off-by:
Hugh Dickins <hughd@google.com> Acked-by:
-
Alex Shi authored
Patch series "bail out early for memcg disable". These 2 patches are indepenedent from per memcg lru lock, and may encounter unexpected warning, so let's move out them from per memcg lru locking patchset. This patch (of 2): We could bail out early when memcg wasn't enabled. Link: https://lkml.kernel.org/r/1604283436-18880-1-git-send-email-alex.shi@linux.alibaba.com Link: https://lkml.kernel.org/r/1604283436-18880-2-git-send-email-alex.shi@linux.alibaba.com Signed-off-by:
-
Roman Gushchin authored
PageKmemcg flag is currently defined as a page type (like buddy, offline, table and guard). Semantically it means that the page was accounted as a kernel memory by the page allocator and has to be uncharged on the release. As a side effect of defining the flag as a page type, the accounted page can't be mapped to userspace (look at page_has_type() and comments above). In particular, this blocks the accounting of vmalloc-backed memory used by some bpf maps, because these maps do map the memory to userspace. One option is to fix it by complicating the access to page->mapcount, which provides some free bits for page->page_type. But it's way better to move this flag into page->memcg_data flags. Indeed, the flag makes no sense without enabled memory cgroups and memory cgroup pointer set in particular. This commit replaces PageKmemcg() and __SetPageKmemcg() with PageMemcgKmem() and an open-coded OR operation setting the memcg pointer with the MEMCG_DATA_KMEM bit. __ClearPageKmemcg() can be simple deleted, as the whole memcg_data is zeroed at once. As a bonus, on !CONFIG_MEMCG build the PageMemcgKmem() check will be compiled out. Link: https://lkml.kernel.org/r/20201027001657.3398190-5-guro@fb.com Signed-off-by:
-
Roman Gushchin authored
The lowest bit in page->memcg_data is used to distinguish between struct memory_cgroup pointer and a pointer to a objcgs array. All checks and modifications of this bit are open-coded. Let's formalize it using page memcg flags, defined in enum page_memcg_data_flags. Additional flags might be added later. Link: https://lkml.kernel.org/r/20201027001657.3398190-4-guro@fb.com Signed-off-by:
-
Roman Gushchin authored
To gather all direct accesses to struct page's memcg_data field in one place, let's introduce 3 new helpers to use in the slab accounting code: struct obj_cgroup **page_objcgs(struct page *page); struct obj_cgroup **page_objcgs_check(struct page *page); bool set_page_objcgs(struct page *page, struct obj_cgroup **objcgs); They are similar to the corresponding API for generic pages, except that the setter can return false, indicating that the value has been already set from a different thread. Link: https://lkml.kernel.org/r/20201027001657.3398190-3-guro@fb.com Signed-off-by:
-
Roman Gushchin authored
Patch series "mm: allow mapping accounted kernel pages to userspace", v6. Currently a non-slab kernel page which has been charged to a memory cgroup can't be mapped to userspace. The underlying reason is simple: PageKmemcg flag is defined as a page type (like buddy, offline, etc), so it takes a bit from a page->mapped counter. Pages with a type set can't be mapped to userspace. But in general the kmemcg flag has nothing to do with mapping to userspace. It only means that the page has been accounted by the page allocator, so it has to be properly uncharged on release. Some bpf maps are mapping the vmalloc-based memory to userspace, and their memory can't be accounted because of this implementation detail. This patchset removes this limitation by moving the PageKmemcg flag into one of the free bits of the page->mem_cgroup pointer. Also it formalizes accesses to the page->mem_cgroup and page->obj_cgroups using new helpers, adds several checks and removes a couple of obsolete functions. As the result the code became more robust with fewer open-coded bit tricks. This patch (of 4): Currently there are many open-coded reads of the page->mem_cgroup pointer, as well as a couple of read helpers, which are barely used. It creates an obstacle on a way to reuse some bits of the pointer for storing additional bits of information. In fact, we already do this for slab pages, where the last bit indicates that a pointer has an attached vector of objcg pointers instead of a regular memcg pointer. This commits uses 2 existing helpers and introduces a new helper to converts all read sides to calls of these helpers: struct mem_cgroup *page_memcg(struct page *page); struct mem_cgroup *page_memcg_rcu(struct page *page); struct mem_cgroup *page_memcg_check(struct page *page); page_memcg_check() is intended to be used in cases when the page can be a slab page and have a memcg pointer pointing at objcg vector. It does check the lowest bit, and if set, returns NULL. page_memcg() contains a VM_BUG_ON_PAGE() check for the page not being a slab page. To make sure nobody uses a direct access, struct page's mem_cgroup/obj_cgroups is converted to unsigned long memcg_data. Link: https://lkml.kernel.org/r/20201027001657.3398190-1-guro@fb.com Link: https://lkml.kernel.org/r/20201027001657.3398190-2-guro@fb.com Signed-off-by:
-
Alex Shi authored
The current relock logic will change lru_lock when it finds a new lruvec, so if 2 memcgs are reading a file or allocating pages at same time, they could hold the lru_lock alternately, and wait for each other for fairness attribute of ticket spin lock. This patch will sort all lru_locks and only hold them once in the above scenario. That could reduce fairness waiting for lock reacquision. vm-scalability/case-lru-file-readtwice gets a ~5% performance gain on my 2P*20core*HT machine. Testing when all or most of the pages belong to the same lruvec show no regression - most time is spent on lru_lock for lru sensitive cases. Link: https://lkml.kernel.org/r/1605860847-47445-1-git-send-email-alex.shi@linux.alibaba.com Suggested-by:
Konstantin Khlebnikov <koct9i@gmail.com> Signed-off-by:
-
Stephen Rothwell authored
-
Jason Yan authored
Fix the following sparse warning: lib/lzo/lzo1x_compress.c:304:5: warning: symbol 'lzogeneric1x_1_compress' was not declared. Should it be static? Link: https://lkml.kernel.org/r/20201020031415.136874-1-yanaijie@huawei.com Signed-off-by:
Jason Yan <yanaijie@huawei.com> Cc: Dave Rodgman <dave.rodgman@arm.com> Signed-off-by:
-
Barnabás Pőcze authored
Commit af3b8544 ("mm/page_alloc.c: allow error injection") introduced EI_ETYPE_TRUE, but did not extend * lib/error-inject.c:error_type_string(), and * kernel/fail_function.c:adjust_error_retval() to accommodate for this change. Handle EI_ETYPE_TRUE in both functions appropriately by * returning "TRUE" in error_type_string(), * adjusting the return value to true (1) in adjust_error_retval(). Furthermore, simplify the logic of handling EI_ETYPE_NULL in adjust_error_retval(). Link: https://lkml.kernel.org/r/njB1czX0ZgWPR9h61euHIBb5bEyePw9D4D2m3i5lc9Cl96P8Q1308dTcmsEZW7Vtz3Ifz4do-rOtSfuFTyGoEDYokkK2aUqBePVptzZEWfU=@protonmail.com Signed-off-by:
Barnabás Pőcze <pobrn@protonmail.com> Acked-by:
Masami Hiramatsu <mhiramat@kernel.org> Reviewed-by:
Akinobu Mita <akinobu.mita@gmail.com> Cc: "Naveen N. Rao" <naveen.n.rao@linux.ibm.com> Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
Matteo Croce authored
BOOT_CF9_SAFE_STR is an internal value used only by the x86 code and it's not possible to set it from userspace. Remove it, and rename 'cf9_force' to 'pci', so to make it coherent with the kernel command line reboot= option. Tested with this script: cd /sys/kernel/reboot/ for i in cold warm hard soft gpio; do echo $i >mode read j <mode [ $i = $j ] || echo "mode $i != $j" done for i in bios acpi kbd triple efi pci; do echo $i >type read j <type [ $i = $j ] || echo "type $i != $j" done for i in $(seq 0 $(nproc --ignore=1)); do echo $i >cpu read j <cpu [ $i = $j ] || echo "cpu $i != $j" done for i in 0 1; do echo $i >force read j <force [ $i = $j ] || echo "force $i != $j" done Link: https://lkml.kernel.org/r/20201113015900.543923-1-mcroce@linux.microsoft.com Fixes: eab8da48579d ("reboot: allow to specify reboot mode via sysfs") Signed-off-by:
Matteo Croce <mcroce@microsoft.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Kees Cook <keescook@chromium.org> Cc: Mike Rapoport <rppt@kernel.org> Cc: Nathan Chancellor <natechancellor@gmail.com> Cc: Pavel Tatashin <pasha.tatashin@soleen.com> Cc: Petr Mladek <pmladek@suse.com> Cc: Tyler Hicks <tyhicks@linux.microsoft.com> Signed-off-by:
-
Nathan Chancellor authored
Clang warns: kernel/reboot.c:707:17: warning: implicit conversion from enumeration type 'enum reboot_type' to different enumeration type 'enum reboot_mode' [-Wenum-conversion] reboot_mode = BOOT_TRIPLE; ~ ^~~~~~~~~~~ kernel/reboot.c:709:17: warning: implicit conversion from enumeration type 'enum reboot_type' to different enumeration type 'enum reboot_mode' [-Wenum-conversion] reboot_mode = BOOT_KBD; ~ ^~~~~~~~ kernel/reboot.c:711:17: warning: implicit conversion from enumeration type 'enum reboot_type' to different enumeration type 'enum reboot_mode' [-Wenum-conversion] reboot_mode = BOOT_BIOS; ~ ^~~~~~~~~ kernel/reboot.c:713:17: warning: implicit conversion from enumeration type 'enum reboot_type' to different enumeration type 'enum reboot_mode' [-Wenum-conversion] reboot_mode = BOOT_ACPI; ~ ^~~~~~~~~ kernel/reboot.c:715:17: warning: implicit conversion from enumeration type 'enum reboot_type' to different enumeration type 'enum reboot_mode' [-Wenum-conversion] reboot_mode = BOOT_EFI; ~ ^~~~~~~~ kernel/reboot.c:717:17: warning: implicit conversion from enumeration type 'enum reboot_type' to different enumeration type 'enum reboot_mode' [-Wenum-conversion] reboot_mode = BOOT_CF9_FORCE; ~ ^~~~~~~~~~~~~~ kernel/reboot.c:719:17: warning: implicit conversion from enumeration type 'enum reboot_type' to different enumeration type 'enum reboot_mode' [-Wenum-conversion] reboot_mode = BOOT_CF9_SAFE; ~ ^~~~~~~~~~~~~ 7 warnings generated. It seems that these assignment should be to reboot_type, not reboot_mode. Fix it so there are no more warnings and the code works properly. Link: https://lkml.kernel.org/r/20201112035023.974748-1-natechancellor@gmail.com Fixes: eab8da48579d ("reboot: allow to specify reboot mode via sysfs") Link: https://github.com/ClangBuiltLinux/linux/issues/1197 Signed-off-by:Petr Mladek <pmladek@suse.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Kees Cook <keescook@chromium.org> Cc: Mike Rapoport <rppt@kernel.org> Cc: Pavel Tatashin <pasha.tatashin@soleen.com> Cc: Tyler Hicks <tyhicks@linux.microsoft.com> Signed-off-by:
-
Matteo Croce authored
The kernel cmdline reboot= option offers some sort of control on how the reboot is issued. We don't always know in advance what type of reboot to perform. Sometimes a warm reboot is preferred to persist certain memory regions across the reboot. Others a cold one is needed to apply a future system update that makes a memory memory model change, like changing the base page size or resizing a persistent memory region. Or simply we want to enable reboot_force because we noticed that something bad happened. Add handles in sysfs to allow setting these reboot options, so they can be changed when the system is booted, other than at boot time. The handlers are under <sysfs>/kernel/reboot, can be read to get the current configuration and written to alter it. # cd /sys/kernel/reboot/ # grep . * cpu:0 force:0 mode:cold type:acpi # echo 2 >cpu # echo yes >force # echo soft >mode # echo bios >type # grep . * cpu:2 force:1 mode:soft type:bios Before setting anything, check for CAP_SYS_BOOT capability, so it's possible to allow an unpriviledged process to change these settings simply by relaxing the handles permissions, without opening them to the world. Link: https://lkml.kernel.org/r/20201110202746.9690-1-mcroce@linux.microsoft.com Signed-off-by:
-
Andrew Morton authored
WARNING: please, no space before tabs #78: FILE: kernel/resource.c:1381: + * ^Imerge it with adjacent, mergeable resources$ total: 0 errors, 1 warnings, 55 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/resource-fix-kernel-doc-markups.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: "Jonathan Corbet" <corbet@lwn.net> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: -
Mauro Carvalho Chehab authored
Kernel-doc markups should use this format: identifier - description While here, fix a kernel-doc tag that was using, instead, a normal comment block. Link: https://lkml.kernel.org/r/c5e38e1070f8dbe2f9607a10b44afe2875bd966c.1605521731.git.mchehab+huawei@kernel.org Signed-off-by:Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Cc: "Jonathan Corbet" <corbet@lwn.net> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by:
-
Oleg Nesterov authored
Change wait_event_hrtimeout() to not call __wait_event_hrtimeout() if timeout == 0, this matches other _timeout() helpers in wait.h. This allows to simplify its only user, read_events(), it no longer needs to optimize the "until == 0" case by hand. Note: this patch doesn't use ___wait_cond_timeout because _hrtimeout() also differs in that it returns 0 if succeeds and -ETIME on timeout. Perhaps we should change this to make it fully compatible with other helpers. Link: http://lkml.kernel.org/r/20190607175413.GA29187@redhat.com Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Reviewed-by:
-
