)]}' { "commit": "3f2dc2798b81531fd93a3b9b7c39da47ec689e55", "tree": "075660db24621f4be8e24882bcaa88e15bc797f4", "parents": [ "a3c0e7b1fe1fc62bba5f591c4bc404eea96823b8", "02f03c4206c1b2a7451d3b3546f86c9c783eac13" ], "author": { "name": "Linus Torvalds", "email": "torvalds@linux-foundation.org", "time": "Sun Sep 29 19:25:39 2019 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@linux-foundation.org", "time": "Sun Sep 29 19:25:39 2019 -0700" }, "message": "Merge branch \u0027entropy\u0027\n\nMerge active entropy generation updates.\n\nThis is admittedly partly \"for discussion\". We need to have a way\nforward for the boot time deadlocks where user space ends up waiting for\nmore entropy, but no entropy is forthcoming because the system is\nentirely idle just waiting for something to happen.\n\nWhile this was triggered by what is arguably a user space bug with\nGDM/gnome-session asking for secure randomness during early boot, when\nthey didn\u0027t even need any such truly secure thing, the issue ends up\nbeing that our \"getrandom()\" interface is prone to that kind of\nconfusion, because people don\u0027t think very hard about whether they want\nto block for sufficient amounts of entropy.\n\nThe approach here-in is to decide to not just passively wait for entropy\nto happen, but to start actively collecting it if it is missing. This\nis not necessarily always possible, but if the architecture has a CPU\ncycle counter, there is a fair amount of noise in the exact timings of\nreasonably complex loads.\n\nWe may end up tweaking the load and the entropy estimates, but this\nshould be at least a reasonable starting point.\n\nAs part of this, we also revert the revert of the ext4 IO pattern\nimprovement that ended up triggering the reported lack of external\nentropy.\n\n* getrandom() active entropy waiting:\n Revert \"Revert \"ext4: make __ext4_get_inode_loc plug\"\"\n random: try to actively add entropy rather than passively wait for it\n", "tree_diff": [] }