{"push_id":2005676249,"size":59,"distinct_size":59,"ref":"refs/heads/oreo","head":"0eb035f2b20125392645bc42e53c922135246995","before":"30989ad1eff6a18ef9a0e8d2682d19ad9afb4043","commits":[{"sha":"1ac13eeade539d9dcdb305b8f64e50c694569780","author":{"name":"Arnd Bergmann","email":"72a0f6d3b182607e6d5c44b93e1abb7b23ee18f3@arndb.de"},"message":"scsi: isci: avoid array subscript warning\n\ncommit 5cfa2a3c7342bd0b50716c8bb32ee491af43c785 upstream.\n\nI'm getting a new warning with gcc-7:\n\nisci/remote_node_context.c: In function 'sci_remote_node_context_destruct':\nisci/remote_node_context.c:69:16: error: array subscript is above array bounds [-Werror=array-bounds]\n\nThis is odd, since we clearly cover all values for enum\nscis_sds_remote_node_context_states here. Anyway, checking for an array\noverflow can't harm and it makes the warning go away.\n\nSigned-off-by: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Martin K. Petersen <martin.petersen@oracle.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/1ac13eeade539d9dcdb305b8f64e50c694569780"},{"sha":"8c2e4d11987ab2845a33c915a2797dbef2b2bf38","author":{"name":"Takashi Iwai","email":"dd0a9a4ae370c51e6d7099900a4bf6656524e055@suse.de"},"message":"ALSA: au88x0: Fix zero clear of stream->resources\n\ncommit 639db596165746ca87bbcb56559b094fd9042890 upstream.\n\nThere are a few calls of memset() to stream->resources, but they all\nare called in a wrong size, sizeof(unsigned char) * VORTEX_RESOURCE_LAST,\nwhile this field is a u32 array.  This may leave the memories not\nzero-cleared.\n\nFix it by replacing them with a simpler sizeof(stream->resources)\ninstead.\n\nReported-by: David Binderman <dcb314@hotmail.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/GZR-Kernels/Addison_Optimus_Drunk/commits/8c2e4d11987ab2845a33c915a2797dbef2b2bf38"},{"sha":"424232b831efd911da4f22762aff3e6232fc7cbf","author":{"name":"Lorenzo Stoakes","email":"37b502a1f2431499c987e34bee55335a73e9e5c9@gmail.com"},"message":"gcov: add support for GCC 5.1\n\ncommit 3e44c471a2dab210f7e9b1e5f7d4d54d52df59eb upstream.\n\nFix kernel gcov support for GCC 5.1.  Similar to commit a992bf836f9\n(\"gcov: add support for GCC 4.9\"), this patch takes into account the\nexistence of a new gcov counter (see gcc's gcc/gcov-counter.def.)\n\nFirstly, it increments GCOV_COUNTERS (to 10), which makes the data\nstructure struct gcov_info compatible with GCC 5.1.\n\nSecondly, a corresponding counter function __gcov_merge_icall_topn (Top N\nvalue tracking for indirect calls) is included in base.c with the other\ngcov counters unused for kernel profiling.\n\nSigned-off-by: Lorenzo Stoakes <lstoakes@gmail.com>\nCc: Andrey Ryabinin <a.ryabinin@samsung.com>\nCc: Yuan Pengfei <coolypf@qq.com>\nTested-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>\nReviewed-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.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":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/424232b831efd911da4f22762aff3e6232fc7cbf"},{"sha":"fc2cc0171f50791a10ef9ba49449c56ed4de91e4","author":{"name":"Florian Meier","email":"adb50d1134f441dfd76555c617fa91206863314d@informatik.uni-erlangen.de"},"message":"gcov: add support for gcc version >= 6\n\ncommit d02038f972538b93011d78c068f44514fbde0a8c upstream.\n\nLink: http://lkml.kernel.org/r/20160701130914.GA23225@styxhp\nSigned-off-by: Florian Meier <Florian.Meier@informatik.uni-erlangen.de>\nReviewed-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>\nTested-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.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":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/fc2cc0171f50791a10ef9ba49449c56ed4de91e4"},{"sha":"e5acb4dbfe71b16a64b6f7f082a4622f81fcd095","author":{"name":"Martin Liska","email":"3a41975fb4f33b0e95d190a286fe91023e7afa0e@suse.cz"},"message":"gcov: support GCC 7.1\n\ncommit 05384213436ab690c46d9dfec706b80ef8d671ab upstream.\n\nStarting from GCC 7.1, __gcov_exit is a new symbol expected to be\nimplemented in a profiling runtime.\n\n[akpm@linux-foundation.org: coding-style fixes]\n[mliska@suse.cz: v2]\n  Link: http://lkml.kernel.org/r/e63a3c59-0149-c97e-4084-20ca8f146b26@suse.cz\nLink: http://lkml.kernel.org/r/8c4084fa-3885-29fe-5fc4-0d4ca199c785@suse.cz\nSigned-off-by: Martin Liska <mliska@suse.cz>\nAcked-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.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":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/e5acb4dbfe71b16a64b6f7f082a4622f81fcd095"},{"sha":"03513b71890d88ce7086c05f959414c242599cf9","author":{"name":"Jiri Slaby","email":"5983af6a8e8283aa60de579a10bd4a0e541489a0@suse.cz"},"message":"p54: memset(0) whole array\n\ncommit 6f17581788206444cbbcdbc107498f85e9765e3d upstream.\n\ngcc 7 complains:\ndrivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan':\ndrivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]\n\nFix that by passing the correct size to memset.\n\nSigned-off-by: Jiri Slaby <jslaby@suse.cz>\nCc: Christian Lamparter <chunkeey@googlemail.com>\nCc: Kalle Valo <kvalo@codeaurora.org>\nAcked-by: Christian Lamparter <chunkeey@googlemail.com>\nSigned-off-by: Kalle Valo <kvalo@codeaurora.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/03513b71890d88ce7086c05f959414c242599cf9"},{"sha":"de5736ae902743114bc6b3b34b774d2498ea797f","author":{"name":"Mark Rutland","email":"7bbc68f29a82fb2eb4daac9d4df0c3f473a4ef26@arm.com"},"message":"arm64: mm: abort uaccess retries upon fatal signal\n\ncommit 289d07a2dc6c6b6f3e4b8a62669320d99dbe6c3d upstream.\n\nWhen there's a fatal signal pending, arm64's do_page_fault()\nimplementation returns 0. The intent is that we'll return to the\nfaulting userspace instruction, delivering the signal on the way.\n\nHowever, if we take a fatal signal during fixing up a uaccess, this\nresults in a return to the faulting kernel instruction, which will be\ninstantly retried, resulting in the same fault being taken forever. As\nthe task never reaches userspace, the signal is not delivered, and the\ntask is left unkillable. While the task is stuck in this state, it can\ninhibit the forward progress of the system.\n\nTo avoid this, we must ensure that when a fatal signal is pending, we\napply any necessary fixup for a faulting kernel instruction. Thus we\nwill return to an error path, and it is up to that code to make forward\nprogress towards delivering the fatal signal.\n\nCc: Catalin Marinas <catalin.marinas@arm.com>\nCc: Laura Abbott <labbott@redhat.com>\nReviewed-by: Steve Capper <steve.capper@arm.com>\nTested-by: Steve Capper <steve.capper@arm.com>\nReviewed-by: James Morse <james.morse@arm.com>\nTested-by: James Morse <james.morse@arm.com>\nSigned-off-by: Mark Rutland <mark.rutland@arm.com>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/de5736ae902743114bc6b3b34b774d2498ea797f"},{"sha":"e7f36c00c87bf9463522cb762428671db0d0d773","author":{"name":"Michal Nazarewicz","email":"3b06a80fbb86cf4b3738455bf6d6701ef9e8c149@mina86.com"},"message":"lib: bitmap: add alignment offset for bitmap_find_next_zero_area()\n\ncommit 5e19b013f55a884c59a14391b22138899d1cc4cc upstream.\n\nAdd a bitmap_find_next_zero_area_off() function which works like\nbitmap_find_next_zero_area() function except it allows an offset to be\nspecified when alignment is checked.  This lets caller request a bit such\nthat its number plus the offset is aligned according to the mask.\n\n[gregory.0xf0@gmail.com: Retrieved from https://patchwork.linuxtv.org/patch/6254/ and updated documentation]\nSigned-off-by: Michal Nazarewicz <mina86@mina86.com>\nSigned-off-by: Kyungmin Park <kyungmin.park@samsung.com>\nSigned-off-by: Marek Szyprowski <m.szyprowski@samsung.com>\nSigned-off-by: Gregory Fong <gregory.0xf0@gmail.com>\nCc: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nCc: Kukjin Kim <kgene.kim@samsung.com>\nCc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>\nCc: Laura Abbott <lauraa@codeaurora.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":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/e7f36c00c87bf9463522cb762428671db0d0d773"},{"sha":"4eb13228ed7e7ca2458fd63bc417fbd7e575da8b","author":{"name":"Pintu Kumar","email":"ab1c0b9a0fd001875a95349afc7189843273e985@samsung.com"},"message":"mm: cma: split cma-reserved in dmesg log\n\ncommit e48322abb061d75096fe52d71886b237e7ae7bfb upstream.\n\nWhen the system boots up, in the dmesg logs we can see the memory\nstatistics along with total reserved as below.  Memory: 458840k/458840k\navailable, 65448k reserved, 0K highmem\n\nWhen CMA is enabled, still the total reserved memory remains the same.\nHowever, the CMA memory is not considered as reserved.  But, when we see\n/proc/meminfo, the CMA memory is part of free memory.  This creates\nconfusion.  This patch corrects the problem by properly subtracting the\nCMA reserved memory from the total reserved memory in dmesg logs.\n\nBelow is the dmesg snapshot from an arm based device with 512MB RAM and\n12MB single CMA region.\n\nBefore this change:\n  Memory: 458840k/458840k available, 65448k reserved, 0K highmem\n\nAfter this change:\n  Memory: 458840k/458840k available, 53160k reserved, 12288k cma-reserved, 0K highmem\n\nSigned-off-by: Pintu Kumar <pintu.k@samsung.com>\nSigned-off-by: Vishnu Pratap Singh <vishnu.ps@samsung.com>\nAcked-by: Michal Nazarewicz <mina86@mina86.com>\nCc: Rafael Aquini <aquini@redhat.com>\nCc: Jerome Marchand <jmarchan@redhat.com>\nCc: Marek Szyprowski <m.szyprowski@samsung.com>\nCc: Joonsoo Kim <iamjoonsoo.kim@lge.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":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/4eb13228ed7e7ca2458fd63bc417fbd7e575da8b"},{"sha":"d0270d43bfdddf8c39abf8d33d6697a7f9729172","author":{"name":"George G. Davis","email":"77b7bec94275857671ee72920c9b303a5f09ed51@gmail.com"},"message":"mm: cma: fix totalcma_pages to include DT defined CMA regions\n\ncommit 94737a85f332aee75255960eaa16e89ddfa4c75a upstream.\n\nThe totalcma_pages variable is not updated to account for CMA regions\ndefined via device tree reserved-memory sub-nodes.  Fix this omission by\nmoving the calculation of totalcma_pages into cma_init_reserved_mem()\ninstead of cma_declare_contiguous() such that it will include reserved\nmemory used by all CMA regions.\n\nSigned-off-by: George G. Davis <george_davis@mentor.com>\nCc: Marek Szyprowski <m.szyprowski@samsung.com>\nAcked-by: Michal Nazarewicz <mina86@mina86.com>\nCc: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nCc: \"Aneesh Kumar K.V\" <aneesh.kumar@linux.vnet.ibm.com>\nCc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.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":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/d0270d43bfdddf8c39abf8d33d6697a7f9729172"},{"sha":"15f9ca7c677090afb99958e7e58e12272760d412","author":{"name":"Gregory Fong","email":"5da2fbcf19819e3a71b066df845483d72efa3ad9@gmail.com"},"message":"mm: cma: align to physical address, not CMA region position\n\nThe alignment in cma_alloc() was done w.r.t. the bitmap.  This is a\nproblem when, for example:\n\n- a device requires 16M (order 12) alignment\n- the CMA region is not 16 M aligned\n\nIn such a case, can result with the CMA region starting at, say,\n0x2f800000 but any allocation you make from there will be aligned from\nthere.  Requesting an allocation of 32 M with 16 M alignment will result\nin an allocation from 0x2f800000 to 0x31800000, which doesn't work very\nwell if your strange device requires 16M alignment.\n\nChange to use bitmap_find_next_zero_area_off() to account for the\ndifference in alignment at reserve-time and alloc-time.\n\nSigned-off-by: Gregory Fong <gregory.0xf0@gmail.com>\nAcked-by: Michal Nazarewicz <mina86@mina86.com>\nCc: Marek Szyprowski <m.szyprowski@samsung.com>\nCc: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nCc: Kukjin Kim <kgene.kim@samsung.com>\nCc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>\nCc: Laura Abbott <lauraa@codeaurora.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/15f9ca7c677090afb99958e7e58e12272760d412"},{"sha":"f3046eb33c04e2843acfa527dafcf93310829ee9","author":{"name":"Thierry Reding","email":"4ab3bbead55647fdaaf6677e676b52259d853f2f@nvidia.com"},"message":"mm/cma: make kmemleak ignore CMA regions\n\nkmemleak will add allocations as objects to a pool.  The memory allocated\nfor each object in this pool is periodically searched for pointers to\nother allocated objects.  This only works for memory that is mapped into\nthe kernel's virtual address space, which happens not to be the case for\nmost CMA regions.\n\nFurthermore, CMA regions are typically used to store data transferred to\nor from a device and therefore don't contain pointers to other objects.\n\nWithout this, the kernel crashes on the first execution of the\nscan_gray_list() because it tries to access highmem.  Perhaps a more\nappropriate fix would be to reject any object that can't map to a kernel\nvirtual address?\n\n[akpm@linux-foundation.org: add comment]\n[akpm@linux-foundation.org: fix comment, per Catalin]\n[sfr@canb.auug.org.au: include linux/io.h for phys_to_virt()]\nSigned-off-by: Thierry Reding <treding@nvidia.com>\nCc: Michal Nazarewicz <mina86@mina86.com>\nCc: Marek Szyprowski <m.szyprowski@samsung.com>\nCc: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nCc: \"Aneesh Kumar K.V\" <aneesh.kumar@linux.vnet.ibm.com>\nCc: Catalin Marinas <catalin.marinas@arm.com>\nSigned-off-by: Stephen Rothwell <sfr@canb.auug.org.au>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/f3046eb33c04e2843acfa527dafcf93310829ee9"},{"sha":"3dded89d0c76fe99e277d49a68c132baf76ab7aa","author":{"name":"Danesh Petigara","email":"350aaa7514ca408f7d208afbe85c4a33ef5088f0@broadcom.com"},"message":"mm: cma: fix CMA aligned offset calculation\n\nThe CMA aligned offset calculation is incorrect for non-zero order_per_bit\nvalues.\n\nFor example, if cma->order_per_bit=1, cma->base_pfn= 0x2f800000 and\nalign_order=12, the function returns a value of 0x17c00 instead of 0x400.\n\nThis patch fixes the CMA aligned offset calculation.\n\nThe previous calculation was wrong and would return too-large values for\nthe offset, so that when cma_alloc looks for free pages in the bitmap with\nthe requested alignment > order_per_bit, it starts too far into the bitmap\nand so CMA allocations will fail despite there actually being plenty of\nfree pages remaining.  It will also probably have the wrong alignment.\nWith this change, we will get the correct offset into the bitmap.\n\nOne affected user is powerpc KVM, which has kvm_cma->order_per_bit set to\nKVM_CMA_CHUNK_ORDER - PAGE_SHIFT, or 18 - 12 = 6.\n\n[gregory.0xf0@gmail.com: changelog additions]\nSigned-off-by: Danesh Petigara <dpetigara@broadcom.com>\nReviewed-by: Gregory Fong <gregory.0xf0@gmail.com>\nAcked-by: Michal Nazarewicz <mina86@mina86.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/3dded89d0c76fe99e277d49a68c132baf76ab7aa"},{"sha":"3217069a65baea4f401b2e0c23eddadbc87e1b58","author":{"name":"Sasha Levin","email":"3eff170737f7f759a98f81ff6bf07d3c251c0277@oracle.com"},"message":"mm: cma: constify and use correct signness in mm/cma.c\n\nConstify function parameters and use correct signness where needed.\n\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>\nCc: Michal Nazarewicz <mina86@mina86.com>\nCc: Marek Szyprowski <m.szyprowski@samsung.com>\nCc: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nCc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>\nAcked-by: Gregory Fong <gregory.0xf0@gmail.com>\nCc: Pintu Kumar <pintu.k@samsung.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/3217069a65baea4f401b2e0c23eddadbc87e1b58"},{"sha":"fb5ce921e338ce1150a46b7f0a54bf472a8355e8","author":{"name":"Rohit Vaswani","email":"f48a55fb1c3eb99475ecf8265ee11a9573339206@codeaurora.org"},"message":"mm: cma: fix incorrect type conversion for size during dma allocation\n\nThis was found during userspace fuzzing test when a large size dma cma\nallocation is made by driver(like ion) through userspace.\n\n  show_stack+0x10/0x1c\n  dump_stack+0x74/0xc8\n  kasan_report_error+0x2b0/0x408\n  kasan_report+0x34/0x40\n  __asan_storeN+0x15c/0x168\n  memset+0x20/0x44\n  __dma_alloc_coherent+0x114/0x18c\n\nSigned-off-by: Rohit Vaswani <rvaswani@codeaurora.org>\nAcked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nCc: Marek Szyprowski <m.szyprowski@samsung.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/fb5ce921e338ce1150a46b7f0a54bf472a8355e8"},{"sha":"9e3f089cd3108b25ef5cbe2be220d70515c71682","author":{"name":"Arnd Bergmann","email":"72a0f6d3b182607e6d5c44b93e1abb7b23ee18f3@arndb.de"},"message":"x86/io: Add \"memory\" clobber to insb/insw/insl/outsb/outsw/outsl\n\ncommit 7206f9bf108eb9513d170c73f151367a1bdf3dbf upstream.\n\nThe x86 version of insb/insw/insl uses an inline assembly that does\nnot have the target buffer listed as an output. This can confuse\nthe compiler, leading it to think that a subsequent access of the\nbuffer is uninitialized:\n\n  drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_mgmt_scan_confirm’:\n  drivers/net/wireless/wl3501_cs.c:665:9: error: ‘sig.status’ is used uninitialized in this function [-Werror=uninitialized]\n  drivers/net/wireless/wl3501_cs.c:668:12: error: ‘sig.cap_info’ may be used uninitialized in this function [-Werror=maybe-uninitialized]\n  drivers/net/sb1000.c: In function 'sb1000_rx':\n  drivers/net/sb1000.c:775:9: error: 'st[0]' is used uninitialized in this function [-Werror=uninitialized]\n  drivers/net/sb1000.c:776:10: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]\n  drivers/net/sb1000.c:784:11: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]\n\nI tried to mark the exact input buffer as an output here, but couldn't\nfigure it out. As suggested by Linus, marking all memory as clobbered\nhowever is good enough too. For the outs operations, I also add the\nmemory clobber, to force the input to be written to local variables.\nThis is probably already guaranteed by the \"asm volatile\", but it can't\nhurt to do this for symmetry.\n\nSuggested-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Arnd Bergmann <arnd@arndb.de>\nAcked-by: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Borislav Petkov <bp@suse.de>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Tom Lendacky <thomas.lendacky@amd.com>\nLink: http://lkml.kernel.org/r/20170719125310.2487451-5-arnd@arndb.de\nLink: https://lkml.org/lkml/2017/7/12/605\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/GZR-Kernels/Addison_Optimus_Drunk/commits/9e3f089cd3108b25ef5cbe2be220d70515c71682"},{"sha":"1319ce6cf439fff53fd46e23edb7c829887344a3","author":{"name":"Ard Biesheuvel","email":"80b89d4a5c0c8f00cebbb9c7d8a672c776f22af1@linaro.org"},"message":"arm64: flush FP/SIMD state correctly after execve()\n\ncommit 674c242c9323d3c293fc4f9a3a3a619fe3063290 upstream.\n\nWhen a task calls execve(), its FP/SIMD state is flushed so that\nnone of the original program state is observeable by the incoming\nprogram.\n\nHowever, since this flushing consists of setting the in-memory copy\nof the FP/SIMD state to all zeroes, the CPU field is set to CPU 0 as\nwell, which indicates to the lazy FP/SIMD preserve/restore code that\nthe FP/SIMD state does not need to be reread from memory if the task\nis scheduled again on CPU 0 without any other tasks having entered\nuserland (or used the FP/SIMD in kernel mode) on the same CPU in the\nmean time. If this happens, the FP/SIMD state of the old program will\nstill be present in the registers when the new program starts.\n\nSo set the CPU field to the invalid value of NR_CPUS when performing\nthe flush, by calling fpsimd_flush_task_state().\n\nReported-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>\nReported-by: Janet Liu <janet.liu@spreadtrum.com>\nSigned-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/1319ce6cf439fff53fd46e23edb7c829887344a3"},{"sha":"96cbf00b3f36be83976a1945b6a7f768bffe2f1e","author":{"name":"Dave Martin","email":"efb8cc9d02b9c95845d8a14436d3a7276e72ae4e@arm.com"},"message":"arm64: fpsimd: Prevent registers leaking across exec\n\ncommit 096622104e14d8a1db4860bd557717067a0515d2 upstream.\n\nThere are some tricky dependencies between the different stages of\nflushing the FPSIMD register state during exec, and these can race\nwith context switch in ways that can cause the old task's regs to\nleak across.  In particular, a context switch during the memset() can\ncause some of the task's old FPSIMD registers to reappear.\n\nDisabling preemption for this small window would be no big deal for\nperformance: preemption is already disabled for similar scenarios\nlike updating the FPSIMD registers in sigreturn.\n\nSo, instead of rearranging things in ways that might swap existing\nsubtle bugs for new ones, this patch just disables preemption\naround the FPSIMD state flushing so that races of this type can't\noccur here.  This brings fpsimd_flush_thread() into line with other\ncode paths.\n\nFixes: 674c242c9323 (\"arm64: flush FP/SIMD state correctly after execve()\")\nReviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nSigned-off-by: Dave Martin <Dave.Martin@arm.com>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/96cbf00b3f36be83976a1945b6a7f768bffe2f1e"},{"sha":"e4fb7d59497661ce20ba76a2669b3fbc95051a48","author":{"name":"Jan Beulich","email":"1fd971496e1aa6d286ec629ae628ee3e35c09db5@suse.com"},"message":"x86-64: Handle PC-relative relocations on per-CPU data\n\ncommit 6d24c5f72dfb26e5fa7f02fa9266dfdbae41adba upstream.\n\nThis is in preparation of using RIP-relative addressing in many of the\nper-CPU accesses.\n\nSigned-off-by: Jan Beulich <jbeulich@suse.com>\nLink: http://lkml.kernel.org/r/5458A15A0200007800044A9A@mail.emea.novell.com\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/e4fb7d59497661ce20ba76a2669b3fbc95051a48"},{"sha":"55b96f42b44346e8063b383d091a8722c79a0b48","author":{"name":"Markus Trippelsdorf","email":"1b28d2c9bd8522dadb87005ecdbf38866624f93e@trippelsdorf.de"},"message":"x86/tools: Fix gcc-7 warning in relocs.c\n\ncommit 7ebb916782949621ff6819acf373a06902df7679 upstream.\n\ngcc-7 warns:\n\nIn file included from arch/x86/tools/relocs_64.c:17:0:\narch/x86/tools/relocs.c: In function ‘process_64’:\narch/x86/tools/relocs.c:953:2: warning: argument 1 null where non-null expected [-Wnonnull]\n  qsort(r->offset, r->count, sizeof(r->offset[0]), cmp_relocs);\n  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nIn file included from arch/x86/tools/relocs.h:6:0,\n                 from arch/x86/tools/relocs_64.c:1:\n/usr/include/stdlib.h:741:13: note: in a call to function ‘qsort’ declared here\n extern void qsort\n\nThis happens because relocs16 is not used for ELF_BITS == 64,\nso there is no point in trying to sort it.\n\nMake the sort_relocs(&relocs16) call 32bit only.\n\nSigned-off-by: Markus Trippelsdorf <markus@trippelsdorf.de>\nLink: http://lkml.kernel.org/r/20161215124513.GA289@x4\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/GZR-Kernels/Addison_Optimus_Drunk/commits/55b96f42b44346e8063b383d091a8722c79a0b48"}]}
{"actor":{"display_login":"Alx31"}}