{"push_id":2743181597,"size":39,"distinct_size":39,"ref":"refs/heads/next","head":"cca3d5290ede73b01144aa522910c88b1e02fcef","before":"dbc3f77c2fea2875e4fd64e2dee57b9a2bda38e8","commits":[{"sha":"a57a04c76e06822e4377831611364c846b7202ca","author":{"name":"Ram Pai","email":"d0209d78f54ea1d3d3bcda860e7c176e91ec7e04@us.ibm.com"},"message":"powerpc/pkeys: Give all threads control of their key permissions\n\nCurrently in a multithreaded application, a key allocated by one\nthread is not usable by other threads. By \"not usable\" we mean that\nother threads are unable to change the access permissions for that\nkey for themselves.\n\nWhen a new key is allocated in one thread, the corresponding UAMOR\nbits for that thread get enabled, however the UAMOR bits for that key\nfor all other threads remain disabled.\n\nOther threads have no way to set permissions on the key, and the\ncurrent default permissions are that read/write is enabled for all\nkeys, which means the key has no effect for other threads. Although\nthat may be the desired behaviour in some circumstances, having all\nthreads able to control their permissions for the key is more\nflexible.\n\nThe current behaviour also differs from the x86 behaviour, which is\nproblematic for users.\n\nTo fix this, enable the UAMOR bits for all keys, at process\ncreation (in start_thread(), ie exec time). Since the contents of\nUAMOR are inherited at fork, all threads are capable of modifying the\npermissions on any key.\n\nThis is technically an ABI break on powerpc, but pkey support is fairly\nnew on powerpc and not widely used, and this brings us into\nline with x86.\n\nFixes: cf43d3b26452 (\"powerpc: Enable pkey subsystem\")\nCc: stable@vger.kernel.org # v4.16+\nTested-by: Florian Weimer <fweimer@redhat.com>\nSigned-off-by: Ram Pai <linuxram@us.ibm.com>\n[mpe: Reword some of the changelog]\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/a57a04c76e06822e4377831611364c846b7202ca"},{"sha":"de113256f8c1c24d8c79ae388bf2a5abd70f7577","author":{"name":"Ram Pai","email":"d0209d78f54ea1d3d3bcda860e7c176e91ec7e04@us.ibm.com"},"message":"powerpc/pkeys: Deny read/write/execute by default\n\nDeny all permissions on all keys, with some exceptions. pkey-0 must\nallow all permissions, or else everything comes to a screaching halt.\nExecute-only key must allow execute permission.\n\nFixes: cf43d3b26452 (\"powerpc: Enable pkey subsystem\")\nCc: stable@vger.kernel.org # v4.16+\nSigned-off-by: Ram Pai <linuxram@us.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/de113256f8c1c24d8c79ae388bf2a5abd70f7577"},{"sha":"4a4a5e5d2aadc793be95024f454cf511d115b62d","author":{"name":"Ram Pai","email":"d0209d78f54ea1d3d3bcda860e7c176e91ec7e04@us.ibm.com"},"message":"powerpc/pkeys: key allocation/deallocation must not change pkey registers\n\nKey allocation and deallocation has the side effect of programming the\nUAMOR/AMR/IAMR registers. This is wrong, since its the responsibility of\nthe application and not that of the kernel, to modify the permission on\nthe key.\n\nDo not modify the pkey registers at key allocation/deallocation.\n\nThis patch also fixes a bug where a sys_pkey_free() resets the UAMOR\nbits of the key, thus making its permissions unmodifiable from user\nspace. Later if the same key gets reallocated from a different thread\nthis thread will no longer be able to change the permissions on the key.\n\nFixes: cf43d3b26452 (\"powerpc: Enable pkey subsystem\")\nCc: stable@vger.kernel.org # v4.16+\nReviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>\nSigned-off-by: Ram Pai <linuxram@us.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/4a4a5e5d2aadc793be95024f454cf511d115b62d"},{"sha":"c76662e825f507b98938dc3bb141c4505bd4968c","author":{"name":"Ram Pai","email":"d0209d78f54ea1d3d3bcda860e7c176e91ec7e04@us.ibm.com"},"message":"powerpc/pkeys: Save the pkey registers before fork\n\nWhen a thread forks the contents of AMR, IAMR, UAMOR registers in the\nnewly forked thread are not inherited.\n\nSave the registers before forking, for content of those\nregisters to be automatically copied into the new thread.\n\nFixes: cf43d3b26452 (\"powerpc: Enable pkey subsystem\")\nCc: stable@vger.kernel.org # v4.16+\nSigned-off-by: Ram Pai <linuxram@us.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/c76662e825f507b98938dc3bb141c4505bd4968c"},{"sha":"fe6a2804e65969a574377bdb3605afb79e6091a9","author":{"name":"Ram Pai","email":"d0209d78f54ea1d3d3bcda860e7c176e91ec7e04@us.ibm.com"},"message":"powerpc/pkeys: Fix calculation of total pkeys.\n\nTotal number of pkeys calculation is off by 1. Fix it.\n\nFixes: 4fb158f65ac5 (\"powerpc: track allocation status of all pkeys\")\nCc: stable@vger.kernel.org # v4.16+\nSigned-off-by: Ram Pai <linuxram@us.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/fe6a2804e65969a574377bdb3605afb79e6091a9"},{"sha":"a4fcc877d4e18b5efe26e93f08f0cfd4e278c7d9","author":{"name":"Ram Pai","email":"d0209d78f54ea1d3d3bcda860e7c176e91ec7e04@us.ibm.com"},"message":"powerpc/pkeys: Preallocate execute-only key\n\nexecute-only key is allocated dynamically. This is a problem. When a\nthread implicitly creates an execute-only key, and resets the UAMOR\nfor that key, the UAMOR value does not percolate to all the other\nthreads. Any other thread may ignorantly change the permissions on the\nkey. This can cause the key to be not execute-only for that thread.\n\nPreallocate the execute-only key and ensure that no thread can change\nthe permission of the key, by resetting the corresponding bit in\nUAMOR.\n\nFixes: 5586cf61e108 (\"powerpc: introduce execute-only pkey\")\nCc: stable@vger.kernel.org # v4.16+\nSigned-off-by: Ram Pai <linuxram@us.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/a4fcc877d4e18b5efe26e93f08f0cfd4e278c7d9"},{"sha":"07f522d203242b359624a284b61977600eebfd5a","author":{"name":"Ram Pai","email":"d0209d78f54ea1d3d3bcda860e7c176e91ec7e04@us.ibm.com"},"message":"powerpc/pkeys: make protection key 0 less special\n\nApplications need the ability to associate an address-range with some\nkey and latter revert to its initial default key. Pkey-0 comes close to\nproviding this function but falls short, because the current\nimplementation disallows applications to explicitly associate pkey-0 to\nthe address range.\n\nLets make pkey-0 less special and treat it almost like any other key.\nThus it can be explicitly associated with any address range, and can be\nfreed. This gives the application more flexibility and power.  The\nability to free pkey-0 must be used responsibily, since pkey-0 is\nassociated with almost all address-range by default.\n\nEven with this change pkey-0 continues to be slightly more special\nfrom the following point of view.\n(a) it is implicitly allocated.\n(b) it is the default key assigned to any address-range.\n(c) its permissions cannot be modified by userspace.\n\nNOTE: (c) is specific to powerpc only. pkey-0 is associated by default\nwith all pages including kernel pages, and pkeys are also active in\nkernel mode. If any permission is denied on pkey-0, the kernel running\nin the context of the application will be unable to operate.\n\nTested on powerpc.\n\nSigned-off-by: Ram Pai <linuxram@us.ibm.com>\n[mpe: Drop #define PKEY_0 0 in favour of plain old 0]\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/07f522d203242b359624a284b61977600eebfd5a"},{"sha":"5db26e8903deb111b303bd6e0cf304215e0b4fd9","author":{"name":"Ram Pai","email":"d0209d78f54ea1d3d3bcda860e7c176e91ec7e04@us.ibm.com"},"message":"selftests/powerpc: Fix core-pkey for default execute permission change\n\nOnly when the key is allocated, its permission are enabled.\n\nReviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>\nSigned-off-by: Ram Pai <linuxram@us.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/5db26e8903deb111b303bd6e0cf304215e0b4fd9"},{"sha":"29e8131cd77ae49750e7e2f9f596afa5812435f2","author":{"name":"Ram Pai","email":"d0209d78f54ea1d3d3bcda860e7c176e91ec7e04@us.ibm.com"},"message":"selftests/powerpc: Fix ptrace-pkey for default execute permission change\n\nThe test case assumes execute-permissions of unallocated keys are\nenabled by default, which is incorrect.\n\nReviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>\nSigned-off-by: Ram Pai <linuxram@us.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/29e8131cd77ae49750e7e2f9f596afa5812435f2"},{"sha":"9b81c0211c249c1bc8caec2ddbc86e36c550ce0f","author":{"name":"Nicholas Piggin","email":"24829078df5003d9dd1dd871ca2aeb0b1cf95ef4@gmail.com"},"message":"powerpc/64s: make PACA_IRQ_HARD_DIS track MSR[EE] closely\n\nWhen the masked interrupt handler clears MSR[EE] for an interrupt in\nthe PACA_IRQ_MUST_HARD_MASK set, it does not set PACA_IRQ_HARD_DIS.\nThis makes them get out of synch.\n\nWith that taken into account, it's only low level irq manipulation\n(and interrupt entry before reconcile) where they can be out of synch.\nThis makes the code less surprising.\n\nIt also allows the IRQ replay code to rely on the IRQ_HARD_DIS value\nand not have to mtmsrd again in this case (e.g., for an external\ninterrupt that has been masked). The bigger benefit might just be\nthat there is not such an element of surprise in these two bits of\nstate.\n\nSigned-off-by: Nicholas Piggin <npiggin@gmail.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/9b81c0211c249c1bc8caec2ddbc86e36c550ce0f"},{"sha":"5b73151fff63fb019db8171cb81c6c978533844b","author":{"name":"Nicholas Piggin","email":"24829078df5003d9dd1dd871ca2aeb0b1cf95ef4@gmail.com"},"message":"powerpc: NMI IPI make NMI IPIs fully sychronous\n\nThere is an asynchronous aspect to smp_send_nmi_ipi. The caller waits\nfor all CPUs to call in to the handler, but it does not wait for\ncompletion of the handler. This is a needless complication, so remove\nit and always wait synchronously.\n\nThe synchronous wait allows the caller to easily time out and clear\nthe wait for completion (zero nmi_ipi_busy_count) in the case of badly\nbehaved handlers. This would have prevented the recent smp_send_stop\nNMI IPI bug from causing the system to hang.\n\nSigned-off-by: Nicholas Piggin <npiggin@gmail.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/5b73151fff63fb019db8171cb81c6c978533844b"},{"sha":"6d44acae1937b81cf8115ada8958e04f601f3f2e","author":{"name":"Michael Ellerman","email":"864f124608374e06e4da1fa5d2e47ed839b95411@ellerman.id.au"},"message":"powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2\n\nWhen I added the spectre_v2 information in sysfs, I included the\navailability of the ori31 speculation barrier.\n\nAlthough the ori31 barrier can be used to mitigate v2, it's primarily\nintended as a spectre v1 mitigation. Spectre v2 is mitigated by\nhardware changes.\n\nSo rework the sysfs files to show the ori31 information in the\nspectre_v1 file, rather than v2.\n\nCurrently we display eg:\n\n  $ grep . spectre_v*\n  spectre_v1:Mitigation: __user pointer sanitization\n  spectre_v2:Mitigation: Indirect branch cache disabled, ori31 speculation barrier enabled\n\nAfter:\n\n  $ grep . spectre_v*\n  spectre_v1:Mitigation: __user pointer sanitization, ori31 speculation barrier enabled\n  spectre_v2:Mitigation: Indirect branch cache disabled\n\nFixes: d6fbe1c55c55 (\"powerpc/64s: Wire up cpu_show_spectre_v2()\")\nCc: stable@vger.kernel.org # v4.17+\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/6d44acae1937b81cf8115ada8958e04f601f3f2e"},{"sha":"8db0c9d416f26018cb7cabfb0b144f5108e29735","author":{"name":"Michael Ellerman","email":"864f124608374e06e4da1fa5d2e47ed839b95411@ellerman.id.au"},"message":"powerpc: Add ppc32_allmodconfig defconfig target\n\nBecause the allmodconfig logic just sets every symbol to M or Y, it\nhas the effect of always generating a 64-bit config, because\nCONFIG_PPC64 becomes Y.\n\nSo to make it easier for folks to test 32-bit code, provide a phony\ndefconfig target that generates a 32-bit allmodconfig.\n\nThe 32-bit port has several mutually exclusive CPU types, we choose\nthe Book3S variants as that's what the help text in Kconfig says is\nmost common.\n\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/8db0c9d416f26018cb7cabfb0b144f5108e29735"},{"sha":"64de5d8d0457c325e2226c9c7efb37b1f772076c","author":{"name":"Michael Ellerman","email":"864f124608374e06e4da1fa5d2e47ed839b95411@ellerman.id.au"},"message":"powerpc: Add ppc64le and ppc64_book3e allmodconfig targets\n\nSimilarly as we just did for 32-bit, add phony targets for generating\na little endian and Book3E allmodconfig. These aren't covered by the\nregular allmodconfig, which is big endian and Book3S due to the way\nthe Kconfig symbols are structured.\n\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/64de5d8d0457c325e2226c9c7efb37b1f772076c"},{"sha":"6aba0c84ec474534bbae3675e95464958a6c5713","author":{"name":"Aneesh Kumar K.V","email":"f511f818e8a0748edef6b9ee378967da9ed0c78f@linux.ibm.com"},"message":"powerpc/mm: Check memblock_add against MAX_PHYSMEM_BITS range\n\nWith SPARSEMEM config enabled, we make sure that we don't add sections beyond\nMAX_PHYSMEM_BITS range. This results in not building vmemmap mapping for\nrange beyond max range. But our memblock layer looks the device tree and create\nmapping for the full memory range. Prevent this by checking against\nMAX_PHSYSMEM_BITS when doing memblock_add.\n\nWe don't do similar check for memeblock_reserve_range. If reserve range is beyond\nMAX_PHYSMEM_BITS we expect that to be configured with 'nomap'. Any other\nreserved range should come from existing memblock ranges which we already\nfiltered while adding.\n\nThis avoids crash as below when running on a system with system ram config above\nMAX_PHSYSMEM_BITS\n\n Unable to handle kernel paging request for data at address 0xc00a001000000440\n Faulting instruction address: 0xc000000001034118\n cpu 0x0: Vector: 300 (Data Access) at [c00000000124fb30]\n     pc: c000000001034118: __free_pages_bootmem+0xc0/0x1c0\n     lr: c00000000103b258: free_all_bootmem+0x19c/0x22c\n     sp: c00000000124fdb0\n    msr: 9000000002001033\n    dar: c00a001000000440\n  dsisr: 40000000\n   current = 0xc00000000120dd00\n   paca    = 0xc000000001f60000^I irqmask: 0x03^I irq_happened: 0x01\n     pid   = 0, comm = swapper\n [c00000000124fe20] c00000000103b258 free_all_bootmem+0x19c/0x22c\n [c00000000124fee0] c000000001010a68 mem_init+0x3c/0x5c\n [c00000000124ff00] c00000000100401c start_kernel+0x298/0x5e4\n [c00000000124ff90] c00000000000b57c start_here_common+0x1c/0x520\n\nSigned-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/6aba0c84ec474534bbae3675e95464958a6c5713"},{"sha":"7d4340bb92a9df78e6e28152f3dd89d9bd82146b","author":{"name":"Aneesh Kumar K.V","email":"f511f818e8a0748edef6b9ee378967da9ed0c78f@linux.ibm.com"},"message":"powerpc/mm: Increase MAX_PHYSMEM_BITS to 128TB with SPARSEMEM_VMEMMAP config\n\nWe do this only with VMEMMAP config so that our page_to_[nid/section] etc are not\nimpacted.\n\nSigned-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/7d4340bb92a9df78e6e28152f3dd89d9bd82146b"},{"sha":"1531cff44b5bb30c899404c044805ec60b2f3620","author":{"name":"Aneesh Kumar K.V","email":"f511f818e8a0748edef6b9ee378967da9ed0c78f@linux.vnet.ibm.com"},"message":"powerpc/mm/hash: Remove the superfluous bitwise operation when find hpte group\n\nWhen computing the starting slot number for a hash page table group we used\nto do this\nhpte_group = ((hash & htab_hash_mask) * HPTES_PER_GROUP) & ~0x7UL;\n\nMultiplying with 8 (HPTES_PER_GROUP) imply the last three bits are 0. Hence we\nreally don't need to clear then separately.\n\nSigned-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/1531cff44b5bb30c899404c044805ec60b2f3620"},{"sha":"a833280b4aeeb3152369a3d5bcdc09447fea8358","author":{"name":"Aneesh Kumar K.V","email":"f511f818e8a0748edef6b9ee378967da9ed0c78f@linux.ibm.com"},"message":"powerpc/mm/hash: Add hpte_get_old_v and use that instead of opencoding\n\nNo functional change\n\nSigned-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/a833280b4aeeb3152369a3d5bcdc09447fea8358"},{"sha":"27d8959da712771e2038ec77318fe8b2b8591e28","author":{"name":"Aneesh Kumar K.V","email":"f511f818e8a0748edef6b9ee378967da9ed0c78f@linux.vnet.ibm.com"},"message":"powerpc/mm/hash: Reduce contention on hpte lock\n\nWe do this in some part. This patch make sure we always try to search\nfor hpte without holding lock and redo the compare with lock held once\nmatch found.\n\nSigned-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/27d8959da712771e2038ec77318fe8b2b8591e28"},{"sha":"65471d763e9178a8dc6f05db1c9c09c292f75c28","author":{"name":"Aneesh Kumar K.V","email":"f511f818e8a0748edef6b9ee378967da9ed0c78f@linux.ibm.com"},"message":"powerpc/pseries: Use pr_xxx() in lpar.c\n\nSwitch from printk to pr_fmt() / pr_xxx().\n\nSigned-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>\n[mpe: Split out of larger patch]\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/65471d763e9178a8dc6f05db1c9c09c292f75c28"}]}
{"actor":{"display_login":"ruscur"}}