)]}'
{
  "commit": "72dbcf72156641fde4d8ea401e977341bfd35a05",
  "tree": "48a69287e39099681405f1981e8280cf2d780835",
  "parents": [
    "1609d7604b847a9820e63393d1a3b6cac7286d40"
  ],
  "author": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Sun Sep 15 12:32:03 2019 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Sun Sep 15 12:32:03 2019 -0700"
  },
  "message": "Revert \"ext4: make __ext4_get_inode_loc plug\"\n\nThis reverts commit b03755ad6f33b7b8cd7312a3596a2dbf496de6e7.\n\nThis is sad, and done for all the wrong reasons.  Because that commit is\ngood, and does exactly what it says: avoids a lot of small disk requests\nfor the inode table read-ahead.\n\nHowever, it turns out that it causes an entirely unrelated problem: the\ngetrandom() system call was introduced back in 2014 by commit\nc6e9d6f38894 (\"random: introduce getrandom(2) system call\"), and people\nuse it as a convenient source of good random numbers.\n\nBut part of the current semantics for getrandom() is that it waits for\nthe entropy pool to fill at least partially (unlike /dev/urandom).  And\nat least ArchLinux apparently has a systemd that uses getrandom() at\nboot time, and the improvements in IO patterns means that existing\ninstallations suddenly start hanging, waiting for entropy that will\nnever happen.\n\nIt seems to be an unlucky combination of not _quite_ enough entropy,\ntogether with a particular systemd version and configuration.  Lennart\nsays that the systemd-random-seed process (which is what does this early\naccess) is supposed to not block any other boot activity, but sadly that\ndoesn\u0027t actually seem to be the case (possibly due bogus dependencies on\ncryptsetup for encrypted swapspace).\n\nThe correct fix is to fix getrandom() to not block when it\u0027s not\nappropriate, but that fix is going to take a lot more discussion.  Do we\njust make it act like /dev/urandom by default, and add a new flag for\n\"wait for entropy\"? Do we add a boot-time option? Or do we just limit\nthe amount of time it will wait for entropy?\n\nSo in the meantime, we do the revert to give us time to discuss the\neventual fix for the fundamental problem, at which point we can re-apply\nthe ext4 inode table access optimization.\n\nReported-by: Ahmed S. Darwish \u003cdarwish.07@gmail.com\u003e\nCc: Ted Ts\u0027o \u003ctytso@mit.edu\u003e\nCc: Willy Tarreau \u003cw@1wt.eu\u003e\nCc: Alexander E. Patrakov \u003cpatrakov@gmail.com\u003e\nCc: Lennart Poettering \u003cmzxreary@0pointer.de\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "420fe3deed39702b93a5567dbebe77a8e4b6b992",
      "old_mode": 33188,
      "old_path": "fs/ext4/inode.c",
      "new_id": "006b7a2070bf6869d2f7c42500eea135919def74",
      "new_mode": 33188,
      "new_path": "fs/ext4/inode.c"
    }
  ]
}