{"push_id":1238425912,"size":3,"distinct_size":3,"ref":"refs/heads/temp","head":"4f3d128ea6beff676f2c084fa1501585933eee74","before":"45f5fd1e0d4b35a0d1fa3e9702ecd2a5f9409407","commits":[{"sha":"6f645429be362d653e7119f113890921d30967ab","author":{"name":"Linus Torvalds","email":"ead7104581934751970e9decb2db5deb20a9e407@linux-foundation.org"},"message":"Fix blocking allocations called very early during bootup\n\nDuring early boot, when the scheduler hasn't really been fully set up,\nwe really can't do blocking allocations because with certain (dubious)\nconfigurations the \"might_resched()\" calls can actually result in\nscheduling events.\n\nWe could just make such users always use GFP_ATOMIC, but quite often the\ncode that does the allocation isn't really aware of the fact that the\nscheduler isn't up yet, and forcing that kind of random knowledge on the\ninitialization code is just annoying and not good for anybody.\n\nAnd we actually have a the 'gfp_allowed_mask' exactly for this reason:\nit's just that the kernel init sequence happens to set it to allow\nblocking allocations much too early.\n\nSo move the 'gfp_allowed_mask' initialization from 'start_kernel()'\n(which is some of the earliest init code, and runs with preemption\ndisabled for good reasons) into 'kernel_init()'.  kernel_init() is run\nin the newly created thread that will become the 'init' process, as\nopposed to the early startup code that runs within the context of what\nwill be the first idle thread.\n\nSo by the time we reach 'kernel_init()', we know that the scheduler must\nbe at least limping along, because we've already scheduled from the idle\nthread into the init thread.\n\nReported-by: Steven Rostedt <rostedt@goodmis.org>\nCc: David Rientjes <rientjes@google.com>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/tunturn/z3kernel/commits/6f645429be362d653e7119f113890921d30967ab"},{"sha":"1d8e13d8e936cb811086b57f9f2a2cc1f574c1a5","author":{"name":"Viresh Kumar","email":"4ca49bc1dcfdfc376d29da1eb07a3e0b3cd46daa@linaro.org"},"message":"cpufreq: Manage only online cpus\n\ncpufreq core doesn't manage offline cpus and if driver->init() has returned\nmask including offline cpus, it may result in unwanted behavior by cpufreq core\nor governors.\n\nWe need to get only online cpus in this mask. There are two places to fix this\nmask, cpufreq core and cpufreq driver. It makes sense to do this at common place\nand hence is done in core.\n\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/tunturn/z3kernel/commits/1d8e13d8e936cb811086b57f9f2a2cc1f574c1a5"},{"sha":"4f3d128ea6beff676f2c084fa1501585933eee74","author":{"name":"imoseyon","email":"10a51fa76245a6d62993b9f678997023cca4f98d@gmail.com"},"message":"cpufreq: force cpuN policy to match cpu0 when changing freq or gov","distinct":true,"url":"https://api.github.com/repos/tunturn/z3kernel/commits/4f3d128ea6beff676f2c084fa1501585933eee74"}]}
{"actor":{"display_login":"tunturn"}}