{"push_id":2169771524,"size":68,"distinct_size":68,"ref":"refs/heads/tr-core","head":"75b5c482164d6565780e453bd58cb12bbfb06fdd","before":"27f6f6dc605dedbb857c8c1d52773f3adab6efb7","commits":[{"sha":"322447c1771b06e12755325d8da581cece49a2e1","author":{"name":"Vasily Gorbik","email":"3b830e88501b966ecd0c0f4be09c49e1a5345e4f@linux.vnet.ibm.com"},"message":"s390/disassembler: increase show_code buffer size\n\ncommit b192571d1ae375e0bbe0aa3ccfa1a3c3704454b9 upstream.\n\nCurrent buffer size of 64 is too small. objdump shows that there are\ninstructions which would require up to 75 bytes buffer (with current\nformating). 128 bytes \"ought to be enough for anybody\".\n\nAlso replaces 8 spaces with a single tab to reduce the memory footprint.\n\nFixes the following KASAN finding:\n\nBUG: KASAN: stack-out-of-bounds in number+0x3fe/0x538\nWrite of size 1 at addr 000000005a4a75a0 by task bash/1282\n\nCPU: 1 PID: 1282 Comm: bash Not tainted 4.14.0+ #215\nHardware name: IBM 2964 N96 702 (z/VM 6.4.0)\nCall Trace:\n([<000000000011eeb6>] show_stack+0x56/0x88)\n [<0000000000e1ce1a>] dump_stack+0x15a/0x1b0\n [<00000000004e2994>] print_address_description+0xf4/0x288\n [<00000000004e2cf2>] kasan_report+0x13a/0x230\n [<0000000000e38ae6>] number+0x3fe/0x538\n [<0000000000e3dfe4>] vsnprintf+0x194/0x948\n [<0000000000e3ea42>] sprintf+0xa2/0xb8\n [<00000000001198dc>] print_insn+0x374/0x500\n [<0000000000119346>] show_code+0x4ee/0x538\n [<000000000011f234>] show_registers+0x34c/0x388\n [<000000000011f2ae>] show_regs+0x3e/0xa8\n [<000000000011f502>] die+0x1ea/0x2e8\n [<0000000000138f0e>] do_no_context+0x106/0x168\n [<0000000000139a1a>] do_protection_exception+0x4da/0x7d0\n [<0000000000e55914>] pgm_check_handler+0x16c/0x1c0\n [<000000000090639e>] sysrq_handle_crash+0x46/0x58\n([<0000000000000007>] 0x7)\n [<00000000009073fa>] __handle_sysrq+0x102/0x218\n [<0000000000907c06>] write_sysrq_trigger+0xd6/0x100\n [<000000000061d67a>] proc_reg_write+0xb2/0x128\n [<0000000000520be6>] __vfs_write+0xee/0x368\n [<0000000000521222>] vfs_write+0x21a/0x278\n [<000000000052156a>] SyS_write+0xda/0x178\n [<0000000000e555cc>] system_call+0xc4/0x270\n\nThe buggy address belongs to the page:\npage:000003d1016929c0 count:0 mapcount:0 mapping:          (null) index:0x0\nflags: 0x0()\nraw: 0000000000000000 0000000000000000 0000000000000000 ffffffff00000000\nraw: 0000000000000100 0000000000000200 0000000000000000 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n 000000005a4a7480: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1\n 000000005a4a7500: 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00 00 00 00\n>000000005a4a7580: 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00\n                               ^\n 000000005a4a7600: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 f8 f8\n 000000005a4a7680: f2 f2 f2 f2 f2 f2 f8 f8 f2 f2 f3 f3 f3 f3 00 00\n==================================================================\n\nSigned-off-by: Vasily Gorbik <gor@linux.vnet.ibm.com>\nSigned-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/322447c1771b06e12755325d8da581cece49a2e1"},{"sha":"532f20acb85f8545fd3084c88f7b4eb80f3e173c","author":{"name":"WANG Cong","email":"3f5d79d28d6d48052800caba9df0b30e06fefe41@gmail.com"},"message":"ipv6: only call ip6_route_dev_notify() once for NETDEV_UNREGISTER\n\ncommit 76da0704507bbc51875013f6557877ab308cfd0a upstream.\n\nIn commit 242d3a49a2a1 (\"ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf\")\nI assumed NETDEV_REGISTER and NETDEV_UNREGISTER are paired,\nunfortunately, as reported by jeffy, netdev_wait_allrefs()\ncould rebroadcast NETDEV_UNREGISTER event until all refs are\ngone.\n\nWe have to add an additional check to avoid this corner case.\nFor netdev_wait_allrefs() dev->reg_state is NETREG_UNREGISTERED,\nfor dev_change_net_namespace(), dev->reg_state is\nNETREG_REGISTERED. So check for dev->reg_state != NETREG_UNREGISTERED.\n\nFixes: 242d3a49a2a1 (\"ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf\")\nReported-by: jeffy <jeffy.chen@rock-chips.com>\nCc: David Ahern <dsahern@gmail.com>\nSigned-off-by: Cong Wang <xiyou.wangcong@gmail.com>\nAcked-by: David Ahern <dsahern@gmail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nCc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/532f20acb85f8545fd3084c88f7b4eb80f3e173c"},{"sha":"f969da257b53e370b6506e3fe0ddf2b8a0a0de90","author":{"name":"Paul E. McKenney","email":"0e7edc073f39d0385f8433ab60979a97c480557c@linux.vnet.ibm.com"},"message":"sched: Make resched_cpu() unconditional\n\ncommit 7c2102e56a3f7d85b5d8f33efbd7aecc1f36fdd8 upstream.\n\nThe current implementation of synchronize_sched_expedited() incorrectly\nassumes that resched_cpu() is unconditional, which it is not.  This means\nthat synchronize_sched_expedited() can hang when resched_cpu()'s trylock\nfails as follows (analysis by Neeraj Upadhyay):\n\no\tCPU1 is waiting for expedited wait to complete:\n\n\tsync_rcu_exp_select_cpus\n\t     rdp->exp_dynticks_snap & 0x1   // returns 1 for CPU5\n\t     IPI sent to CPU5\n\n\tsynchronize_sched_expedited_wait\n\t\t ret = swait_event_timeout(rsp->expedited_wq,\n\t\t\t\t\t   sync_rcu_preempt_exp_done(rnp_root),\n\t\t\t\t\t   jiffies_stall);\n\n\texpmask = 0x20, CPU 5 in idle path (in cpuidle_enter())\n\no\tCPU5 handles IPI and fails to acquire rq lock.\n\n\tHandles IPI\n\t     sync_sched_exp_handler\n\t\t resched_cpu\n\t\t     returns while failing to try lock acquire rq->lock\n\t\t need_resched is not set\n\no\tCPU5 calls  rcu_idle_enter() and as need_resched is not set, goes to\n\tidle (schedule() is not called).\n\no\tCPU 1 reports RCU stall.\n\nGiven that resched_cpu() is now used only by RCU, this commit fixes the\nassumption by making resched_cpu() unconditional.\n\nReported-by: Neeraj Upadhyay <neeraju@codeaurora.org>\nSuggested-by: Neeraj Upadhyay <neeraju@codeaurora.org>\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nAcked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>\nAcked-by: Peter Zijlstra (Intel) <peterz@infradead.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/f969da257b53e370b6506e3fe0ddf2b8a0a0de90"},{"sha":"c5cba444b50fee1bd32ce80c7de65bfb551cff50","author":{"name":"Eric Biggers","email":"0106d512ed1cb672be29d4b167a07ead51709fba@google.com"},"message":"lib/mpi: call cond_resched() from mpi_powm() loop\n\ncommit 1d9ddde12e3c9bab7f3d3484eb9446315e3571ca upstream.\n\nOn a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the\nlargest permitted inputs (16384 bits), the kernel spends 10+ seconds\ndoing modular exponentiation in mpi_powm() without rescheduling.  If all\nthreads do it, it locks up the system.  Moreover, it can cause\nrcu_sched-stall warnings.\n\nNotwithstanding the insanity of doing this calculation in kernel mode\nrather than in userspace, fix it by calling cond_resched() as each bit\nfrom the exponent is processed.  It's still noninterruptible, but at\nleast it's preemptible now.\n\nDo the cond_resched() once per bit rather than once per MPI limb because\neach limb might still easily take 100+ milliseconds on slow CPUs.\n\nSigned-off-by: Eric Biggers <ebiggers@google.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/c5cba444b50fee1bd32ce80c7de65bfb551cff50"},{"sha":"a9d2e94440aa03d68fd4ae8f3e66fff7bf3e34c4","author":{"name":"Masami Hiramatsu","email":"5ab6ef7bee6728a5bff222670b7ceb5278b7ee85@kernel.org"},"message":"x86/decoder: Add new TEST instruction pattern\n\ncommit 12a78d43de767eaf8fb272facb7a7b6f2dc6a9df upstream.\n\nThe kbuild test robot reported this build warning:\n\n  Warning: arch/x86/tools/test_get_len found difference at <jump_table>:ffffffff8103dd2c\n\n  Warning: ffffffff8103dd82: f6 09 d8 testb $0xd8,(%rcx)\n  Warning: objdump says 3 bytes, but insn_get_length() says 2\n  Warning: decoded and checked 1569014 instructions with 1 warnings\n\nThis sequence seems to be a new instruction not in the opcode map in the Intel SDM.\n\nThe instruction sequence is \"F6 09 d8\", means Group3(F6), MOD(00)REG(001)RM(001), and 0xd8.\nIntel SDM vol2 A.4 Table A-6 said the table index in the group is \"Encoding of Bits 5,4,3 of\nthe ModR/M Byte (bits 2,1,0 in parenthesis)\"\n\nIn that table, opcodes listed by the index REG bits as:\n\n  000         001       010 011  100        101        110         111\n TEST Ib/Iz,(undefined),NOT,NEG,MUL AL/rAX,IMUL AL/rAX,DIV AL/rAX,IDIV AL/rAX\n\nSo, it seems TEST Ib is assigned to 001.\n\nAdd the new pattern.\n\nReported-by: kbuild test robot <fengguang.wu@intel.com>\nSigned-off-by: Masami Hiramatsu <mhiramat@kernel.org>\nCc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nCc: H. Peter Anvin <hpa@zytor.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: linux-kernel@vger.kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/a9d2e94440aa03d68fd4ae8f3e66fff7bf3e34c4"},{"sha":"649f0b61465aed92c16115b08c6e583779e9e60d","author":{"name":"Philip Derrin","email":"bdbe007522dbb5441efb474fa64f45edd80c8549@cog.systems"},"message":"ARM: 8721/1: mm: dump: check hardware RO bit for LPAE\n\ncommit 3b0c0c922ff4be275a8beb87ce5657d16f355b54 upstream.\n\nWhen CONFIG_ARM_LPAE is set, the PMD dump relies on the software\nread-only bit to determine whether a page is writable. This\nconcealed a bug which left the kernel text section writable\n(AP2=0) while marked read-only in the software bit.\n\nIn a kernel with the AP2 bug, the dump looks like this:\n\n    ---[ Kernel Mapping ]---\n    0xc0000000-0xc0200000           2M RW NX SHD\n    0xc0200000-0xc0600000           4M ro x  SHD\n    0xc0600000-0xc0800000           2M ro NX SHD\n    0xc0800000-0xc4800000          64M RW NX SHD\n\nThe fix is to check that the software and hardware bits are both\nset before displaying \"ro\". The dump then shows the true perms:\n\n    ---[ Kernel Mapping ]---\n    0xc0000000-0xc0200000           2M RW NX SHD\n    0xc0200000-0xc0600000           4M RW x  SHD\n    0xc0600000-0xc0800000           2M RW NX SHD\n    0xc0800000-0xc4800000          64M RW NX SHD\n\nFixes: ded947798469 (\"ARM: 8109/1: mm: Modify pte_write and pmd_write logic for LPAE\")\nSigned-off-by: Philip Derrin <philip@cog.systems>\nTested-by: Neil Dick <neil@cog.systems>\nReviewed-by: Kees Cook <keescook@chromium.org>\nSigned-off-by: Russell King <rmk+kernel@armlinux.org.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/649f0b61465aed92c16115b08c6e583779e9e60d"},{"sha":"b41db8773db8ff451b86f0d1df266191fa0c597c","author":{"name":"Vijendar Mukunda","email":"f4f07ca5b1bec74bfc608b282242a6f291f9eb45@amd.com"},"message":"ALSA: hda: Add Raven PCI ID\n\ncommit 9ceace3c9c18c67676e75141032a65a8e01f9a7a upstream.\n\nThis commit adds PCI ID for Raven platform\n\nSigned-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/b41db8773db8ff451b86f0d1df266191fa0c597c"},{"sha":"6a6bb12780d6cbc007644904d420a881d543714b","author":{"name":"Eric Biggers","email":"0106d512ed1cb672be29d4b167a07ead51709fba@google.com"},"message":"dm bufio: fix integer overflow when limiting maximum cache size\n\ncommit 74d4108d9e681dbbe4a2940ed8fdff1f6868184c upstream.\n\nThe default max_cache_size_bytes for dm-bufio is meant to be the lesser\nof 25% of the size of the vmalloc area and 2% of the size of lowmem.\nHowever, on 32-bit systems the intermediate result in the expression\n\n    (VMALLOC_END - VMALLOC_START) * DM_BUFIO_VMALLOC_PERCENT / 100\n\noverflows, causing the wrong result to be computed.  For example, on a\n32-bit system where the vmalloc area is 520093696 bytes, the result is\n1174405 rather than the expected 130023424, which makes the maximum\ncache size much too small (far less than 2% of lowmem).  This causes\nsevere performance problems for dm-verity users on affected systems.\n\nFix this by using mult_frac() to correctly multiply by a percentage.  Do\nthis for all places in dm-bufio that multiply by a percentage.  Also\nreplace (VMALLOC_END - VMALLOC_START) with VMALLOC_TOTAL, which contrary\nto the comment is now defined in include/linux/vmalloc.h.\n\nDepends-on: 9993bc635 (\"sched/x86: Fix overflow in cyc2ns_offset\")\nFixes: 95d402f057f2 (\"dm: add bufio\")\nSigned-off-by: Eric Biggers <ebiggers@google.com>\nSigned-off-by: Mike Snitzer <snitzer@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/6a6bb12780d6cbc007644904d420a881d543714b"},{"sha":"2ce9f1c7fade79f54053b9035a99e2d07e58c19e","author":{"name":"Hou Tao","email":"3e98258678d766fc8032de731347d0f5060ad78c@huawei.com"},"message":"dm: fix race between dm_get_from_kobject() and __dm_destroy()\n\ncommit b9a41d21dceadf8104812626ef85dc56ee8a60ed upstream.\n\nThe following BUG_ON was hit when testing repeat creation and removal of\nDM devices:\n\n    kernel BUG at drivers/md/dm.c:2919!\n    CPU: 7 PID: 750 Comm: systemd-udevd Not tainted 4.1.44\n    Call Trace:\n     [<ffffffff81649e8b>] dm_get_from_kobject+0x34/0x3a\n     [<ffffffff81650ef1>] dm_attr_show+0x2b/0x5e\n     [<ffffffff817b46d1>] ? mutex_lock+0x26/0x44\n     [<ffffffff811df7f5>] sysfs_kf_seq_show+0x83/0xcf\n     [<ffffffff811de257>] kernfs_seq_show+0x23/0x25\n     [<ffffffff81199118>] seq_read+0x16f/0x325\n     [<ffffffff811de994>] kernfs_fop_read+0x3a/0x13f\n     [<ffffffff8117b625>] __vfs_read+0x26/0x9d\n     [<ffffffff8130eb59>] ? security_file_permission+0x3c/0x44\n     [<ffffffff8117bdb8>] ? rw_verify_area+0x83/0xd9\n     [<ffffffff8117be9d>] vfs_read+0x8f/0xcf\n     [<ffffffff81193e34>] ? __fdget_pos+0x12/0x41\n     [<ffffffff8117c686>] SyS_read+0x4b/0x76\n     [<ffffffff817b606e>] system_call_fastpath+0x12/0x71\n\nThe bug can be easily triggered, if an extra delay (e.g. 10ms) is added\nbetween the test of DMF_FREEING & DMF_DELETING and dm_get() in\ndm_get_from_kobject().\n\nTo fix it, we need to ensure the test of DMF_FREEING & DMF_DELETING and\ndm_get() are done in an atomic way, so _minor_lock is used.\n\nThe other callers of dm_get() have also been checked to be OK: some\ncallers invoke dm_get() under _minor_lock, some callers invoke it under\n_hash_lock, and dm_start_request() invoke it after increasing\nmd->open_count.\n\nSigned-off-by: Hou Tao <houtao1@huawei.com>\nSigned-off-by: Mike Snitzer <snitzer@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/2ce9f1c7fade79f54053b9035a99e2d07e58c19e"},{"sha":"ee003ae371a16d30af2d5a32ee82dd81e7978015","author":{"name":"Maciej W. Rozycki","email":"006a10158a5aec37e39763a69b0658f4e7f13280@mips.com"},"message":"MIPS: Fix an n32 core file generation regset support regression\n\ncommit 547da673173de51f73887377eb275304775064ad upstream.\n\nFix a commit 7aeb753b5353 (\"MIPS: Implement task_user_regset_view.\")\nregression, then activated by commit 6a9c001b7ec3 (\"MIPS: Switch ELF\ncore dumper to use regsets.)\", that caused n32 processes to dump o32\ncore files by failing to set the EF_MIPS_ABI2 flag in the ELF core file\nheader's `e_flags' member:\n\n$ file tls-core\ntls-core: ELF 32-bit MSB executable, MIPS, N32 MIPS64 rel2 version 1 (SYSV), [...]\n$ ./tls-core\nAborted (core dumped)\n$ file core\ncore: ELF 32-bit MSB core file MIPS, MIPS-I version 1 (SYSV), SVR4-style\n$\n\nPreviously the flag was set as the result of a:\n\nstatement placed in arch/mips/kernel/binfmt_elfn32.c, however in the\nregset case, i.e. when CORE_DUMP_USE_REGSET is set, ELF_CORE_EFLAGS is\nno longer used by `fill_note_info' in fs/binfmt_elf.c, and instead the\n`->e_flags' member of the regset view chosen is.  We have the views\ndefined in arch/mips/kernel/ptrace.c, however only an o32 and an n64\none, and the latter is used for n32 as well.  Consequently an o32 core\nfile is incorrectly dumped from n32 processes (the ELF32 vs ELF64 class\nis chosen elsewhere, and the 32-bit one is correctly selected for n32).\n\nCorrect the issue then by defining an n32 regset view and using it as\nappropriate.  Issue discovered in GDB testing.\n\nFixes: 7aeb753b5353 (\"MIPS: Implement task_user_regset_view.\")\nSigned-off-by: Maciej W. Rozycki <macro@mips.com>\nCc: Ralf Baechle <ralf@linux-mips.org>\nCc: Djordje Todorovic <djordje.todorovic@rt-rk.com>\nCc: linux-mips@linux-mips.org\nPatchwork: https://patchwork.linux-mips.org/patch/17617/\nSigned-off-by: James Hogan <jhogan@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/ee003ae371a16d30af2d5a32ee82dd81e7978015"},{"sha":"b3d6fad703d93c1e17a2e207fc039b82dedfb3c4","author":{"name":"Mirko Parthey","email":"3a6907a4527c4ecca3fa64cf211570c4b7e43602@web.de"},"message":"MIPS: BCM47XX: Fix LED inversion for WRT54GSv1\n\ncommit 56a46acf62af5ba44fca2f3f1c7c25a2d5385b19 upstream.\n\nThe WLAN LED on the Linksys WRT54GSv1 is active low, but the software\ntreats it as active high. Fix the inverted logic.\n\nFixes: 7bb26b169116 (\"MIPS: BCM47xx: Fix LEDs on WRT54GS V1.0\")\nSigned-off-by: Mirko Parthey <mirko.parthey@web.de>\nLooks-ok-by: Rafał Miłecki <zajec5@gmail.com>\nCc: Hauke Mehrtens <hauke@hauke-m.de>\nCc: linux-mips@linux-mips.org\nPatchwork: https://patchwork.linux-mips.org/patch/16071/\nSigned-off-by: James Hogan <jhogan@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/b3d6fad703d93c1e17a2e207fc039b82dedfb3c4"},{"sha":"31d333f7bc3c14039c23f09b492d9ac972b2c577","author":{"name":"NeilBrown","email":"2d905a3497a379bccf401a15c6d441d61e66863c@suse.com"},"message":"autofs: don't fail mount for transient error\n\ncommit ecc0c469f27765ed1e2b967be0aa17cee1a60b76 upstream.\n\nCurrently if the autofs kernel module gets an error when writing to the\npipe which links to the daemon, then it marks the whole moutpoint as\ncatatonic, and it will stop working.\n\nIt is possible that the error is transient.  This can happen if the\ndaemon is slow and more than 16 requests queue up.  If a subsequent\nprocess tries to queue a request, and is then signalled, the write to\nthe pipe will return -ERESTARTSYS and autofs will take that as total\nfailure.\n\nSo change the code to assess -ERESTARTSYS and -ENOMEM as transient\nfailures which only abort the current request, not the whole mountpoint.\n\nIt isn't a crash or a data corruption, but having autofs mountpoints\nsuddenly stop working is rather inconvenient.\n\nIan said:\n\n: And given the problems with a half dozen (or so) user space applications\n: consuming large amounts of CPU under heavy mount and umount activity this\n: could happen more easily than we expect.\n\nLink: http://lkml.kernel.org/r/87y3norvgp.fsf@notabene.neil.brown.name\nSigned-off-by: NeilBrown <neilb@suse.com>\nAcked-by: Ian Kent <raven@themaw.net>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/31d333f7bc3c14039c23f09b492d9ac972b2c577"},{"sha":"87b4a04f4543f7c6010a49722fc19f4ec82dba19","author":{"name":"Andreas Rohner","email":"9d5bf6969d5bbb14b8be0e49c5dc406e09ed0b91@gmx.net"},"message":"nilfs2: fix race condition that causes file system corruption\n\ncommit 31ccb1f7ba3cfe29631587d451cf5bb8ab593550 upstream.\n\nThere is a race condition between nilfs_dirty_inode() and\nnilfs_set_file_dirty().\n\nWhen a file is opened, nilfs_dirty_inode() is called to update the\naccess timestamp in the inode.  It calls __nilfs_mark_inode_dirty() in a\nseparate transaction.  __nilfs_mark_inode_dirty() caches the ifile\nbuffer_head in the i_bh field of the inode info structure and marks it\nas dirty.\n\nAfter some data was written to the file in another transaction, the\nfunction nilfs_set_file_dirty() is called, which adds the inode to the\nns_dirty_files list.\n\nThen the segment construction calls nilfs_segctor_collect_dirty_files(),\nwhich goes through the ns_dirty_files list and checks the i_bh field.\nIf there is a cached buffer_head in i_bh it is not marked as dirty\nagain.\n\nSince nilfs_dirty_inode() and nilfs_set_file_dirty() use separate\ntransactions, it is possible that a segment construction that writes out\nthe ifile occurs in-between the two.  If this happens the inode is not\non the ns_dirty_files list, but its ifile block is still marked as dirty\nand written out.\n\nIn the next segment construction, the data for the file is written out\nand nilfs_bmap_propagate() updates the b-tree.  Eventually the bmap root\nis written into the i_bh block, which is not dirty, because it was\nwritten out in another segment construction.\n\nAs a result the bmap update can be lost, which leads to file system\ncorruption.  Either the virtual block address points to an unallocated\nDAT block, or the DAT entry will be reused for something different.\n\nThe error can remain undetected for a long time.  A typical error\nmessage would be one of the \"bad btree\" errors or a warning that a DAT\nentry could not be found.\n\nThis bug can be reproduced reliably by a simple benchmark that creates\nand overwrites millions of 4k files.\n\nLink: http://lkml.kernel.org/r/1509367935-3086-2-git-send-email-konishi.ryusuke@lab.ntt.co.jp\nSigned-off-by: Andreas Rohner <andreas.rohner@gmx.net>\nSigned-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>\nTested-by: Andreas Rohner <andreas.rohner@gmx.net>\nTested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/87b4a04f4543f7c6010a49722fc19f4ec82dba19"},{"sha":"106213f311bc141b00a2b8b8d38aec2da4b95059","author":{"name":"Dan Carpenter","email":"60b2bf2bc0bec4ca4a4b046ca7ef9255248abff8@oracle.com"},"message":"eCryptfs: use after free in ecryptfs_release_messaging()\n\ncommit db86be3a12d0b6e5c5b51c2ab2a48f06329cb590 upstream.\n\nWe're freeing the list iterator so we should be using the _safe()\nversion of hlist_for_each_entry().\n\nFixes: 88b4a07e6610 (\"[PATCH] eCryptfs: Public key transport mechanism\")\nSigned-off-by: Dan Carpenter <dan.carpenter@oracle.com>\nSigned-off-by: Tyler Hicks <tyhicks@canonical.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/106213f311bc141b00a2b8b8d38aec2da4b95059"},{"sha":"f6b69de3c1d4a28539e6c6fe2353da36b31b3e59","author":{"name":"Coly Li","email":"79aeb687a9c5175fb9509f7d4337195284d24710@suse.de"},"message":"bcache: check ca->alloc_thread initialized before wake up it\n\ncommit 91af8300d9c1d7c6b6a2fd754109e08d4798b8d8 upstream.\n\nIn bcache code, sysfs entries are created before all resources get\nallocated, e.g. allocation thread of a cache set.\n\nThere is posibility for NULL pointer deference if a resource is accessed\nbut which is not initialized yet. Indeed Jorg Bornschein catches one on\ncache set allocation thread and gets a kernel oops.\n\nThe reason for this bug is, when bch_bucket_alloc() is called during\ncache set registration and attaching, ca->alloc_thread is not properly\nallocated and initialized yet, call wake_up_process() on ca->alloc_thread\ntriggers NULL pointer deference failure. A simple and fast fix is, before\nwaking up ca->alloc_thread, checking whether it is allocated, and only\nwake up ca->alloc_thread when it is not NULL.\n\nSigned-off-by: Coly Li <colyli@suse.de>\nReported-by: Jorg Bornschein <jb@capsec.org>\nCc: Kent Overstreet <kent.overstreet@gmail.com>\nReviewed-by: Michael Lyle <mlyle@lyle.org>\nSigned-off-by: Jens Axboe <axboe@kernel.dk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/f6b69de3c1d4a28539e6c6fe2353da36b31b3e59"},{"sha":"ccd27a40dd0b1b0fb6a5c4fd4faeef8a74c71b9a","author":{"name":"Arnd Bergmann","email":"72a0f6d3b182607e6d5c44b93e1abb7b23ee18f3@arndb.de"},"message":"isofs: fix timestamps beyond 2027\n\ncommit 34be4dbf87fc3e474a842305394534216d428f5d upstream.\n\nisofs uses a 'char' variable to load the number of years since\n1900 for an inode timestamp. On architectures that use a signed\nchar type by default, this results in an invalid date for\nanything beyond 2027.\n\nThis changes the function argument to a 'u8' array, which\nis defined the same way on all architectures, and unambiguously\nlets us use years until 2155.\n\nThis should be backported to all kernels that might still be\nin use by that date.\n\nSigned-off-by: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Jan Kara <jack@suse.cz>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/ccd27a40dd0b1b0fb6a5c4fd4faeef8a74c71b9a"},{"sha":"68be4b00ef14d9908b0b8f76466dfe9abe73f38c","author":{"name":"Joshua Watt","email":"0546a43f9f1fcbe8810633069c058cfd07f76295@gmail.com"},"message":"NFS: Fix typo in nomigration mount option\n\ncommit f02fee227e5f21981152850744a6084ff3fa94ee upstream.\n\nThe option was incorrectly masking off all other options.\n\nSigned-off-by: Joshua Watt <JPEWhacker@gmail.com>\nSigned-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/68be4b00ef14d9908b0b8f76466dfe9abe73f38c"},{"sha":"6de4ff87ad09f48dc3925d183a0c6bc2fd5eee05","author":{"name":"Chuck Lever","email":"038685acf1ee4025ac374ddb5227621ea96609b9@oracle.com"},"message":"nfs: Fix ugly referral attributes\n\ncommit c05cefcc72416a37eba5a2b35f0704ed758a9145 upstream.\n\nBefore traversing a referral and performing a mount, the mounted-on\ndirectory looks strange:\n\ndr-xr-xr-x. 2 4294967294 4294967294 0 Dec 31  1969 dir.0\n\nnfs4_get_referral is wiping out any cached attributes with what was\nreturned via GETATTR(fs_locations), but the bit mask for that\noperation does not request any file attributes.\n\nRetrieve owner and timestamp information so that the memcpy in\nnfs4_get_referral fills in more attributes.\n\nChanges since v1:\n- Don't request attributes that the client unconditionally replaces\n- Request only MOUNTED_ON_FILEID or FILEID attribute, not both\n- encode_fs_locations() doesn't use the third bitmask word\n\nFixes: 6b97fd3da1ea (\"NFSv4: Follow a referral\")\nSuggested-by: Pradeep Thomas <pradeepthomas@gmail.com>\nSigned-off-by: Chuck Lever <chuck.lever@oracle.com>\nSigned-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/6de4ff87ad09f48dc3925d183a0c6bc2fd5eee05"},{"sha":"d31e5b83a1cc1db6628d7cc78c484b3ce0968d66","author":{"name":"Andrew Elble","email":"0b3ab30fa87741bc1806c8082c1abf206f668981@rit.edu"},"message":"nfsd: deal with revoked delegations appropriately\n\ncommit 95da1b3a5aded124dd1bda1e3cdb876184813140 upstream.\n\nIf a delegation has been revoked by the server, operations using that\ndelegation should error out with NFS4ERR_DELEG_REVOKED in the >4.1\ncase, and NFS4ERR_BAD_STATEID otherwise.\n\nThe server needs NFSv4.1 clients to explicitly free revoked delegations.\nIf the server returns NFS4ERR_DELEG_REVOKED, the client will do that;\notherwise it may just forget about the delegation and be unable to\nrecover when it later sees SEQ4_STATUS_RECALLABLE_STATE_REVOKED set on a\nSEQUENCE reply.  That can cause the Linux 4.1 client to loop in its\nstage manager.\n\nSigned-off-by: Andrew Elble <aweits@rit.edu>\nReviewed-by: Trond Myklebust <trond.myklebust@primarydata.com>\nSigned-off-by: J. Bruce Fields <bfields@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/d31e5b83a1cc1db6628d7cc78c484b3ce0968d66"},{"sha":"21ad9e8baf8f4ebcd7297aeefe75e8cba4a2dc68","author":{"name":"Theodore Ts'o","email":"27d72d8f7672ec04389c6b6ff53fcc4e9145bb77@mit.edu"},"message":"ext4: fix interaction between i_size, fallocate, and delalloc after a crash\n\ncommit 51e3ae81ec58e95f10a98ef3dd6d7bce5d8e35a2 upstream.\n\nIf there are pending writes subject to delayed allocation, then i_size\nwill show size after the writes have completed, while i_disksize\ncontains the value of i_size on the disk (since the writes have not\nbeen persisted to disk).\n\nIf fallocate(2) is called with the FALLOC_FL_KEEP_SIZE flag, either\nwith or without the FALLOC_FL_ZERO_RANGE flag set, and the new size\nafter the fallocate(2) is between i_size and i_disksize, then after a\ncrash, if a journal commit has resulted in the changes made by the\nfallocate() call to be persisted after a crash, but the delayed\nallocation write has not resolved itself, i_size would not be updated,\nand this would cause the following e2fsck complaint:\n\nInode 12, end of extent exceeds allowed value\n\t(logical block 33, physical block 33441, len 7)\n\nThis can only take place on a sparse file, where the fallocate(2) call\nis allocating blocks in a range which is before a pending delayed\nallocation write which is extending i_size.  Since this situation is\nquite rare, and the window in which the crash must take place is\ntypically < 30 seconds, in practice this condition will rarely happen.\n\nNevertheless, it can be triggered in testing, and in particular by\nxfstests generic/456.\n\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\nReported-by: Amir Goldstein <amir73il@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/TR-OS/android_kernel_oneplus_msm8996/commits/21ad9e8baf8f4ebcd7297aeefe75e8cba4a2dc68"}]}
{"actor":{"display_login":"TR-OS"}}