{"push_id":3116841790,"size":1000,"distinct_size":5,"ref":"refs/heads/for-upstream/atmel-mxt-fixes","head":"ebf4dd1c045138705d278d5bf1f42e2a91e21329","before":"3d4dd7829af1b1f4ee57d9622ed33a162515cec6","commits":[{"sha":"8a02bdd50b2ecb6d62121d2958d3ea186cc88ce7","author":{"name":"Jozsef Kadlecsik","email":"5a7b97a838c5f3992292d1fd9e7ad830cc55ada6@blackhole.kfki.hu"},"message":"netfilter: ipset: Fix calling ip_set() macro at dumping\n\nThe ip_set() macro is called when either ip_set_ref_lock held only\nor no lock/nfnl mutex is held at dumping. Take this into account\nproperly. Also, use Pablo's suggestion to use rcu_dereference_raw(),\nthe ref_netlink protects the set.\n\nSigned-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/8a02bdd50b2ecb6d62121d2958d3ea186cc88ce7"},{"sha":"a95a7774d51e13f9cf4b7285666829b68852f07a","author":{"name":"Pablo Neira Ayuso","email":"707d14912bb250caf67dfe0ea4035681fbfc4f56@netfilter.org"},"message":"netfilter: conntrack: add nf_{tcp,udp,sctp,icmp,dccp,icmpv6,generic}_pernet()\n\nExpose these functions to access conntrack protocol tracker netns area,\nnfnetlink_cttimeout needs this.\n\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/a95a7774d51e13f9cf4b7285666829b68852f07a"},{"sha":"8866df9264a34e675b4ee8a151db819b87cce2d3","author":{"name":"Pablo Neira Ayuso","email":"707d14912bb250caf67dfe0ea4035681fbfc4f56@netfilter.org"},"message":"netfilter: nfnetlink_cttimeout: pass default timeout policy to obj_to_nlattr\n\nOtherwise, we hit a NULL pointer deference since handlers always assume\ndefault timeout policy is passed.\n\n  netlink: 24 bytes leftover after parsing attributes in process `syz-executor2'.\n  kasan: CONFIG_KASAN_INLINE enabled\n  kasan: GPF could be caused by NULL-ptr deref or user memory access\n  general protection fault: 0000 [#1] PREEMPT SMP KASAN\n  CPU: 0 PID: 9575 Comm: syz-executor1 Not tainted 4.19.0+ #312\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n  RIP: 0010:icmp_timeout_obj_to_nlattr+0x77/0x170 net/netfilter/nf_conntrack_proto_icmp.c:297\n\nFixes: c779e849608a (\"netfilter: conntrack: remove get_timeout() indirection\")\nReported-by: Eric Dumazet <eric.dumazet@gmail.com>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/8866df9264a34e675b4ee8a151db819b87cce2d3"},{"sha":"e4844c9c62a0fe47980d6c3d4b7a096a5d755925","author":{"name":"Florian Westphal","email":"cef439e78636cdab99cd2923826c5065a0743e5b@strlen.de"},"message":"netfilter: nft_compat: ebtables 'nat' table is normal chain type\n\nUnlike ip(6)tables, the ebtables nat table has no special properties.\nThis bug causes 'ebtables -A' to fail when using a target such as\n'snat' (ebt_snat target sets \".table = \"nat\"').  Targets that have\nno table restrictions work fine.\n\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/e4844c9c62a0fe47980d6c3d4b7a096a5d755925"},{"sha":"f393808dc64149ccd0e5a8427505ba2974a59854","author":{"name":"Vasily Khoruzhick","email":"8d423c6462c386eeb08996628b7802c179650542@arista.com"},"message":"netfilter: conntrack: fix calculation of next bucket number in early_drop\n\nIf there's no entry to drop in bucket that corresponds to the hash,\nearly_drop() should look for it in other buckets. But since it increments\nhash instead of bucket number, it actually looks in the same bucket 8\ntimes: hsize is 16k by default (14 bits) and hash is 32-bit value, so\nreciprocal_scale(hash, hsize) returns the same value for hash..hash+7 in\nmost cases.\n\nFix it by increasing bucket number instead of hash and rename _hash\nto bucket to avoid future confusion.\n\nFixes: 3e86638e9a0b (\"netfilter: conntrack: consider ct netns in early_drop logic\")\nCc: <stable@vger.kernel.org> # v4.7+\nSigned-off-by: Vasily Khoruzhick <vasilykh@arista.com>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/f393808dc64149ccd0e5a8427505ba2974a59854"},{"sha":"e68599a3c3ad0f3171a7cb4e48aa6f9a69381902","author":{"name":"Roman Gushchin","email":"8c2caf221cab692fe667556bdd683727bc401c9e@fb.com"},"message":"mm: handle no memcg case in memcg_kmem_charge() properly\n\nMike Galbraith reported a regression caused by the commit 9b6f7e163cd0\n(\"mm: rework memcg kernel stack accounting\") on a system with\n\"cgroup_disable=memory\" boot option: the system panics with the following\nstack trace:\n\n  BUG: unable to handle kernel NULL pointer dereference at 00000000000000f8\n  PGD 0 P4D 0\n  Oops: 0002 [#1] PREEMPT SMP PTI\n  CPU: 0 PID: 1 Comm: systemd Not tainted 4.19.0-preempt+ #410\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20180531_142017-buildhw-08.phx2.fed4\n  RIP: 0010:page_counter_try_charge+0x22/0xc0\n  Code: 41 5d c3 c3 0f 1f 40 00 0f 1f 44 00 00 48 85 ff 0f 84 a7 00 00 00 41 56 48 89 f8 49 89 fe 49\n  Call Trace:\n   try_charge+0xcb/0x780\n   memcg_kmem_charge_memcg+0x28/0x80\n   memcg_kmem_charge+0x8b/0x1d0\n   copy_process.part.41+0x1ca/0x2070\n   _do_fork+0xd7/0x3d0\n   do_syscall_64+0x5a/0x180\n   entry_SYSCALL_64_after_hwframe+0x49/0xbe\n\nThe problem occurs because get_mem_cgroup_from_current() returns the NULL\npointer if memory controller is disabled.  Let's check if this is a case\nat the beginning of memcg_kmem_charge() and just return 0 if\nmem_cgroup_disabled() returns true.  This is how we handle this case in\nmany other places in the memory controller code.\n\nLink: http://lkml.kernel.org/r/20181029215123.17830-1-guro@fb.com\nFixes: 9b6f7e163cd0 (\"mm: rework memcg kernel stack accounting\")\nSigned-off-by: Roman Gushchin <guro@fb.com>\nReported-by: Mike Galbraith <efault@gmx.de>\nAcked-by: Rik van Riel <riel@surriel.com>\nAcked-by: Michal Hocko <mhocko@suse.com>\nCc: Johannes Weiner <hannes@cmpxchg.org>\nCc: Vladimir Davydov <vdavydov.dev@gmail.com>\nCc: Shakeel Butt <shakeelb@google.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/e68599a3c3ad0f3171a7cb4e48aa6f9a69381902"},{"sha":"94e297c50b529f5d01cfd1dbc808d61e95180ab7","author":{"name":"Sam Protsenko","email":"e3e0098ede0001339d6139e93917c216f5e40eec@linaro.org"},"message":"include/linux/notifier.h: SRCU: fix ctags\n\nctags indexing (\"make tags\" command) throws this warning:\n\n    ctags: Warning: include/linux/notifier.h:125:\n    null expansion of name pattern \"\\1\"\n\nThis is the result of DEFINE_PER_CPU() macro expansion.  Fix that by\ngetting rid of line break.\n\nSimilar fix was already done in commit 25528213fe9f (\"tags: Fix\nDEFINE_PER_CPU expansions\"), but this one probably wasn't noticed.\n\nLink: http://lkml.kernel.org/r/20181030202808.28027-1-semen.protsenko@linaro.org\nFixes: 9c80172b902d (\"kernel/SRCU: provide a static initializer\")\nSigned-off-by: Sam Protsenko <semen.protsenko@linaro.org>\nCc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>\nCc: Andy Shevchenko <andy.shevchenko@gmail.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/94e297c50b529f5d01cfd1dbc808d61e95180ab7"},{"sha":"ac5b2c18911ffe95c08d69273917f90212cf5659","author":{"name":"Andrea Arcangeli","email":"6cb163d975a8c4c46420677e0054b55c39bdb339@redhat.com"},"message":"mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings\n\nTHP allocation might be really disruptive when allocated on NUMA system\nwith the local node full or hard to reclaim.  Stefan has posted an\nallocation stall report on 4.12 based SLES kernel which suggests the\nsame issue:\n\n  kvm: page allocation stalls for 194572ms, order:9, mode:0x4740ca(__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_THISNODE|__GFP_MOVABLE|__GFP_DIRECT_RECLAIM), nodemask=(null)\n  kvm cpuset=/ mems_allowed=0-1\n  CPU: 10 PID: 84752 Comm: kvm Tainted: G        W 4.12.0+98-ph <a href=\"/view.php?id=1\" title=\"[geschlossen] Integration Ramdisk\" class=\"resolved\">0000001</a> SLE15 (unreleased)\n  Hardware name: Supermicro SYS-1029P-WTRT/X11DDW-NT, BIOS 2.0 12/05/2017\n  Call Trace:\n   dump_stack+0x5c/0x84\n   warn_alloc+0xe0/0x180\n   __alloc_pages_slowpath+0x820/0xc90\n   __alloc_pages_nodemask+0x1cc/0x210\n   alloc_pages_vma+0x1e5/0x280\n   do_huge_pmd_wp_page+0x83f/0xf00\n   __handle_mm_fault+0x93d/0x1060\n   handle_mm_fault+0xc6/0x1b0\n   __do_page_fault+0x230/0x430\n   do_page_fault+0x2a/0x70\n   page_fault+0x7b/0x80\n   [...]\n  Mem-Info:\n  active_anon:126315487 inactive_anon:1612476 isolated_anon:5\n   active_file:60183 inactive_file:245285 isolated_file:0\n   unevictable:15657 dirty:286 writeback:1 unstable:0\n   slab_reclaimable:75543 slab_unreclaimable:2509111\n   mapped:81814 shmem:31764 pagetables:370616 bounce:0\n   free:32294031 free_pcp:6233 free_cma:0\n  Node 0 active_anon:254680388kB inactive_anon:1112760kB active_file:240648kB inactive_file:981168kB unevictable:13368kB isolated(anon):0kB isolated(file):0kB mapped:280240kB dirty:1144kB writeback:0kB shmem:95832kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 81225728kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no\n  Node 1 active_anon:250583072kB inactive_anon:5337144kB active_file:84kB inactive_file:0kB unevictable:49260kB isolated(anon):20kB isolated(file):0kB mapped:47016kB dirty:0kB writeback:4kB shmem:31224kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 31897600kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no\n\nThe defrag mode is \"madvise\" and from the above report it is clear that\nthe THP has been allocated for MADV_HUGEPAGA vma.\n\nAndrea has identified that the main source of the problem is\n__GFP_THISNODE usage:\n\n: The problem is that direct compaction combined with the NUMA\n: __GFP_THISNODE logic in mempolicy.c is telling reclaim to swap very\n: hard the local node, instead of failing the allocation if there's no\n: THP available in the local node.\n:\n: Such logic was ok until __GFP_THISNODE was added to the THP allocation\n: path even with MPOL_DEFAULT.\n:\n: The idea behind the __GFP_THISNODE addition, is that it is better to\n: provide local memory in PAGE_SIZE units than to use remote NUMA THP\n: backed memory. That largely depends on the remote latency though, on\n: threadrippers for example the overhead is relatively low in my\n: experience.\n:\n: The combination of __GFP_THISNODE and __GFP_DIRECT_RECLAIM results in\n: extremely slow qemu startup with vfio, if the VM is larger than the\n: size of one host NUMA node. This is because it will try very hard to\n: unsuccessfully swapout get_user_pages pinned pages as result of the\n: __GFP_THISNODE being set, instead of falling back to PAGE_SIZE\n: allocations and instead of trying to allocate THP on other nodes (it\n: would be even worse without vfio type1 GUP pins of course, except it'd\n: be swapping heavily instead).\n\nFix this by removing __GFP_THISNODE for THP requests which are\nrequesting the direct reclaim.  This effectivelly reverts 5265047ac301\non the grounds that the zone/node reclaim was known to be disruptive due\nto premature reclaim when there was memory free.  While it made sense at\nthe time for HPC workloads without NUMA awareness on rare machines, it\nwas ultimately harmful in the majority of cases.  The existing behaviour\nis similar, if not as widespare as it applies to a corner case but\ncrucially, it cannot be tuned around like zone_reclaim_mode can.  The\ndefault behaviour should always be to cause the least harm for the\ncommon case.\n\nIf there are specialised use cases out there that want zone_reclaim_mode\nin specific cases, then it can be built on top.  Longterm we should\nconsider a memory policy which allows for the node reclaim like behavior\nfor the specific memory ranges which would allow a\n\n[1] http://lkml.kernel.org/r/20180820032204.9591-1-aarcange@redhat.com\n\nMel said:\n\n: Both patches look correct to me but I'm responding to this one because\n: it's the fix.  The change makes sense and moves further away from the\n: severe stalling behaviour we used to see with both THP and zone reclaim\n: mode.\n:\n: I put together a basic experiment with usemem configured to reference a\n: buffer multiple times that is 80% the size of main memory on a 2-socket\n: box with symmetric node sizes and defrag set to \"always\".  The defrag\n: setting is not the default but it would be functionally similar to\n: accessing a buffer with madvise(MADV_HUGEPAGE).  Usemem is configured to\n: reference the buffer multiple times and while it's not an interesting\n: workload, it would be expected to complete reasonably quickly as it fits\n: within memory.  The results were;\n:\n: usemem\n:                                   vanilla           noreclaim-v1\n: Amean     Elapsd-1       42.78 (   0.00%)       26.87 (  37.18%)\n: Amean     Elapsd-3       27.55 (   0.00%)        7.44 (  73.00%)\n: Amean     Elapsd-4        5.72 (   0.00%)        5.69 (   0.45%)\n:\n: This shows the elapsed time in seconds for 1 thread, 3 threads and 4\n: threads referencing buffers 80% the size of memory.  With the patches\n: applied, it's 37.18% faster for the single thread and 73% faster with two\n: threads.  Note that 4 threads showing little difference does not indicate\n: the problem is related to thread counts.  It's simply the case that 4\n: threads gets spread so their workload mostly fits in one node.\n:\n: The overall view from /proc/vmstats is more startling\n:\n:                          4.19.0-rc1  4.19.0-rc1\n:                             vanillanoreclaim-v1r1\n: Minor Faults               35593425      708164\n: Major Faults                 484088          36\n: Swap Ins                    3772837           0\n: Swap Outs                   3932295           0\n:\n: Massive amounts of swap in/out without the patch\n:\n: Direct pages scanned        6013214           0\n: Kswapd pages scanned              0           0\n: Kswapd pages reclaimed            0           0\n: Direct pages reclaimed      4033009           0\n:\n: Lots of reclaim activity without the patch\n:\n: Kswapd efficiency              100%        100%\n: Kswapd velocity               0.000       0.000\n: Direct efficiency               67%        100%\n: Direct velocity           11191.956       0.000\n:\n: Mostly from direct reclaim context as you'd expect without the patch.\n:\n: Page writes by reclaim  3932314.000       0.000\n: Page writes file                 19           0\n: Page writes anon            3932295           0\n: Page reclaim immediate        42336           0\n:\n: Writes from reclaim context is never good but the patch eliminates it.\n:\n: We should never have default behaviour to thrash the system for such a\n: basic workload.  If zone reclaim mode behaviour is ever desired but on a\n: single task instead of a global basis then the sensible option is to build\n: a mempolicy that enforces that behaviour.\n\nThis was a severe regression compared to previous kernels that made\nimportant workloads unusable and it starts when __GFP_THISNODE was\nadded to THP allocations under MADV_HUGEPAGE.  It is not a significant\nrisk to go to the previous behavior before __GFP_THISNODE was added, it\nworked like that for years.\n\nThis was simply an optimization to some lucky workloads that can fit in\na single node, but it ended up breaking the VM for others that can't\npossibly fit in a single node, so going back is safe.\n\n[mhocko@suse.com: rewrote the changelog based on the one from Andrea]\nLink: http://lkml.kernel.org/r/20180925120326.24392-2-mhocko@kernel.org\nFixes: 5265047ac301 (\"mm, thp: really limit transparent hugepage allocation to local node\")\nSigned-off-by: Andrea Arcangeli <aarcange@redhat.com>\nSigned-off-by: Michal Hocko <mhocko@suse.com>\nReported-by: Stefan Priebe <s.priebe@profihost.ag>\nDebugged-by: Andrea Arcangeli <aarcange@redhat.com>\nReported-by: Alex Williamson <alex.williamson@redhat.com>\nReviewed-by: Mel Gorman <mgorman@techsingularity.net>\nTested-by: Mel Gorman <mgorman@techsingularity.net>\nCc: Zi Yan <zi.yan@cs.rutgers.edu>\nCc: Vlastimil Babka <vbabka@suse.cz>\nCc: David Rientjes <rientjes@google.com>\nCc: \"Kirill A. Shutemov\" <kirill@shutemov.name>\nCc: <stable@vger.kernel.org>\t[4.1+]\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/ac5b2c18911ffe95c08d69273917f90212cf5659"},{"sha":"a634644751c46238df58bbfe992e30c1668388db","author":{"name":"Gang He","email":"2e4790562711923f45b41a0580b92090cd94a2e1@suse.com"},"message":"ocfs2: remove ocfs2_is_o2cb_active()\n\nRemove ocfs2_is_o2cb_active().  We have similar functions to identify\nwhich cluster stack is being used via osb->osb_cluster_stack.\n\nSecondly, the current implementation of ocfs2_is_o2cb_active() is not\ntotally safe.  Based on the design of stackglue, we need to get\nocfs2_stack_lock before using ocfs2_stack related data structures, and\nthat active_stack pointer can be NULL in the case of mount failure.\n\nLink: http://lkml.kernel.org/r/1495441079-11708-1-git-send-email-ghe@suse.com\nSigned-off-by: Gang He <ghe@suse.com>\nReviewed-by: Joseph Qi <jiangqi903@gmail.com>\nReviewed-by: Eric Ren <zren@suse.com>\nAcked-by: Changwei Ge <ge.changwei@h3c.com>\nCc: Mark Fasheh <mark@fasheh.com>\nCc: Joel Becker <jlbec@evilplan.org>\nCc: Junxiao Bi <junxiao.bi@oracle.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/a634644751c46238df58bbfe992e30c1668388db"},{"sha":"21158ca85b73ddd0088076a5209cfd040513a8b5","author":{"name":"Guozhonghua","email":"c9e81aab04e6364945133f8d716627cc682a81db@h3c.com"},"message":"ocfs2: without quota support, avoid calling quota recovery\n\nDuring one dead node's recovery by other node, quota recovery work will\nbe queued.  We should avoid calling quota when it is not supported, so\ncheck the quota flags.\n\nLink: http://lkml.kernel.org/r/71604351584F6A4EBAE558C676F37CA401071AC9FB@H3CMLB12-EX.srv.huawei-3com.com\nSigned-off-by: guozhonghua <guozhonghua@h3c.com>\nReviewed-by: Jan Kara <jack@suse.cz>\nCc: Mark Fasheh <mark@fasheh.com>\nCc: Joel Becker <jlbec@evilplan.org>\nCc: Junxiao Bi <junxiao.bi@oracle.com>\nCc: Joseph Qi <jiangqi903@gmail.com>\nCc: Changwei Ge <ge.changwei@h3c.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/21158ca85b73ddd0088076a5209cfd040513a8b5"},{"sha":"9e985787750db8aae87f02b67e908f28ac4d6b83","author":{"name":"Changwei Ge","email":"426c7ff62140bfc2cdb2378eb8f3d7f86c8efe1c@h3c.com"},"message":"ocfs2: don't use iocb when EIOCBQUEUED returns\n\nWhen -EIOCBQUEUED returns, it means that aio_complete() will be called\nfrom dio_complete(), which is an asynchronous progress against\nwrite_iter.  Generally, IO is a very slow progress than executing\ninstruction, but we still can't take the risk to access a freed iocb.\n\nAnd we do face a BUG crash issue.  Using the crash tool, iocb is\nobviously freed already.\n\n  crash> struct -x kiocb ffff881a350f5900\n  struct kiocb {\n    ki_filp = 0xffff881a350f5a80,\n    ki_pos = 0x0,\n    ki_complete = 0x0,\n    private = 0x0,\n    ki_flags = 0x0\n  }\n\nAnd the backtrace shows:\n  ocfs2_file_write_iter+0xcaa/0xd00 [ocfs2]\n  aio_run_iocb+0x229/0x2f0\n  do_io_submit+0x291/0x540\n  SyS_io_submit+0x10/0x20\n  system_call_fastpath+0x16/0x75\n\nLink: http://lkml.kernel.org/r/1523361653-14439-1-git-send-email-ge.changwei@h3c.com\nSigned-off-by: Changwei Ge <ge.changwei@h3c.com>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nCc: Mark Fasheh <mark@fasheh.com>\nCc: Joel Becker <jlbec@evilplan.org>\nCc: Junxiao Bi <junxiao.bi@oracle.com>\nCc: Joseph Qi <jiangqi903@gmail.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/9e985787750db8aae87f02b67e908f28ac4d6b83"},{"sha":"29aa30167a0a2e6045a0d6d2e89d8168132333d5","author":{"name":"Changwei Ge","email":"426c7ff62140bfc2cdb2378eb8f3d7f86c8efe1c@h3c.com"},"message":"ocfs2: fix a misuse a of brelse after failing ocfs2_check_dir_entry\n\nSomehow, file system metadata was corrupted, which causes\nocfs2_check_dir_entry() to fail in function ocfs2_dir_foreach_blk_el().\n\nAccording to the original design intention, if above happens we should\nskip the problematic block and continue to retrieve dir entry.  But\nthere is obviouse misuse of brelse around related code.\n\nAfter failure of ocfs2_check_dir_entry(), current code just moves to\nnext position and uses the problematic buffer head again and again\nduring which the problematic buffer head is released for multiple times.\nI suppose, this a serious issue which is long-lived in ocfs2.  This may\ncause other file systems which is also used in a the same host insane.\n\nSo we should also consider about bakcporting this patch into linux\n-stable.\n\nLink: http://lkml.kernel.org/r/HK2PR06MB045211675B43EED794E597B6D56E0@HK2PR06MB0452.apcprd06.prod.outlook.com\nSigned-off-by: Changwei Ge <ge.changwei@h3c.com>\nSuggested-by: Changkuo Shi <shi.changkuo@h3c.com>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nCc: Mark Fasheh <mark@fasheh.com>\nCc: Joel Becker <jlbec@evilplan.org>\nCc: Junxiao Bi <junxiao.bi@oracle.com>\nCc: Joseph Qi <jiangqi903@gmail.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":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/29aa30167a0a2e6045a0d6d2e89d8168132333d5"},{"sha":"cf76c78595ca87548ca5e45c862ac9e0949c4687","author":{"name":"Changwei Ge","email":"426c7ff62140bfc2cdb2378eb8f3d7f86c8efe1c@h3c.com"},"message":"ocfs2: don't put and assigning null to bh allocated outside\n\nocfs2_read_blocks() and ocfs2_read_blocks_sync() are both used to read\nseveral blocks from disk.  Currently, the input argument *bhs* can be\nNULL or NOT.  It depends on the caller's behavior.  If the function\nfails in reading blocks from disk, the corresponding bh will be assigned\nto NULL and put.\n\nObviously, above process for non-NULL input bh is not appropriate.\nBecause the caller doesn't even know its bhs are put and re-assigned.\n\nIf buffer head is managed by caller, ocfs2_read_blocks and\nocfs2_read_blocks_sync() should not evaluate it to NULL.  It will cause\ncaller accessing illegal memory, thus crash.\n\nLink: http://lkml.kernel.org/r/HK2PR06MB045285E0F4FBB561F9F2F9B3D5680@HK2PR06MB0452.apcprd06.prod.outlook.com\nSigned-off-by: Changwei Ge <ge.changwei@h3c.com>\nReviewed-by: Guozhonghua <guozhonghua@h3c.com>\nCc: Mark Fasheh <mark@fasheh.com>\nCc: Joel Becker <jlbec@evilplan.org>\nCc: Junxiao Bi <junxiao.bi@oracle.com>\nCc: Joseph Qi <jiangqi903@gmail.com>\nCc: Changwei Ge <ge.changwei@h3c.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/cf76c78595ca87548ca5e45c862ac9e0949c4687"},{"sha":"3a3d1e51042895c58d4797831921c940b28d8c4b","author":{"name":"Arnd Bergmann","email":"f2c659f01951776204a6c5b902787d9019fbeebd@arndb.de"},"message":"ocfs2: dlmglue: clean up timestamp handling\n\nThe handling of timestamps outside of the 1970..2038 range in the dlm\nglue is rather inconsistent: on 32-bit architectures, this has always\nwrapped around to negative timestamps in the 1902..1969 range, while on\n64-bit kernels all timestamps are interpreted as positive 34 bit numbers\nin the 1970..2514 year range.\n\nNow that the VFS code handles 64-bit timestamps on all architectures, we\ncan make the behavior more consistent here, and return the same result\nthat we had on 64-bit already, making the file system y2038 safe in the\nprocess.  Outside of dlmglue, it already uses 64-bit on-disk timestamps\nanway, so that part is fine.\n\nFor consistency, I'm changing ocfs2_pack_timespec() to clamp anything\noutside of the supported range to the minimum and maximum values.  This\navoids a possible ambiguity of values before 1970 in particular, which\nused to be interpreted as times at the end of the 2514 range previously.\n\nLink: http://lkml.kernel.org/r/20180619155826.4106487-1-arnd@arndb.de\nSigned-off-by: Arnd Bergmann <arnd@arndb.de>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nCc: Mark Fasheh <mark@fasheh.com>\nCc: Joel Becker <jlbec@evilplan.org>\nCc: Junxiao Bi <junxiao.bi@oracle.com>\nCc: Joseph Qi <jiangqi903@gmail.com>\nCc: Changwei Ge <ge.changwei@h3c.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/3a3d1e51042895c58d4797831921c940b28d8c4b"},{"sha":"6194ae4242dec0c9d604bc05df83aa9260a899e4","author":{"name":"Larry Chen","email":"128805bb22d6924a3cef262af3ec77db420aae3d@suse.com"},"message":"ocfs2: fix clusters leak in ocfs2_defrag_extent()\n\nocfs2_defrag_extent() might leak allocated clusters.  When the file\nsystem has insufficient space, the number of claimed clusters might be\nless than the caller wants.  If that happens, the original code might\ndirectly commit the transaction without returning clusters.\n\nThis patch is based on code in ocfs2_add_clusters_in_btree().\n\n[akpm@linux-foundation.org: include localalloc.h, reduce scope of data_ac]\nLink: http://lkml.kernel.org/r/20180904041621.16874-3-lchen@suse.com\nSigned-off-by: Larry Chen <lchen@suse.com>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nCc: Mark Fasheh <mark@fasheh.com>\nCc: Joel Becker <jlbec@evilplan.org>\nCc: Junxiao Bi <junxiao.bi@oracle.com>\nCc: Joseph Qi <jiangqi903@gmail.com>\nCc: Changwei Ge <ge.changwei@h3c.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/6194ae4242dec0c9d604bc05df83aa9260a899e4"},{"sha":"89c83fb539f95491be80cdd5158e6f0ce329e317","author":{"name":"Michal Hocko","email":"829500b200af6c2a0eca4dfd5c388e6b8fbe8dc6@suse.com"},"message":"mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask\n\nTHP allocation mode is quite complex and it depends on the defrag mode.\nThis complexity is hidden in alloc_hugepage_direct_gfpmask from a large\npart currently. The NUMA special casing (namely __GFP_THISNODE) is\nhowever independent and placed in alloc_pages_vma currently. This both\nadds an unnecessary branch to all vma based page allocation requests and\nit makes the code more complex unnecessarily as well. Not to mention\nthat e.g. shmem THP used to do the node reclaiming unconditionally\nregardless of the defrag mode until recently. This was not only\nunexpected behavior but it was also hardly a good default behavior and I\nstrongly suspect it was just a side effect of the code sharing more than\na deliberate decision which suggests that such a layering is wrong.\n\nGet rid of the thp special casing from alloc_pages_vma and move the\nlogic to alloc_hugepage_direct_gfpmask. __GFP_THISNODE is applied to the\nresulting gfp mask only when the direct reclaim is not requested and\nwhen there is no explicit numa binding to preserve the current logic.\n\nPlease note that there's also a slight difference wrt MPOL_BIND now. The\nprevious code would avoid using __GFP_THISNODE if the local node was\noutside of policy_nodemask(). After this patch __GFP_THISNODE is avoided\nfor all MPOL_BIND policies. So there's a difference that if local node\nis actually allowed by the bind policy's nodemask, previously\n__GFP_THISNODE would be added, but now it won't be. From the behavior\nPOV this is still correct because the policy nodemask is used.\n\nLink: http://lkml.kernel.org/r/20180925120326.24392-3-mhocko@kernel.org\nSigned-off-by: Michal Hocko <mhocko@suse.com>\nAcked-by: Vlastimil Babka <vbabka@suse.cz>\nCc: Alex Williamson <alex.williamson@redhat.com>\nCc: Andrea Arcangeli <aarcange@redhat.com>\nCc: David Rientjes <rientjes@google.com>\nCc: \"Kirill A. Shutemov\" <kirill@shutemov.name>\nCc: Mel Gorman <mgorman@techsingularity.net>\nCc: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>\nCc: Zi Yan <zi.yan@cs.rutgers.edu>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/89c83fb539f95491be80cdd5158e6f0ce329e317"},{"sha":"3383b36040522505546cb112f0a543a5998edfb6","author":{"name":"zhong jiang","email":"e00b852f945f8ed516726e617fc62ab2ed3a16a5@huawei.com"},"message":"kernel/kexec_file.c: remove some duplicated includes\n\nWe include kexec.h and slab.h twice in kexec_file.c. It's unnecessary.\nhence just remove them.\n\nLink: http://lkml.kernel.org/r/1537498098-19171-1-git-send-email-zhongjiang@huawei.com\nSigned-off-by: zhong jiang <zhongjiang@huawei.com>\nReviewed-by: Bhupesh Sharma <bhsharma@redhat.com>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nAcked-by: Baoquan He <bhe@redhat.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/3383b36040522505546cb112f0a543a5998edfb6"},{"sha":"6f0483d1f91b612186abeaebf3ce43bf805eb9f7","author":{"name":"Michael Schupikov","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@schupikov.de"},"message":"kernel/sysctl.c: remove duplicated include\n\nRemove one include of <linux/pipe_fs_i.h>.\nNo functional changes.\n\nLink: http://lkml.kernel.org/r/20181004134223.17735-1-michael@schupikov.de\nSigned-off-by: Michael Schupikov <michael@schupikov.de>\nReviewed-by: Richard Weinberger <richard@nod.at>\nAcked-by: Luis Chamberlain <mcgrof@kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/6f0483d1f91b612186abeaebf3ce43bf805eb9f7"},{"sha":"9f2df09a33aa2c76ce6385d382693f98d7f2f07e","author":{"name":"Tetsuo Handa","email":"3d00b54ad717112934d0b63b7ac2975b44022a61@I-love.SAKURA.ne.jp"},"message":"bfs: add sanity check at bfs_fill_super()\n\nsyzbot is reporting too large memory allocation at bfs_fill_super() [1].\nSince file system image is corrupted such that bfs_sb->s_start == 0,\nbfs_fill_super() is trying to allocate 8MB of continuous memory. Fix\nthis by adding a sanity check on bfs_sb->s_start, __GFP_NOWARN and\nprintf().\n\n[1] https://syzkaller.appspot.com/bug?id=16a87c236b951351374a84c8a32f40edbc034e96\n\nLink: http://lkml.kernel.org/r/1525862104-3407-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp\nSigned-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>\nReported-by: syzbot <syzbot+71c6b5d68e91149fc8a4@syzkaller.appspotmail.com>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nCc: Tigran Aivazian <aivazian.tigran@gmail.com>\nCc: Matthew Wilcox <willy@infradead.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/9f2df09a33aa2c76ce6385d382693f98d7f2f07e"},{"sha":"dd33ad7b251f900481701b2a82d25de583867708","author":{"name":"Michal Hocko","email":"829500b200af6c2a0eca4dfd5c388e6b8fbe8dc6@suse.com"},"message":"memory_hotplug: cond_resched in __remove_pages\n\nWe have received a bug report that unbinding a large pmem (>1TB) can\nresult in a soft lockup:\n\n  NMI watchdog: BUG: soft lockup - CPU#9 stuck for 23s! [ndctl:4365]\n  [...]\n  Supported: Yes\n  CPU: 9 PID: 4365 Comm: ndctl Not tainted 4.12.14-94.40-default #1 SLE12-SP4\n  Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.01.00.0833.051120182255 05/11/2018\n  task: ffff9cce7d4410c0 task.stack: ffffbe9eb1bc4000\n  RIP: 0010:__put_page+0x62/0x80\n  Call Trace:\n   devm_memremap_pages_release+0x152/0x260\n   release_nodes+0x18d/0x1d0\n   device_release_driver_internal+0x160/0x210\n   unbind_store+0xb3/0xe0\n   kernfs_fop_write+0x102/0x180\n   __vfs_write+0x26/0x150\n   vfs_write+0xad/0x1a0\n   SyS_write+0x42/0x90\n   do_syscall_64+0x74/0x150\n   entry_SYSCALL_64_after_hwframe+0x3d/0xa2\n  RIP: 0033:0x7fd13166b3d0\n\nIt has been reported on an older (4.12) kernel but the current upstream\ncode doesn't cond_resched in the hot remove code at all and the given\nrange to remove might be really large.  Fix the issue by calling\ncond_resched once per memory section.\n\nLink: http://lkml.kernel.org/r/20181031125840.23982-1-mhocko@kernel.org\nSigned-off-by: Michal Hocko <mhocko@suse.com>\nAcked-by: Johannes Thumshirn <jthumshirn@suse.de>\nCc: Dan Williams <dan.j.williams@gmail.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":false,"url":"https://api.github.com/repos/PabloPL/linux/commits/dd33ad7b251f900481701b2a82d25de583867708"}]}
{"actor":{"display_login":"PabloPL"}}