)]}'
{
  "log": [
    {
      "commit": "65f27f38446e1976cc98fd3004b110fedcddd189",
      "tree": "68f8be93feae31dfa018c22db392a05546b63ee1",
      "parents": [
        "365970a1ea76d81cb1ad2f652acb605f06dae256"
      ],
      "author": {
        "name": "David Howells",
        "email": "dhowells@redhat.com",
        "time": "Wed Nov 22 14:55:48 2006 +0000"
      },
      "committer": {
        "name": "David Howells",
        "email": "dhowells@redhat.com",
        "time": "Wed Nov 22 14:55:48 2006 +0000"
      },
      "message": "WorkStruct: Pass the work_struct pointer instead of context data\n\nPass the work_struct pointer to the work function rather than context data.\nThe work function can use container_of() to work out the data.\n\nFor the cases where the container of the work_struct may go away the moment the\npending bit is cleared, it is made possible to defer the release of the\nstructure by deferring the clearing of the pending bit.\n\nTo make this work, an extra flag is introduced into the management side of the\nwork_struct.  This governs auto-release of the structure upon execution.\n\nOrdinarily, the work queue executor would release the work_struct for further\nscheduling or deallocation by clearing the pending bit prior to jumping to the\nwork function.  This means that, unless the driver makes some guarantee itself\nthat the work_struct won\u0027t go away, the work function may not access anything\nelse in the work_struct or its container lest they be deallocated..  This is a\nproblem if the auxiliary data is taken away (as done by the last patch).\n\nHowever, if the pending bit is *not* cleared before jumping to the work\nfunction, then the work function *may* access the work_struct and its container\nwith no problems.  But then the work function must itself release the\nwork_struct by calling work_release().\n\nIn most cases, automatic release is fine, so this is the default.  Special\ninitiators exist for the non-auto-release case (ending in _NAR).\n\n\nSigned-Off-By: David Howells \u003cdhowells@redhat.com\u003e\n"
    },
    {
      "commit": "6bfd48096ff8ecabf955958b51ddfa7988eb0a14",
      "tree": "813799f00d8402348ba6817953b1c631541be66c",
      "parents": [
        "492e2b63eb10c28f4f0b694264d74a8755cd1be0"
      ],
      "author": {
        "name": "Herbert Xu",
        "email": "herbert@gondor.apana.org.au",
        "time": "Thu Sep 21 11:39:29 2006 +1000"
      },
      "committer": {
        "name": "Herbert Xu",
        "email": "herbert@gondor.apana.org.au",
        "time": "Thu Sep 21 11:39:29 2006 +1000"
      },
      "message": "[CRYPTO] api: Added spawns\n\nSpawns lock a specific crypto algorithm in place.  They can then be used\nwith crypto_spawn_tfm to allocate a tfm for that algorithm.  When the base\nalgorithm of a spawn is deregistered, all its spawns will be automatically\nremoved.\n\nSigned-off-by: Herbert Xu \u003cherbert@gondor.apana.org.au\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n"
    },
    {
      "commit": "492e2b63eb10c28f4f0b694264d74a8755cd1be0",
      "tree": "d882a2df15d939b2edf9064963d73c71c5985b9b",
      "parents": [
        "2b8c19dbdc692e81243a328725a02efb77b144a5"
      ],
      "author": {
        "name": "Herbert Xu",
        "email": "herbert@gondor.apana.org.au",
        "time": "Thu Sep 21 11:35:17 2006 +1000"
      },
      "committer": {
        "name": "Herbert Xu",
        "email": "herbert@gondor.apana.org.au",
        "time": "Thu Sep 21 11:35:17 2006 +1000"
      },
      "message": "[CRYPTO] api: Allow algorithm lookup by type\n\nThis patch also adds the infrastructure to pick an algorithm based on\ntheir type.  For example, this allows you to select the encryption\nalgorithm \"aes\", instead of any algorithm registered under the name\n\"aes\".  For now this is only accessible internally.  Eventually it\nwill be made available through crypto_alloc_tfm.\n\nSigned-off-by: Herbert Xu \u003cherbert@gondor.apana.org.au\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n"
    },
    {
      "commit": "2b8c19dbdc692e81243a328725a02efb77b144a5",
      "tree": "f9256d5515cc315d54971f62e0e9812d5db572ba",
      "parents": [
        "2825982d9d66ebba4b532a07391dfbb357f71c5f"
      ],
      "author": {
        "name": "Herbert Xu",
        "email": "herbert@gondor.apana.org.au",
        "time": "Thu Sep 21 11:31:44 2006 +1000"
      },
      "committer": {
        "name": "Herbert Xu",
        "email": "herbert@gondor.apana.org.au",
        "time": "Thu Sep 21 11:31:44 2006 +1000"
      },
      "message": "[CRYPTO] api: Add cryptomgr\n\nThe cryptomgr module is a simple manager of crypto algorithm instances.\nIt ensures that parameterised algorithms of the type tmpl(alg) (e.g.,\ncbc(aes)) are always created.\n\nThis is meant to satisfy the needs for most users.  For more complex\ncases such as deeper combinations or multiple parameters, a netlink\nmodule will be created which allows arbitrary expressions to be parsed\nin user-space.\n\nSigned-off-by: Herbert Xu \u003cherbert@gondor.apana.org.au\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n"
    }
  ]
}