{"push_id":2329476665,"size":24,"distinct_size":14,"ref":"refs/heads/merge","head":"3f6f556fae7fb3ac846d2bf4f9af5d28bb37779d","before":"7d5f2edc5013f805f52df347ace6a51ceb8de892","commits":[{"sha":"eff84b379089cd8b4e83599639c1f5f6e34ef7bf","author":{"name":"Eric Biggers","email":"0106d512ed1cb672be29d4b167a07ead51709fba@google.com"},"message":"crypto: sha512-mb - initialize pending lengths correctly\n\nThe SHA-512 multibuffer code keeps track of the number of blocks pending\nin each lane.  The minimum of these values is used to identify the next\nlane that will be completed.  Unused lanes are set to a large number\n(0xFFFFFFFF) so that they don't affect this calculation.\n\nHowever, it was forgotten to set the lengths to this value in the\ninitial state, where all lanes are unused.  As a result it was possible\nfor sha512_mb_mgr_get_comp_job_avx2() to select an unused lane, causing\na NULL pointer dereference.  Specifically this could happen in the case\nwhere ->update() was passed fewer than SHA512_BLOCK_SIZE bytes of data,\nso it then called sha_complete_job() without having actually submitted\nany blocks to the multi-buffer code.  This hit a NULL pointer\ndereference if another task happened to have submitted blocks\nconcurrently to the same CPU and the flush timer had not yet expired.\n\nFix this by initializing sha512_mb_mgr->lens correctly.\n\nAs usual, this bug was found by syzkaller.\n\nFixes: 45691e2d9b18 (\"crypto: sha512-mb - submit/flush routines for AVX2\")\nReported-by: syzbot <syzkaller@googlegroups.com>\nCc: <stable@vger.kernel.org> # v4.8+\nSigned-off-by: Eric Biggers <ebiggers@google.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/eff84b379089cd8b4e83599639c1f5f6e34ef7bf"},{"sha":"87a81dce53b1ea61acaeefa5191a0376a2d1d721","author":{"name":"LEROY Christophe","email":"039dabc4895565112aed26d4ec2b65f486237723@c-s.fr"},"message":"crypto: talitos - fix Kernel Oops on hashing an empty file\n\nPerforming the hash of an empty file leads to a kernel Oops\n\n[   44.504600] Unable to handle kernel paging request for data at address 0x0000000c\n[   44.512819] Faulting instruction address: 0xc02d2be8\n[   44.524088] Oops: Kernel access of bad area, sig: 11 [#1]\n[   44.529171] BE PREEMPT CMPC885\n[   44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 4.15.0-rc8-00211-g3a968610b6ea #81\n[   44.540814] NIP:  c02d2be8 LR: c02d2984 CTR: 00000000\n[   44.545812] REGS: c6813c90 TRAP: 0300   Not tainted  (4.15.0-rc8-00211-g3a968610b6ea)\n[   44.554223] MSR:  00009032 <EE,ME,IR,DR,RI>  CR: 48222822  XER: 20000000\n[   44.560855] DAR: 0000000c DSISR: c0000000\n[   44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 00000001 00000001 00000001 00000000\n[   44.560855] GPR08: 0000004c 00000000 c000bfcc 00000000 28222822 100280d4 00000000 10020008\n[   44.560855] GPR16: 00000000 00000020 00000000 00000000 10024008 00000000 c646f9f0 c6179a10\n[   44.560855] GPR24: 00000000 00000001 c62f0018 c6179a10 00000000 c6367a30 c62f0000 c646f9c0\n[   44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700\n[   44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700\n[   44.608868] Call Trace:\n[   44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unreliable)\n[   44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210\n[   44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138\n[   44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84\n[   44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4\n[   44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38\n[   44.645530] Instruction dump:\n[   44.648465] 38c00001 7f63db78 4e800421 7c791b78 54690ffe 0f090000 80ff0190 2f870000\n[   44.656122] 40befe50 2f990001 409e0210 813f01bc <8129000c> b39e003a 7d29c214 913e003c\n\nThis patch fixes that Oops by checking if src is NULL.\n\nFixes: 6a1e8d14156d4 (\"crypto: talitos - making mapping helpers more generic\")\nCc: <stable@vger.kernel.org>\nSigned-off-by: Christophe Leroy <christophe.leroy@c-s.fr>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/87a81dce53b1ea61acaeefa5191a0376a2d1d721"},{"sha":"4767b9ad7d762876a5865a06465e13e139a01b6b","author":{"name":"Ard Biesheuvel","email":"80b89d4a5c0c8f00cebbb9c7d8a672c776f22af1@linaro.org"},"message":"crypto: sha3-generic - deal with oversize stack frames\n\nAs reported by kbuild test robot, the optimized SHA3 C implementation\ncompiles to mn10300 code that uses a disproportionate amount of stack\nspace, i.e.,\n\n  crypto/sha3_generic.c: In function 'keccakf':\n  crypto/sha3_generic.c:147:1: warning: the frame size of 1232 bytes is larger than 1024 bytes [-Wframe-larger-than=]\n\nAs kindly diagnosed by Arnd, this does not only occur when building for\nthe mn10300 architecture (which is what the report was about) but also\nfor h8300, and builds for other 32-bit architectures show an increase in\nstack space utilization as well.\n\nGiven that SHA3 operates on 64-bit quantities, and keeps a state matrix\nof 25 64-bit words, it is not surprising that 32-bit architectures with\nfew general purpose registers are impacted the most by this, and it is\ntherefore reasonable to implement a workaround that distinguishes between\n32-bit and 64-bit architectures.\n\nArnd figured out that taking the round calculation out of the loop, and\ninlining it explicitly but only on 64-bit architectures preserves most\nof the performance gain achieved by the rewrite, and also gets rid of\nthe excessive use of stack space.\n\nReported-by: kbuild test robot <fengguang.wu@intel.com>\nSuggested-by: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/4767b9ad7d762876a5865a06465e13e139a01b6b"},{"sha":"df5d45aa08f848b79caf395211b222790534ccc7","author":{"name":"Geert Uytterhoeven","email":"6ab3568c168343bc5fcca77fbd6a3d6e63ce9838@linux-m68k.org"},"message":"compiler-gcc.h: Introduce __optimize function attribute\n\nCreate a new function attribute __optimize, which allows to specify an\noptimization level on a per-function basis.\n\nSigned-off-by: Geert Uytterhoeven <geert@linux-m68k.org>\nAcked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/df5d45aa08f848b79caf395211b222790534ccc7"},{"sha":"d9afaaa4ff7af8b87d4a205e48cb8a6f666d7f01","author":{"name":"Geert Uytterhoeven","email":"6ab3568c168343bc5fcca77fbd6a3d6e63ce9838@linux-m68k.org"},"message":"compiler-gcc.h: __nostackprotector needs gcc-4.4 and up\n\nGcc versions before 4.4 do not recognize the __optimize__ compiler\nattribute:\n\n    warning: ‘__optimize__’ attribute directive ignored\n\nFixes: 7375ae3a0b79ea07 (\"compiler-gcc.h: Introduce __nostackprotector function attribute\")\nSigned-off-by: Geert Uytterhoeven <geert@linux-m68k.org>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/d9afaaa4ff7af8b87d4a205e48cb8a6f666d7f01"},{"sha":"ba916b6a0339ed6cc6441ad83c097ab795dbdbc5","author":{"name":"Geert Uytterhoeven","email":"6ab3568c168343bc5fcca77fbd6a3d6e63ce9838@linux-m68k.org"},"message":"crypto: sha3-generic - Use __optimize to support old compilers\n\nWith gcc-4.1.2:\n\n    crypto/sha3_generic.c:39: warning: ‘__optimize__’ attribute directive ignored\n\nUse the newly introduced __optimize macro to fix this.\n\nFixes: 83dee2ce1ae791c3 (\"crypto: sha3-generic - rewrite KECCAK transform to help the compiler optimize\")\nSigned-off-by: Geert Uytterhoeven <geert@linux-m68k.org>\nAcked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/ba916b6a0339ed6cc6441ad83c097ab795dbdbc5"},{"sha":"225ece3e7dad4cfc44cca38ce7a3a80f255ea8f1","author":{"name":"Horia Geantă","email":"87fbee286af4b152b592859165e8b005642ca748@nxp.com"},"message":"crypto: caam - fix endless loop when DECO acquire fails\n\nIn case DECO0 cannot be acquired - i.e. run_descriptor_deco0() fails\nwith -ENODEV, caam_probe() enters an endless loop:\n\nrun_descriptor_deco0\n\tret -ENODEV\n\t-> instantiate_rng\n\t\t-ENODEV, overwritten by -EAGAIN\n\t\tret -EAGAIN\n\t\t-> caam_probe\n\t\t\t-EAGAIN results in endless loop\n\nIt turns out the error path in instantiate_rng() is incorrect,\nthe checks are done in the wrong order.\n\nCc: <stable@vger.kernel.org> # 3.13+\nFixes: 1005bccd7a4a6 (\"crypto: caam - enable instantiation of all RNG4 state handles\")\nReported-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>\nSuggested-by: Auer Lukas <lukas.auer@aisec.fraunhofer.de>\nSigned-off-by: Horia Geantă <horia.geanta@nxp.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/225ece3e7dad4cfc44cca38ce7a3a80f255ea8f1"},{"sha":"dd78c832ffaf86eb6434e56de4bc3bc31f03f771","author":{"name":"Artem Savkov","email":"6f84535b49cc169b4b40d93a9ee3baa71262f99e@gmail.com"},"message":"crypto: sun4i_ss_prng - fix return value of sun4i_ss_prng_generate\n\nAccording to crypto/rng.h generate function should return 0 on success\nand < 0 on error.\n\nFixes: b8ae5c7387ad (\"crypto: sun4i-ss - support the Security System PRNG\")\nSigned-off-by: Artem Savkov <artem.savkov@gmail.com>\nAcked-by: Corentin Labbe <clabbe.montjoie@gmail.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/dd78c832ffaf86eb6434e56de4bc3bc31f03f771"},{"sha":"2e7d1d61ea6c0f1c4da5eb82cafac750d55637a7","author":{"name":"Artem Savkov","email":"6f84535b49cc169b4b40d93a9ee3baa71262f99e@gmail.com"},"message":"crypto: sun4i_ss_prng - convert lock to _bh in sun4i_ss_prng_generate\n\nLockdep detects a possible deadlock in sun4i_ss_prng_generate() and\nthrows an \"inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage\" warning.\nDisabling softirqs to fix this.\n\nFixes: b8ae5c7387ad (\"crypto: sun4i-ss - support the Security System PRNG\")\nSigned-off-by: Artem Savkov <artem.savkov@gmail.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/2e7d1d61ea6c0f1c4da5eb82cafac750d55637a7"},{"sha":"aece34cd576c7625181b0488a8129c1e165355f7","author":{"name":"Paul Burton","email":"6cf344976ede6e423f0f16c3121262bddc8fed82@mips.com"},"message":"dt-bindings: Document mti,mips-cpc binding\n\nDocument a binding for the MIPS Cluster Power Controller (CPC) that\nallows the device tree to specify where the CPC registers are located.\n\nSigned-off-by: Paul Burton <paul.burton@mips.com>\nSigned-off-by: Aleksandar Markovic <aleksandar.markovic@mips.com>\nReviewed-by: Rob Herring <robh@kernel.org>\nCc: linux-mips@linux-mips.org\nCc: devicetree@vger.kernel.org\nPatchwork: https://patchwork.linux-mips.org/patch/18512/\nSigned-off-by: James Hogan <jhogan@kernel.org>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/aece34cd576c7625181b0488a8129c1e165355f7"},{"sha":"791412dafbbfd860e78983d45cf71db603a82f67","author":{"name":"Paul Burton","email":"6cf344976ede6e423f0f16c3121262bddc8fed82@mips.com"},"message":"MIPS: CPC: Map registers using DT in mips_cpc_default_phys_base()\n\nReading mips_cpc_base value from the DT allows each platform to\ndefine it according to its needs. This is especially convenient\nfor MIPS_GENERIC kernel where this kind of information should be\ndetermined in runtime.\n\nUse mti,mips-cpc compatible string with just a reg property to\nspecify the register location for your platform.\n\nSigned-off-by: Paul Burton <paul.burton@mips.com>\nSigned-off-by: Miodrag Dinic <miodrag.dinic@mips.com>\nSigned-off-by: Aleksandar Markovic <aleksandar.markovic@mips.com>\nCc: linux-mips@linux-mips.org\nCc: Ralf Baechle <ralf@linux-mips.org>\nPatchwork: https://patchwork.linux-mips.org/patch/18513/\nSigned-off-by: James Hogan <jhogan@kernel.org>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/791412dafbbfd860e78983d45cf71db603a82f67"},{"sha":"178e834c47b0d01352c48730235aae69898fbc02","author":{"name":"Linus Torvalds","email":"ead7104581934751970e9decb2db5deb20a9e407@linux-foundation.org"},"message":"Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6\n\nPull crypto fixes from Herbert Xu:\n \"This fixes the following issues:\n\n   - oversize stack frames on mn10300 in sha3-generic\n\n   - warning on old compilers in sha3-generic\n\n   - API error in sun4i_ss_prng\n\n   - potential dead-lock in sun4i_ss_prng\n\n   - null-pointer dereference in sha512-mb\n\n   - endless loop when DECO acquire fails in caam\n\n   - kernel oops when hashing empty message in talitos\"\n\n* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:\n  crypto: sun4i_ss_prng - convert lock to _bh in sun4i_ss_prng_generate\n  crypto: sun4i_ss_prng - fix return value of sun4i_ss_prng_generate\n  crypto: caam - fix endless loop when DECO acquire fails\n  crypto: sha3-generic - Use __optimize to support old compilers\n  compiler-gcc.h: __nostackprotector needs gcc-4.4 and up\n  compiler-gcc.h: Introduce __optimize function attribute\n  crypto: sha3-generic - deal with oversize stack frames\n  crypto: talitos - fix Kernel Oops on hashing an empty file\n  crypto: sha512-mb - initialize pending lengths correctly","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/178e834c47b0d01352c48730235aae69898fbc02"},{"sha":"c9dccf1d074a67d36c510845f663980d69e3409b","author":{"name":"Sam Bobroff","email":"198d89b753a45ced78bccd32615a2bcbd2522272@au1.ibm.com"},"message":"powerpc/pseries: Enable RAS hotplug events later\n\nCurrently if the kernel receives a memory hot-unplug event early\nenough, it may get stuck in an infinite loop in\ndissolve_free_huge_pages(). This appears as a stall just after:\n\n  pseries-hotplug-mem: Attempting to hot-remove XX LMB(s) at YYYYYYYY\n\nIt appears to be caused by \"minimum_order\" being uninitialized, due to\ninit_ras_IRQ() executing before hugetlb_init().\n\nTo correct this, extract the part of init_ras_IRQ() that enables\nhotplug event processing and place it in the machine_late_initcall\nphase, which is guaranteed to be after hugetlb_init() is called.\n\nSigned-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>\nAcked-by: Balbir Singh <bsingharora@gmail.com>\n[mpe: Reorder the functions to make the diff readable]\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":false,"url":"https://api.github.com/repos/linuxppc/linux/commits/c9dccf1d074a67d36c510845f663980d69e3409b"},{"sha":"b00b62898631b756c3e123542bbb0487aa343dd9","author":{"name":"Nicholas Piggin","email":"f05c04607627fe5da053d74c5f6ef1dc9d849ab6@gmail.com"},"message":"powerpc/vas: Don't set uses_vas for kernel windows\n\ncp_abort is only required for user windows, because kernel context\nmust not be preempted between a copy/paste pair.\n\nWithout this patch, the init task gets used_vas set when it runs the\nnx842_powernv_init initcall, which opens windows for kernel usage.\n\nused_vas is then never cleared anywhere, so it gets propagated into\nall other tasks. It's a property of the address space, so it should\nreally be cleared when a new mm is created (or in dup_mmap if the\nmmaps are marked as VM_DONTCOPY). For now we seem to have no such\ndriver, so leave that for another patch.\n\nFixes: 6c8e6bb2a52d (\"powerpc/vas: Add support for user receive window\")\nCc: stable@vger.kernel.org # v4.15+\nSigned-off-by: Nicholas Piggin <npiggin@gmail.com>\nReviewed-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":false,"url":"https://api.github.com/repos/linuxppc/linux/commits/b00b62898631b756c3e123542bbb0487aa343dd9"},{"sha":"62e984ddfd6b056d399e24113f5e6a7145e579d8","author":{"name":"Alexey Kardashevskiy","email":"4ac31ea3affe1efd3f0ea903dab9f9666559912c@ozlabs.ru"},"message":"powerpc/mm: Flush radix process translations when setting MMU type\n\nRadix guests do normally invalidate process-scoped translations when a\nnew pid is allocated but migrated guests do not invalidate these so\nmigrated guests crash sometime, especially easy to reproduce with\nmigration happening within first 10 seconds after the guest boot start\non the same machine.\n\nThis adds the \"Invalidate process-scoped translations\" flush to fix\nradix guests migration.\n\nFixes: 2ee13be34b13 (\"KVM: PPC: Book3S HV: Update kvmppc_set_arch_compat() for ISA v3.00\")\nCc: stable@vger.kernel.org # v4.10+\nSigned-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>\nTested-by: Laurent Vivier <lvivier@redhat.com>\nTested-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":false,"url":"https://api.github.com/repos/linuxppc/linux/commits/62e984ddfd6b056d399e24113f5e6a7145e579d8"},{"sha":"fae2211697c9490414e974431051f7fed5506653","author":{"name":"Aneesh Kumar K.V","email":"e35455d9785cc3190a5bd1427d7474d5511fd373@linux.vnet.ibm.com"},"message":"powerpc/mm: Fix crashes with 16G huge pages\n\nTo support memory keys, we moved the hash pte slot information to the\nsecond half of the page table. This was ok with PTE entries at level\n4 (PTE page) and level 3 (PMD). We already allocate larger page table\npages at those levels to accomodate extra details. For level 4 we\nalready have the extra space which was used to track 4k hash page\ntable entry details and at level 3 the extra space was allocated to\ntrack the THP details.\n\nWith hugetlbfs PTE, we used this extra space at the PMD level to store\nthe slot details. But we also support hugetlbfs PTE at PUD level for\n16GB pages and PUD level page didn't allocate extra space. This\nresulted in memory corruption.\n\nFix this by allocating extra space at PUD level when HUGETLB is\nenabled.\n\nFixes: bf9a95f9a648 (\"powerpc: Free up four 64K PTE bits in 64K backed HPTE pages\")\nSigned-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>\nReviewed-by: Ram Pai <linuxram@us.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":false,"url":"https://api.github.com/repos/linuxppc/linux/commits/fae2211697c9490414e974431051f7fed5506653"},{"sha":"4a7aa4fecbbf94b5c6fae8acccc983d919992bde","author":{"name":"Aneesh Kumar K.V","email":"e35455d9785cc3190a5bd1427d7474d5511fd373@linux.vnet.ibm.com"},"message":"powerpc/mm/hash64: Allocate larger PMD table if hugetlb config is enabled\n\nWe use the second half of the page table to store slot information, so we must\nallocate it always if hugetlb is possible.\n\nFixes: bf9a95f9a648 (\"powerpc: Free up four 64K PTE bits in 64K backed HPTE pages\")\nSigned-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>\nReviewed-by: Ram Pai <linuxram@us.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":false,"url":"https://api.github.com/repos/linuxppc/linux/commits/4a7aa4fecbbf94b5c6fae8acccc983d919992bde"},{"sha":"ff31e105464d8c8c973019646827020aed9c2d9f","author":{"name":"Aneesh Kumar K.V","email":"e35455d9785cc3190a5bd1427d7474d5511fd373@linux.vnet.ibm.com"},"message":"powerpc/mm/hash64: Store the slot information at the right offset for hugetlb\n\nThe hugetlb pte entries are at the PMD and PUD level, so we can't use\nPTRS_PER_PTE to find the second half of the page table. Use the right\noffset for PUD/PMD to get to the second half of the table.\n\nFixes: bf9a95f9a648 (\"powerpc: Free up four 64K PTE bits in 64K backed HPTE pages\")\nSigned-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>\nReviewed-by: Ram Pai <linuxram@us.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":false,"url":"https://api.github.com/repos/linuxppc/linux/commits/ff31e105464d8c8c973019646827020aed9c2d9f"},{"sha":"fc5c2f4a55a2c258e12013cdf287cf266dbcd2a7","author":{"name":"Aneesh Kumar K.V","email":"e35455d9785cc3190a5bd1427d7474d5511fd373@linux.vnet.ibm.com"},"message":"powerpc/mm/hash64: Zero PGD pages on allocation\n\nOn powerpc we allocate page table pages from slab caches of different\nsizes. Currently we have a constructor that zeroes out the objects when\nwe allocate them for the first time.\n\nWe expect the objects to be zeroed out when we free the the object\nback to slab cache. This happens in the unmap path. For hugetlb pages\nwe call huge_pte_get_and_clear() to do that.\n\nWith the current configuration of page table size, both PUD and PGD\nlevel tables are allocated from the same slab cache. At the PUD level,\nwe use the second half of the table to store the slot information. But\nwe never clear that when unmapping.\n\nWhen such a freed object is then allocated for a PGD page, the second\nhalf of the page table page will not be zeroed as expected. This\nresults in a kernel crash.\n\nFix it by always clearing PGD pages when they're allocated.\n\nSigned-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>\n[mpe: Change log wording and formatting, add whitespace]\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":false,"url":"https://api.github.com/repos/linuxppc/linux/commits/fc5c2f4a55a2c258e12013cdf287cf266dbcd2a7"},{"sha":"82343484a2d4c97a03bfd81303b5493c65f05c50","author":{"name":"Guenter Roeck","email":"177f6c7e7d0681e1b64ab10ef561094344edf6d6@roeck-us.net"},"message":"powerpc/pseries: Fix build break for SPLPAR=n and CPU hotplug\n\nCommit e67e02a544e9 (\"powerpc/pseries: Fix cpu hotplug crash with\nmemoryless nodes\") adds an unconditional call to\nfind_and_online_cpu_nid(), which is only declared if CONFIG_PPC_SPLPAR\nis enabled. This results in the following build error if this is not\nthe case.\n\n  arch/powerpc/platforms/pseries/hotplug-cpu.o: In function `dlpar_online_cpu':\n  arch/powerpc/platforms/pseries/hotplug-cpu.c:369:\n  \t\t\tundefined reference to `.find_and_online_cpu_nid'\n\nFollow the guideline provided by similar functions and provide a dummy\nfunction if CONFIG_PPC_SPLPAR is not enabled. This also moves the\nexternal function declaration into an include file where it should be.\n\nFixes: e67e02a544e9 (\"powerpc/pseries: Fix cpu hotplug crash with memoryless nodes\")\nSigned-off-by: Guenter Roeck <linux@roeck-us.net>\n[mpe: Change subject to emphasise the build fix]\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":false,"url":"https://api.github.com/repos/linuxppc/linux/commits/82343484a2d4c97a03bfd81303b5493c65f05c50"}]}
{"actor":{"display_login":"mpe"}}