{"push_id":2322846106,"size":69,"distinct_size":1,"ref":"refs/heads/linaro/linux-linaro-lsk-v4.9","head":"9cebd248bd83dea5ead3f1ab5f3cbaf241588e37","before":"4f0ca2b2718d297c88b1c303f2d414327c537636","commits":[{"sha":"c36c940cd4aab393c09d457e2414423ac92bd339","author":{"name":"Andy Lutomirski","email":"3cb7d5a8804519b67b2d7945dee31e85c91c02f9@kernel.org"},"message":"x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels\n\ncommit 1c52d859cb2d417e7216d3e56bb7fea88444cec9 upstream.\n\nWe support various non-Intel CPUs that don't have the CPUID\ninstruction, so the M486 test was wrong.  For now, fix it with a big\nhammer: handle missing CPUID on all 32-bit CPUs.\n\nReported-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>\nSigned-off-by: Andy Lutomirski <luto@kernel.org>\nCc: Juergen Gross <jgross@suse.com>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Brian Gerst <brgerst@gmail.com>\nCc: Matthew Whitehead <tedheadster@gmail.com>\nCc: Borislav Petkov <bp@alien8.de>\nCc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>\nCc: Andrew Cooper <andrew.cooper3@citrix.com>\nCc: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nCc: xen-devel <Xen-devel@lists.xen.org>\nLink: http://lkml.kernel.org/r/685bd083a7c036f7769510b6846315b17d6ba71f.1481307769.git.luto@kernel.org\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nCc: \"Zhang, Ning A\" <ning.a.zhang@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/c36c940cd4aab393c09d457e2414423ac92bd339"},{"sha":"fb39345e73141e4ae4529168965c37024cb3acb3","author":{"name":"Martin Brandenburg","email":"ea98e1d0a9a4d10e3af04e16be88050749615623@omnibond.com"},"message":"orangefs: use list_for_each_entry_safe in purge_waiting_ops\n\ncommit 0afc0decf247f65b7aba666a76a0a68adf4bc435 upstream.\n\nset_op_state_purged can delete the op.\n\nSigned-off-by: Martin Brandenburg <martin@omnibond.com>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/fb39345e73141e4ae4529168965c37024cb3acb3"},{"sha":"5c26ee198fcacda157918a9b211ba1f111e1ed9b","author":{"name":"Martin Brandenburg","email":"ea98e1d0a9a4d10e3af04e16be88050749615623@omnibond.com"},"message":"orangefs: initialize op on loop restart in orangefs_devreq_read\n\ncommit a0ec1ded22e6a6bc41981fae22406835b006a66e upstream.\n\nIn orangefs_devreq_read, there is a loop which picks an op off the list\nof pending ops.  If the loop fails to find an op, there is nothing to\nread, and it returns EAGAIN.  If the op has been given up on, the loop\nis restarted via a goto.  The bug is that the variable which the found\nop is written to is not reinitialized, so if there are no more eligible\nops on the list, the code runs again on the already handled op.\n\nThis is triggered by interrupting a process while the op is being copied\nto the client-core.  It's a fairly small window, but it's there.\n\nSigned-off-by: Martin Brandenburg <martin@omnibond.com>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/5c26ee198fcacda157918a9b211ba1f111e1ed9b"},{"sha":"ce601a07bc504b4748f8e7a34896684f79514e51","author":{"name":"Shuah Khan","email":"1a8b7edcfc00bb8cbbb1f50ab3153da93b81fdf3@osg.samsung.com"},"message":"usbip: prevent vhci_hcd driver from leaking a socket pointer address\n\ncommit 2f2d0088eb93db5c649d2a5e34a3800a8a935fc5 upstream.\n\nWhen a client has a USB device attached over IP, the vhci_hcd driver is\nlocally leaking a socket pointer address via the\n\n/sys/devices/platform/vhci_hcd/status file (world-readable) and in debug\noutput when \"usbip --debug port\" is run.\n\nFix it to not leak. The socket pointer address is not used at the moment\nand it was made visible as a convenient way to find IP address from socket\npointer address by looking up /proc/net/{tcp,tcp6}.\n\nAs this opens a security hole, the fix replaces socket pointer address with\nsockfd.\n\nReported-by: Secunia Research <vuln@secunia.com>\nSigned-off-by: Shuah Khan <shuahkh@osg.samsung.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/ce601a07bc504b4748f8e7a34896684f79514e51"},{"sha":"853c39f239eb89cfd91ee03257c624aaac0575c6","author":{"name":"Jonathan Dieter","email":"87adf5bf660404714130c2c97cef51f5434532f0@lesbg.com"},"message":"usbip: Fix implicit fallthrough warning\n\ncommit cfd6ed4537a9e938fa76facecd4b9cd65b6d1563 upstream.\n\nGCC 7 now warns when switch statements fall through implicitly, and with\n-Werror enabled in configure.ac, that makes these tools unbuildable.\n\nWe fix this by notifying the compiler that this particular case statement\nis meant to fall through.\n\nReviewed-by: Peter Senna Tschudin <peter.senna@gmail.com>\nSigned-off-by: Jonathan Dieter <jdieter@lesbg.com>\nSigned-off-by: Shuah Khan <shuahkh@osg.samsung.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/853c39f239eb89cfd91ee03257c624aaac0575c6"},{"sha":"69e78e7214e39c084fcafdfb83b4d13d21b0008b","author":{"name":"Jonathan Dieter","email":"87adf5bf660404714130c2c97cef51f5434532f0@lesbg.com"},"message":"usbip: Fix potential format overflow in userspace tools\n\ncommit e5dfa3f902b9a642ae8c6997d57d7c41e384a90b upstream.\n\nThe usbip userspace tools call sprintf()/snprintf() and don't check for\nthe return value which can lead the paths to overflow, truncating the\nfinal file in the path.\n\nMore urgently, GCC 7 now warns that these aren't checked with\n-Wformat-overflow, and with -Werror enabled in configure.ac, that makes\nthese tools unbuildable.\n\nThis patch fixes these problems by replacing sprintf() with snprintf() in\none place and adding checks for the return value of snprintf().\n\nReviewed-by: Peter Senna Tschudin <peter.senna@gmail.com>\nSigned-off-by: Jonathan Dieter <jdieter@lesbg.com>\nAcked-by: Shuah Khan <shuahkh@osg.samsung.com>\nSigned-off-by: Shuah Khan <shuahkh@osg.samsung.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/69e78e7214e39c084fcafdfb83b4d13d21b0008b"},{"sha":"40bf2c0c1c9ec9c3a17afac43fcd18b39759defd","author":{"name":"Marc Kleine-Budde","email":"86a3a4ad69448b8f7c92083394f83d765887082e@pengutronix.de"},"message":"can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once\n\ncommit 8cb68751c115d176ec851ca56ecfbb411568c9e8 upstream.\n\nIf an invalid CAN frame is received, from a driver or from a tun\ninterface, a Kernel warning is generated.\n\nThis patch replaces the WARN_ONCE by a simple pr_warn_once, so that a\nkernel, bootet with panic_on_warn, does not panic. A printk seems to be\nmore appropriate here.\n\nReported-by: syzbot+4386709c0c1284dca827@syzkaller.appspotmail.com\nSuggested-by: Dmitry Vyukov <dvyukov@google.com>\nAcked-by: Oliver Hartkopp <socketcan@hartkopp.net>\nSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>\nSigned-off-by: Oliver Hartkopp <socketcan@hartkopp.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/40bf2c0c1c9ec9c3a17afac43fcd18b39759defd"},{"sha":"41e4aa17bc02430db764b748e990bdc392347f0d","author":{"name":"Marc Kleine-Budde","email":"86a3a4ad69448b8f7c92083394f83d765887082e@pengutronix.de"},"message":"can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once\n\ncommit d4689846881d160a4d12a514e991a740bcb5d65a upstream.\n\nIf an invalid CANFD frame is received, from a driver or from a tun\ninterface, a Kernel warning is generated.\n\nThis patch replaces the WARN_ONCE by a simple pr_warn_once, so that a\nkernel, bootet with panic_on_warn, does not panic. A printk seems to be\nmore appropriate here.\n\nReported-by: syzbot+e3b775f40babeff6e68b@syzkaller.appspotmail.com\nSuggested-by: Dmitry Vyukov <dvyukov@google.com>\nAcked-by: Oliver Hartkopp <socketcan@hartkopp.net>\nCc: linux-stable <stable@vger.kernel.org>\nSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>\nSigned-off-by: Oliver Hartkopp <socketcan@hartkopp.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/41e4aa17bc02430db764b748e990bdc392347f0d"},{"sha":"45ee9d5e97a4c6814a166c4ddf5c7c3764084270","author":{"name":"Punit Agrawal","email":"75943ccc3e8de68c9c78c204d85a030d9c92fbe3@arm.com"},"message":"KVM: arm/arm64: Check pagesize when allocating a hugepage at Stage 2\n\ncommit c507babf10ead4d5c8cca704539b170752a8ac84 upstream.\n\nKVM only supports PMD hugepages at stage 2 but doesn't actually check\nthat the provided hugepage memory pagesize is PMD_SIZE before populating\nstage 2 entries.\n\nIn cases where the backing hugepage size is smaller than PMD_SIZE (such\nas when using contiguous hugepages), KVM can end up creating stage 2\nmappings that extend beyond the supplied memory.\n\nFix this by checking for the pagesize of userspace vma before creating\nPMD hugepage at stage 2.\n\nFixes: 66b3923a1a0f77a (\"arm64: hugetlb: add support for PTE contiguous bit\")\nSigned-off-by: Punit Agrawal <punit.agrawal@arm.com>\nCc: Marc Zyngier <marc.zyngier@arm.com>\nReviewed-by: Christoffer Dall <christoffer.dall@linaro.org>\nSigned-off-by: Christoffer Dall <christoffer.dall@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/45ee9d5e97a4c6814a166c4ddf5c7c3764084270"},{"sha":"318e17d09cbc40593ce42194ece3ecd1a464cc5e","author":{"name":"Janakarajan Natarajan","email":"12bc70e14cd69d351d9172c4df707df25f506d59@amd.com"},"message":"Prevent timer value 0 for MWAITX\n\ncommit 88d879d29f9cc0de2d930b584285638cdada6625 upstream.\n\nNewer hardware has uncovered a bug in the software implementation of\nusing MWAITX for the delay function. A value of 0 for the timer is meant\nto indicate that a timeout will not be used to exit MWAITX. On newer\nhardware this can result in MWAITX never returning, resulting in NMI\nsoft lockup messages being printed. On older hardware, some of the other\nconditions under which MWAITX can exit masked this issue. The AMD APM\ndoes not currently document this and will be updated.\n\nPlease refer to http://marc.info/?l=kvm&m=148950623231140 for\ninformation regarding NMI soft lockup messages on an AMD Ryzen 1800X.\nThis has been root-caused as a 0 passed to MWAITX causing it to wait\nindefinitely.\n\nThis change has the added benefit of avoiding the unnecessary setup of\nMONITORX/MWAITX when the delay value is zero.\n\nSigned-off-by: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>\nLink: http://lkml.kernel.org/r/1493156643-29366-1-git-send-email-Janakarajan.Natarajan@amd.com\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Davidlohr Bueso <dbueso@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/318e17d09cbc40593ce42194ece3ecd1a464cc5e"},{"sha":"f5aaa5a2836d86e3b6559200422c153a4dfb6d66","author":{"name":"Sudeep Holla","email":"59421025db0a4566b0c646d02b1a8fb3615a9cf9@arm.com"},"message":"drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled\n\ncommit fac51482577d5e05bbb0efa8d602a3c2111098bf upstream.\n\nWith CONFIG_OF enabled on x86, we get the following error on boot:\n\"\n\tFailed to find cpu0 device node\n \tUnable to detect cache hierarchy from DT for CPU 0\n\"\nand the cacheinfo fails to get populated in the corresponding sysfs\nentries. This is because cache_setup_of_node looks for of_node for\nsetting up the shared cpu_map without checking that it's already\npopulated in the architecture specific callback.\n\nIn order to indicate that the shared cpu_map is already populated, this\npatch introduces a boolean `cpu_map_populated` in struct cpu_cacheinfo\nthat can be used by the generic code to skip cache_shared_cpu_map_setup.\n\nThis patch also sets that boolean for x86.\n\nCc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>\nSigned-off-by: Mian Yousaf Kaukab <yousaf.kaukab@suse.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/f5aaa5a2836d86e3b6559200422c153a4dfb6d66"},{"sha":"1d8c402e0c46ce630746e081c904068af455b1e5","author":{"name":"Sudeep Holla","email":"59421025db0a4566b0c646d02b1a8fb3615a9cf9@arm.com"},"message":"drivers: base: cacheinfo: fix boot error message when acpi is enabled\n\ncommit 55877ef45fbd7f975d078426866b7d1a2435dcc3 upstream.\n\nARM64 enables both CONFIG_OF and CONFIG_ACPI and the firmware can pass\nboth ACPI tables and the device tree. Based on the kernel parameter, one\nof the two will be chosen. If acpi is enabled, then device tree is not\nunflattened.\n\nCurrently ARM64 platforms report:\n\"\n\tFailed to find cpu0 device node\n\tUnable to detect cache hierarchy from DT for CPU 0\n\"\nwhich is incorrect when booting with ACPI. Also latest ACPI v6.1 has no\nsupport for cache properties/hierarchy.\n\nThis patch adds check for unflattened device tree and also returns as\n\"not supported\" if ACPI is runtime enabled.\n\nIt also removes the reference to DT from the error message as the cache\nhierarchy can be detected from the firmware(OF/DT/ACPI)\n\nCc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>\nSigned-off-by: Mian Yousaf Kaukab <yousaf.kaukab@suse.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/1d8c402e0c46ce630746e081c904068af455b1e5"},{"sha":"c57664bd12997742da5e12556e328e1ec0b5b654","author":{"name":"Michal Hocko","email":"549a3b539eb67715c6526d830d82ed0bec455278@suse.com"},"message":"mm/mmap.c: do not blow on PROT_NONE MAP_FIXED holes in the stack\n\ncommit 561b5e0709e4a248c67d024d4d94b6e31e3edf2f upstream.\n\nCommit 1be7107fbe18 (\"mm: larger stack guard gap, between vmas\") has\nintroduced a regression in some rust and Java environments which are\ntrying to implement their own stack guard page.  They are punching a new\nMAP_FIXED mapping inside the existing stack Vma.\n\nThis will confuse expand_{downwards,upwards} into thinking that the\nstack expansion would in fact get us too close to an existing non-stack\nvma which is a correct behavior wrt safety.  It is a real regression on\nthe other hand.\n\nLet's work around the problem by considering PROT_NONE mapping as a part\nof the stack.  This is a gros hack but overflowing to such a mapping\nwould trap anyway an we only can hope that usespace knows what it is\ndoing and handle it propely.\n\nFixes: 1be7107fbe18 (\"mm: larger stack guard gap, between vmas\")\nLink: http://lkml.kernel.org/r/20170705182849.GA18027@dhcp22.suse.cz\nSigned-off-by: Michal Hocko <mhocko@suse.com>\nDebugged-by: Vlastimil Babka <vbabka@suse.cz>\nCc: Ben Hutchings <ben@decadent.org.uk>\nCc: Willy Tarreau <w@1wt.eu>\nCc: Oleg Nesterov <oleg@redhat.com>\nCc: Rik van Riel <riel@redhat.com>\nCc: Hugh Dickins <hughd@google.com>\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":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/c57664bd12997742da5e12556e328e1ec0b5b654"},{"sha":"bc0e2174b092638f1146d792a8be71ab90a7e56d","author":{"name":"Michal Hocko","email":"549a3b539eb67715c6526d830d82ed0bec455278@suse.com"},"message":"hwpoison, memcg: forcibly uncharge LRU pages\n\ncommit 18365225f0440d09708ad9daade2ec11275c3df9 upstream.\n\nLaurent Dufour has noticed that hwpoinsoned pages are kept charged.  In\nhis particular case he has hit a bad_page(\"page still charged to\ncgroup\") when onlining a hwpoison page.  While this looks like something\nthat shouldn't happen in the first place because onlining hwpages and\nreturning them to the page allocator makes only little sense it shows a\nreal problem.\n\nhwpoison pages do not get freed usually so we do not uncharge them (at\nleast not since commit 0a31bc97c80c (\"mm: memcontrol: rewrite uncharge\nAPI\")).  Each charge pins memcg (since e8ea14cc6ead (\"mm: memcontrol:\ntake a css reference for each charged page\")) as well and so the\nmem_cgroup and the associated state will never go away.  Fix this leak\nby forcibly uncharging a LRU hwpoisoned page in delete_from_lru_cache().\nWe also have to tweak uncharge_list because it cannot rely on zero ref\ncount for these pages.\n\n[akpm@linux-foundation.org: coding-style fixes]\nFixes: 0a31bc97c80c (\"mm: memcontrol: rewrite uncharge API\")\nLink: http://lkml.kernel.org/r/20170502185507.GB19165@dhcp22.suse.cz\nSigned-off-by: Michal Hocko <mhocko@suse.com>\nReported-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>\nTested-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>\nReviewed-by: Balbir Singh <bsingharora@gmail.com>\nReviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>\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":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/bc0e2174b092638f1146d792a8be71ab90a7e56d"},{"sha":"714c19ef57a5271c14ab6d1b5878f5662a0b3034","author":{"name":"Doug Berger","email":"a5e842be13d05e3351c9e4cf3d1cd95903dfe01e@gmail.com"},"message":"cma: fix calculation of aligned offset\n\ncommit e048cb32f69038aa1c8f11e5c1b331be4181659d upstream.\n\nThe align_offset parameter is used by bitmap_find_next_zero_area_off()\nto represent the offset of map's base from the previous alignment\nboundary; the function ensures that the returned index, plus the\nalign_offset, honors the specified align_mask.\n\nThe logic introduced by commit b5be83e308f7 (\"mm: cma: align to physical\naddress, not CMA region position\") has the cma driver calculate the\noffset to the *next* alignment boundary.  In most cases, the base\nalignment is greater than that specified when making allocations,\nresulting in a zero offset whether we align up or down.  In the example\ngiven with the commit, the base alignment (8MB) was half the requested\nalignment (16MB) so the math also happened to work since the offset is\n8MB in both directions.  However, when requesting allocations with an\nalignment greater than twice that of the base, the returned index would\nnot be correctly aligned.\n\nAlso, the align_order arguments of cma_bitmap_aligned_mask() and\ncma_bitmap_aligned_offset() should not be negative so the argument type\nwas made unsigned.\n\nFixes: b5be83e308f7 (\"mm: cma: align to physical address, not CMA region position\")\nLink: http://lkml.kernel.org/r/20170628170742.2895-1-opendmb@gmail.com\nSigned-off-by: Angus Clark <angus@angusclark.org>\nSigned-off-by: Doug Berger <opendmb@gmail.com>\nAcked-by: Gregory Fong <gregory.0xf0@gmail.com>\nCc: Doug Berger <opendmb@gmail.com>\nCc: Angus Clark <angus@angusclark.org>\nCc: Laura Abbott <labbott@redhat.com>\nCc: Vlastimil Babka <vbabka@suse.cz>\nCc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nCc: Lucas Stach <l.stach@pengutronix.de>\nCc: Catalin Marinas <catalin.marinas@arm.com>\nCc: Shiraz Hashim <shashim@codeaurora.org>\nCc: Jaewon Kim <jaewon31.kim@samsung.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Vlastimil Babka <vbabka@suse.cz>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/714c19ef57a5271c14ab6d1b5878f5662a0b3034"},{"sha":"685cce58f1c2e4fb5dbc891edf3e1bbca217ed3e","author":{"name":"Vlastimil Babka","email":"920c003c51ff5a11a6ee976b813fb82ea89684e4@suse.cz"},"message":"mm, page_alloc: fix potential false positive in __zone_watermark_ok\n\ncommit b050e3769c6b4013bb937e879fc43bf1847ee819 upstream.\n\nSince commit 97a16fc82a7c (\"mm, page_alloc: only enforce watermarks for\norder-0 allocations\"), __zone_watermark_ok() check for high-order\nallocations will shortcut per-migratetype free list checks for\nALLOC_HARDER allocations, and return true as long as there's free page\nof any migratetype.  The intention is that ALLOC_HARDER can allocate\nfrom MIGRATE_HIGHATOMIC free lists, while normal allocations can't.\n\nHowever, as a side effect, the watermark check will then also return\ntrue when there are pages only on the MIGRATE_ISOLATE list, or (prior to\nCMA conversion to ZONE_MOVABLE) on the MIGRATE_CMA list.  Since the\nallocation cannot actually obtain isolated pages, and might not be able\nto obtain CMA pages, this can result in a false positive.\n\nThe condition should be rare and perhaps the outcome is not a fatal one.\nStill, it's better if the watermark check is correct.  There also\nshouldn't be a performance tradeoff here.\n\nLink: http://lkml.kernel.org/r/20171102125001.23708-1-vbabka@suse.cz\nFixes: 97a16fc82a7c (\"mm, page_alloc: only enforce watermarks for order-0 allocations\")\nSigned-off-by: Vlastimil Babka <vbabka@suse.cz>\nAcked-by: Mel Gorman <mgorman@techsingularity.net>\nCc: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nCc: Rik van Riel <riel@redhat.com>\nCc: David Rientjes <rientjes@google.com>\nCc: Johannes Weiner <hannes@cmpxchg.org>\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":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/685cce58f1c2e4fb5dbc891edf3e1bbca217ed3e"},{"sha":"542cde0e3cc27bd4d6cbfa596d9278d3c97bc193","author":{"name":"Jiri Slaby","email":"5983af6a8e8283aa60de579a10bd4a0e541489a0@suse.cz"},"message":"ipc: msg, make msgrcv work with LONG_MIN\n\ncommit 999898355e08ae3b92dfd0a08db706e0c6703d30 upstream.\n\nWhen LONG_MIN is passed to msgrcv, one would expect to recieve any\nmessage.  But convert_mode does *msgtyp = -*msgtyp and -LONG_MIN is\nundefined.  In particular, with my gcc -LONG_MIN produces -LONG_MIN\nagain.\n\nSo handle this case properly by assigning LONG_MAX to *msgtyp if\nLONG_MIN was specified as msgtyp to msgrcv.\n\nThis code:\n  long msg[] = { 100, 200 };\n  int m = msgget(IPC_PRIVATE, IPC_CREAT | 0644);\n  msgsnd(m, &msg, sizeof(msg), 0);\n  msgrcv(m, &msg, sizeof(msg), LONG_MIN, 0);\n\nproduces currently nothing:\n\n  msgget(IPC_PRIVATE, IPC_CREAT|0644)     = 65538\n  msgsnd(65538, {100, \"\\310\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\"}, 16, 0) = 0\n  msgrcv(65538, ...\n\nExcept a UBSAN warning:\n\n  UBSAN: Undefined behaviour in ipc/msg.c:745:13\n  negation of -9223372036854775808 cannot be represented in type 'long int':\n\nWith the patch, I see what I expect:\n\n  msgget(IPC_PRIVATE, IPC_CREAT|0644)     = 0\n  msgsnd(0, {100, \"\\310\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\"}, 16, 0) = 0\n  msgrcv(0, {100, \"\\310\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\"}, 16, -9223372036854775808, 0) = 16\n\nLink: http://lkml.kernel.org/r/20161024082633.10148-1-jslaby@suse.cz\nSigned-off-by: Jiri Slaby <jslaby@suse.cz>\nCc: Davidlohr Bueso <dave@stgolabs.net>\nCc: Manfred Spraul <manfred@colorfullife.com>\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":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/542cde0e3cc27bd4d6cbfa596d9278d3c97bc193"},{"sha":"3a53accd9c397f836858defa475720a65b5dd662","author":{"name":"Rafael J. Wysocki","email":"eb3c82195bc87396d74859a40992e20b7267b462@intel.com"},"message":"ACPI / scan: Prefer devices without _HID/_CID for _ADR matching\n\ncommit c2a6bbaf0c5f90463a7011a295bbdb7e33c80b51 upstream.\n\nThe way acpi_find_child_device() works currently is that, if there\nare two (or more) devices with the same _ADR value in the same\nnamespace scope (which is not specifically allowed by the spec and\nthe OS behavior in that case is not defined), the first one of them\nfound to be present (with the help of _STA) will be returned.\n\nThis covers the majority of cases, but is not sufficient if some of\nthe devices in question have a _HID (or _CID) returning some valid\nACPI/PNP device IDs (which is disallowed by the spec) and the\nASL writers' expectation appears to be that the OS will match\ndevices without a valid ACPI/PNP device ID against a given bus\naddress first.\n\nTo cover this special case as well, modify find_child_checks()\nto prefer devices without ACPI/PNP device IDs over devices that\nhave them.\n\nSuggested-by: Mika Westerberg <mika.westerberg@linux.intel.com>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nTested-by: Hans de Goede <hdegoede@redhat.com>\nSigned-off-by: Jiri Slaby <jslaby@suse.cz>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/3a53accd9c397f836858defa475720a65b5dd662"},{"sha":"2915f16bdce204621695e7a0dfcd5f73b120cccb","author":{"name":"Seunghun Han","email":"a840ccba1f7163117d09130a533ba0b40a452e66@gmail.com"},"message":"ACPICA: Namespace: fix operand cache leak\n\ncommit 3b2d69114fefa474fca542e51119036dceb4aa6f upstream.\n\nACPICA commit a23325b2e583556eae88ed3f764e457786bf4df6\n\nI found some ACPI operand cache leaks in ACPI early abort cases.\n\nBoot log of ACPI operand cache leak is as follows:\n>[    0.174332] ACPI: Added _OSI(Module Device)\n>[    0.175504] ACPI: Added _OSI(Processor Device)\n>[    0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)\n>[    0.177032] ACPI: Added _OSI(Processor Aggregator Device)\n>[    0.178284] ACPI: SCI (IRQ16705) allocation failed\n>[    0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install\nSystem Control Interrupt handler (20160930/evevent-131)\n>[    0.180008] ACPI: Unable to start the ACPI Interpreter\n>[    0.181125] ACPI Error: Could not remove SCI handler\n(20160930/evmisc-281)\n>[    0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has\nobjects\n>[    0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2\n>[    0.186820] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS\nvirtual_box 12/01/2006\n>[    0.188000] Call Trace:\n>[    0.188000]  ? dump_stack+0x5c/0x7d\n>[    0.188000]  ? kmem_cache_destroy+0x224/0x230\n>[    0.188000]  ? acpi_sleep_proc_init+0x22/0x22\n>[    0.188000]  ? acpi_os_delete_cache+0xa/0xd\n>[    0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b\n>[    0.188000]  ? acpi_terminate+0x5/0xf\n>[    0.188000]  ? acpi_init+0x288/0x32e\n>[    0.188000]  ? __class_create+0x4c/0x80\n>[    0.188000]  ? video_setup+0x7a/0x7a\n>[    0.188000]  ? do_one_initcall+0x4e/0x1b0\n>[    0.188000]  ? kernel_init_freeable+0x194/0x21a\n>[    0.188000]  ? rest_init+0x80/0x80\n>[    0.188000]  ? kernel_init+0xa/0x100\n>[    0.188000]  ? ret_from_fork+0x25/0x30\n\nWhen early abort is occurred due to invalid ACPI information, Linux kernel\nterminates ACPI by calling acpi_terminate() function. The function calls\nacpi_ns_terminate() function to delete namespace data and ACPI operand cache\n(acpi_gbl_module_code_list).\n\nBut the deletion code in acpi_ns_terminate() function is wrapped in\nACPI_EXEC_APP definition, therefore the code is only executed when the\ndefinition exists. If the define doesn't exist, ACPI operand cache\n(acpi_gbl_module_code_list) is leaked, and stack dump is shown in kernel log.\n\nThis causes a security threat because the old kernel (<= 4.9) shows memory\nlocations of kernel functions in stack dump, therefore kernel ASLR can be\nneutralized.\n\nTo fix ACPI operand leak for enhancing security, I made a patch which\nremoves the ACPI_EXEC_APP define in acpi_ns_terminate() function for\nexecuting the deletion code unconditionally.\n\nLink: https://github.com/acpica/acpica/commit/a23325b2\nSigned-off-by: Seunghun Han <kkamagui@gmail.com>\nSigned-off-by: Lv Zheng <lv.zheng@intel.com>\nSigned-off-by: Bob Moore <robert.moore@intel.com>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nAcked-by: Lee, Chun-Yi <jlee@suse.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/2915f16bdce204621695e7a0dfcd5f73b120cccb"},{"sha":"2c3184ea80322347287bc7e57f782d77f478e73c","author":{"name":"Kevin Cernekee","email":"3219fdf39e3ba5f552e432c31cc96159991751aa@chromium.org"},"message":"netfilter: nfnetlink_cthelper: Add missing permission checks\n\ncommit 4b380c42f7d00a395feede754f0bc2292eebe6e5 upstream.\n\nThe capability check in nfnetlink_rcv() verifies that the caller\nhas CAP_NET_ADMIN in the namespace that \"owns\" the netlink socket.\nHowever, nfnl_cthelper_list is shared by all net namespaces on the\nsystem.  An unprivileged user can create user and net namespaces\nin which he holds CAP_NET_ADMIN to bypass the netlink_net_capable()\ncheck:\n\n    $ nfct helper list\n    nfct v1.4.4: netlink error: Operation not permitted\n    $ vpnns -- nfct helper list\n    {\n            .name = ftp,\n            .queuenum = 0,\n            .l3protonum = 2,\n            .l4protonum = 6,\n            .priv_data_len = 24,\n            .status = enabled,\n    };\n\nAdd capable() checks in nfnetlink_cthelper, as this is cleaner than\ntrying to generalize the solution.\n\nSigned-off-by: Kevin Cernekee <cernekee@chromium.org>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>\nAcked-by: Michal Kubecek <mkubecek@suse.cz>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/2c3184ea80322347287bc7e57f782d77f478e73c"}]}
{"actor":{"display_login":"mifl"}}