{"push_id":1423578094,"size":80,"distinct_size":80,"ref":"refs/heads/4.8","head":"26232c926b4c769b43ce08e19ce56eefadf8c7d7","before":"07b51ce6da8b32c153b5b2704311bce1784744d8","commits":[{"sha":"6777c2034033ac4b2408786a2f87882c0afd6c0c","author":{"name":"Steven Barrett","email":"1745667f465f588877e987cca116e0aa57a977ec@liquorix.net"},"message":"Merge branch '4.8/upstream-updates' into 4.8/master","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/6777c2034033ac4b2408786a2f87882c0afd6c0c"},{"sha":"3b26688163076e5be304f42fae8430a6a9d08d51","author":{"name":"Steven Barrett","email":"1745667f465f588877e987cca116e0aa57a977ec@liquorix.net"},"message":"zen: raise BLKDEV_MAX_RQ to 512\n\nIn a surprising turn of events, while benchmarking and testing\nhierarchical scheduling with BFQ + writeback throttling, it turns out\nthat raising the number of requests in queue _actually_ improves\nresponsiveness and completely eliminates the random stalls that would\nnormally occur without hierarchical scheduling.\n\nTo make this test more intense, I used the following test:\n\nRotational disk1: rsync -a /source/of/data /target/to/disk1\nRotational disk2: rsync -a /source/of/data /target/to/disk2\n\nAnd periodically attempted to write super fast with:\ndd if=/dev/zero of=/target/to/disk1/block bs=4096\n\nThis wrote 10gb incredibly fast to writeback and I encountered zero\nstalls through this entire test of 10-15 minutes.\n\nMy suspicion is that with cgroups, BFQ is more able to properly sort\namong multiple drives, reducing the chance of a starved process.  This\nplus writeback throttling completely eliminate any outstanding bugs with\nhigh writeback ratios, letting the user enjoy low latency writes\n(application thinks they're already done), and super high throughput due\nto batched writes in writeback.\n\nPlease note however, without the following configuration, I cannot\nguarantee you will not get stalls:\n\nCONFIG_BLK_CGROUP=y\nCONFIG_CGROUP_WRITEBACK=y\nCONFIG_IOSCHED_CFQ=y\nCONFIG_CFQ_GROUP_IOSCHED=y\nCONFIG_IOSCHED_BFQ=y\nCONFIG_BFQ_GROUP_IOSCHED=y\nCONFIG_DEFAULT_BFQ=y\nCONFIG_SCSI_MQ_DEFAULT=n\n\nSpecial thanks to h2, author of smxi and inxi, for providing evidence\nthat a configuration specific to Debian did not cause stalls found the\nLiquorix kernels under heavy IO load.  This specific configuration\nturned out to be hierarchical scheduling on CFQ (thus, BFQ as well).","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/3b26688163076e5be304f42fae8430a6a9d08d51"},{"sha":"093082ad75d6e63b3b5f0c90ce61ab0ec32afc83","author":{"name":"Steven Barrett","email":"1745667f465f588877e987cca116e0aa57a977ec@liquorix.net"},"message":"Merge branch '4.8/zen-tune' into 4.8/master","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/093082ad75d6e63b3b5f0c90ce61ab0ec32afc83"},{"sha":"3f3919abcf8ce0f4a4f508bcb64665a6a552d7fc","author":{"name":"Con Kolivas","email":"d73dc0ee41f8b02bae277090e92abc1675af05ac@kolivas.org"},"message":"muqss: Merge version 0.144\n\nremote https://github.com/ckolivas/linux\nbranch 4.8-muqss\ncommit 68b1c4cc096882fe38d0ffccce82a5c725d4bb75","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/3f3919abcf8ce0f4a4f508bcb64665a6a552d7fc"},{"sha":"46755717ff6f7040c7156e13654deb83cfd312ca","author":{"name":"Jan Alexander Steffens (heftig)","email":"0dc8097fef40cb90785ac6e74ec50d171335a7c3@gmail.com"},"message":"Merge branch '4.8/muqss' into 4.8/master","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/46755717ff6f7040c7156e13654deb83cfd312ca"},{"sha":"92a747f643333cdf8a7b1c07833d0c8c88d5886d","author":{"name":"Jan Alexander Steffens (heftig)","email":"0dc8097fef40cb90785ac6e74ec50d171335a7c3@gmail.com"},"message":"init/Kconfig: Fix ZEN_INTERACTIVE doc","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/92a747f643333cdf8a7b1c07833d0c8c88d5886d"},{"sha":"f95665675ff978cbea6730b8319dcfc0ca1322dd","author":{"name":"Jan Alexander Steffens (heftig)","email":"0dc8097fef40cb90785ac6e74ec50d171335a7c3@gmail.com"},"message":"Merge branch '4.8/zen-tune' into 4.8/master","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/f95665675ff978cbea6730b8319dcfc0ca1322dd"},{"sha":"87d06ce401584ed4ac23fda36579a0ad4ac82f04","author":{"name":"Jan Alexander Steffens (heftig)","email":"0dc8097fef40cb90785ac6e74ec50d171335a7c3@gmail.com"},"message":"ZEN: Merge current exFAT code\n\nremote https://github.com/dorimanx/exfat-nofuse\nbranch master\ncommit 42c14eb78feaca93d0bde7dd0dd78fc9bb5331f7","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/87d06ce401584ed4ac23fda36579a0ad4ac82f04"},{"sha":"5b91528dad39cabe601aaae06ce071a191300dce","author":{"name":"Jan Alexander Steffens (heftig)","email":"0dc8097fef40cb90785ac6e74ec50d171335a7c3@gmail.com"},"message":"Merge branch '4.8/misc' into 4.8/master","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/5b91528dad39cabe601aaae06ce071a191300dce"},{"sha":"f8c74cf95655e814d253307283561cf2d47398df","author":{"name":"Yazen Ghannam","email":"181379dd5445340388b3c30843365a63baf86cf0@amd.com"},"message":"x86/cpu/AMD: Fix cpu_llc_id for AMD Fam17h systems\n\ncommit b0b6e86846093c5f8820386bc01515f857dd8faa upstream.\n\ncpu_llc_id (Last Level Cache ID) derivation on AMD Fam17h has an\nunderflow bug when extracting the socket_id value. It starts from 0\nso subtracting 1 from it will result in an invalid value. This breaks\nscheduling topology later on since the cpu_llc_id will be incorrect.\n\nFor example, the the cpu_llc_id of the *other* CPU in the loops in\nset_cpu_sibling_map() underflows and we're generating the funniest\nthread_siblings masks and then when I run 8 threads of nbench, they get\nspread around the LLC domains in a very strange pattern which doesn't\ngive you the normal scheduling spread one would expect for performance.\n\nOther things like EDAC use cpu_llc_id so they will be b0rked too.\n\nSo, the APIC ID is preset in APICx020 for bits 3 and above: they contain\nthe core complex, node and socket IDs.\n\nThe LLC is at the core complex level so we can find a unique cpu_llc_id\nby right shifting the APICID by 3 because then the least significant bit\nwill be the Core Complex ID.\n\nTested-by: Borislav Petkov <bp@suse.de>\nSigned-off-by: Yazen Ghannam <Yazen.Ghannam@amd.com>\n[ Cleaned up and extended the commit message. ]\nSigned-off-by: Borislav Petkov <bp@suse.de>\nAcked-by: Thomas Gleixner <tglx@linutronix.de>\nCc: Aravind Gopalakrishnan <aravindksg.lkml@gmail.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Peter Zijlstra <peterz@infradead.org>\nFixes: 3849e91f571d (\"x86/AMD: Fix last level cache topology for AMD Fam17h systems\")\nLink: http://lkml.kernel.org/r/20161108083506.rvqb5h4chrcptj7d@pd.tnic\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/backbone/backbone-sources/commits/f8c74cf95655e814d253307283561cf2d47398df"},{"sha":"23555ca21394c0f5a146c891128bd4edc3e78862","author":{"name":"Paolo Bonzini","email":"7438500e0207b21c4e5dfca8d2a7898734cd7706@redhat.com"},"message":"KVM: x86: fix missed SRCU usage in kvm_lapic_set_vapic_addr\n\ncommit 7301d6abaea926d685832f7e1f0c37dd206b01f4 upstream.\n\nReported by syzkaller:\n\n    [ INFO: suspicious RCU usage. ]\n    4.9.0-rc4+ #47 Not tainted\n    -------------------------------\n    ./include/linux/kvm_host.h:536 suspicious rcu_dereference_check() usage!\n\n    stack backtrace:\n    CPU: 1 PID: 6679 Comm: syz-executor Not tainted 4.9.0-rc4+ #47\n    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011\n     ffff880039e2f6d0 ffffffff81c2e46b ffff88003e3a5b40 0000000000000000\n     0000000000000001 ffffffff83215600 ffff880039e2f700 ffffffff81334ea9\n     ffffc9000730b000 0000000000000004 ffff88003c4f8420 ffff88003d3f8000\n    Call Trace:\n     [<     inline     >] __dump_stack lib/dump_stack.c:15\n     [<ffffffff81c2e46b>] dump_stack+0xb3/0x118 lib/dump_stack.c:51\n     [<ffffffff81334ea9>] lockdep_rcu_suspicious+0x139/0x180 kernel/locking/lockdep.c:4445\n     [<     inline     >] __kvm_memslots include/linux/kvm_host.h:534\n     [<     inline     >] kvm_memslots include/linux/kvm_host.h:541\n     [<ffffffff8105d6ae>] kvm_gfn_to_hva_cache_init+0xa1e/0xce0 virt/kvm/kvm_main.c:1941\n     [<ffffffff8112685d>] kvm_lapic_set_vapic_addr+0xed/0x140 arch/x86/kvm/lapic.c:2217\n\nReported-by: Dmitry Vyukov <dvyukov@google.com>\nFixes: fda4e2e85589191b123d31cdc21fd33ee70f50fd\nCc: Andrew Honig <ahonig@google.com>\nSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>\nReviewed-by: David Hildenbrand <david@redhat.com>\nSigned-off-by: Radim Krčmář <rkrcmar@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/23555ca21394c0f5a146c891128bd4edc3e78862"},{"sha":"1cb9b2489e778b4f0d97a98ef35be00b2498d94d","author":{"name":"Ignacio Alvarado","email":"b73eee07696f40cc9ebf36ffd3d82479992c8b65@google.com"},"message":"KVM: Disable irq while unregistering user notifier\n\ncommit 1650b4ebc99da4c137bfbfc531be4a2405f951dd upstream.\n\nFunction user_notifier_unregister should be called only once for each\nregistered user notifier.\n\nFunction kvm_arch_hardware_disable can be executed from an IPI context\nwhich could cause a race condition with a VCPU returning to user mode\nand attempting to unregister the notifier.\n\nSigned-off-by: Ignacio Alvarado <ikalvarado@google.com>\nFixes: 18863bdd60f8 (\"KVM: x86 shared msr infrastructure\")\nReviewed-by: Paolo Bonzini <pbonzini@redhat.com>\nSigned-off-by: Radim Krčmář <rkrcmar@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/1cb9b2489e778b4f0d97a98ef35be00b2498d94d"},{"sha":"8d8b37e242decffb789cd86f501100dd881ded10","author":{"name":"Wei Huang","email":"fb98242a50d75dab760b39e4d1977f574d79e9e1@redhat.com"},"message":"arm64: KVM: pmu: Fix AArch32 cycle counter access\n\ncommit 9e3f7a29694049edd728e2400ab57ad7553e5aa9 upstream.\n\nWe're missing the handling code for the cycle counter accessed\nfrom a 32bit guest, leading to unexpected results.\n\nSigned-off-by: Wei Huang <wei@redhat.com>\nSigned-off-by: Marc Zyngier <marc.zyngier@arm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/8d8b37e242decffb789cd86f501100dd881ded10"},{"sha":"f271087fb2ea6eb4352340893225655f6ab491d0","author":{"name":"Wei Huang","email":"fb98242a50d75dab760b39e4d1977f574d79e9e1@redhat.com"},"message":"KVM: arm64: Fix the issues when guest PMCCFILTR is configured\n\ncommit b112c84a6ff035271d41d548c10215f18443d6a6 upstream.\n\nKVM calls kvm_pmu_set_counter_event_type() when PMCCFILTR is configured.\nBut this function can't deals with PMCCFILTR correctly because the evtCount\nbits of PMCCFILTR, which is reserved 0, conflits with the SW_INCR event\ntype of other PMXEVTYPER<n> registers. To fix it, when eventsel == 0, this\nfunction shouldn't return immediately; instead it needs to check further\nif select_idx is ARMV8_PMU_CYCLE_IDX.\n\nAnother issue is that KVM shouldn't copy the eventsel bits of PMCCFILTER\nblindly to attr.config. Instead it ought to convert the request to the\n\"cpu cycle\" event type (i.e. 0x11).\n\nTo support this patch and to prevent duplicated definitions, a limited\nset of ARMv8 perf event types were relocated from perf_event.c to\nasm/perf_event.h.\n\nAcked-by: Will Deacon <will.deacon@arm.com>\nSigned-off-by: Wei Huang <wei@redhat.com>\nSigned-off-by: Marc Zyngier <marc.zyngier@arm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/f271087fb2ea6eb4352340893225655f6ab491d0"},{"sha":"c5d20ce0b459b6e2d00f58b599543eb0e8e725e4","author":{"name":"Alexei Starovoitov","email":"50b16f6527d2958df737674aa9b4293ff06b2058@fb.com"},"message":"ftrace: Ignore FTRACE_FL_DISABLED while walking dyn_ftrace records\n\ncommit 977c1f9c8c022d0173181766b34a0db3705265a4 upstream.\n\nftrace_shutdown() checks for sanity of ftrace records\nand if dyn_ftrace->flags is not zero, it will warn.\nIt can happen that 'flags' are set to FTRACE_FL_DISABLED at this point,\nsince some module was loaded, but before ftrace_module_enable()\ncleared the flags for this module.\n\nIn other words the module.c is doing:\nftrace_module_init(mod); // calls ftrace_update_code() that sets flags=FTRACE_FL_DISABLED\n... // here ftrace_shutdown() is called that warns, since\nerr = prepare_coming_module(mod); // didn't have a chance to clear FTRACE_FL_DISABLED\n\nFix it by ignoring disabled records.\nIt's similar to what __ftrace_hash_rec_update() is already doing.\n\nLink: http://lkml.kernel.org/r/1478560460-3818619-1-git-send-email-ast@fb.com\n\nFixes: b7ffffbb46f2 \"ftrace: Add infrastructure for delayed enabling of module functions\"\nSigned-off-by: Alexei Starovoitov <ast@kernel.org>\nSigned-off-by: Steven Rostedt <rostedt@goodmis.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/c5d20ce0b459b6e2d00f58b599543eb0e8e725e4"},{"sha":"8844024c883972fe9ce983a60cd9cc55cfb073ae","author":{"name":"Steven Rostedt (Red Hat)","email":"9f626a07de58780741a9085807c77fd646ef3459@goodmis.org"},"message":"ftrace: Add more checks for FTRACE_FL_DISABLED in processing ip records\n\ncommit 546fece4eae871f033925ccf0ff2b740725ae915 upstream.\n\nWhen a module is first loaded and its function ip records are added to the\nftrace list of functions to modify, they are set to DISABLED, as their text\nis still in a read only state. When the module is fully loaded, and can be\nupdated, the flag is cleared, and if their's any functions that should be\ntracing them, it is updated at that moment.\n\nBut there's several locations that do record accounting and should ignore\nrecords that are marked as disabled, or they can cause issues.\n\nAlexei already fixed one location, but others need to be addressed.\n\nFixes: b7ffffbb46f2 \"ftrace: Add infrastructure for delayed enabling of module functions\"\nReported-by: Alexei Starovoitov <ast@kernel.org>\nSigned-off-by: Steven Rostedt <rostedt@goodmis.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/8844024c883972fe9ce983a60cd9cc55cfb073ae"},{"sha":"de58c50e84e27ede34b509ad900414e43da5721a","author":{"name":"Thomas Gleixner","email":"352b5f5ba0189d2583768a9bb8247f98115b9038@linutronix.de"},"message":"genirq: Use irq type from irqdata instead of irqdesc\n\ncommit 7ee7e87dfb158e79019ea1d5ea1b0e6f2bc93ee4 upstream.\n\nThe type flags in the irq descriptor are there for historical reasons and\nonly updated via irq_modify_status() or irq_set_type(). Both functions also\nupdate the type flags in irqdata. __setup_irq() is the only left over user\nof the type flags in the irq descriptor.\n\nIf __setup_irq() is called with empty irq type flags, then the type flags\nare retrieved from irqdata. If an interrupt is shared, then the type flags\nare compared with the type flags stored in the irq descriptor.\n\nOn x86 the ioapic does not have a irq_set_type() callback because the type\nis defined in the BIOS tables and cannot be changed. The type is stored in\nirqdata at setup time without updating the type data in the irq\ndescriptor. As a result the comparison described above fails.\n\nThere is no point in updating the irq descriptor flags because the only\nrelevant storage is irqdata. Use the type flags from irqdata for both\nretrieval and comparison in __setup_irq() instead.\n\nAside of that the print out in case of non matching type flags has the old\nand new type flags arguments flipped. Fix that as well.\n\nFor correctness sake the flags stored in the irq descriptor should be\nremoved, but this is beyond the scope of this bugfix and will be done in a\nlater patch.\n\nFixes: 4b357daed698 (\"genirq: Look-up trigger type if not specified by caller\")\nReported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nCc: Marc Zyngier <marc.zyngier@arm.com>\nCc: Jon Hunter <jonathanh@nvidia.com>\nLink: http://lkml.kernel.org/r/alpine.DEB.2.20.1611072020360.3501@nanos\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/backbone/backbone-sources/commits/de58c50e84e27ede34b509ad900414e43da5721a"},{"sha":"ca720a2b11b4c90d1798b406d3c191cd5395b5e3","author":{"name":"Miklos Szeredi","email":"c27ee2952768e22f4d3ab9aec0e78ac5f4ddea98@redhat.com"},"message":"fuse: fix fuse_write_end() if zero bytes were copied\n\ncommit 59c3b76cc61d1d676f965c192cc7969aa5cb2744 upstream.\n\nIf pos is at the beginning of a page and copied is zero then page is not\nzeroed but is marked uptodate.\n\nFix by skipping everything except unlock/put of page if zero bytes were\ncopied.\n\nReported-by: Al Viro <viro@zeniv.linux.org.uk>\nFixes: 6b12c1b37e55 (\"fuse: Implement write_begin/write_end callbacks\")\nSigned-off-by: Miklos Szeredi <mszeredi@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/ca720a2b11b4c90d1798b406d3c191cd5395b5e3"},{"sha":"06eac15f11e014e471f1486fa47817d3a3697b4d","author":{"name":"Dennis Dalessandro","email":"634a4c9ac8cac6d34c4785eb7c306b61be4b21e6@intel.com"},"message":"IB/rdmavt: rdmavt can handle non aligned page maps\n\ncommit e1fafdcbe0e3e769c6a83317dd845bc99b4fe61d upstream.\n\nThe initial code for rdmavt carried with it a restriction that was a\nvestige from the qib driver, that to dma map a page it had to be less\nthan a page size. This is not the case on modern hardware, both qib and\nhfi1 will be just fine with unaligned map requests.\n\nThis fixes a 4.8 regression where by an IPoIB transfer of > PAGE_SIZE\nwill hang because the dma map page call always fails. This was\nintroduced after commit 5faba5469522 (\"IB/ipoib: Report SG feature\nregardless of HW UD CSUM capability\") added the capability to use SG by\ndefault. Rather than override this, the HW supports it, so allow SG.\n\nReviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>\nSigned-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>\nSigned-off-by: Doug Ledford <dledford@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/06eac15f11e014e471f1486fa47817d3a3697b4d"},{"sha":"8b4d44f46bf22c7b77fdc91ed668c50261f9b536","author":{"name":"Ira Weiny","email":"a7559bb87c8386d6b9313dcb8aeaceee1228c9b3@intel.com"},"message":"IB/hfi1: Fix rnr_timer addition\n\ncommit 458ed666fe14a54dfb6690a1a7f541782d1342c9 upstream.\n\nThe new s_rnr_timeout was not properly being set and the code was\nincorrectly setting a different timer.\n\nFound by code inspection.\n\nFixes: 08279d5c9424 (\"staging/rdma/hfi1: use new RNR timer\")\nReviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>\nSigned-off-by: Ira Weiny <ira.weiny@intel.com>\nSigned-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>\nSigned-off-by: Doug Ledford <dledford@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/backbone/backbone-sources/commits/8b4d44f46bf22c7b77fdc91ed668c50261f9b536"}]}
{"actor":{"display_login":"backbone"}}