{"push_id":915431442,"size":15,"distinct_size":15,"ref":"refs/heads/development","head":"8cf46da51a2ae3af139833b9bbe8fa9840296a88","before":"fc15b5016881d06ea2bfcf8977458c42c238132b","commits":[{"sha":"9dd54b06e6f28044ec0e3e79777be50d225cc414","author":{"email":"1a53202f7826b15a582486d4ea9c371e05720251@oracle.com","name":"Sowmini Varadhan"},"message":"sparc: Use GFP_ATOMIC in ldc_alloc_exp_dring() as it can be called in softirq context\n\nUpstream commit 671d773297969bebb1732e1cdc1ec03aa53c6be2\n\nSince it is possible for vnet_event_napi to end up doing\nvnet_control_pkt_engine -> ... -> vnet_send_attr ->\nvnet_port_alloc_tx_ring -> ldc_alloc_exp_dring -> kzalloc()\n(i.e., in softirq context), kzalloc() should be called with\nGFP_ATOMIC from ldc_alloc_exp_dring.\n\nSigned-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/artefvck/X_Artefvck/commits/9dd54b06e6f28044ec0e3e79777be50d225cc414"},{"sha":"1e89e2b60726e14a89516b656fc9a02083407ad4","author":{"email":"966b74740c67c4df944e25f0a65bfdba363503f7@blackwall.org","name":"Nikolay Aleksandrov"},"message":"bridge: fix multicast router rlist endless loop\n\n[ Upstream commit 1a040eaca1a22f8da8285ceda6b5e4a2cb704867 ]\n\nSince the addition of sysfs multicast router support if one set\nmulticast_router to \"2\" more than once, then the port would be added to\nthe hlist every time and could end up linking to itself and thus causing an\nendless loop for rlist walkers.\nSo to reproduce just do:\necho 2 > multicast_router; echo 2 > multicast_router;\nin a bridge port and let some igmp traffic flow, for me it hangs up\nin br_multicast_flood().\nFix this by adding a check in br_multicast_add_router() if the port is\nalready linked.\nThe reason this didn't happen before the addition of multicast_router\nsysfs entries is because there's a !hlist_unhashed check that prevents\nit.\n\nSigned-off-by: Nikolay Aleksandrov <razor@blackwall.org>\nFixes: 0909e11758bd (\"bridge: Add multicast_router sysfs entries\")\nAcked-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/artefvck/X_Artefvck/commits/1e89e2b60726e14a89516b656fc9a02083407ad4"},{"sha":"2d572fd2ae283189fb1e19ebe41b1b34666cb8e9","author":{"email":"966b74740c67c4df944e25f0a65bfdba363503f7@blackwall.org","name":"Nikolay Aleksandrov"},"message":"bridge: fix br_stp_set_bridge_priority race conditions\n\n[ Upstream commit 2dab80a8b486f02222a69daca6859519e05781d9 ]\n\nAfter the ->set() spinlocks were removed br_stp_set_bridge_priority\nwas left running without any protection when used via sysfs. It can\nrace with port add/del and could result in use-after-free cases and\ncorrupted lists. Tested by running port add/del in a loop with stp\nenabled while setting priority in a loop, crashes are easily\nreproducible.\nThe spinlocks around sysfs ->set() were removed in commit:\n14f98f258f19 (\"bridge: range check STP parameters\")\nThere's also a race condition in the netlink priority support that is\nfixed by this change, but it was introduced recently and the fixes tag\ncovers it, just in case it's needed the commit is:\naf615762e972 (\"bridge: add ageing_time, stp_state, priority over netlink\")\n\nSigned-off-by: Nikolay Aleksandrov <razor@blackwall.org>\nFixes: 14f98f258f19 (\"bridge: range check STP parameters\")\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/artefvck/X_Artefvck/commits/2d572fd2ae283189fb1e19ebe41b1b34666cb8e9"},{"sha":"5c4100732fdbaa25360951e7eb1f7dfcf4660b89","author":{"email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com","name":"Eric Dumazet"},"message":"packet: read num_members once in packet_rcv_fanout()\n\n[ Upstream commit f98f4514d07871da7a113dd9e3e330743fd70ae4 ]\n\nWe need to tell compiler it must not read f->num_members multiple\ntimes. Otherwise testing if num is not zero is flaky, and we could\nattempt an invalid divide by 0 in fanout_demux_cpu()\n\nNote bug was present in packet_rcv_fanout_hash() and\npacket_rcv_fanout_lb() but final 3.1 had a simple location\nafter commit 95ec3eb417115fb (\"packet: Add 'cpu' fanout policy.\")\n\nFixes: dc99f600698dc (\"packet: Add fanout support.\")\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nCc: Willem de Bruijn <willemb@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/artefvck/X_Artefvck/commits/5c4100732fdbaa25360951e7eb1f7dfcf4660b89"},{"sha":"4c164d3610afa2f0bda3a8a7d9c94f74299b601b","author":{"email":"1ee125182537a91f90180f97fc3b3cb011bdf78a@google.com","name":"Willem de Bruijn"},"message":"packet: avoid out of bounds read in round robin fanout\n\n[ Upstream commit 468479e6043c84f5a65299cc07cb08a22a28c2b1 ]\n\nPACKET_FANOUT_LB computes f->rr_cur such that it is modulo\nf->num_members. It returns the old value unconditionally, but\nf->num_members may have changed since the last store. Ensure\nthat the return value is always < num.\n\nWhen modifying the logic, simplify it further by replacing the loop\nwith an unconditional atomic increment.\n\nFixes: dc99f600698d (\"packet: Add fanout support.\")\nSuggested-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Willem de Bruijn <willemb@google.com>\nAcked-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/artefvck/X_Artefvck/commits/4c164d3610afa2f0bda3a8a7d9c94f74299b601b"},{"sha":"1b24918424a65b595bcb5869131d28c92356b996","author":{"email":"dace7423e438e9d50a283477134876fe17cd3341@nokia.com","name":"Alexander Sverdlin"},"message":"sctp: Fix race between OOTB responce and route removal\n\n[ Upstream commit 29c4afc4e98f4dc0ea9df22c631841f9c220b944 ]\n\nThere is NULL pointer dereference possible during statistics update if the route\nused for OOTB responce is removed at unfortunate time. If the route exists when\nwe receive OOTB packet and we finally jump into sctp_packet_transmit() to send\nABORT, but in the meantime route is removed under our feet, we take \"no_route\"\npath and try to update stats with IP_INC_STATS(sock_net(asoc->base.sk), ...).\n\nBut sctp_ootb_pkt_new() used to prepare responce packet doesn't call\nsctp_transport_set_owner() and therefore there is no asoc associated with this\npacket. Probably temporary asoc just for OOTB responces is overkill, so just\nintroduce a check like in all other places in sctp_packet_transmit(), where\n\"asoc\" is dereferenced.\n\nTo reproduce this, one needs to\n0. ensure that sctp module is loaded (otherwise ABORT is not generated)\n1. remove default route on the machine\n2. while true; do\n     ip route del [interface-specific route]\n     ip route add [interface-specific route]\n   done\n3. send enough OOTB packets (i.e. HB REQs) from another host to trigger ABORT\n   responce\n\nOn x86_64 the crash looks like this:\n\nBUG: unable to handle kernel NULL pointer dereference at 0000000000000020\nIP: [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]\nPGD 0\nOops: 0000 [#1] PREEMPT SMP\nModules linked in: ...\nCPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O    4.0.5-1-ARCH #1\nHardware name: ...\ntask: ffffffff818124c0 ti: ffffffff81800000 task.ti: ffffffff81800000\nRIP: 0010:[<ffffffffa05ec9ac>]  [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]\nRSP: 0018:ffff880127c037b8  EFLAGS: 00010296\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000015ff66b480\nRDX: 00000015ff66b400 RSI: ffff880127c17200 RDI: ffff880123403700\nRBP: ffff880127c03888 R08: 0000000000017200 R09: ffffffff814625af\nR10: ffffea00047e4680 R11: 00000000ffffff80 R12: ffff8800b0d38a28\nR13: ffff8800b0d38a28 R14: ffff8800b3e88000 R15: ffffffffa05f24e0\nFS:  0000000000000000(0000) GS:ffff880127c00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b\nCR2: 0000000000000020 CR3: 00000000c855b000 CR4: 00000000000007f0\nStack:\n ffff880127c03910 ffff8800b0d38a28 ffffffff8189d240 ffff88011f91b400\n ffff880127c03828 ffffffffa05c94c5 0000000000000000 ffff8800baa1c520\n 0000000000000000 0000000000000001 0000000000000000 0000000000000000\nCall Trace:\n <IRQ>\n [<ffffffffa05c94c5>] ? sctp_sf_tabort_8_4_8.isra.20+0x85/0x140 [sctp]\n [<ffffffffa05d6b42>] ? sctp_transport_put+0x52/0x80 [sctp]\n [<ffffffffa05d0bfc>] sctp_do_sm+0xb8c/0x19a0 [sctp]\n [<ffffffff810b0e00>] ? trigger_load_balance+0x90/0x210\n [<ffffffff810e0329>] ? update_process_times+0x59/0x60\n [<ffffffff812c7a40>] ? timerqueue_add+0x60/0xb0\n [<ffffffff810e0549>] ? enqueue_hrtimer+0x29/0xa0\n [<ffffffff8101f599>] ? read_tsc+0x9/0x10\n [<ffffffff8116d4b5>] ? put_page+0x55/0x60\n [<ffffffff810ee1ad>] ? clockevents_program_event+0x6d/0x100\n [<ffffffff81462b68>] ? skb_free_head+0x58/0x80\n [<ffffffffa029a10b>] ? chksum_update+0x1b/0x27 [crc32c_generic]\n [<ffffffff81283f3e>] ? crypto_shash_update+0xce/0xf0\n [<ffffffffa05d3993>] sctp_endpoint_bh_rcv+0x113/0x280 [sctp]\n [<ffffffffa05dd4e6>] sctp_inq_push+0x46/0x60 [sctp]\n [<ffffffffa05ed7a0>] sctp_rcv+0x880/0x910 [sctp]\n [<ffffffffa05ecb50>] ? sctp_packet_transmit_chunk+0xb0/0xb0 [sctp]\n [<ffffffffa05ecb70>] ? sctp_csum_update+0x20/0x20 [sctp]\n [<ffffffff814b05a5>] ? ip_route_input_noref+0x235/0xd30\n [<ffffffff81051d6b>] ? ack_ioapic_level+0x7b/0x150\n [<ffffffff814b27be>] ip_local_deliver_finish+0xae/0x210\n [<ffffffff814b2e15>] ip_local_deliver+0x35/0x90\n [<ffffffff814b2a15>] ip_rcv_finish+0xf5/0x370\n [<ffffffff814b3128>] ip_rcv+0x2b8/0x3a0\n [<ffffffff81474193>] __netif_receive_skb_core+0x763/0xa50\n [<ffffffff81476c28>] __netif_receive_skb+0x18/0x60\n [<ffffffff81476cb0>] netif_receive_skb_internal+0x40/0xd0\n [<ffffffff814776c8>] napi_gro_receive+0xe8/0x120\n [<ffffffffa03946aa>] rtl8169_poll+0x2da/0x660 [r8169]\n [<ffffffff8147896a>] net_rx_action+0x21a/0x360\n [<ffffffff81078dc1>] __do_softirq+0xe1/0x2d0\n [<ffffffff8107912d>] irq_exit+0xad/0xb0\n [<ffffffff8157d158>] do_IRQ+0x58/0xf0\n [<ffffffff8157b06d>] common_interrupt+0x6d/0x6d\n <EOI>\n [<ffffffff810e1218>] ? hrtimer_start+0x18/0x20\n [<ffffffffa05d65f9>] ? sctp_transport_destroy_rcu+0x29/0x30 [sctp]\n [<ffffffff81020c50>] ? mwait_idle+0x60/0xa0\n [<ffffffff810216ef>] arch_cpu_idle+0xf/0x20\n [<ffffffff810b731c>] cpu_startup_entry+0x3ec/0x480\n [<ffffffff8156b365>] rest_init+0x85/0x90\n [<ffffffff818eb035>] start_kernel+0x48b/0x4ac\n [<ffffffff818ea120>] ? early_idt_handlers+0x120/0x120\n [<ffffffff818ea339>] x86_64_start_reservations+0x2a/0x2c\n [<ffffffff818ea49c>] x86_64_start_kernel+0x161/0x184\nCode: 90 48 8b 80 b8 00 00 00 48 89 85 70 ff ff ff 48 83 bd 70 ff ff ff 00 0f 85 cd fa ff ff 48 89 df 31 db e8 18 63 e7 e0 48 8b 45 80 <48> 8b 40 20 48 8b 40 30 48 8b 80 68 01 00 00 65 48 ff 40 78 e9\nRIP  [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]\n RSP <ffff880127c037b8>\nCR2: 0000000000000020\n---[ end trace 5aec7fd2dc983574 ]---\nKernel panic - not syncing: Fatal exception in interrupt\nKernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)\ndrm_kms_helper: panic occurred, switching back to text console\n---[ end Kernel panic - not syncing: Fatal exception in interrupt\n\nSigned-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>\nAcked-by: Neil Horman <nhorman@tuxdriver.com>\nAcked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>\nAcked-by: Vlad Yasevich <vyasevich@gmail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/artefvck/X_Artefvck/commits/1b24918424a65b595bcb5869131d28c92356b996"},{"sha":"0b6d7fb08438bc3332d16a853f91e85ef56082a7","author":{"email":"6135224f23789828bd8d3b771a2745286516a2b5@freescale.com","name":"Horia Geant?"},"message":"crypto: talitos - avoid memleak in talitos_alg_alloc()\n\ncommit 5fa7dadc898567ce14d6d6d427e7bd8ce6eb5d39 upstream.\n\nFixes: 1d11911a8c57 (\"crypto: talitos - fix warning: 'alg' may be used uninitialized in this function\")\nSigned-off-by: Horia Geanta <horia.geanta@freescale.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/artefvck/X_Artefvck/commits/0b6d7fb08438bc3332d16a853f91e85ef56082a7"},{"sha":"3afe90730b1755c356e4c7d6ea0132308d449341","author":{"email":"6135224f23789828bd8d3b771a2745286516a2b5@freescale.com","name":"Horia Geant?"},"message":"Revert \"crypto: talitos - convert to use be16_add_cpu()\"\n\ncommit 69d9cd8c592f1abce820dbce7181bbbf6812cfbd upstream.\n\nThis reverts commit 7291a932c6e27d9768e374e9d648086636daf61c.\n\nThe conversion to be16_add_cpu() is incorrect in case cryptlen is\nnegative due to premature (i.e. before addition / subtraction)\nimplicit conversion of cryptlen (int -> u16) leading to sign loss.\n\nCc: Wei Yongjun <yongjun_wei@trendmicro.com.cn>\nSigned-off-by: Horia Geanta <horia.geanta@freescale.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/artefvck/X_Artefvck/commits/3afe90730b1755c356e4c7d6ea0132308d449341"},{"sha":"44b639b437d2aec03e0f8542f7430afe489ab827","author":{"email":"a16cc0c82647c52d401177f8e50567df5499e36c@arm.com","name":"Marc Zyngier"},"message":"arm: KVM: force execution of HCPTR access on VM exit\n\ncommit 85e84ba31039595995dae80b277378213602891b upstream.\n\nOn VM entry, we disable access to the VFP registers in order to\nperform a lazy save/restore of these registers.\n\nOn VM exit, we restore access, test if we did enable them before,\nand save/restore the guest/host registers if necessary. In this\nsequence, the FPEXC register is always accessed, irrespective\nof the trapping configuration.\n\nIf the guest didn't touch the VFP registers, then the HCPTR access\nhas now enabled such access, but we're missing a barrier to ensure\narchitectural execution of the new HCPTR configuration. If the HCPTR\naccess has been delayed/reordered, the subsequent access to FPEXC\nwill cause a trap, which we aren't prepared to handle at all.\n\nThe same condition exists when trapping to enable VFP for the guest.\n\nThe fix is to introduce a barrier after enabling VFP access. In the\nvmexit case, it can be relaxed to only takes place if the guest hasn't\naccessed its view of the VFP registers, making the access to FPEXC safe.\n\nThe set_hcptr macro is modified to deal with both vmenter/vmexit and\nvmtrap operations, and now takes an optional label that is branched to\nwhen the guest hasn't touched the VFP registers.\n\nReported-by: Vikram Sethi <vikrams@codeaurora.org>\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/artefvck/X_Artefvck/commits/44b639b437d2aec03e0f8542f7430afe489ab827"},{"sha":"3f695dddcea767793df9856c452355d29e62ef1a","author":{"email":"14deb5e5e417133e888bf47bb6a3555c9bb7d81c@samba.org","name":"Anton Blanchard"},"message":"powerpc/perf: Fix book3s kernel to userspace backtraces\n\ncommit 72e349f1124a114435e599479c9b8d14bfd1ebcd upstream.\n\nWhen we take a PMU exception or a software event we call\nperf_read_regs(). This overloads regs->result with a boolean that\ndescribes if we should use the sampled instruction address register\n(SIAR) or the regs.\n\nIf the exception is in kernel, we start with the kernel regs and\nbacktrace through the kernel stack. At this point we switch to the\nuserspace regs and backtrace the user stack with perf_callchain_user().\n\nUnfortunately these regs have not got the perf_read_regs() treatment,\nso regs->result could be anything. If it is non zero,\nperf_instruction_pointer() decides to use the SIAR, and we get issues\nlike this:\n\n0.11%  qemu-system-ppc  [kernel.kallsyms]        [k] _raw_spin_lock_irqsave\n       |\n       ---_raw_spin_lock_irqsave\n          |\n          |--52.35%-- 0\n          |          |\n          |          |--46.39%-- __hrtimer_start_range_ns\n          |          |          kvmppc_run_core\n          |          |          kvmppc_vcpu_run_hv\n          |          |          kvmppc_vcpu_run\n          |          |          kvm_arch_vcpu_ioctl_run\n          |          |          kvm_vcpu_ioctl\n          |          |          do_vfs_ioctl\n          |          |          sys_ioctl\n          |          |          system_call\n          |          |          |\n          |          |          |--67.08%-- _raw_spin_lock_irqsave <--- hi mum\n          |          |          |          |\n          |          |          |           --100.00%-- 0x7e714\n          |          |          |                     0x7e714\n\nNotice the bogus _raw_spin_irqsave when we transition from kernel\n(system_call) to userspace (0x7e714). We inserted what was in the SIAR.\n\nAdd a check in regs_use_siar() to check that the regs in question\nare from a PMU exception. With this fix the backtrace makes sense:\n\n     0.47%  qemu-system-ppc  [kernel.vmlinux]         [k] _raw_spin_lock_irqsave\n            |\n            ---_raw_spin_lock_irqsave\n               |\n               |--53.83%-- 0\n               |          |\n               |          |--44.73%-- hrtimer_try_to_cancel\n               |          |          kvmppc_start_thread\n               |          |          kvmppc_run_core\n               |          |          kvmppc_vcpu_run_hv\n               |          |          kvmppc_vcpu_run\n               |          |          kvm_arch_vcpu_ioctl_run\n               |          |          kvm_vcpu_ioctl\n               |          |          do_vfs_ioctl\n               |          |          sys_ioctl\n               |          |          system_call\n               |          |          __ioctl\n               |          |          0x7e714\n               |          |          0x7e714\n\nSigned-off-by: Anton Blanchard <anton@samba.org>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/artefvck/X_Artefvck/commits/3f695dddcea767793df9856c452355d29e62ef1a"},{"sha":"998cb3eaaaf3137ce0e28ad5236323ebd5a88aba","author":{"email":"f10ec01be0c6b54271af5c550cd257810bdf3268@google.com","name":"Bjorn Helgaas"},"message":"x86/PCI: Use host bridge _CRS info on Foxconn K8M890-8237A\n\ncommit 1dace0116d0b05c967d94644fc4dfe96be2ecd3d upstream.\n\nThe Foxconn K8M890-8237A has two PCI host bridges, and we can't assign\nresources correctly without the information from _CRS that tells us which\naddress ranges are claimed by which bridge.  In the bugs mentioned below,\nwe incorrectly assign a sound card address (this example is from 1033299):\n\n  bus: 00 index 2 [mem 0x80000000-0xfcffffffff]\n  ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f])\n  pci_root PNP0A08:00: host bridge window [mem 0x80000000-0xbfefffff] (ignored)\n  pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff] (ignored)\n  pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfebfffff] (ignored)\n  ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-ff])\n  pci_root PNP0A08:01: host bridge window [mem 0xbff00000-0xbfffffff] (ignored)\n  pci 0000:80:01.0: [1106:3288] type 0 class 0x000403\n  pci 0000:80:01.0: reg 10: [mem 0xbfffc000-0xbfffffff 64bit]\n  pci 0000:80:01.0: address space collision: [mem 0xbfffc000-0xbfffffff 64bit] conflicts with PCI Bus #00 [mem 0x80000000-0xfcffffffff]\n  pci 0000:80:01.0: BAR 0: assigned [mem 0xfd00000000-0xfd00003fff 64bit]\n  BUG: unable to handle kernel paging request at ffffc90000378000\n  IP: [<ffffffffa0345f63>] azx_create+0x37c/0x822 [snd_hda_intel]\n\nWe assigned 0xfd_0000_0000, but that is not in any of the host bridge\nwindows, and the sound card doesn't work.\n\nTurn on pci=use_crs automatically for this system.\n\nLink: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/931368\nLink: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1033299\nSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/artefvck/X_Artefvck/commits/998cb3eaaaf3137ce0e28ad5236323ebd5a88aba"},{"sha":"5667a358eaf8cbfa92bfeb860ba41518b887c5f6","author":{"email":"547fa85bb3888a0222eed8ec39e36708605c6d53@imgtec.com","name":"James Hogan"},"message":"MIPS: Fix KVM guest fixmap address\n\ncommit 8e748c8d09a9314eedb5c6367d9acfaacddcdc88 upstream.\n\nKVM guest kernels for trap & emulate run in user mode, with a modified\nset of kernel memory segments. However the fixmap address is still in\nthe normal KSeg3 region at 0xfffe0000 regardless, causing problems when\ncache alias handling makes use of them when handling copy on write.\n\nTherefore define FIXADDR_TOP as 0x7ffe0000 in the guest kernel mapped\nregion when CONFIG_KVM_GUEST is defined.\n\nSigned-off-by: James Hogan <james.hogan@imgtec.com>\nCc: linux-mips@linux-mips.org\nPatchwork: https://patchwork.linux-mips.org/patch/9887/\nSigned-off-by: Ralf Baechle <ralf@linux-mips.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/artefvck/X_Artefvck/commits/5667a358eaf8cbfa92bfeb860ba41518b887c5f6"},{"sha":"e26e461c215066deff8dafb4b5755fde608b0a31","author":{"email":"e4aea3f2c531804c57884e1d444a6744efb5af4d@redhat.com","name":"Radim Krčmář"},"message":"KVM: x86: make vapics_in_nmi_mode atomic\n\ncommit 42720138b06301cc8a7ee8a495a6d021c4b6a9bc upstream.\n\nWrites were a bit racy, but hard to turn into a bug at the same time.\n(Particularly because modern Linux doesn't use this feature anymore.)\n\nSigned-off-by: Radim Krčmář <rkrcmar@redhat.com>\n[Actually the next patch makes it much, much easier to trigger the race\n so I'm including this one for stable@ as well. - Paolo]\nSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/artefvck/X_Artefvck/commits/e26e461c215066deff8dafb4b5755fde608b0a31"},{"sha":"78bbbac29af0b10c5af0225c13df84cd7cfa2d26","author":{"email":"596727c8a0ea4db3ba2ceceedccbacd3d7b371b8@suse.cz","name":"Jan Kara"},"message":"fs: Fix S_NOSEC handling\n\ncommit 2426f3910069ed47c0cc58559a6d088af7920201 upstream.\n\nfile_remove_suid() could mistakenly set S_NOSEC inode bit when root was\nmodifying the file. As a result following writes to the file by ordinary\nuser would avoid clearing suid or sgid bits.\n\nFix the bug by checking actual mode bits before setting S_NOSEC.\n\nSigned-off-by: Jan Kara <jack@suse.cz>\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/artefvck/X_Artefvck/commits/78bbbac29af0b10c5af0225c13df84cd7cfa2d26"},{"sha":"8cf46da51a2ae3af139833b9bbe8fa9840296a88","author":{"email":"4645f7897fd33786a2ee1264d590b3c400559d85@linuxfoundation.org","name":"Greg Kroah-Hartman"},"message":"Linux 3.10.84","distinct":true,"url":"https://api.github.com/repos/artefvck/X_Artefvck/commits/8cf46da51a2ae3af139833b9bbe8fa9840296a88"}]}