{"push_id":566878502,"size":8,"distinct_size":8,"ref":"refs/heads/cm-12.0","head":"2dd5d44066d3c3d3d671343aa9bc5aaf95aa8930","before":"3b40d1ee7ca098c16e8ca4cbb6042d8f4bca5875","commits":[{"sha":"b99020e89533c642858f023885f574b4266b3f44","author":{"email":"7cbcbfe495bad5f7f26ddc6bf28ecd9f36b2e347@etersoft.ru","name":"Pavel Shilovsky"},"message":"fuse: fix stat call on 32 bit platforms\n\ncommit 45c72cd73c788dd18c8113d4a404d6b4a01decf1 upstream.\n\nNow we store attr->ino at inode->i_ino, return attr->ino at the\nfirst time and then return inode->i_ino if the attribute timeout\nisn't expired. That's wrong on 32 bit platforms because attr->ino\nis 64 bit and inode->i_ino is 32 bit in this case.\n\nFix this by saving 64 bit ino in fuse_inode structure and returning\nit every time we call getattr. Also squash attr->ino into inode->i_ino\nexplicitly.\n\nSigned-off-by: Pavel Shilovsky <piastry@etersoft.ru>\nSigned-off-by: Miklos Szeredi <mszeredi@suse.cz>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/CyanogenMod/android_kernel_htc_msm8974/commits/b99020e89533c642858f023885f574b4266b3f44"},{"sha":"e04ef0524a7436d76e8b1ac26b2a3699fcb324fa","author":{"email":"bdd5a5f42152ba789e24c1ef8132eb16704ed8a4@redhat.com","name":"Zach Brown"},"message":"fuse: verify all ioctl retry iov elements\n\ncommit fb6ccff667712c46b4501b920ea73a326e49626a upstream.\n\nCommit 7572777eef78ebdee1ecb7c258c0ef94d35bad16 attempted to verify that\nthe total iovec from the client doesn't overflow iov_length() but it\nonly checked the first element.  The iovec could still overflow by\nstarting with a small element.  The obvious fix is to check all the\nelements.\n\nThe overflow case doesn't look dangerous to the kernel as the copy is\nlimited by the length after the overflow.  This fix restores the\nintention of returning an error instead of successfully copying less\nthan the iovec represented.\n\nI found this by code inspection.  I built it but don't have a test case.\nI'm cc:ing stable because the initial commit did as well.\n\nSigned-off-by: Zach Brown <zab@redhat.com>\nSigned-off-by: Miklos Szeredi <mszeredi@suse.cz>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/CyanogenMod/android_kernel_htc_msm8974/commits/e04ef0524a7436d76e8b1ac26b2a3699fcb324fa"},{"sha":"414f8e0aff43bf2c573153d9cdc20ccae513f87a","author":{"email":"84cd5483a2f9acd1c37251cba7c2908448f221b8@suse.cz","name":"Miklos Szeredi"},"message":"fuse: fix retrieve length\n\ncommit c9e67d483776d8d2a5f3f70491161b205930ffe1 upstream.\n\nIn some cases fuse_retrieve() would return a short byte count if offset was\nnon-zero.  The data returned was correct, though.\n\nSigned-off-by: Miklos Szeredi <mszeredi@suse.cz>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/CyanogenMod/android_kernel_htc_msm8974/commits/414f8e0aff43bf2c573153d9cdc20ccae513f87a"},{"sha":"5cdf60124d597062d2a2ad0cf231068f5cf6178f","author":{"email":"84cd5483a2f9acd1c37251cba7c2908448f221b8@suse.cz","name":"Miklos Szeredi"},"message":"fuse: don't WARN when nlink is zero\n\ncommit dfca7cebc2679f3d129f8e680a8f199a7ad16e38 upstream.\n\ndrop_nlink() warns if nlink is already zero.  This is triggerable by a buggy\nuserspace filesystem.  The cure, I think, is worse than the disease so disable\nthe warning.\n\nReported-by: Tero Roponen <tero.roponen@gmail.com>\nSigned-off-by: Miklos Szeredi <mszeredi@suse.cz>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/CyanogenMod/android_kernel_htc_msm8974/commits/5cdf60124d597062d2a2ad0cf231068f5cf6178f"},{"sha":"9366fb46d7a84cd43f0766a4c00d0e3fa9f11c5a","author":{"email":"a03f90017ab580fcc9558a98cd061c91599c42fd@parallels.com","name":"Maxim Patlasov"},"message":"fuse: postpone end_page_writeback() in fuse_writepage_locked()\n\ncommit 4a4ac4eba1010ef9a804569058ab29e3450c0315 upstream.\n\nThe patch fixes a race between ftruncate(2), mmap-ed write and write(2):\n\n1) An user makes a page dirty via mmap-ed write.\n2) The user performs shrinking truncate(2) intended to purge the page.\n3) Before fuse_do_setattr calls truncate_pagecache, the page goes to\n   writeback. fuse_writepage_locked fills FUSE_WRITE request and releases\n   the original page by end_page_writeback.\n4) fuse_do_setattr() completes and successfully returns. Since now, i_mutex\n   is free.\n5) Ordinary write(2) extends i_size back to cover the page. Note that\n   fuse_send_write_pages do wait for fuse writeback, but for another\n   page->index.\n6) fuse_writepage_locked proceeds by queueing FUSE_WRITE request.\n   fuse_send_writepage is supposed to crop inarg->size of the request,\n   but it doesn't because i_size has already been extended back.\n\nMoving end_page_writeback to the end of fuse_writepage_locked fixes the\nrace because now the fact that truncate_pagecache is successfully returned\ninfers that fuse_writepage_locked has already called end_page_writeback.\nAnd this, in turn, infers that fuse_flush_writepages has already called\nfuse_send_writepage, and the latter used valid (shrunk) i_size. write(2)\ncould not extend it because of i_mutex held by ftruncate(2).\n\nSigned-off-by: Maxim Patlasov <mpatlasov@parallels.com>\nSigned-off-by: Miklos Szeredi <mszeredi@suse.cz>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/CyanogenMod/android_kernel_htc_msm8974/commits/9366fb46d7a84cd43f0766a4c00d0e3fa9f11c5a"},{"sha":"e35c4e9db5787d2b16f13f9c618350ec6d096b66","author":{"email":"6a1810c170bd423868ce2e225ecea39d80cade0f@redhat.com","name":"Anand Avati"},"message":"fuse: invalidate inode attributes on xattr modification\n\ncommit d331a415aef98717393dda0be69b7947da08eba3 upstream.\n\nCalls like setxattr and removexattr result in updation of ctime.\nTherefore invalidate inode attributes to force a refresh.\n\nSigned-off-by: Anand Avati <avati@redhat.com>\nReviewed-by: Brian Foster <bfoster@redhat.com>\nSigned-off-by: Miklos Szeredi <mszeredi@suse.cz>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/CyanogenMod/android_kernel_htc_msm8974/commits/e35c4e9db5787d2b16f13f9c618350ec6d096b66"},{"sha":"ccddcf5d2f20df12d82e9169ca56b4c592fdb18f","author":{"email":"84cd5483a2f9acd1c37251cba7c2908448f221b8@suse.cz","name":"Miklos Szeredi"},"message":"fuse: readdir: check for slash in names\n\ncommit efeb9e60d48f7778fdcad4a0f3ad9ea9b19e5dfd upstream.\n\nUserspace can add names containing a slash character to the directory\nlisting.  Don't allow this as it could cause all sorts of trouble.\n\nSigned-off-by: Miklos Szeredi <mszeredi@suse.cz>\n[bwh: Backported to 3.2: drop changes to parse_dirplusfile() which we\n don'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/CyanogenMod/android_kernel_htc_msm8974/commits/ccddcf5d2f20df12d82e9169ca56b4c592fdb18f"},{"sha":"2dd5d44066d3c3d3d671343aa9bc5aaf95aa8930","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\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/CyanogenMod/android_kernel_htc_msm8974/commits/2dd5d44066d3c3d3d671343aa9bc5aaf95aa8930"}]}