{"push_id":602768771,"size":3,"distinct_size":3,"ref":"refs/heads/cm-12.0","head":"ee4adac622799c3a863a103d0f2c2b3897b0a0ef","before":"92aec5086caf6684f9b47ac6e71278f33c20fd73","commits":[{"sha":"13da517b31a8fe8943597fc561dd5d081d753a5b","author":{"email":"e8b50d7b4a37839a028792f3f95c0e00a3aa8c10@lge.com","name":"Devin Kim"},"message":"seq_file: always update file->f_pos in seq_lseek()\n\nThis issue was first pointed out by Jiaxing Wang several months ago, but no\nfurther comments:\nhttps://lkml.org/lkml/2013/6/29/41\n\nAs we know pread() does not change f_pos, so after pread(), file->f_pos\nand m->read_pos become different. And seq_lseek() does not update file->f_pos\nif offset equals to m->read_pos, so after pread() and seq_lseek()(lseek to\nm->read_pos), then a subsequent read may read from a wrong position, the\nfollowing program produces the problem:\n\n    char str1[32] = { 0 };\n    char str2[32] = { 0 };\n    int poffset = 10;\n    int count = 20;\n\n    /*open any seq file*/\n    int fd = open(\"/proc/modules\", O_RDONLY);\n\n    pread(fd, str1, count, poffset);\n    printf(\"pread:%s\\n\", str1);\n\n    /*seek to where m->read_pos is*/\n    lseek(fd, poffset+count, SEEK_SET);\n\n    /*supposed to read from poffset+count, but this read from position 0*/\n    read(fd, str2, count);\n    printf(\"read:%s\\n\", str2);\n\nout put:\npread:\n ck_netbios_ns 12665\nread:\n nf_conntrack_netbios\n\n/proc/modules:\nnf_conntrack_netbios_ns 12665 0 - Live 0xffffffffa038b000\nnf_conntrack_broadcast 12589 1 nf_conntrack_netbios_ns, Live 0xffffffffa0386000\n\nSo we always update file->f_pos to offset in seq_lseek() to fix this issue.\n\ncherry-picked from https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/seq_file.c?id=05e16745c0c471bba313961b605b6da3b21a853d\n\nSigned-off-by: Jiaxing Wang <hello.wjx@gmail.com>\nSigned-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\n\nConflicts:\n\tfs/seq_file.c\n\nChange-Id: If419b92498e2c3e08669a4342e9b9ebf99ad3768\nSigned-off-by: Devin Kim <dojip.kim@lge.com>","distinct":true,"url":"https://api.github.com/repos/CyanogenMod/android_kernel_samsung_msm8930-common/commits/13da517b31a8fe8943597fc561dd5d081d753a5b"},{"sha":"cd0ddec855f8b8b74ad0c4cca9553f67df2b88ae","author":{"email":"e8b50d7b4a37839a028792f3f95c0e00a3aa8c10@lge.com","name":"Devin Kim"},"message":"cgroup: remove synchronize_rcu() from cgroup_attach_{task|proc}()\n\nThese 2 syncronize_rcu()s make attaching a task to a cgroup\nquite slow, and it can't be ignored in some situations.\n\nA real case from Colin Cross: Android uses cgroups heavily to\nmanage thread priorities, putting threads in a background group\nwith reduced cpu.shares when they are not visible to the user,\nand in a foreground group when they are. Some RPCs from foreground\nthreads to background threads will temporarily move the background\nthread into the foreground group for the duration of the RPC.\nThis results in many calls to cgroup_attach_task.\n\nIn cgroup_attach_task() it's task->cgroups that is protected by RCU,\nand put_css_set() calls kfree_rcu() to free it.\n\nIf we remove this synchronize_rcu(), there can be threads in RCU-read\nsections accessing their old cgroup via current->cgroups with\nconcurrent rmdir operation, but this is safe.\n\n # time for ((i=0; i<50; i++)) { echo $$ > /mnt/sub/tasks; echo $$ > /mnt/tasks; }\n\nreal    0m2.524s\nuser    0m0.008s\nsys     0m0.004s\n\nWith this patch:\n\nreal    0m0.004s\nuser    0m0.004s\nsys     0m0.000s\n\ntj: These synchronize_rcu()s are utterly confused.  synchornize_rcu()\n    necessarily has to come between two operations to guarantee that\n    the changes made by the former operation are visible to all rcu\n    readers before proceeding to the latter operation.  Here,\n    synchornize_rcu() are at the end of attach operations with nothing\n    beyond it.  Its only effect would be delaying completion of\n    write(2) to sysfs tasks/procs files until all rcu readers see the\n    change, which doesn't mean anything.\n\ncherry-picked from:\nhttps://android.googlesource.com/kernel/common/+/5d65bc0ca1bceb73204dab943922ba3c83276a8c\n\nBug: 17709419\nChange-Id: I98dacd6c13da27cb3496fe4a24a24084e46bdd9c\nSigned-off-by: Li Zefan <lizefan@huawei.com>\nSigned-off-by: Tejun Heo <tj@kernel.org>\nReported-by: Colin Cross <ccross@google.com>\nSigned-off-by: Devin Kim <dojip.kim@lge.com>","distinct":true,"url":"https://api.github.com/repos/CyanogenMod/android_kernel_samsung_msm8930-common/commits/cd0ddec855f8b8b74ad0c4cca9553f67df2b88ae"},{"sha":"ee4adac622799c3a863a103d0f2c2b3897b0a0ef","author":{"email":"8c3c6f288c7f42d337a1136cfef3d76aa3305278@motorola.com","name":"Shengzhe Zhao"},"message":"vfs: check if f_count is 0 or negative\n\nfilp_close is using !file_count(filp) to check if f_count is 0. if it is\n0, filp_close think it is a closed file then will return. However, for a\nclosed file, f_count could be reduced to -1, then !file_count(filp) is\nfalse, filp_close will proceed to handle this file then could panic.\nThis change will check if f_count is 0 or negative instead of only\nchecking 0 to avoid panic.\n\nb/18200219 LRX21M: kernel_panic\nChange-Id: I3881574d4971bf4e0bc261cf3459451600ce6a27\n\nSigned-off-by: Shengzhe Zhao <a18689@motorola.com>\nReviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>\nSigned-off-by: Iliyan Malchev <malchev@google.com>","distinct":true,"url":"https://api.github.com/repos/CyanogenMod/android_kernel_samsung_msm8930-common/commits/ee4adac622799c3a863a103d0f2c2b3897b0a0ef"}]}