)]}'
{
  "commit": "9ab020cf07e457a8b425bf5af17e704f90f86d8b",
  "tree": "8119f741492575b12968f325cb225ec16f437fc7",
  "parents": [
    "0329326e85aaa30fb8d427828c718d565c287385"
  ],
  "author": {
    "name": "Jeff Mahoney",
    "email": "jeffm@suse.com",
    "time": "Wed Jan 12 17:00:48 2011 -0800"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Thu Jan 13 08:03:19 2011 -0800"
  },
  "message": "taskstats: use better ifdef for alignment\n\nCommit 4be2c95d (\"taskstats: pad taskstats netlink response for aligment\nissues on ia64\") added a null field to align the taskstats structure but\nthe discussion centered around ia64.  The issue exists on other platforms\nwith inefficient unaligned access and adding them piecemeal would be an\nunmaintainable mess.\n\nThis patch uses Dave Miller\u0027s suggestion of using a combination of\nCONFIG_64BIT \u0026\u0026 !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to determine\nwhether alignment is needed.\n\nNote that this will cause breakage on those platforms with applications\nlike iotop which had hard-coded offsets into the packet to access the\ntaskstats structure.\n\nThe message seen on systems without the alignment fixes looks like: kernel\nunaligned access to 0xe000023879dca9bc, ip\u003d0xa000000100133d10\n\nThe addresses may vary but resolve to locations inside __delayacct_add_tsk.\n\niotop makes what I\u0027d call unreasonable assumptions about the contents of a\nnetlink genetlink packet containing generic attributes.  They\u0027re typed and\nhave headers that specify value lengths, so the client can (should)\nidentify and skip the ones the client doesn\u0027t understand.\n\nThe kernel, as of version 2.6.36, presented a packet like so:\n+--------------------------------+\n| genlmsghdr - 4 bytes           |\n+--------------------------------+\n| NLA header - 4 bytes           | /* Aggregate header */\n+-+------------------------------+\n| | NLA header - 4 bytes         | /* PID header */\n| +------------------------------+\n| | pid/tgid   - 4 bytes         |\n| +------------------------------+\n| | NLA header - 4 bytes         | /* stats header */\n| + -----------------------------+ \u003c- oops. aligned on 4 byte boundary\n| | struct taskstats - 328 bytes |\n+-+------------------------------+\n\nThe iotop code expects that the kernel will behave as it did then,\nassuming that the packet format is set in stone.  The format is set in\nstone, but the packet offsets are not.  There\u0027s nothing in the packet\nformat that guarantees that the packet will be sent in exactly the same\nway.  The attribute contents are set (or versioned) and the aggregate\ncontents are set but they can be anywhere in the packet.\n\nThe issue here isn\u0027t that an unaligned structure gets passed to userspace,\nit\u0027s that the NLA infrastructure has something of a weakness: The 4 byte\nattribute header may force the payload to be unaligned.  The taskstats\nstructure is created at an unaligned location and then 64-bit values are\noperated on inside the kernel, so the unaligned access warnings gets\nspewed everywhere.\n\nIt\u0027s possible to use the unaligned access API to operate on the structure\nin the kernel but it seems like a wasted effort to work around userspace\ncode that isn\u0027t following the packet format.  Any new additions would also\nneed the be worked around.  It\u0027s a maintenance nightmare.\n\nThe conclusion of the earlier discussion seemed to be \"ok fine, if we have\nto break it, don\u0027t break it on arches that don\u0027t have the problem.\" Dave\npointed out that the unaligned access problem doesn\u0027t only exist on ia64,\nbut also on other 64-bit arches that don\u0027t have efficient unaligned access\nand it should be fixed there as well.  The committed version of the patch\nand this addition keep with the conclusion of that discussion not to break\nit unnecessarily, which the pid padding and the packet padding fixes did\ndo.  x86_64 and powerpc don\u0027t suffer this problem so they shouldn\u0027t suffer\nthe solution.  Other 64-bit architectures do and will, though.\n\nSigned-off-by: Jeff Mahoney \u003cjeffm@suse.com\u003e\nReported-by: David S. Miller \u003cdavem@davemloft.net\u003e\nAcked-by: David S. Miller \u003cdavem@davemloft.net\u003e\nCc: Dan Carpenter \u003cerror27@gmail.com\u003e\nCc: Balbir Singh \u003cbalbir@in.ibm.com\u003e\nCc: Florian Mickler \u003cflorian@mickler.org\u003e\nCc: Guillaume Chazarain \u003cguichaz@gmail.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "69691eb4b715da804555e04c79aa4ba44ec2bdd3",
      "old_mode": 33188,
      "old_path": "kernel/taskstats.c",
      "new_id": "3971c6b9d58db668c029365a1120506dda3179d8",
      "new_mode": 33188,
      "new_path": "kernel/taskstats.c"
    }
  ]
}