)]}'
{
  "commit": "f29e71bb4424ea9e1a3cfccd4985e18fd23e42b9",
  "tree": "3787e4408a969105a570e6044b9c45d268441665",
  "parents": [
    "b1c32770858844766af8fee1d32a6c92f57a2041"
  ],
  "author": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Mon Sep 16 11:38:31 2019 -0400"
  },
  "committer": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Tue Oct 08 17:11:11 2019 -0400"
  },
  "message": "arena: fix __arena_add() quantum alignment issue\n\n__arena_add() was asserting that the span we were adding was quantum\n\u0027aligned.\u0027  However, our source gives us allocations according to *its*\nquantum, not our quantum.  If our source was e.g. bytes and we give out\npages, then our source could give us a span that does not match our\nquantum.\n\nThis is fine, albeit a source of fragmentation.  We just make sure our\narena\u0027s bt tracks the object we want (on a quantum boundary and a\nmultiple of quantum).  span_bt will track whatever we actually got from\nour source.\n\nAnother note: ALIGNED() checks on quantum were currently wrong - there\u0027s\nnothing in the arena code that forced quantum to be a power of two.  At\nleast, I didn\u0027t see it, and don\u0027t want to restrict us to that yet.\nThough we\u0027ll likely have issues with align, non-aligned quantums, and\nqcaches.  For instance, if you ask for a quantum of 3, with an align of\n64, the qcaches were told to do an align of 3 (quantum).\n\nSigned-off-by: Barret Rhoden \u003cbrho@cs.berkeley.edu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "2c9062826071006660593261ebfaf06abce893fe",
      "old_mode": 33188,
      "old_path": "kern/src/arena.c",
      "new_id": "a9adc33979decdd543d5037670b5e96706f94776",
      "new_mode": 33188,
      "new_path": "kern/src/arena.c"
    }
  ]
}