{"push_id":2650426864,"size":10,"distinct_size":10,"ref":"refs/heads/rebase","head":"1b3374c47f0893b2bbeb1c75143ee8a7828b37f3","before":"52eabe46eaa0894ba0d42c20f3d9891fa5144194","commits":[{"sha":"358dfc06d1383173132bb0ebd09e3eb8ae7c76e8","author":{"name":"ahmedradaideh","email":"71de5f176f030447b368d1126d2349e503841193@gmail.com"},"message":"TEST\n\nSigned-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>","distinct":true,"url":"https://api.github.com/repos/ahmedradaideh/OnePlus3T/commits/358dfc06d1383173132bb0ebd09e3eb8ae7c76e8"},{"sha":"f20fe0ed50ddff35eff4c7c360c4d7f1817ea154","author":{"name":"Arnd Bergmann","email":"f2c659f01951776204a6c5b902787d9019fbeebd@arndb.de"},"message":"crypto: aes-generic - build with -Os on gcc-7+\n\nWhile testing other changes, I discovered that gcc-7.2.1 produces badly\noptimized code for aes_encrypt/aes_decrypt. This is especially true when\nCONFIG_UBSAN_SANITIZE_ALL is enabled, where it leads to extremely\nlarge stack usage that in turn might cause kernel stack overflows:\n\ncrypto/aes_generic.c: In function 'aes_encrypt':\ncrypto/aes_generic.c:1371:1: warning: the frame size of 4880 bytes is larger than 2048 bytes [-Wframe-larger-than=]\ncrypto/aes_generic.c: In function 'aes_decrypt':\ncrypto/aes_generic.c:1441:1: warning: the frame size of 4864 bytes is larger than 2048 bytes [-Wframe-larger-than=]\n\nI verified that this problem exists on all architectures that are\nsupported by gcc-7.2, though arm64 in particular is less affected than\nthe others. I also found that gcc-7.1 and gcc-8 do not show the extreme\nstack usage but still produce worse code than earlier versions for this\nfile, apparently because of optimization passes that generally provide\na substantial improvement in object code quality but understandably fail\nto find any shortcuts in the AES algorithm.\n\nPossible workarounds include\n\na) disabling -ftree-pre and -ftree-sra optimizations, this was an earlier\n   patch I tried, which reliably fixed the stack usage, but caused a\n   serious performance regression in some versions, as later testing\n   found.\n\nb) disabling UBSAN on this file or all ciphers, as suggested by Ard\n   Biesheuvel. This would lead to massively better crypto performance in\n   UBSAN-enabled kernels and avoid the stack usage, but there is a concern\n   over whether we should exclude arbitrary files from UBSAN at all.\n\nc) Forcing the optimization level in a different way. Similar to a),\n   but rather than deselecting specific optimization stages,\n   this now uses \"gcc -Os\" for this file, regardless of the\n   CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE/SIZE option. This is a reliable\n   workaround for the stack consumption on all architecture, and I've\n   retested the performance results now on x86, cycles/byte (lower is\n   better) for cbc(aes-generic) with 256 bit keys:\n\n\t\t\t-O2     -Os\n\tgcc-6.3.1\t14.9\t15.1\n\tgcc-7.0.1\t14.7\t15.3\n\tgcc-7.1.1\t15.3\t14.7\n\tgcc-7.2.1\t16.8\t15.9\n\tgcc-8.0.0\t15.5\t15.6\n\nThis implements the option c) by enabling forcing -Os on all compiler\nversions starting with gcc-7.1. As a workaround for PR83356, it would\nonly be needed for gcc-7.2+ with UBSAN enabled, but since it also shows\nbetter performance on gcc-7.1 without UBSAN, it seems appropriate to\nuse the faster version here as well.\n\nSide note: during testing, I also played with the AES code in libressl,\nwhich had a similar performance regression from gcc-6 to gcc-7.2,\nbut was three times slower overall. It might be interesting to\ninvestigate that further and possibly port the Linux implementation\ninto that.\n\nLink: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356\nLink: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651\nCc: Richard Biener <rguenther@suse.de>\nCc: Jakub Jelinek <jakub@gcc.gnu.org>\nCc: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nSigned-off-by: Arnd Bergmann <arnd@arndb.de>\nAcked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>","distinct":true,"url":"https://api.github.com/repos/ahmedradaideh/OnePlus3T/commits/f20fe0ed50ddff35eff4c7c360c4d7f1817ea154"},{"sha":"93e3847a52fb00013743aa7629b5d3e34e54f942","author":{"name":"Xiongfeng Wang","email":"2953875ffd1f4b3268e6a0899452fe5227b7730f@linaro.org"},"message":"Kbuild: suppress packed-not-aligned warning for default setting only\n\ngcc-8 reports many -Wpacked-not-aligned warnings. The below are some\nexamples.\n\n./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct\nceph_entity_addr' is less than 8 [-Wpacked-not-aligned]\n } __attribute__ ((packed));\n\n./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct\nceph_entity_addr' is less than 8 [-Wpacked-not-aligned]\n } __attribute__ ((packed));\n\n./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct\nceph_entity_addr' is less than 8 [-Wpacked-not-aligned]\n } __attribute__ ((packed));\n\nThis patch suppresses this kind of warnings for default setting.\n\nSigned-off-by: Xiongfeng Wang <xiongfeng.wang@linaro.org>\nSigned-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>\nSigned-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>","distinct":true,"url":"https://api.github.com/repos/ahmedradaideh/OnePlus3T/commits/93e3847a52fb00013743aa7629b5d3e34e54f942"},{"sha":"5df189af91528118621273364266218fd3679f1b","author":{"name":"Arnd Bergmann","email":"f2c659f01951776204a6c5b902787d9019fbeebd@arndb.de"},"message":"crypto: aes-generic - fix aes-generic regression on powerpc\n\nMy last bugfix added -Os on the command line, which unfortunately caused\na build regression on powerpc in some configurations.\n\nI've done some more analysis of the original problem and found slightly\ndifferent workaround that avoids this regression and also results in\nbetter performance on gcc-7.0: -fcode-hoisting is an optimization step\nthat got added in gcc-7 and that for all gcc-7 versions causes worse\nperformance.\n\nThis disables -fcode-hoisting on all compilers that understand the option.\nFor gcc-7.1 and 7.2 I found the same performance as my previous patch\n(using -Os), in gcc-7.0 it was even better. On gcc-8 I could see no\nchange in performance from this patch. In theory, code hoisting should\nnot be able make things better for the AES cipher, so leaving it\ndisabled for gcc-8 only serves to simplify the Makefile change.\n\nReported-by: kbuild test robot <fengguang.wu@intel.com>\nLink: https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg30418.html\nLink: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356\nLink: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651\nFixes: 148b974deea9 (\"crypto: aes-generic - build with -Os on gcc-7+\")\nSigned-off-by: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>","distinct":true,"url":"https://api.github.com/repos/ahmedradaideh/OnePlus3T/commits/5df189af91528118621273364266218fd3679f1b"},{"sha":"89cc61e3ac730db6adba0c903b2357f732690260","author":{"name":"Josh Poimboeuf","email":"4e2e91f15355af385c021c68a9357f2fd253fb9d@redhat.com"},"message":"compiler-gcc: require gcc 4.8 for powerpc __builtin_bswap16()\n\ngcc support for __builtin_bswap16() was supposedly added for powerpc in\ngcc 4.6, and was then later added for other architectures in gcc 4.8.\n\nHowever, Stephen Rothwell reported that attempting to use it on powerpc\nin gcc 4.6 fails with:\n\n  lib/vsprintf.c:160:2: error: initializer element is not constant\n  lib/vsprintf.c:160:2: error: (near initialization for 'decpair[0]')\n  lib/vsprintf.c:160:2: error: initializer element is not constant\n  lib/vsprintf.c:160:2: error: (near initialization for 'decpair[1]')\n  ...\n\nI'm not entirely sure what those errors mean, but I don't see them on\ngcc 4.8.  So let's consider gcc 4.8 to be the official starting point\nfor __builtin_bswap16().\n\nArnd Bergmann adds:\n \"I found the commit in gcc-4.8 that replaced the powerpc-specific\n  implementation of __builtin_bswap16 with an architecture-independent\n  one.  Apparently the powerpc version (gcc-4.6 and 4.7) just mapped to\n  the lhbrx/sthbrx instructions, so it ended up not being a constant,\n  though the intent of the patch was mainly to add support for the\n  builtin to x86:\n\n    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52624\n\n  has the patch that went into gcc-4.8 and more information.\"\n\nFixes: 7322dd755e7d (\"byteswap: try to avoid __builtin_constant_p gcc bug\")\nReported-by: Stephen Rothwell <sfr@canb.auug.org.au>\nTested-by: Stephen Rothwell <sfr@canb.auug.org.au>\nAcked-by: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Josh Poimboeuf <jpoimboe@redhat.com>\nSigned-off-by: Stephen Rothwell <sfr@canb.auug.org.au>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>","distinct":true,"url":"https://api.github.com/repos/ahmedradaideh/OnePlus3T/commits/89cc61e3ac730db6adba0c903b2357f732690260"},{"sha":"97c2337e1e45b5092ea34fec8bf8efc14870f423","author":{"name":"Rasmus Villemoes","email":"ba324ca7b1c77fc20bb970d5aff6eea9377918a5@rasmusvillemoes.dk"},"message":"compiler.h: add support for malloc attribute\n\ngcc as far back as at least 3.04 documents the function attribute\n__malloc__.  Add a shorthand for attaching that to a function\ndeclaration.  This was also suggested by Andi Kleen way back in 2002\n[1], but didn't get applied, perhaps because gcc at that time generated\nthe exact same code with and without this attribute.\n\nThis attribute tells the compiler that the return value (if non-NULL)\ncan be assumed not to alias any other valid pointers at the time of the\ncall.\n\nPlease note that the documentation for a range of gcc versions (starting\nfrom around 4.7) contained a somewhat confusing and self-contradicting\ntext:\n\n  The malloc attribute is used to tell the compiler that a function may\n  be treated as if any non-NULL pointer it returns cannot alias any other\n  pointer valid when the function returns and *that the memory has\n  undefined content*.  [...] Standard functions with this property include\n  malloc and *calloc*.\n\n(emphasis mine). The intended meaning has later been clarified [2]:\n\n  This tells the compiler that a function is malloc-like, i.e., that the\n  pointer P returned by the function cannot alias any other pointer valid\n  when the function returns, and moreover no pointers to valid objects\n  occur in any storage addressed by P.\n\nWhat this means is that we can apply the attribute to kmalloc and\nfriends, and it is ok for the returned memory to have well-defined\ncontents (__GFP_ZERO).  But it is not ok to apply it to kmemdup(), nor\nto other functions which both allocate and possibly initialize the\nmemory with existing pointers.  So unless someone is doing something\npretty perverted kstrdup() should also be a fine candidate.\n\n[1] http://thread.gmane.org/gmane.linux.kernel/57172\n[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955\n\nSigned-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>\nCc: Christoph Lameter <cl@linux.com>\nCc: Pekka Enberg <penberg@kernel.org>\nCc: David Rientjes <rientjes@google.com>\nCc: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nCc: Andi Kleen <ak@linux.intel.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>","distinct":true,"url":"https://api.github.com/repos/ahmedradaideh/OnePlus3T/commits/97c2337e1e45b5092ea34fec8bf8efc14870f423"},{"sha":"d018a00ca74551883836e63cc0d06d62998dc56d","author":{"name":"Johannes Berg","email":"bff32994ff0f8d048f262a8388145a71b6071bfe@intel.com"},"message":"byteswap: don't use __builtin_bswap*() with sparse\n\nAlthough sparse declares __builtin_bswap*(), it can't actually do\nconstant folding inside them (yet).  As such, things like\n\n  switch (protocol) {\n  case htons(ETH_P_IP):\n          break;\n  }\n\nwhich we do all over the place cause sparse to warn that it expects a\nconstant instead of a function call.\n\nDisable __HAVE_BUILTIN_BSWAP*__ if __CHECKER__ is defined to avoid this.\n\nFixes: 7322dd755e7d (\"byteswap: try to avoid __builtin_constant_p gcc bug\")\nLink: http://lkml.kernel.org/r/1470914102-26389-1-git-send-email-johannes@sipsolutions.net\nSigned-off-by: Johannes Berg <johannes.berg@intel.com>\nAcked-by: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>","distinct":true,"url":"https://api.github.com/repos/ahmedradaideh/OnePlus3T/commits/d018a00ca74551883836e63cc0d06d62998dc56d"},{"sha":"d74d46e66dc2bf2d1e4b1d024b3bf9eac7e9c279","author":{"name":"Benjamin Peterson","email":"0691a664b24b6f15b20cd5aee64b72271db08be1@benjamin.pe"},"message":"compiler-gcc.h: use \"proved\" instead of \"proofed\"\n\nLink: http://lkml.kernel.org/r/1477894241.1103202.772260161.1B0A5995@webmail.messagingengine.com\nSigned-off-by: Benjamin Peterson <bp@benjamin.pe>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>","distinct":true,"url":"https://api.github.com/repos/ahmedradaideh/OnePlus3T/commits/d74d46e66dc2bf2d1e4b1d024b3bf9eac7e9c279"},{"sha":"32eb5e7e3c71478b1633e8036f45b438efe59bbc","author":{"name":"Gideon Israel Dsouza","email":"c46dc5905f785d84b66ddcb7c969fa19e40ea4bf@gmail.com"},"message":"BACKPORT: compiler-gcc.h: add a new macro to wrap gcc attribute\n\nAdd __mode(x) into compiler-gcc.h as part of a cleanup task I've taken\nup, to replace gcc specific attributes with macros.\n\nThe next patch is a cleanup of the m68k subsystem and it requires a new\nmacro to wrap __attribute__ ((mode (...)))\n\nLink: http://lkml.kernel.org/r/1485540901-1988-2-git-send-email-gidisrael@gmail.com\nSigned-off-by: Gideon Israel Dsouza <gidisrael@gmail.com>\nCc: Greg Ungerer <gerg@linux-m68k.org>\nCc: Geert Uytterhoeven <geert@linux-m68k.org>\nCc: Paul Gortmaker <paul.gortmaker@windriver.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>","distinct":true,"url":"https://api.github.com/repos/ahmedradaideh/OnePlus3T/commits/32eb5e7e3c71478b1633e8036f45b438efe59bbc"},{"sha":"1b3374c47f0893b2bbeb1c75143ee8a7828b37f3","author":{"name":"Arnd Bergmann","email":"f2c659f01951776204a6c5b902787d9019fbeebd@arndb.de"},"message":"bug.h: work around GCC PR82365 in BUG()\n\nLooking at functions with large stack frames across all architectures\nled me discovering that BUG() suffers from the same problem as\nfortify_panic(), which I've added a workaround for already.\n\nIn short, variables that go out of scope by calling a noreturn function\nor __builtin_unreachable() keep using stack space in functions\nafterwards.\n\nA workaround that was identified is to insert an empty assembler\nstatement just before calling the function that doesn't return.  I'm\nadding a macro \"barrier_before_unreachable()\" to document this, and\ninsert calls to that in all instances of BUG() that currently suffer\nfrom this problem.\n\nThe files that saw the largest change from this had these frame sizes\nbefore, and much less with my patch:\n\n  fs/ext4/inode.c:82:1: warning: the frame size of 1672 bytes is larger than 800 bytes [-Wframe-larger-than=]\n  fs/ext4/namei.c:434:1: warning: the frame size of 904 bytes is larger than 800 bytes [-Wframe-larger-than=]\n  fs/ext4/super.c:2279:1: warning: the frame size of 1160 bytes is larger than 800 bytes [-Wframe-larger-than=]\n  fs/ext4/xattr.c:146:1: warning: the frame size of 1168 bytes is larger than 800 bytes [-Wframe-larger-than=]\n  fs/f2fs/inode.c:152:1: warning: the frame size of 1424 bytes is larger than 800 bytes [-Wframe-larger-than=]\n  net/netfilter/ipvs/ip_vs_core.c:1195:1: warning: the frame size of 1068 bytes is larger than 800 bytes [-Wframe-larger-than=]\n  net/netfilter/ipvs/ip_vs_core.c:395:1: warning: the frame size of 1084 bytes is larger than 800 bytes [-Wframe-larger-than=]\n  net/netfilter/ipvs/ip_vs_ftp.c:298:1: warning: the frame size of 928 bytes is larger than 800 bytes [-Wframe-larger-than=]\n  net/netfilter/ipvs/ip_vs_ftp.c:418:1: warning: the frame size of 908 bytes is larger than 800 bytes [-Wframe-larger-than=]\n  net/netfilter/ipvs/ip_vs_lblcr.c:718:1: warning: the frame size of 960 bytes is larger than 800 bytes [-Wframe-larger-than=]\n  drivers/net/xen-netback/netback.c:1500:1: warning: the frame size of 1088 bytes is larger than 800 bytes [-Wframe-larger-than=]\n\nIn case of ARC and CRIS, it turns out that the BUG() implementation\nactually does return (or at least the compiler thinks it does),\nresulting in lots of warnings about uninitialized variable use and\nleaving noreturn functions, such as:\n\n  block/cfq-iosched.c: In function 'cfq_async_queue_prio':\n  block/cfq-iosched.c:3804:1: error: control reaches end of non-void function [-Werror=return-type]\n  include/linux/dmaengine.h: In function 'dma_maxpq':\n  include/linux/dmaengine.h:1123:1: error: control reaches end of non-void function [-Werror=return-type]\n\nThis makes them call __builtin_trap() instead, which should normally\ndump the stack and kill the current process, like some of the other\narchitectures already do.\n\nI tried adding barrier_before_unreachable() to panic() and\nfortify_panic() as well, but that had very little effect, so I'm not\nsubmitting that patch.\n\nVineet said:\n\n: For ARC, it is double win.\n:\n: 1. Fixes 3 -Wreturn-type warnings\n:\n: | ../net/core/ethtool.c:311:1: warning: control reaches end of non-void function\n: [-Wreturn-type]\n: | ../kernel/sched/core.c:3246:1: warning: control reaches end of non-void function\n: [-Wreturn-type]\n: | ../include/linux/sunrpc/svc_xprt.h:180:1: warning: control reaches end of\n: non-void function [-Wreturn-type]\n:\n: 2.  bloat-o-meter reports code size improvements as gcc elides the\n:    generated code for stack return.\n\nLink: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365\nLink: http://lkml.kernel.org/r/20171219114112.939391-1-arnd@arndb.de\nSigned-off-by: Arnd Bergmann <arnd@arndb.de>\nAcked-by: Vineet Gupta <vgupta@synopsys.com>\t[arch/arc]\nTested-by: Vineet Gupta <vgupta@synopsys.com>\t[arch/arc]\nCc: Mikael Starvik <starvik@axis.com>\nCc: Jesper Nilsson <jesper.nilsson@axis.com>\nCc: Tony Luck <tony.luck@intel.com>\nCc: Fenghua Yu <fenghua.yu@intel.com>\nCc: Geert Uytterhoeven <geert@linux-m68k.org>\nCc: \"David S. Miller\" <davem@davemloft.net>\nCc: Christopher Li <sparse@chrisli.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Kees Cook <keescook@chromium.org>\nCc: Ingo Molnar <mingo@kernel.org>\nCc: Josh Poimboeuf <jpoimboe@redhat.com>\nCc: Will Deacon <will.deacon@arm.com>\nCc: \"Steven Rostedt (VMware)\" <rostedt@goodmis.org>\nCc: Mark Rutland <mark.rutland@arm.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>","distinct":true,"url":"https://api.github.com/repos/ahmedradaideh/OnePlus3T/commits/1b3374c47f0893b2bbeb1c75143ee8a7828b37f3"}]}
{"actor":{"display_login":"ahmedradaideh"}}