{"push_id":3753613937,"size":41,"distinct_size":41,"ref":"refs/heads/latest","head":"5367edb0385d1c500fc1b9b3edd4a91b19540ad3","before":"b5570786f2df3c43b67a2728c227958f555a47d0","commits":[{"sha":"e0812cc56958f77826d1b621c3a63e4005b90c3a","author":{"name":"Michal Hocko","email":"829500b200af6c2a0eca4dfd5c388e6b8fbe8dc6@suse.com"},"message":"BACKPORT: mm: introduce kv[mz]alloc helpers\n\nPatch series \"kvmalloc\", v5.\n\nThere are many open coded kmalloc with vmalloc fallback instances in the\ntree.  Most of them are not careful enough or simply do not care about\nthe underlying semantic of the kmalloc/page allocator which means that\na) some vmalloc fallbacks are basically unreachable because the kmalloc\npart will keep retrying until it succeeds b) the page allocator can\ninvoke a really disruptive steps like the OOM killer to move forward\nwhich doesn't sound appropriate when we consider that the vmalloc\nfallback is available.\n\nAs it can be seen implementing kvmalloc requires quite an intimate\nknowledge if the page allocator and the memory reclaim internals which\nstrongly suggests that a helper should be implemented in the memory\nsubsystem proper.\n\nMost callers, I could find, have been converted to use the helper\ninstead.  This is patch 6.  There are some more relying on __GFP_REPEAT\nin the networking stack which I have converted as well and Eric Dumazet\nwas not opposed [2] to convert them as well.\n\n[1] http://lkml.kernel.org/r/20170130094940.13546-1-mhocko@kernel.org\n[2] http://lkml.kernel.org/r/1485273626.16328.301.camel@edumazet-glaptop3.roam.corp.google.com\n\nThis patch (of 9):\n\nUsing kmalloc with the vmalloc fallback for larger allocations is a\ncommon pattern in the kernel code.  Yet we do not have any common helper\nfor that and so users have invented their own helpers.  Some of them are\nreally creative when doing so.  Let's just add kv[mz]alloc and make sure\nit is implemented properly.  This implementation makes sure to not make\na large memory pressure for > PAGE_SZE requests (__GFP_NORETRY) and also\nto not warn about allocation failures.  This also rules out the OOM\nkiller as the vmalloc is a more approapriate fallback than a disruptive\nuser visible action.\n\nThis patch also changes some existing users and removes helpers which\nare specific for them.  In some cases this is not possible (e.g.\next4_kvmalloc, libcfs_kvzalloc) because those seems to be broken and\nrequire GFP_NO{FS,IO} context which is not vmalloc compatible in general\n(note that the page table allocation is GFP_KERNEL).  Those need to be\nfixed separately.\n\nWhile we are at it, document that __vmalloc{_node} about unsupported gfp\nmask because there seems to be a lot of confusion out there.\nkvmalloc_node will warn about GFP_KERNEL incompatible (which are not\nsuperset) flags to catch new abusers.  Existing ones would have to die\nslowly.\n\n[sfr@canb.auug.org.au: f2fs fixup]\n  Link: http://lkml.kernel.org/r/20170320163735.332e64b7@canb.auug.org.au\nLink: http://lkml.kernel.org/r/20170306103032.2540-2-mhocko@kernel.org\nSigned-off-by: Michal Hocko <mhocko@suse.com>\nSigned-off-by: Stephen Rothwell <sfr@canb.auug.org.au>\nReviewed-by: Andreas Dilger <adilger@dilger.ca>\t[ext4 part]\nAcked-by: Vlastimil Babka <vbabka@suse.cz>\nCc: John Hubbard <jhubbard@nvidia.com>\nCc: David Miller <davem@davemloft.net>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Angelo G. Del Regno <kholk11@gmail.com>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/e0812cc56958f77826d1b621c3a63e4005b90c3a"},{"sha":"b72f4bbecd42e1db043143e4818ba2e6c02f1b0d","author":{"name":"Michal Hocko","email":"829500b200af6c2a0eca4dfd5c388e6b8fbe8dc6@suse.com"},"message":"mm, vmalloc: properly track vmalloc users\n\n__vmalloc_node_flags used to be static inline but this has changed by\n\"mm: introduce kv[mz]alloc helpers\" because kvmalloc_node needs to use\nit as well and the code is outside of the vmalloc proper.  I haven't\nrealized that changing this will lead to a subtle bug though.  The\nfunction is responsible to track the caller as well.  This caller is\nthen printed by /proc/vmallocinfo.  If __vmalloc_node_flags is not\ninline then we would get only direct users of __vmalloc_node_flags as\ncallers (e.g.  v[mz]alloc) which reduces usefulness of this debugging\nfeature considerably.  It simply doesn't help to see that the given\nrange belongs to vmalloc as a caller:\n\n  0xffffc90002c79000-0xffffc90002c7d000   16384 vmalloc+0x16/0x18 pages=3 vmalloc N0=3\n  0xffffc90002c81000-0xffffc90002c85000   16384 vmalloc+0x16/0x18 pages=3 vmalloc N1=3\n  0xffffc90002c8d000-0xffffc90002c91000   16384 vmalloc+0x16/0x18 pages=3 vmalloc N1=3\n  0xffffc90002c95000-0xffffc90002c99000   16384 vmalloc+0x16/0x18 pages=3 vmalloc N1=3\n\nWe really want to catch the _caller_ of the vmalloc function.  Fix this\nissue by making __vmalloc_node_flags static inline again.\n\nLink: http://lkml.kernel.org/r/20170502134657.12381-1-mhocko@kernel.org\nSigned-off-by: Michal Hocko <mhocko@suse.com>\nCc: Vlastimil Babka <vbabka@suse.cz>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/b72f4bbecd42e1db043143e4818ba2e6c02f1b0d"},{"sha":"95dcdd81c7ed1b37c893598ebc26193205218454","author":{"name":"Michal Hocko","email":"829500b200af6c2a0eca4dfd5c388e6b8fbe8dc6@suse.com"},"message":"mm, vmalloc: use __GFP_HIGHMEM implicitly\n\n__vmalloc* allows users to provide gfp flags for the underlying\nallocation.  This API is quite popular\n\n  $ git grep \"=[[:space:]]__vmalloc\\|return[[:space:]]*__vmalloc\" | wc -l\n  77\n\nThe only problem is that many people are not aware that they really want\nto give __GFP_HIGHMEM along with other flags because there is really no\nreason to consume precious lowmemory on CONFIG_HIGHMEM systems for pages\nwhich are mapped to the kernel vmalloc space.  About half of users don't\nuse this flag, though.  This signals that we make the API unnecessarily\ntoo complex.\n\nThis patch simply uses __GFP_HIGHMEM implicitly when allocating pages to\nbe mapped to the vmalloc space.  Current users which add __GFP_HIGHMEM\nare simplified and drop the flag.\n\nLink: http://lkml.kernel.org/r/20170307141020.29107-1-mhocko@kernel.org\nSigned-off-by: Michal Hocko <mhocko@suse.com>\nReviewed-by: Matthew Wilcox <mawilcox@microsoft.com>\nCc: Al Viro <viro@zeniv.linux.org.uk>\nCc: Vlastimil Babka <vbabka@suse.cz>\nCc: David Rientjes <rientjes@google.com>\nCc: Cristopher Lameter <cl@linux.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/95dcdd81c7ed1b37c893598ebc26193205218454"},{"sha":"a8f6cb829b5c6fb53e8bc3d3975b6a91b091f535","author":{"name":"Michal Hocko","email":"829500b200af6c2a0eca4dfd5c388e6b8fbe8dc6@suse.com"},"message":"mm, vmalloc: fix vmalloc users tracking properly\n\nCommit 1f5307b1e094 (\"mm, vmalloc: properly track vmalloc users\") has\npulled asm/pgtable.h include dependency to linux/vmalloc.h and that\nturned out to be a bad idea for some architectures.  E.g.  m68k fails\nwith\n\n   In file included from arch/m68k/include/asm/pgtable_mm.h:145:0,\n                    from arch/m68k/include/asm/pgtable.h:4,\n                    from include/linux/vmalloc.h:9,\n                    from arch/m68k/kernel/module.c:9:\n   arch/m68k/include/asm/mcf_pgtable.h: In function 'nocache_page':\n>> arch/m68k/include/asm/mcf_pgtable.h:339:43: error: 'init_mm' undeclared (first use in this function)\n    #define pgd_offset_k(address) pgd_offset(&init_mm, address)\n\nas spotted by kernel build bot. nios2 fails for other reason\n\n  In file included from include/asm-generic/io.h:767:0,\n                   from arch/nios2/include/asm/io.h:61,\n                   from include/linux/io.h:25,\n                   from arch/nios2/include/asm/pgtable.h:18,\n                   from include/linux/mm.h:70,\n                   from include/linux/pid_namespace.h:6,\n                   from include/linux/ptrace.h:9,\n                   from arch/nios2/include/uapi/asm/elf.h:23,\n                   from arch/nios2/include/asm/elf.h:22,\n                   from include/linux/elf.h:4,\n                   from include/linux/module.h:15,\n                   from init/main.c:16:\n  include/linux/vmalloc.h: In function '__vmalloc_node_flags':\n  include/linux/vmalloc.h:99:40: error: 'PAGE_KERNEL' undeclared (first use in this function); did you mean 'GFP_KERNEL'?\n\nwhich is due to the newly added #include <asm/pgtable.h>, which on nios2\nincludes <linux/io.h> and thus <asm/io.h> and <asm-generic/io.h> which\nagain includes <linux/vmalloc.h>.\n\nTweaking that around just turns out a bigger headache than necessary.\nThis patch reverts 1f5307b1e094 and reimplements the original fix in a\ndifferent way.  __vmalloc_node_flags can stay static inline which will\ncover vmalloc* functions.  We only have one external user\n(kvmalloc_node) and we can export __vmalloc_node_flags_caller and\nprovide the caller directly.  This is much simpler and it doesn't really\nneed any games with header files.\n\n[akpm@linux-foundation.org: coding-style fixes]\n[mhocko@kernel.org: revert old comment]\n  Link: http://lkml.kernel.org/r/20170509211054.GB16325@dhcp22.suse.cz\nFixes: 1f5307b1e094 (\"mm, vmalloc: properly track vmalloc users\")\nLink: http://lkml.kernel.org/r/20170509153702.GR6481@dhcp22.suse.cz\nSigned-off-by: Michal Hocko <mhocko@suse.com>\nCc: Tobias Klauser <tklauser@distanz.ch>\nCc: Geert Uytterhoeven <geert@linux-m68k.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/a8f6cb829b5c6fb53e8bc3d3975b6a91b091f535"},{"sha":"025fedace0258129f4e2add3d35f28fef074fe15","author":{"name":"Laura Abbott","email":"b8f3952ea9a7ddc193d05c7cc03f120086c69f1e@redhat.com"},"message":"mm/vmalloc.c: don't unconditonally use __GFP_HIGHMEM\n\nCommit 19809c2da28a (\"mm, vmalloc: use __GFP_HIGHMEM implicitly\") added\nuse of __GFP_HIGHMEM for allocations.  vmalloc_32 may use\nGFP_DMA/GFP_DMA32 which does not play nice with __GFP_HIGHMEM and will\ntrigger a BUG in gfp_zone.\n\nOnly add __GFP_HIGHMEM if we aren't using GFP_DMA/GFP_DMA32.\n\nBugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1482249\nLink: http://lkml.kernel.org/r/20170816220705.31374-1-labbott@redhat.com\nFixes: 19809c2da28a (\"mm, vmalloc: use __GFP_HIGHMEM implicitly\")\nSigned-off-by: Laura Abbott <labbott@redhat.com>\nAcked-by: Michal Hocko <mhocko@suse.com>\nCc: Vlastimil Babka <vbabka@suse.cz>\nCc: \"Kirill A. Shutemov\" <kirill.shutemov@linux.intel.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/025fedace0258129f4e2add3d35f28fef074fe15"},{"sha":"a9cbe186aaa579e0a6728cec9650e784814b95bb","author":{"name":"Catalin Marinas","email":"15ce75b290ebaf27c3f9fd73ab848685ed3d8261@arm.com"},"message":"mm: kmemleak: slightly reduce the size of some structures on 64-bit architectures\n\nChange the kmemleak_object.flags type to unsigned int and moves the\nearly_log.min_count (int) near early_log.op_type (int) to slightly\nreduce the size of these structures on 64-bit architectures.\n\nLink: http://lkml.kernel.org/r/1495726937-23557-2-git-send-email-catalin.marinas@arm.com\nSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>\nCc: Michal Hocko <mhocko@kernel.org>\nCc: Andy Lutomirski <luto@amacapital.net>\nCc: \"Luis R. Rodriguez\" <mcgrof@kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/a9cbe186aaa579e0a6728cec9650e784814b95bb"},{"sha":"4b62cd6dd8979c58bf966d3caa3e68d6d0c0360b","author":{"name":"Catalin Marinas","email":"15ce75b290ebaf27c3f9fd73ab848685ed3d8261@arm.com"},"message":"mm: kmemleak: factor object reference updating out of scan_block()\n\nscan_block() updates the number of references (pointers) to objects,\nadding them to the gray_list when object->min_count is reached.  The\npatch factors out this functionality into a separate update_refs()\nfunction.\n\nLink: http://lkml.kernel.org/r/1495726937-23557-3-git-send-email-catalin.marinas@arm.com\nSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>\nCc: Michal Hocko <mhocko@kernel.org>\nCc: Andy Lutomirski <luto@amacapital.net>\nCc: \"Luis R. Rodriguez\" <mcgrof@kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/4b62cd6dd8979c58bf966d3caa3e68d6d0c0360b"},{"sha":"86c90ddfb566670ea6ee29b672b92d8cf85bb88b","author":{"name":"Catalin Marinas","email":"15ce75b290ebaf27c3f9fd73ab848685ed3d8261@arm.com"},"message":"mm: kmemleak: treat vm_struct as alternative reference to vmalloc'ed objects\n\nKmemleak requires that vmalloc'ed objects have a minimum reference count\nof 2: one in the corresponding vm_struct object and the other owned by\nthe vmalloc() caller.  There are cases, however, where the original\nvmalloc() returned pointer is lost and, instead, a pointer to vm_struct\nis stored (see free_thread_stack()).  Kmemleak currently reports such\nobjects as leaks.\n\nThis patch adds support for treating any surplus references to an object\nas additional references to a specified object.  It introduces the\nkmemleak_vmalloc() API function which takes a vm_struct pointer and sets\nits surplus reference passing to the actual vmalloc() returned pointer.\nThe __vmalloc_node_range() calling site has been modified accordingly.\n\nLink: http://lkml.kernel.org/r/1495726937-23557-4-git-send-email-catalin.marinas@arm.com\nSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>\nReported-by: \"Luis R. Rodriguez\" <mcgrof@kernel.org>\nCc: Michal Hocko <mhocko@kernel.org>\nCc: Andy Lutomirski <luto@amacapital.net>\nCc: \"Luis R. Rodriguez\" <mcgrof@kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/86c90ddfb566670ea6ee29b672b92d8cf85bb88b"},{"sha":"9c279158ceaf640222130deec84bfad9cac5207a","author":{"name":"Wei Yang","email":"625b313770607d27ce1f12b6d57a9f50d742bd94@gmail.com"},"message":"mm/vmalloc.c: halve the number of comparisons performed in pcpu_get_vm_areas()\n\nIn pcpu_get_vm_areas(), it checks each range is not overlapped.  To make\nsure it is, only (N^2)/2 comparison is necessary, while current code\ndoes N^2 times.  By starting from the next range, it achieves the goal\nand the continue could be removed.\n\nAlso,\n\n - the overlap check of two ranges could be done with one clause\n\n - one typo in comment is fixed.\n\nLink: http://lkml.kernel.org/r/20170803063822.48702-1-richard.weiyang@gmail.com\nSigned-off-by: Wei Yang <richard.weiyang@gmail.com>\nAcked-by: Tejun Heo <tj@kernel.org>\nCc: Michal Hocko <mhocko@kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/9c279158ceaf640222130deec84bfad9cac5207a"},{"sha":"f7286bb8bd2d9a30a952742701ed5121017893a5","author":{"name":"Byungchul Park","email":"e40c5f8992a9890dae9876367c0c4ab1dc1f880b@lge.com"},"message":"mm/vmalloc.c: don't reinvent the wheel but use existing llist API\n\nAlthough llist provides proper APIs, they are not used.  Make them used.\n\nLink: http://lkml.kernel.org/r/1502095374-16112-1-git-send-email-byungchul.park@lge.com\nSigned-off-by: Byungchul Park <byungchul.park@lge.com>\nCc: zijun_hu <zijun_hu@htc.com>\nCc: Michal Hocko <mhocko@suse.com>\nCc: Vlastimil Babka <vbabka@suse.cz>\nCc: Joel Fernandes <joelaf@google.com>\nCc: Andrey Ryabinin <aryabinin@virtuozzo.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/f7286bb8bd2d9a30a952742701ed5121017893a5"},{"sha":"7a5bb92b0a438bdb472003c71eeb1316435fc500","author":{"name":"Michal Hocko","email":"829500b200af6c2a0eca4dfd5c388e6b8fbe8dc6@suse.com"},"message":"vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems\n\nKai Heng Feng has noticed that BUG_ON(PageHighMem(pg)) triggers in\ndrivers/media/common/saa7146/saa7146_core.c since 19809c2da28a (\"mm,\nvmalloc: use __GFP_HIGHMEM implicitly\").\n\nsaa7146_vmalloc_build_pgtable uses vmalloc_32 and it is reasonable to\nexpect that the resulting page is not in highmem.  The above commit\naimed to add __GFP_HIGHMEM only for those requests which do not specify\nany zone modifier gfp flag.  vmalloc_32 relies on GFP_VMALLOC32 which\nshould do the right thing.  Except it has been missed that GFP_VMALLOC32\nis an alias for GFP_KERNEL on 32b architectures.  Thanks to Matthew to\nnotice this.\n\nFix the problem by unconditionally setting GFP_DMA32 in GFP_VMALLOC32\nfor !64b arches (as a bailout).  This should do the right thing and use\nZONE_NORMAL which should be always below 4G on 32b systems.\n\nDebugged by Matthew Wilcox.\n\n[akpm@linux-foundation.org: coding-style fixes]\nLink: http://lkml.kernel.org/r/20180212095019.GX21609@dhcp22.suse.cz\nFixes: 19809c2da28a (\"mm, vmalloc: use __GFP_HIGHMEM implicitly”)\nSigned-off-by: Michal Hocko <mhocko@suse.com>\nReported-by: Kai Heng Feng <kai.heng.feng@canonical.com>\nCc: Matthew Wilcox <willy@infradead.org>\nCc: Laura Abbott <labbott@redhat.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/7a5bb92b0a438bdb472003c71eeb1316435fc500"},{"sha":"1ad1639a28dc664644253d8fafaee04e51705bcf","author":{"name":"Chintan Pandya","email":"f8ab2c5e1dd93cba379c44b5945c0110170970c1@codeaurora.org"},"message":"mm: vmalloc: clean up vunmap to avoid pgtable ops twice\n\nvunmap does page table clear operations twice in the case when\nDEBUG_PAGEALLOC_ENABLE_DEFAULT is enabled.\n\nSo, clean up the code as that is unintended.\n\nAs a perf gain, we save few us.  Below ftrace data was obtained while\ndoing 1 MB of vmalloc/vfree on ARM64 based SoC *without* this patch\napplied.  After this patch, we can save ~3 us (on 1 extra\nvunmap_page_range).\n\n  CPU  DURATION                  FUNCTION CALLS\n  |     |   |                     |   |   |   |\n 6)               |  __vunmap() {\n 6)               |    vmap_debug_free_range() {\n 6)   3.281 us    |      vunmap_page_range();\n 6) + 45.468 us   |    }\n 6)   2.760 us    |    vunmap_page_range();\n 6) ! 505.105 us  |  }\n\n[cpandya@codeaurora.org: v3]\n  Link: http://lkml.kernel.org/r/1525176960-18408-1-git-send-email-cpandya@codeaurora.org\nLink: http://lkml.kernel.org/r/1523876342-10545-1-git-send-email-cpandya@codeaurora.org\nSigned-off-by: Chintan Pandya <cpandya@codeaurora.org>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nCc: Vlastimil Babka <vbabka@suse.cz>\nCc: Laura Abbott <labbott@redhat.com>\nCc: Catalin Marinas <catalin.marinas@arm.com>\nCc: Johannes Weiner <hannes@cmpxchg.org>\nCc: Florian Fainelli <f.fainelli@gmail.com>\nCc: Yisheng Xie <xieyisheng1@huawei.com>\nCc: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nCc: Wei Yang <richard.weiyang@gmail.com>\nCc: Byungchul Park <byungchul.park@lge.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/1ad1639a28dc664644253d8fafaee04e51705bcf"},{"sha":"f3d56ddb223185f5221e0b3447cb78eb38300ff8","author":{"name":"Chintan Pandya","email":"f8ab2c5e1dd93cba379c44b5945c0110170970c1@codeaurora.org"},"message":"mm: vmalloc: pass proper vm_start into debugobjects\n\nClient can call vunmap with some intermediate 'addr' which may not be\nthe start of the VM area.  Entire unmap code works with vm->vm_start\nwhich is proper but debug object API is called with 'addr'.  This could\nbe a problem within debug objects.\n\nPass proper start address into debug object API.\n\n[akpm@linux-foundation.org: fix warning]\nLink: http://lkml.kernel.org/r/1523961828-9485-3-git-send-email-cpandya@codeaurora.org\nSigned-off-by: Chintan Pandya <cpandya@codeaurora.org>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nCc: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nCc: Byungchul Park <byungchul.park@lge.com>\nCc: Catalin Marinas <catalin.marinas@arm.com>\nCc: Florian Fainelli <f.fainelli@gmail.com>\nCc: Johannes Weiner <hannes@cmpxchg.org>\nCc: Laura Abbott <labbott@redhat.com>\nCc: Vlastimil Babka <vbabka@suse.cz>\nCc: Wei Yang <richard.weiyang@gmail.com>\nCc: Yisheng Xie <xieyisheng1@huawei.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/f3d56ddb223185f5221e0b3447cb78eb38300ff8"},{"sha":"91b1771f96aa8573254af0ca8b5db0683d8902b1","author":{"name":"Luis R. Rodriguez","email":"d4fa18192c5a479e564d29c2300c2e15afd1d8d7@kernel.org"},"message":"mm: provide a fallback for PAGE_KERNEL_EXEC for architectures\n\nSome architectures just don't have PAGE_KERNEL_EXEC.  The mm/nommu.c and\nmm/vmalloc.c code have been using PAGE_KERNEL as a fallback for years.\nMove this fallback to asm-generic.\n\nLink: http://lkml.kernel.org/r/20180510185507.2439-3-mcgrof@kernel.org\nSigned-off-by: Luis R. Rodriguez <mcgrof@kernel.org>\nSuggested-by: Matthew Wilcox <willy@infradead.org>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nCc: Arnd Bergmann <arnd@arndb.de>\nCc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nCc: Geert Uytterhoeven <geert@linux-m68k.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/91b1771f96aa8573254af0ca8b5db0683d8902b1"},{"sha":"f51b0f90b939d25735bb743932936070eb9043ad","author":{"name":"Andrey Ryabinin","email":"1db0f9e76dd8a9115570382660c6cd919b5a95b9@virtuozzo.com"},"message":"vfree: add debug might_sleep()\n\nAdd might_sleep() call to vfree() to catch potential sleep-in-atomic bugs\nearlier.\n\n[aryabinin@virtuozzo.com: drop might_sleep_if() from kvfree()]\n  Link: http://lkml.kernel.org/r/7e19e4df-b1a6-29bd-9ae7-0266d50bef1d@virtuozzo.com\nLink: http://lkml.kernel.org/r/20180914130512.10394-3-aryabinin@virtuozzo.com\nSigned-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/f51b0f90b939d25735bb743932936070eb9043ad"},{"sha":"fb8795778bdfb5d29321859667d6c715bc104b4d","author":{"name":"Arun KS","email":"38554de63a792bf9e80ee818d908d226bcb5d1ac@codeaurora.org"},"message":"BACKPORTED: mm: convert totalram_pages and totalhigh_pages variables to atomic\n\ntotalram_pages and totalhigh_pages are made static inline function.\n\nMain motivation was that managed_page_count_lock handling was complicating\nthings.  It was discussed in length here,\nhttps://lore.kernel.org/patchwork/patch/995739/#1181785 So it seemes\nbetter to remove the lock and convert variables to atomic, with preventing\npoteintial store-to-read tearing as a bonus.\n\n[akpm@linux-foundation.org: coding style fixes]\nLink: http://lkml.kernel.org/r/1542090790-21750-4-git-send-email-arunks@codeaurora.org\nSigned-off-by: Arun KS <arunks@codeaurora.org>\nSuggested-by: Michal Hocko <mhocko@suse.com>\nSuggested-by: Vlastimil Babka <vbabka@suse.cz>\nReviewed-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>\nReviewed-by: Pavel Tatashin <pasha.tatashin@soleen.com>\nAcked-by: Michal Hocko <mhocko@suse.com>\nAcked-by: Vlastimil Babka <vbabka@suse.cz>\nCc: David Hildenbrand <david@redhat.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Angelo G. Del Regno <kholk11@gmail.com>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/fb8795778bdfb5d29321859667d6c715bc104b4d"},{"sha":"5e25bab181a1d70c3a6579c31205f33a5e3f8011","author":{"name":"Liviu Dudau","email":"e1b4b92edef483791b6339ac03e7cb6e6fdb865d@dudau.co.uk"},"message":"mm/vmalloc.c: don't dereference possible NULL pointer in __vunmap()\n\nfind_vmap_area() can return a NULL pointer and we're going to\ndereference it without checking it first.  Use the existing\nfind_vm_area() function which does exactly what we want and checks for\nthe NULL pointer.\n\nLink: http://lkml.kernel.org/r/20181228171009.22269-1-liviu@dudau.co.uk\nFixes: f3c01d2f3ade (\"mm: vmalloc: avoid racy handling of debugobjects in vunmap\")\nSigned-off-by: Liviu Dudau <liviu@dudau.co.uk>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nCc: Chintan Pandya <cpandya@codeaurora.org>\nCc: Andrey Ryabinin <aryabinin@virtuozzo.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/5e25bab181a1d70c3a6579c31205f33a5e3f8011"},{"sha":"4ced33d9985102102ed5e88e1dc3ff55da6d2c78","author":{"name":"Roman Penyaev","email":"5ffa6b82cf9ad80649a6dfab98886ec472da14b5@suse.de"},"message":"mm/vmalloc.c: make vmalloc_32_user() align base kernel virtual address to SHMLBA\n\nThis patch repeats the original one from David S Miller:\n\n  2dca6999eed5 (\"mm, perf_event: Make vmalloc_user() align base kernel virtual address to SHMLBA\")\n\nbut for missed vmalloc_32_user() case, which also requires correct\nalignment of virtual address on kernel side to avoid D-caches aliases.\nA bit of copy-paste from original patch to recover in memory of what is\nall about:\n\n  When a vmalloc'd area is mmap'd into userspace, some kind of\n  co-ordination is necessary for this to work on platforms with cpu\n  D-caches which can have aliases.\n\n  Otherwise kernel side writes won't be seen properly in userspace and\n  vice versa.\n\n  If the kernel side mapping and the user side one have the same\n  alignment, modulo SHMLBA, this can work as long as VM_SHARED is shared\n  of VMA and for all current users this is true. VM_SHARED will force\n  SHMLBA alignment of the user side mmap on platforms with D-cache\n  aliasing matters.\n\n  David S. Miller\n\n> What are the user-visible runtime effects of this change?\n\nIn simple words: proper alignment avoids possible difference in data,\nseen by different virtual mapings: userspace and kernel in our case.\nI.e. userspace reads cache line A, kernel writes to cache line B.  Both\ncache lines correspond to the same physical memory (thus aliases).\n\nSo this should fix data corruption for archs with vivt and vipt caches,\ne.g. armv6.  Personally I've never worked with this archs, I just\nspotted the strange difference in code: for one case we do alignment,\nfor another - not.  I have a strong feeling that David simply missed\nvmalloc_32_user() case.\n\n>\n> Is a -stable backport needed?\n\nNo, I do not think so.  The only one user of vmalloc_32_user() is\nvirtual frame buffer device drivers/video/fbdev/vfb.c, which has in the\ndescription \"The main use of this frame buffer device is testing and\ndebugging the frame buffer subsystem.  Do NOT enable it for normal\nsystems!\".\n\nAnd it seems to me that this vfb.c does not need 32bit addressable pages\n(vmalloc_32_user() case), because it is virtual device and should not\ncare about things like dma32 zones, etc.  Probably is better to clean\nthe code and switch vfb.c from vmalloc_32_user() to vmalloc_user() case\nand wipe out vmalloc_32_user() from vmalloc.c completely.  But I'm not\nvery much sure that this is worth to do, that's so minor, so we can\nleave it as is.\n\nLink: http://lkml.kernel.org/r/20190108110944.23591-1-rpenyaev@suse.de\nSigned-off-by: Roman Penyaev <rpenyaev@suse.de>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nCc: Stephen Rothwell <sfr@canb.auug.org.au>\nCc: Michal Hocko <mhocko@suse.com>\nCc: David S. Miller <davem@davemloft.net>\nCc: Peter Zijlstra <peterz@infradead.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/4ced33d9985102102ed5e88e1dc3ff55da6d2c78"},{"sha":"9e9ea79956f7dc3e7940fd64a8371f96eca692f9","author":{"name":"Roman Penyaev","email":"5ffa6b82cf9ad80649a6dfab98886ec472da14b5@suse.de"},"message":"mm/vmalloc: do not call kmemleak_free() on not yet accounted memory\n\n__vmalloc_area_node() calls vfree() on error path, which in turn calls\nkmemleak_free(), but area is not yet accounted by kmemleak_vmalloc().\n\nLink: http://lkml.kernel.org/r/20190103145954.16942-3-rpenyaev@suse.de\nSigned-off-by: Roman Penyaev <rpenyaev@suse.de>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nCc: Michal Hocko <mhocko@suse.com>\nCc: Andrey Ryabinin <aryabinin@virtuozzo.com>\nCc: Joe Perches <joe@perches.com>\nCc: \"Luis R. Rodriguez\" <mcgrof@kernel.org>\nCc: Catalin Marinas <catalin.marinas@arm.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/9e9ea79956f7dc3e7940fd64a8371f96eca692f9"},{"sha":"ad9e261d15fba2992481c1ad22eaad206429f304","author":{"name":"Roman Penyaev","email":"5ffa6b82cf9ad80649a6dfab98886ec472da14b5@suse.de"},"message":"mm/vmalloc: pass VM_USERMAP flags directly to __vmalloc_node_range()\n\nvmalloc_user*() calls differ from normal vmalloc() only in that they set\nVM_USERMAP flags for the area.  During the whole history of vmalloc.c\nchanges now it is possible simply to pass VM_USERMAP flags directly to\n__vmalloc_node_range() call instead of finding the area (which obviously\ntakes time) after the allocation.\n\nLink: http://lkml.kernel.org/r/20190103145954.16942-4-rpenyaev@suse.de\nSigned-off-by: Roman Penyaev <rpenyaev@suse.de>\nAcked-by: Michal Hocko <mhocko@suse.com>\nCc: Andrey Ryabinin <aryabinin@virtuozzo.com>\nCc: Joe Perches <joe@perches.com>\nCc: \"Luis R. Rodriguez\" <mcgrof@kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/lazerl0rd/kernel/commits/ad9e261d15fba2992481c1ad22eaad206429f304"}]}
{"actor":{"display_login":"lazerl0rd"}}