{"push_id":1749404518,"size":1000,"distinct_size":2,"ref":"refs/heads/comment","head":"ae46aa7cd1873af4d0ef98dfdd1bd34d955450fa","before":"05791954c3a7e0648f1248153bf77f25d18d663a","commits":[{"sha":"d5ff5061c35448525fcb38950f06af6b9ae12c04","author":{"name":"Stefano Stabellini","email":"9544b95d34ae1db891f97d14750985597484f7b4@kernel.org"},"message":"xen/arm,arm64: rename __generic_dma_ops to xen_get_dma_ops\n\nNow that __generic_dma_ops is a xen specific function, rename it to\nxen_get_dma_ops. Change all the call sites appropriately.\n\nSigned-off-by: Stefano Stabellini <sstabellini@kernel.org>\nReviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nAcked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\nCC: linux@armlinux.org.uk\nCC: catalin.marinas@arm.com\nCC: will.deacon@arm.com\nCC: boris.ostrovsky@oracle.com\nCC: jgross@suse.com\nCC: Julien Grall <julien.grall@arm.com>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/d5ff5061c35448525fcb38950f06af6b9ae12c04"},{"sha":"6483e3135a693548874429db901c0544d3a9b4cd","author":{"name":"Geliang Tang","email":"bd74e8ca27341f584803a5a1f60187557a0aa095@gmail.com"},"message":"xen/scsifront: use offset_in_page() macro\n\nUse offset_in_page() macro instead of open-coding.\n\nSigned-off-by: Geliang Tang <geliangtang@gmail.com>\nReviewed-by: Juergen Gross <jgross@suse.com>\nSigned-off-by: Juergen Gross <jgross@suse.com>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/6483e3135a693548874429db901c0544d3a9b4cd"},{"sha":"5f6a1614fab801834e32b420b60acdc27acfcdec","author":{"name":"Boris Ostrovsky","email":"8d8eed10c3f35eaa3a548daad1882614e248ed99@oracle.com"},"message":"xen/pvh: Do not fill kernel's e820 map in init_pvh_bootparams()\n\ne820 map is updated with information from the zeropage (i.e. pvh_bootparams)\nby default_machine_specific_memory_setup(). With the way things are done\nnow,  we end up with a duplicated e820 map.\n\nSigned-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nReviewed-by: Juergen Gross <jgross@suse.com>\nSigned-off-by: Juergen Gross <jgross@suse.com>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/5f6a1614fab801834e32b420b60acdc27acfcdec"},{"sha":"84d582d236dc1f9085e741affc72e9ba061a67c2","author":{"name":"Boris Ostrovsky","email":"8d8eed10c3f35eaa3a548daad1882614e248ed99@oracle.com"},"message":"xen: Revert commits da72ff5bfcb0 and 72a9b186292d\n\nRecent discussion (http://marc.info/?l=xen-devel&m=149192184523741)\nestablished that commit 72a9b186292d (\"xen: Remove event channel\nnotification through Xen PCI platform device\") (and thus commit\nda72ff5bfcb0 (\"partially revert \"xen: Remove event channel\nnotification through Xen PCI platform device\"\")) are unnecessary and,\nin fact, prevent HVM guests from booting on Xen releases prior to 4.0\n\nTherefore we revert both of those commits.\n\nThe summary of that discussion is below:\n\n  Here is the brief summary of the current situation:\n\n  Before the offending commit (72a9b186292):\n\n  1) INTx does not work because of the reset_watches path.\n  2) The reset_watches path is only taken if you have Xen > 4.0\n  3) The Linux Kernel by default will use vector inject if the hypervisor\n     support. So even INTx does not work no body running the kernel with\n     Xen > 4.0 would notice. Unless he explicitly disabled this feature\n     either in the kernel or in Xen (and this can only be disabled by\n     modifying the code, not user-supported way to do it).\n\n  After the offending commit (+ partial revert):\n\n  1) INTx is no longer support for HVM (only for PV guests).\n  2) Any HVM guest The kernel will not boot on Xen < 4.0 which does\n     not have vector injection support. Since the only other mode\n     supported is INTx which.\n\n  So based on this summary, I think before commit (72a9b186292) we were\n  in much better position from a user point of view.\n\nSigned-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nReviewed-by: Juergen Gross <jgross@suse.com>\nSigned-off-by: Juergen Gross <jgross@suse.com>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/84d582d236dc1f9085e741affc72e9ba061a67c2"},{"sha":"f31b969217b42df605b2e0e64aa6b3e03e781a4f","author":{"name":"Boris Ostrovsky","email":"8d8eed10c3f35eaa3a548daad1882614e248ed99@oracle.com"},"message":"xen/x86: Call xen_smp_intr_init_pv() on BSP\n\nRecent code rework that split handling ov PV, HVM and PVH guests into\nseparate files missed calling xen_smp_intr_init_pv() on CPU0.\n\nAdd this call.\n\nSigned-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nReported-by: Sander Eikelenboom <linux@eikelenboom.it>\nSigned-off-by: Juergen Gross <jgross@suse.com>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/f31b969217b42df605b2e0e64aa6b3e03e781a4f"},{"sha":"5d9404e1185de8d508cd042761306495f727d7eb","author":{"name":"Julien Grall","email":"0460a59ae5383817b5074239c81e847df6531cb1@arm.com"},"message":"xen: Export xen_reboot\n\nThe helper xen_reboot will be called by the EFI code in a later patch.\n\nNote that the ARM version does not yet exist and will be added in a\nlater patch too.\n\nSigned-off-by: Julien Grall <julien.grall@arm.com>\nSigned-off-by: Juergen Gross <jgross@suse.com>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/5d9404e1185de8d508cd042761306495f727d7eb"},{"sha":"fa12a870a9d594ba458242a04a4d17a76fc816a4","author":{"name":"Julien Grall","email":"0460a59ae5383817b5074239c81e847df6531cb1@arm.com"},"message":"arm/xen: Consolidate calls to shutdown hypercall in a single helper\n\nSigned-off-by: Julien Grall <julien.grall@arm.com>\nSigned-off-by: Juergen Gross <jgross@suse.com>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/fa12a870a9d594ba458242a04a4d17a76fc816a4"},{"sha":"e371fd7607999fabbd955b4d22c8e912594a7997","author":{"name":"Julien Grall","email":"0460a59ae5383817b5074239c81e847df6531cb1@arm.com"},"message":"xen: Implement EFI reset_system callback\n\nWhen rebooting DOM0 with ACPI on ARM64, the kernel is crashing with the stack\ntrace [1].\n\nThis is happening because when EFI runtimes are enabled, the reset code\n(see machine_restart) will first try to use EFI restart method.\n\nHowever, the EFI restart code is expecting the reset_system callback to\nbe always set. This is not the case for Xen and will lead to crash.\n\nThe EFI restart helper is used in multiple places and some of them don't\nnot have fallback (see machine_power_off). So implement reset_system\ncallback as a call to xen_reboot when using EFI Xen.\n\n[   36.999270] reboot: Restarting system\n[   37.002921] Internal error: Attempting to execute userspace memory: 86000004 [#1] PREEMPT SMP\n[   37.011460] Modules linked in:\n[   37.014598] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.11.0-rc1-00003-g1e248b60a39b-dirty #506\n[   37.023903] Hardware name: (null) (DT)\n[   37.027734] task: ffff800902068000 task.stack: ffff800902064000\n[   37.033739] PC is at 0x0\n[   37.036359] LR is at efi_reboot+0x94/0xd0\n[   37.040438] pc : [<0000000000000000>] lr : [<ffff00000880f2c4>] pstate: 404001c5\n[   37.047920] sp : ffff800902067cf0\n[   37.051314] x29: ffff800902067cf0 x28: ffff800902068000\n[   37.056709] x27: ffff000008992000 x26: 000000000000008e\n[   37.062104] x25: 0000000000000123 x24: 0000000000000015\n[   37.067499] x23: 0000000000000000 x22: ffff000008e6e250\n[   37.072894] x21: ffff000008e6e000 x20: 0000000000000000\n[   37.078289] x19: ffff000008e5d4c8 x18: 0000000000000010\n[   37.083684] x17: 0000ffffa7c27470 x16: 00000000deadbeef\n[   37.089079] x15: 0000000000000006 x14: ffff000088f42bef\n[   37.094474] x13: ffff000008f42bfd x12: ffff000008e706c0\n[   37.099870] x11: ffff000008e70000 x10: 0000000005f5e0ff\n[   37.105265] x9 : ffff800902067a50 x8 : 6974726174736552\n[   37.110660] x7 : ffff000008cc6fb8 x6 : ffff000008cc6fb0\n[   37.116055] x5 : ffff000008c97dd8 x4 : 0000000000000000\n[   37.121453] x3 : 0000000000000000 x2 : 0000000000000000\n[   37.126845] x1 : 0000000000000000 x0 : 0000000000000000\n[   37.132239]\n[   37.133808] Process systemd-shutdow (pid: 1, stack limit = 0xffff800902064000)\n[   37.141118] Stack: (0xffff800902067cf0 to 0xffff800902068000)\n[   37.146949] 7ce0:                                   ffff800902067d40 ffff000008085334\n[   37.154869] 7d00: 0000000000000000 ffff000008f3b000 ffff800902067d40 ffff0000080852e0\n[   37.162787] 7d20: ffff000008cc6fb0 ffff000008cc6fb8 ffff000008c7f580 ffff000008c97dd8\n[   37.170706] 7d40: ffff800902067d60 ffff0000080e2c2c 0000000000000000 0000000001234567\n[   37.178624] 7d60: ffff800902067d80 ffff0000080e2ee8 0000000000000000 ffff0000080e2df4\n[   37.186544] 7d80: 0000000000000000 ffff0000080830f0 0000000000000000 00008008ff1c1000\n[   37.194462] 7da0: ffffffffffffffff 0000ffffa7c4b1cc 0000000000000000 0000000000000024\n[   37.202380] 7dc0: ffff800902067dd0 0000000000000005 0000fffff24743c8 0000000000000004\n[   37.210299] 7de0: 0000fffff2475f03 0000000000000010 0000fffff2474418 0000000000000005\n[   37.218218] 7e00: 0000fffff2474578 000000000000000a 0000aaaad6b722c0 0000000000000001\n[   37.226136] 7e20: 0000000000000123 0000000000000038 ffff800902067e50 ffff0000081e7294\n[   37.234055] 7e40: ffff800902067e60 ffff0000081e935c ffff800902067e60 ffff0000081e9388\n[   37.241973] 7e60: ffff800902067eb0 ffff0000081ea388 0000000000000000 00008008ff1c1000\n[   37.249892] 7e80: ffffffffffffffff 0000ffffa7c4a79c 0000000000000000 ffff000000020000\n[   37.257810] 7ea0: 0000010000000004 0000000000000000 0000000000000000 ffff0000080830f0\n[   37.265729] 7ec0: fffffffffee1dead 0000000028121969 0000000001234567 0000000000000000\n[   37.273651] 7ee0: ffffffffffffffff 8080000000800000 0000800000008080 feffa9a9d4ff2d66\n[   37.281567] 7f00: 000000000000008e feffa9a9d5b60e0f 7f7fffffffff7f7f 0101010101010101\n[   37.289485] 7f20: 0000000000000010 0000000000000008 000000000000003a 0000ffffa7ccf588\n[   37.297404] 7f40: 0000aaaad6b87d00 0000ffffa7c4b1b0 0000fffff2474be0 0000aaaad6b88000\n[   37.305326] 7f60: 0000fffff2474fb0 0000000001234567 0000000000000000 0000000000000000\n[   37.313240] 7f80: 0000000000000000 0000000000000001 0000aaaad6b70d4d 0000000000000000\n[   37.321159] 7fa0: 0000000000000001 0000fffff2474ea0 0000aaaad6b5e2e0 0000fffff2474e80\n[   37.329078] 7fc0: 0000ffffa7c4b1cc 0000000000000000 fffffffffee1dead 000000000000008e\n[   37.336997] 7fe0: 0000000000000000 0000000000000000 9ce839cffee77eab fafdbf9f7ed57f2f\n[   37.344911] Call trace:\n[   37.347437] Exception stack(0xffff800902067b20 to 0xffff800902067c50)\n[   37.353970] 7b20: ffff000008e5d4c8 0001000000000000 0000000080f82000 0000000000000000\n[   37.361883] 7b40: ffff800902067b60 ffff000008e17000 ffff000008f44c68 00000001081081b4\n[   37.369802] 7b60: ffff800902067bf0 ffff000008108478 0000000000000000 ffff000008c235b0\n[   37.377721] 7b80: ffff800902067ce0 0000000000000000 0000000000000000 0000000000000015\n[   37.385643] 7ba0: 0000000000000123 000000000000008e ffff000008992000 ffff800902068000\n[   37.393557] 7bc0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000\n[   37.401477] 7be0: 0000000000000000 ffff000008c97dd8 ffff000008cc6fb0 ffff000008cc6fb8\n[   37.409396] 7c00: 6974726174736552 ffff800902067a50 0000000005f5e0ff ffff000008e70000\n[   37.417318] 7c20: ffff000008e706c0 ffff000008f42bfd ffff000088f42bef 0000000000000006\n[   37.425234] 7c40: 00000000deadbeef 0000ffffa7c27470\n[   37.430190] [<          (null)>]           (null)\n[   37.434982] [<ffff000008085334>] machine_restart+0x6c/0x70\n[   37.440550] [<ffff0000080e2c2c>] kernel_restart+0x6c/0x78\n[   37.446030] [<ffff0000080e2ee8>] SyS_reboot+0x130/0x228\n[   37.451337] [<ffff0000080830f0>] el0_svc_naked+0x24/0x28\n[   37.456737] Code: bad PC value\n[   37.459891] ---[ end trace 76e2fc17e050aecd ]---\n\nSigned-off-by: Julien Grall <julien.grall@arm.com>\n\n--\n\nCc: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nCc: Juergen Gross <jgross@suse.com>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Ingo Molnar <mingo@redhat.com>\nCc: \"H. Peter Anvin\" <hpa@zytor.com>\nCc: x86@kernel.org\n\nThe x86 code has theoritically a similar issue, altought EFI does not\nseem to be the preferred method. I have only built test it on x86.\n\nThis should also probably be fixed in stable tree.\n\n    Changes in v2:\n        - Implement xen_efi_reset_system using xen_reboot\n        - Move xen_efi_reset_system in drivers/xen/efi.c\nSigned-off-by: Juergen Gross <jgross@suse.com>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/e371fd7607999fabbd955b4d22c8e912594a7997"},{"sha":"45f580c42e5c125d55dbd8099750a1998de3d917","author":{"name":"Maksim Salau","email":"c32685a6b3af0291fdc3b5b1fe95084394006ba8@gmail.com"},"message":"video: fbdev: udlfb: Fix buffer on stack\n\nAllocate buffers on HEAP instead of STACK for local array\nthat is to be sent using usb_control_msg().\n\nSigned-off-by: Maksim Salau <maksim.salau@gmail.com>\nCc: Bernie Thompson <bernie@plugable.com>\nCc: Geert Uytterhoeven <geert@linux-m68k.org>\nSigned-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/45f580c42e5c125d55dbd8099750a1998de3d917"},{"sha":"dc85e9a87420613b3129d5cc5ecd79c58351c546","author":{"name":"Alexey Khoroshilov","email":"ace9a61ddd722b948531d2d4c78db504ebfc9f1b@ispras.ru"},"message":"sm501fb: don't return zero on failure path in sm501fb_start()\n\nIf fbmem iomemory mapping failed, sm501fb_start() breaks off\ninitialization, deallocates resources, but returns zero.\nAs a result, double deallocation can happen in sm501fb_stop().\n\nFound by Linux Driver Verification project (linuxtesting.org).\n\nSigned-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>\nCc: Tomi Valkeinen <tomi.valkeinen@ti.com>\nSigned-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/dc85e9a87420613b3129d5cc5ecd79c58351c546"},{"sha":"5c9cfda13dc503f4b25b486a57974e0414adb6f1","author":{"name":"Karim Eshapa","email":"932f557868e7e39dad0daa431dd87c565213cad6@gmail.com"},"message":"drivers/video/fbdev/omap/lcd_mipid.c: Use time comparison kernel macros\n\nUse time_before_eq time comparison defind kernel macro\nthat has safety check.\n\nSigned-off-by: Karim Eshapa <karim.eshapa@gmail.com>\nCc: Tomi Valkeinen <tomi.valkeinen@ti.com>\nSigned-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/5c9cfda13dc503f4b25b486a57974e0414adb6f1"},{"sha":"ea9a26d117cf0637c71d3e0076f4a124bf5859df","author":{"name":"Vaibhav Jain","email":"73e733f54aec8147bb41865f6b4b9148827fbae7@linux.vnet.ibm.com"},"message":"cxl: Force context lock during EEH flow\n\nDuring an eeh event when the cxl card is fenced and card sysfs attr\nperst_reloads_same_image is set following warning message is seen in the\nkernel logs:\n\n  Adapter context unlocked with 0 active contexts\n  ------------[ cut here ]------------\n  WARNING: CPU: 12 PID: 627 at\n  ../drivers/misc/cxl/main.c:325 cxl_adapter_context_unlock+0x60/0x80 [cxl]\n\nEven though this warning is harmless, it clutters the kernel log\nduring an eeh event. This warning is triggered as the EEH callback\ncxl_pci_error_detected doesn't obtain a context-lock before forcibly\ndetaching all active context and when context-lock is released during\ncall to cxl_configure_adapter from cxl_pci_slot_reset, a warning in\ncxl_adapter_context_unlock is triggered.\n\nTo fix this warning, we acquire the adapter context-lock via\ncxl_adapter_context_lock() in the eeh callback\ncxl_pci_error_detected() once all the virtual AFU PHBs are notified\nand their contexts detached. The context-lock is released in\ncxl_pci_slot_reset() after the adapter is successfully reconfigured\nand before the we call the slot_reset callback on slice attached\ndevice-drivers.\n\nFixes: 70b565bbdb91 (\"cxl: Prevent adapter reset if an active context exists\")\nCc: stable@vger.kernel.org # v4.9+\nReported-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>\nSigned-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>\nAcked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>\nReviewed-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>\nTested-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/ea9a26d117cf0637c71d3e0076f4a124bf5859df"},{"sha":"4f58f0bf155e87dda31a3088b1e107fa9dd79f0e","author":{"name":"Vaibhav Jain","email":"73e733f54aec8147bb41865f6b4b9148827fbae7@linux.vnet.ibm.com"},"message":"cxl: Route eeh events to all drivers in cxl_pci_error_detected()\n\nFix a boundary condition where in some cases an eeh event that results\nin card reset isn't passed on to a driver attached to the virtual PCI\ndevice associated with a slice. This will happen in case when a slice\nattached device driver returns a value other than\nPCI_ERS_RESULT_NEED_RESET from the eeh error_detected() callback. This\nwould result in an early return from cxl_pci_error_detected() and\nother drivers attached to other AFUs on the card wont be notified.\n\nThe patch fixes this by making sure that all slice attached\ndevice-drivers are notified and the return values from\nerror_detected() callback are aggregated in a scheme where request for\n'disconnect' trumps all and 'none' trumps 'need_reset'.\n\nFixes: 9e8df8a21963 (\"cxl: EEH support\")\nCc: stable@vger.kernel.org # v4.3+\nSigned-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>\nReviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>\nAcked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/4f58f0bf155e87dda31a3088b1e107fa9dd79f0e"},{"sha":"a715626a8e904e7226915d1bc4885317ea9da141","author":{"name":"Alastair D'Silva","email":"f85ea65b016700ba7d82ef8b7cc7909be6b39b15@d-silva.org"},"message":"cxl: Mask slice error interrupts after first occurrence\n\nIn some situations, a faulty AFU slice may create an interrupt storm of\nslice errors, rendering the machine unusable. Since these interrupts are\ninformational only, present the interrupt once, then mask it off to\nprevent it from being retriggered until the AFU is reset.\n\nSigned-off-by: Alastair D'Silva <alastair@d-silva.org>\nReviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>\nReviewed-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>\nAcked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/a715626a8e904e7226915d1bc4885317ea9da141"},{"sha":"daeba2956f32f91f3493788ff6ee02fb1b2f02fa","author":{"name":"Russell Currey","email":"2eacafec92f559d51886f12bbdf842327b6af83e@russell.cc"},"message":"powerpc/eeh: Avoid use after free in eeh_handle_special_event()\n\neeh_handle_special_event() is called when an EEH event is detected but\ncan't be narrowed down to a specific PE.  This function looks through\nevery PE to find one in an erroneous state, then calls the regular event\nhandler eeh_handle_normal_event() once it knows which PE has an error.\n\nHowever, if eeh_handle_normal_event() found that the PE cannot possibly\nbe recovered, it will free it, rendering the passed PE stale.\nThis leads to a use after free in eeh_handle_special_event() as it attempts to\nclear the \"recovering\" state on the PE after eeh_handle_normal_event() returns.\n\nThus, make sure the PE is valid when attempting to clear state in\neeh_handle_special_event().\n\nFixes: 8a6b1bc70dbb (\"powerpc/eeh: EEH core to handle special event\")\nCc: stable@vger.kernel.org # v3.11+\nReported-by: Alexey Kardashevskiy <aik@ozlabs.ru>\nSigned-off-by: Russell Currey <ruscur@russell.cc>\nReviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/daeba2956f32f91f3493788ff6ee02fb1b2f02fa"},{"sha":"c0b64978f09195e00d6649ca0ad0242a80e6e99a","author":{"name":"Russell Currey","email":"2eacafec92f559d51886f12bbdf842327b6af83e@russell.cc"},"message":"powerpc/eeh: Clean up and document event handling functions\n\nRemove unnecessary tags in eeh_handle_normal_event(), and add function\ncomments for eeh_handle_normal_event() and eeh_handle_special_event().\n\nThe only functional difference is that in the case of a PE reaching the\nmaximum number of failures, rather than one message telling you of this\nand suggesting you reseat the device, there are two separate messages.\n\nSuggested-by: Alexey Kardashevskiy <aik@ozlabs.ru>\nSigned-off-by: Russell Currey <ruscur@russell.cc>\nReviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>\nReviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/c0b64978f09195e00d6649ca0ad0242a80e6e99a"},{"sha":"5c0aea0e8d98e38858fbb3a09870ed8487a01da2","author":{"name":"David Hildenbrand","email":"d8099b0f90e53c29d29eb12a7a3caa5af4f12681@redhat.com"},"message":"KVM: x86: don't hold kvm->lock in KVM_SET_GSI_ROUTING\n\nWe needed the lock to avoid racing with creation of the irqchip on x86. As\nkvm_set_irq_routing() calls srcu_synchronize_expedited(), this lock\nmight be held for a longer time.\n\nLet's introduce an arch specific callback to check if we can actually\nadd irq routes. For x86, all we have to do is check if we have an\nirqchip in the kernel. We don't need kvm->lock at that point as the\nirqchip is marked as inititalized only when actually fully created.\n\nReported-by: Steve Rutherford <srutherford@google.com>\nReviewed-by: Radim Krčmář <rkrcmar@redhat.com>\nFixes: 1df6ddede10a (\"KVM: x86: race between KVM_SET_GSI_ROUTING and KVM_CREATE_IRQCHIP\")\nSigned-off-by: David Hildenbrand <david@redhat.com>\nSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/5c0aea0e8d98e38858fbb3a09870ed8487a01da2"},{"sha":"45753c5f315749711b935a2506ee5c10eef5c23d","author":{"name":"Ingo Molnar","email":"90e4d1e8f219066a3d31774bfa42a254ac6b5b82@kernel.org"},"message":"srcu: Debloat the <linux/rcu_segcblist.h> header\n\nLinus noticed that the <linux/rcu_segcblist.h> has huge inline functions\nwhich should not be inline at all.\n\nAs a first step in cleaning this up, move them all to kernel/rcu/ and\nonly keep an absolute minimum of data type defines in the header:\n\n  before:   -rw-r--r-- 1 mingo mingo 22284 May  2 10:25 include/linux/rcu_segcblist.h\n   after:   -rw-r--r-- 1 mingo mingo  3180 May  2 10:22 include/linux/rcu_segcblist.h\n\nMore can be done, such as uninlining the large functions, which inlining\nis unjustified even if it's an RCU internal matter.\n\nReported-by: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/45753c5f315749711b935a2506ee5c10eef5c23d"},{"sha":"c0332694903a37cf8ecdc9102d5c9e09cf8643d0","author":{"name":"Bart Van Assche","email":"b8a13ad2fc8473e67a34a68acf4216fb1fa3477b@sandisk.com"},"message":"block: Remove elevator_change()\n\nSince commit 84253394927c (\"remove the mg_disk driver\") removed the\nonly caller of elevator_change(), also remove the elevator_change()\nfunction itself.\n\nSigned-off-by: Bart Van Assche <bart.vanassche@sandisk.com>\nCc: Christoph Hellwig <hch@lst.de>\nCc: Markus Trippelsdorf <markus@trippelsdorf.de>\nSigned-off-by: Jens Axboe <axboe@fb.com>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/c0332694903a37cf8ecdc9102d5c9e09cf8643d0"},{"sha":"0f6422a2c57c6afcf66ead903dc3fa6641184aa4","author":{"name":"Jens Axboe","email":"f8b120bbe297304053fa957b507156696820d130@fb.com"},"message":"mtip32xx: get rid of 'atomic' argument to mtip_exec_internal_command()\n\nAll callers can safely block. Kill the atomic/block argument, and\nremove the argument from all callers.\n\nReviewed-by: Bart Van Assche <Bart.VanAssche@sandisk.com>\nReviewed-by: Christoph Hellwig <hch@lst.de>\nTested-by: Ming Lei <ming.lei@redhat.com>\nSigned-off-by: Jens Axboe <axboe@fb.com>","distinct":false,"url":"https://api.github.com/repos/rocklee104/linux/commits/0f6422a2c57c6afcf66ead903dc3fa6641184aa4"}]}
{"actor":{"display_login":"rocklee104"}}