{"push_id":571434630,"size":5,"distinct_size":5,"ref":"refs/heads/lp5.0","head":"2db518832d4326494435af203875a835ce7a3d7c","before":"f0a8c3123338e838b1f1d11c0fb420acfb9c54c8","commits":[{"sha":"80128d68b2f7bfbd68a4f85922919e33e4c8c597","author":{"email":"a03f90017ab580fcc9558a98cd061c91599c42fd@parallels.com","name":"Maxim Patlasov"},"message":"fuse: hotfix truncate_pagecache() issue\n\ncommit 06a7c3c2781409af95000c60a5df743fd4e2f8b4 upstream.\n\nThe way how fuse calls truncate_pagecache() from fuse_change_attributes()\nis completely wrong. Because, w/o i_mutex held, we never sure whether\n'oldsize' and 'attr->size' are valid by the time of execution of\ntruncate_pagecache(inode, oldsize, attr->size). In fact, as soon as we\nreleased fc->lock in the middle of fuse_change_attributes(), we completely\nloose control of actions which may happen with given inode until we reach\ntruncate_pagecache. The list of potentially dangerous actions includes\nmmap-ed reads and writes, ftruncate(2) and write(2) extending file size.\n\nThe typical outcome of doing truncate_pagecache() with outdated arguments\nis data corruption from user point of view. This is (in some sense)\nacceptable in cases when the issue is triggered by a change of the file on\nthe server (i.e. externally wrt fuse operation), but it is absolutely\nintolerable in scenarios when a single fuse client modifies a file without\nany external intervention. A real life case I discovered by fsx-linux\nlooked like this:\n\n1. Shrinking ftruncate(2) comes to fuse_do_setattr(). The latter sends\nFUSE_SETATTR to the server synchronously, but before getting fc->lock ...\n2. fuse_dentry_revalidate() is asynchronously called. It sends FUSE_LOOKUP\nto the server synchronously, then calls fuse_change_attributes(). The\nlatter updates i_size, releases fc->lock, but before comparing oldsize vs\nattr->size..\n3. fuse_do_setattr() from the first step proceeds by acquiring fc->lock and\nupdating attributes and i_size, but now oldsize is equal to\noutarg.attr.size because i_size has just been updated (step 2). Hence,\nfuse_do_setattr() returns w/o calling truncate_pagecache().\n4. As soon as ftruncate(2) completes, the user extends file size by\nwrite(2) making a hole in the middle of file, then reads data from the hole\neither by read(2) or mmap-ed read. The user expects to get zero data from\nthe hole, but gets stale data because truncate_pagecache() is not executed\nyet.\n\nThe scenario above illustrates one side of the problem: not truncating the\npage cache even though we should. Another side corresponds to truncating\npage cache too late, when the state of inode changed significantly.\nTheoretically, the following is possible:\n\n1. As in the previous scenario fuse_dentry_revalidate() discovered that\ni_size changed (due to our own fuse_do_setattr()) and is going to call\ntruncate_pagecache() for some 'new_size' it believes valid right now. But\nby the time that particular truncate_pagecache() is called ...\n2. fuse_do_setattr() returns (either having called truncate_pagecache() or\nnot -- it doesn't matter).\n3. The file is extended either by write(2) or ftruncate(2) or fallocate(2).\n4. mmap-ed write makes a page in the extended region dirty.\n\nThe result will be the lost of data user wrote on the fourth step.\n\nThe patch is a hotfix resolving the issue in a simplistic way: let's skip\ndangerous i_size update and truncate_pagecache if an operation changing\nfile size is in progress. This simplistic approach looks correct for the\ncases w/o external changes. And to handle them properly, more sophisticated\nand intrusive techniques (e.g. NFS-like one) would be required. I'd like to\npostpone it until the issue is well discussed on the mailing list(s).\n\nChanged in v2:\n - improved patch description to cover both sides of the issue.\n\nChange-Id: If69a07a88f9d8dfc1e051987a629ff9f91f1aa43\nSigned-off-by: Maxim Patlasov <mpatlasov@parallels.com>\nSigned-off-by: Miklos Szeredi <mszeredi@suse.cz>\n[bwh: Backported to 3.2: add the fuse_inode::state field which we didn't have]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>\nCc: Rui Xiang <rui.xiang@huawei.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/SlimRoms/kernel_htc_msm8974/commits/80128d68b2f7bfbd68a4f85922919e33e4c8c597"},{"sha":"78da123db9eeb372f1a15ae0f246360afe6520b3","author":{"email":"f170b3970e1ff8de8ac083ab81eba96499e5ab96@codeaurora.org","name":"Zhen Kong"},"message":"qseecom: Check if ce clock is enabled before sending cmd to TZ\n\nMake change to check if ce clock is enabled before sending command\nto TZ, then to prevent data aborting if clock is not enabled for\nTZ crypto operation.\n\nCRs-Fixed: 726840\nChange-Id: I55b5b10ad80e741c39f8cf411f67e6b83887f3bb\nSigned-off-by: Zhen Kong <zkong@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/SlimRoms/kernel_htc_msm8974/commits/78da123db9eeb372f1a15ae0f246360afe6520b3"},{"sha":"a94e60bd861dbf2d1969be96f4671bbfb4f5cbf6","author":{"email":"f170b3970e1ff8de8ac083ab81eba96499e5ab96@codeaurora.org","name":"Zhen Kong"},"message":"qseecom: Enable/disable clock for client if bus scaling is not enabled\n\nTo avoid the service failure on a target where bus scaling flag is not\nenabled in target device tree file by mistake, make a change to enable/\ndisable crypto clocks when the client calls to scale up bus bandwidth\nand send command even if bus scaling feature is not enabled.\n\nCRs-Fixed: 726840\nChange-Id: Ib33a535051b68561bde5ab6a23ad0f02dc27ab13\nSigned-off-by: Zhen Kong <zkong@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/SlimRoms/kernel_htc_msm8974/commits/a94e60bd861dbf2d1969be96f4671bbfb4f5cbf6"},{"sha":"15ff16234d80d919ed63afd56c8979e2733cc56f","author":{"email":"41c88242557e7288c285ee699a693678d02cf422@codeaurora.org","name":"William Clark"},"message":"qseecom: fix secure app loading failure by kernel mode qseecom client\n\nMake a change to fix secure app loading failure due to premature\nkzfree() from __qseecom_load_fw(), when kernel mode qseecom client\ntries to load app.\n\nCRs-fixed: 694541\n\nChange-Id: I1ac39ee885c12e08e863d976321dda2380ace852\nSigned-off-by: William Clark <wclark@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/SlimRoms/kernel_htc_msm8974/commits/15ff16234d80d919ed63afd56c8979e2733cc56f"},{"sha":"2db518832d4326494435af203875a835ce7a3d7c","author":{"email":"f170b3970e1ff8de8ac083ab81eba96499e5ab96@codeaurora.org","name":"Zhen Kong"},"message":"qseecom: Just check current bus scaling mode in qseecom_suspend\n\nIn current qseecom_suspend function, qseecom will scale down bus\nbandwidth if both of accumultive mode and current mode are not\nINACTIVE. But if device goes into suspend before bus scaling timeout\nhappens, the accumulative mode may be zero but current mode is\nstill not INACTIVE. This may prevent the device going to suspend,\nthus, make a change to just check current bus scaling mode in\nqseecom_suspend.\n\nCRs-Fixed: 740287\nChange-Id: I60e90000aa9efe428b144fb766e19e81312af66f\nSigned-off-by: Zhen Kong <zkong@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/SlimRoms/kernel_htc_msm8974/commits/2db518832d4326494435af203875a835ce7a3d7c"}]}