{"push_id":1412021887,"size":4,"distinct_size":0,"ref":"refs/heads/caf/3.10/caf/korg/linux-3.18.y","head":"a6846cfd266b48af1ee7c3c19d5cb60477ca4469","before":"3cab355c2ff3a781b6ebe9d1a25bd4ebc1207430","commits":[{"sha":"e45a502bdeae5a075257c4f061d1ff4ff0821354","author":{"name":"Linus Torvalds","email":"ead7104581934751970e9decb2db5deb20a9e407@linux-foundation.org"},"message":"mm: remove gup_flags FOLL_WRITE games from __get_user_pages()\n\n[ Upstream commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 ]\n\nThis is an ancient bug that was actually attempted to be fixed once\n(badly) by me eleven years ago in commit 4ceb5db9757a (\"Fix\nget_user_pages() race for write access\") but that was then undone due to\nproblems on s390 by commit f33ea7f404e5 (\"fix get_user_pages bug\").\n\nIn the meantime, the s390 situation has long been fixed, and we can now\nfix it by checking the pte_dirty() bit properly (and do it better).  The\ns390 dirty bit was implemented in abf09bed3cce (\"s390/mm: implement\nsoftware dirty bits\") which made it into v3.9.  Earlier kernels will\nhave to look at the page state itself.\n\nAlso, the VM has become more scalable, and what used a purely\ntheoretical race back then has become easier to trigger.\n\nTo fix it, we introduce a new internal FOLL_COW flag to mark the \"yes,\nwe already did a COW\" rather than play racy games with FOLL_WRITE that\nis very fundamental, and then use the pte dirty flag to validate that\nthe FOLL_COW flag is still valid.\n\nReported-and-tested-by: Phil \"not Paul\" Oester <kernel@linuxace.com>\nAcked-by: Hugh Dickins <hughd@google.com>\nReviewed-by: Michal Hocko <mhocko@suse.com>\nCc: Andy Lutomirski <luto@kernel.org>\nCc: Kees Cook <keescook@chromium.org>\nCc: Oleg Nesterov <oleg@redhat.com>\nCc: Willy Tarreau <w@1wt.eu>\nCc: Nick Piggin <npiggin@gmail.com>\nCc: Greg Thelen <gthelen@google.com>\nCc: stable@vger.kernel.org\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Sasha Levin <alexander.levin@verizon.com>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/e45a502bdeae5a075257c4f061d1ff4ff0821354"},{"sha":"bb2f5ed8935a47f78a70ac48e58e993de46430e0","author":{"name":"Andrew Cooper","email":"ce6e7acce1f5d55db389f61db68b4ce33f3ea3e3@citrix.com"},"message":"x86/cpu: Fix SMAP check in PVOPS environments\n\n[ Upstream commit 581b7f158fe0383b492acd1ce3fb4e99d4e57808 ]\n\nThere appears to be no formal statement of what pv_irq_ops.save_fl() is\nsupposed to return precisely.  Native returns the full flags, while lguest and\nXen only return the Interrupt Flag, and both have comments by the\nimplementations stating that only the Interrupt Flag is looked at.  This may\nhave been true when initially implemented, but no longer is.\n\nTo make matters worse, the Xen PVOP leaves the upper bits undefined, making\nthe BUG_ON() undefined behaviour.  Experimentally, this now trips for 32bit PV\nguests on Broadwell hardware.  The BUG_ON() is consistent for an individual\nbuild, but not consistent for all builds.  It has also been a sitting timebomb\nsince SMAP support was introduced.\n\nUse native_save_fl() instead, which will obtain an accurate view of the AC\nflag.\n\nSigned-off-by: Andrew Cooper <andrew.cooper3@citrix.com>\nReviewed-by: David Vrabel <david.vrabel@citrix.com>\nTested-by: Rusty Russell <rusty@rustcorp.com.au>\nCc: Rusty Russell <rusty@rustcorp.com.au>\nCc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\nCc: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nCc: <lguest@lists.ozlabs.org>\nCc: Xen-devel <xen-devel@lists.xen.org>\nCC: stable@vger.kernel.org\nLink: http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.cooper3@citrix.com\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Sasha Levin <alexander.levin@verizon.com>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/bb2f5ed8935a47f78a70ac48e58e993de46430e0"},{"sha":"c003797af3bc3b267a262b4d28ca06efc80390d4","author":{"name":"Mathias Nyman","email":"6f76a2d91b00c1a813d5588fd87cc784fe96486e@linux.intel.com"},"message":"xhci: fix usb2 resume timing and races.\n\n[ Upstream commit f69115fdbc1ac0718e7d19ad3caa3da2ecfe1c96 ]\n\nAccording to USB 2 specs ports need to signal resume for at least 20ms,\nin practice even longer, before moving to U0 state.\nBoth host and devices can initiate resume.\n\nOn device initiated resume, a port status interrupt with the port in resume\nstate in issued. The interrupt handler tags a resume_done[port]\ntimestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer.\nRoot hub timer requests for port status, finds the port in resume state,\nchecks if resume_done[port] timestamp passed, and set port to U0 state.\n\nOn host initiated resume, current code sets the port to resume state,\nsleep 20ms, and finally sets the port to U0 state. This should also\nbe changed to work in a similar way as the device initiated resume, with\ntimestamp tagging, but that is not yet tested and will be a separate\nfix later.\n\nThere are a few issues with this approach\n\n1. A host initiated resume will also generate a resume event. The event\n   handler will find the port in resume state, believe it's a device\n   initiated resume, and act accordingly.\n\n2. A port status request might cut the resume signalling short if a\n   get_port_status request is handled during the host resume signalling.\n   The port will be found in resume state. The timestamp is not set leading\n   to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0.\n   get_port_status will proceed with moving the port to U0.\n\n3. If an error, or anything else happens to the port during device\n   initiated resume signalling it will leave all the device resume\n   parameters hanging uncleared, preventing further suspend, returning\n   -EBUSY, and cause the pm thread to busyloop trying to enter suspend.\n\nFix this by using the existing resuming_ports bitfield to indicate that\nresume signalling timing is taken care of.\nCheck if the resume_done[port] is set before using it for timestamp\ncomparison, and also clear out any resume signalling related variables\nif port is not in U0 or Resume state\n\nThis issue was discovered when a PM thread busylooped, trying to runtime\nsuspend the xhci USB 2 roothub on a Dell XPS\n\nCc: stable <stable@vger.kernel.org>\nReported-by: Daniel J Blueman <daniel@quora.org>\nTested-by: Daniel J Blueman <daniel@quora.org>\nSigned-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Sasha Levin <alexander.levin@verizon.com>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/c003797af3bc3b267a262b4d28ca06efc80390d4"},{"sha":"a6846cfd266b48af1ee7c3c19d5cb60477ca4469","author":{"name":"Sasha Levin","email":"21b3700b83417709f72331cfb49b49e6145a3cad@verizon.com"},"message":"Linux 3.18.44\n\nSigned-off-by: Sasha Levin <alexander.levin@verizon.com>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/a6846cfd266b48af1ee7c3c19d5cb60477ca4469"}]}
{"actor":{"display_login":"dianlujitao"}}