{"push_id":852775091,"size":13,"distinct_size":13,"ref":"refs/heads/lollipop","head":"3577764280cb960d9efadb944c5cf655b68301c9","before":"a2b3d5e0a22a88062f63ead932a3474ced521830","commits":[{"sha":"ee4deeed9502d7b9c55d274a1deae3ba806229ec","author":{"email":"bba47ad64dee34c4d300854848a6414e05073f51@codeaurora.org","name":"Oliver Wang"},"message":"input: add new input event code to pass timestamp to userspace\n\nThere's timestamp jitter between the input events and input_sync.\nAdd two more event code to pass the timestamp to userspace. This\nis needed since some input devices such as sensors need to retrieve\nthe accurate timestamp of the events generated.\n\nSigned-off-by: Oliver Wang <mengmeng@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/neobuddy89/shamu/commits/ee4deeed9502d7b9c55d274a1deae3ba806229ec"},{"sha":"b84510be48340a724ac83dccd9a0032f91719185","author":{"email":"433adf4e000ef006e7ed86a6a87b34fca89b9b00@samsung.com","name":"Anshul Garg"},"message":"input: optimize events_per_packet count calculation\n\nThis patch avoids unnecessary operations while estimating events per\npacket for an input device when event type is not set.\n\nSigned-off-by: Anshul Garg <anshul.g@samsung.com>\nSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>\nGit-commit: baf332c0f1cede26e9c2af6276b36b4c3a36e34a\nGit-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\nSigned-off-by: Matt Wagantall <mattw@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/neobuddy89/shamu/commits/b84510be48340a724ac83dccd9a0032f91719185"},{"sha":"27a29896a316d3580961874d38524cc0f8807553","author":{"email":"b3c147b7b1fea00c05d6b38573ec7cd70637c400@codeaurora.org","name":"Gopikrishnaiah Anandan"},"message":"mdss: mdp: Set completion if backlight level is zero\n\nDuring rapid suspend/resume usecases assertive display is being turned\non with backlight level zero. When on command is received with backlight\nlevel zero driver bails out with out turning on AD and doesn't signal\nthe client that worker queue has stopped processing which results in a\ntimeout for on command. Change will ensure that client is signalled if\ndriver is skipping the processing of AD due to backlight being zero.\n\nSigned-off-by: Gopikrishnaiah Anandan <agopik@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/neobuddy89/shamu/commits/27a29896a316d3580961874d38524cc0f8807553"},{"sha":"4e7be08e6384c46120f1fcfd6d77690fdde8552a","author":{"email":"c9a1f8bf19f76c8ec591b159d3e7c3a1b7483092@codeaurora.org","name":"Jeevan Shriram"},"message":"msm: mdss: reduce log level when ping pong timeout happens\n\nIn the current implementation, driver has a recovery mechanism\nfrom pingpong timeout on command mode interface. This change\nreplaces WARN macro with pr_warn to reduce the logging in dmesg\nwhen the pingpong timeout happens only once.\n\nSigned-off-by: Jeevan Shriram <jshriram@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/neobuddy89/shamu/commits/4e7be08e6384c46120f1fcfd6d77690fdde8552a"},{"sha":"3e861e98f98b15e96fe88b7134b5007122ac740b","author":{"email":"695912e9a92fbf1491499dabcbfa8b6645fca07f@codeaurora.org","name":"Harshdeep Dhatt"},"message":"msm: kgsl: Ratelimit memory related error messages\n\nIn a low memory state, mem error messages can get flooded\ncausing a watchdog bite. Ratelimit these messages to avoid\nthe same.\n\nSigned-off-by: Harshdeep Dhatt <hdhatt@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/neobuddy89/shamu/commits/3e861e98f98b15e96fe88b7134b5007122ac740b"},{"sha":"ed89fdcb781bcefb198ab1fa18e006ff9d2c8f8c","author":{"email":"58d301c70203188c35d379474c26c9cc0636a189@google.com","name":"Neal Cardwell"},"message":"tcp: fix timing issue in CUBIC slope calculation\n\nThis patch fixes a bug in CUBIC that causes cwnd to increase slightly\ntoo slowly when multiple ACKs arrive in the same jiffy.\n\nIf cwnd is supposed to increase at a rate of more than once per jiffy,\nthen CUBIC was sometimes too slow. Because the bic_target is\ncalculated for a future point in time, calculated with time in\njiffies, the cwnd can increase over the course of the jiffy while the\nbic_target calculated as the proper CUBIC cwnd at time\nt=tcp_time_stamp+rtt does not increase, because tcp_time_stamp only\nincreases on jiffy tick boundaries.\n\nSo since the cnt is set to:\n\tca->cnt = cwnd / (bic_target - cwnd);\nas cwnd increases but bic_target does not increase due to jiffy\ngranularity, the cnt becomes too large, causing cwnd to increase\ntoo slowly.\n\nFor example:\n- suppose at the beginning of a jiffy, cwnd=40, bic_target=44\n- so CUBIC sets:\n   ca->cnt =  cwnd / (bic_target - cwnd) = 40 / (44 - 40) = 40/4 = 10\n- suppose we get 10 acks, each for 1 segment, so tcp_cong_avoid_ai()\n   increases cwnd to 41\n- so CUBIC sets:\n   ca->cnt =  cwnd / (bic_target - cwnd) = 41 / (44 - 41) = 41 / 3 = 13\n\nSo now CUBIC will wait for 13 packets to be ACKed before increasing\ncwnd to 42, insted of 10 as it should.\n\nThe fix is to avoid adjusting the slope (determined by ca->cnt)\nmultiple times within a jiffy, and instead skip to compute the Reno\ncwnd, the \"TCP friendliness\" code path.\n\nReported-by: Eyal Perry <eyalpe@mellanox.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/neobuddy89/shamu/commits/ed89fdcb781bcefb198ab1fa18e006ff9d2c8f8c"},{"sha":"b01bc7aa6b829d6c44a78cb65d52902c1172b8a1","author":{"email":"69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","name":"Linus Torvalds"},"message":"mm: get rid of 'vmalloc_info' from /proc/meminfo\n\nIt turns out that at least some versions of glibc end up reading\n/proc/meminfo at every single startup, because glibc wants to know the\namount of memory the machine has.  And while that's arguably insane,\nit's just how things are.\n\nAnd it turns out that it's not all that expensive most of the time, but\nthe vmalloc information statistics (amount of virtual memory used in the\nvmalloc space, and the biggest remaining chunk) can be rather expensive\nto compute.\n\nThe 'get_vmalloc_info()' function actually showed up on my profiles as\n4% of the CPU usage of \"make test\" in the git source repository, because\nthe git tests are lots of very short-lived shell-scripts etc.\n\nIt turns out that apparently this same silly vmalloc info gathering\nshows up on the facebook servers too, according to Dave Jones.  So it's\nnot just \"make test\" for git.\n\nWe had two patches to just cache the information (one by me, one by\nIngo) to mitigate this issue, but the whole vmalloc information of of\nrather dubious value to begin with, and people who *actually* want to\nknow what the situation is wrt the vmalloc area should just look at the\nmuch more complete /proc/vmallocinfo instead.\n\nIn fact, according to my testing - and perhaps more importantly,\naccording to that big search engine in the sky: Google - there is\nnothing out there that actually cares about those two expensive fields:\nVmallocUsed and VmallocChunk.\n\nSo let's try to just remove them entirely.  Actually, this just removes\nthe computation and reports the numbers as zero for now, just to try to\nbe minimally intrusive.\n\nIf this breaks anything, we'll obviously have to re-introduce the code\nto compute this all and add the caching patches on top.  But if given\nthe option, I'd really prefer to just remove this bad idea entirely\nrather than add even more code to work around our historical mistake\nthat likely nobody really cares about.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/neobuddy89/shamu/commits/b01bc7aa6b829d6c44a78cb65d52902c1172b8a1"},{"sha":"a1ddf136f7a289fc4067703a44318c66cbde7900","author":{"email":"69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","name":"Linus Torvalds"},"message":"vfs: Fix pathological performance case for __alloc_fd()\n\nAl Viro points out that:\n> >     * [Linux-specific aside] our __alloc_fd() can degrade quite badly\n> > with some use patterns.  The cacheline pingpong in the bitmap is probably\n> > inevitable, unless we accept considerably heavier memory footprint,\n> > but we also have a case when alloc_fd() takes O(n) and it's _not_ hard\n> > to trigger - close(3);open(...); will have the next open() after that\n> > scanning the entire in-use bitmap.\n\nAnd Eric Dumazet has a somewhat realistic multithreaded microbenchmark\nthat opens and closes a lot of sockets with minimal work per socket.\n\nThis patch largely fixes it.  We keep a 2nd-level bitmap of the open\nfile bitmaps, showing which words are already full.  So then we can\ntraverse that second-level bitmap to efficiently skip already allocated\nfile descriptors.\n\nOn his benchmark, this improves performance by up to an order of\nmagnitude, by avoiding the excessive open file bitmap scanning.\n\nTested-and-acked-by: Eric Dumazet <edumazet@google.com>\nCc: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/neobuddy89/shamu/commits/a1ddf136f7a289fc4067703a44318c66cbde7900"},{"sha":"ac18e5e67ead179a629cd4e1571c36c64a89f85b","author":{"email":"69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","name":"Linus Torvalds"},"message":"vfs: conditionally clear close-on-exec flag\n\nWe clear the close-on-exec flag when opening and closing files, and the\nbit was almost always already clear before.  Avoid dirtying the\ncacheline if the clearning isn't necessary.  That avoids unnecessary\ncacheline dirtying and bouncing in multi-socket environments.\n\nEric Dumazet has a file descriptor benchmark that goes 4% faster from\nthis on his two-socket machine.  It's probably partly superlinear\nimprovement due to getting slightly less spinlock contention on the\nfile_lock spinlock due to less work in the critical section.\n\nTested-by: Eric Dumazet <eric.dumazet@gmail.com>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/neobuddy89/shamu/commits/ac18e5e67ead179a629cd4e1571c36c64a89f85b"},{"sha":"f358c677d5065e617da00994610f074545d8f9a9","author":{"email":"bece199d04f3dd7698e386ce6d24b866b933be5a@codeaurora.org","name":"Nikhilesh Reddy"},"message":"ext4: rate limit printk in buffer_io_error()\n\nIf there are a lot of outstanding buffered IOs when a device is\ntaken offline (due to hardware errors etc), ext4_end_bio prints\nout a message for each failed logical block. While this is desirable,\nwe see thousands of such lines being printed out before the\nserial console gets overwhelmed, causing ext4_end_bio() wait for\nthe printk to complete.\n\nThis in itself isn't a disaster, except for the detail that this\nfunction is being called with the queue lock held.\nThis causes any other function in the block layer\nto spin on its spin_lock_irqsave while the serial console is\ndraining. If NMI watchdog is enabled on this machine then it\neventually comes along and shoots the machine in the head.\n\nThe end result is that losing any one disk causes the machine to\ngo down. This patch rate limits the printk to bandaid around the\nproblem.\n\nSigned-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>\nSigned-off-by: Nikhilesh Reddy <reddyn@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/neobuddy89/shamu/commits/f358c677d5065e617da00994610f074545d8f9a9"},{"sha":"5b8c70f47b478307f59a4bb8af106b9a87afd303","author":{"email":"6815899b55edca03f20e8149476f059e0f75e460@motorola.com","name":"Jiangli Yuan"},"message":"sps: add lock protection for pipe list\n\n There is some race condition between iteration over pipe list and\n list_del. Adding list lock protection to avoid kernel panic.\n\nSigned-off-by: Jiangli Yuan <jlyuan@motorola.com>\nReviewed-on: http://gerrit.mot.com/721057\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Sheng-Zhe Zhao <a18689@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/neobuddy89/shamu/commits/5b8c70f47b478307f59a4bb8af106b9a87afd303"},{"sha":"f7bf0e4d3d2dce622a8c2587dec6ae30a0957d2b","author":{"email":"6815899b55edca03f20e8149476f059e0f75e460@motorola.com","name":"Jiangli Yuan"},"message":"sps: make sure pipe active mask match with pipe list status\n\n The pipe may get removed but pipe active mask is not update yet.\n Add protection to make sure those two are matched.\n\nSigned-off-by: Jiangli Yuan <jlyuan@motorola.com>\nReviewed-on: http://gerrit.mot.com/721532\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Zhi-Ming Yuan <a14194@motorola.com>\nReviewed-by: Sheng-Zhe Zhao <a18689@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/neobuddy89/shamu/commits/f7bf0e4d3d2dce622a8c2587dec6ae30a0957d2b"},{"sha":"3577764280cb960d9efadb944c5cf655b68301c9","author":{"email":"6815899b55edca03f20e8149476f059e0f75e460@motorola.com","name":"Jiangli Yuan"},"message":"sps: Always clear pipe irq status before enabling sps irq.\n\n   Clear pipe irq  status before enabling sps irq to avoid spurious sps irq.\n\nSigned-off-by: Jiangli Yuan <jlyuan@motorola.com>\nReviewed-on: http://gerrit.mot.com/753115\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nSME-Granted: SME Approvals Granted\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Zhi-Ming Yuan <a14194@motorola.com>\nReviewed-by: Christopher Fries <cfries@motorola.com>\nReviewed-by: Russell Knize <rknize@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/neobuddy89/shamu/commits/3577764280cb960d9efadb944c5cf655b68301c9"}]}