{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":686867994,"defaultBranch":"14.0.0-sultan","name":"android_kernel_google_gs201","ownerLogin":"kerneltoast","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2023-09-04T05:50:06.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/2985099?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1715582014.0","currentOid":""},"activityList":{"items":[{"before":"901c71ce251be9ff8408e0bd7e55210ea619aaf2","after":"7ecd641cb345b90634e1cc53a9fdcfd280be7917","ref":"refs/heads/14.0.0-sultan","pushedAt":"2024-05-13T06:33:21.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"sched/core: Forbid Unity-based games from changing their CPU affinity\n\nUnity-based games (such as Wild Rift) like to shoot themselves in the foot\nby setting a nonsense CPU affinity, restricting the game to a narrow set of\nCPU cores that it thinks are the \"big\" cores in a heterogeneous CPU. It\nassumes that CPUs only have two performance domains (clusters), and\ntherefore royally mucks up games' CPU affinities on CPUs which have more\nthan two performance domains.\n\nCheck if a setaffinity target task is part of a Unity-based game and\nsilently ignore the setaffinity request so that it can't sabotage itself.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"sched/core: Forbid Unity-based games from changing their CPU affinity"}},{"before":null,"after":"901c71ce251be9ff8408e0bd7e55210ea619aaf2","ref":"refs/heads/14.0.0-sultan","pushedAt":"2023-10-21T04:57:02.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"eh: Make the compression thread freezable to fix suspend death\n\nSince kthreads aren't freezable by default, it's possible for the\ncompression thread to run after the system is frozen and thus after EH has\nbeen suspended. This is a fatal error, because EH hardware can neither\nfinish its work nor be interacted with after it is put to sleep.\n\nSymptoms of the compression thread running after EH is suspended range from\ncomplete system hangs due to the compression thread waiting for EH to\nfinish a compression that got lost during suspend, to kernel panics and\nnon-secure watchdog bites when the compression thread attempts to read EH\nregisters after EH is powered off.\n\nAs such, the compression thread must not run after EH is suspended. Fix\nthis by making the compression thread freezable, so that it must enter the\nrefrigerator before EH can suspend. Participating in system-wide freezing\nalso guarantees the compression thread won't be unfrozen until after EH is\nresumed.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"eh: Make the compression thread freezable to fix suspend death"}},{"before":"fb6699bcbb3d2fe5c73854e387ea1fca689d40e0","after":"efb152477b543924c922a4e1793eab39c6cec127","ref":"refs/heads/13.0.0-sultan","pushedAt":"2023-10-21T04:56:25.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"eh: Make the compression thread freezable to fix suspend death\n\nSince kthreads aren't freezable by default, it's possible for the\ncompression thread to run after the system is frozen and thus after EH has\nbeen suspended. This is a fatal error, because EH hardware can neither\nfinish its work nor be interacted with after it is put to sleep.\n\nSymptoms of the compression thread running after EH is suspended range from\ncomplete system hangs due to the compression thread waiting for EH to\nfinish a compression that got lost during suspend, to kernel panics and\nnon-secure watchdog bites when the compression thread attempts to read EH\nregisters after EH is powered off.\n\nAs such, the compression thread must not run after EH is suspended. Fix\nthis by making the compression thread freezable, so that it must enter the\nrefrigerator before EH can suspend. Participating in system-wide freezing\nalso guarantees the compression thread won't be unfrozen until after EH is\nresumed.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"eh: Make the compression thread freezable to fix suspend death"}},{"before":"b2e92b02bd50773636fe308080e58095ef33b3dd","after":"fb6699bcbb3d2fe5c73854e387ea1fca689d40e0","ref":"refs/heads/13.0.0-sultan","pushedAt":"2023-10-04T07:45:00.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"eh: Fix compression thread deadlock due to nr_request becoming negative\n\nThe \"eh: Make the compression thread more efficient\" patch changed the\norder in which nr_request is incremented with respect to compression\nkickoff. As a result, a narrow window for a race condition opened up which\nmade it possible to deadlock the compression thread.\n\nBecause compression is kicked off before nr_request is incremented, the\ncompression thread may finish processing a new compression request before\nnr_request is incremented for that request. This would then lead to the\ncompression thread looping again on the nr_request != 0 check, and then\ndeadlock forever waiting for a compression completion interrupt that'll\nnever arrive because there are no compression requests in flight.\n\nFix it by restoring the original order in which nr_request is incremented\nwith respect to compression kickoff. There's no actual need for nr_request\nto be incremented after compression kickoff, so this is safe.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"eh: Fix compression thread deadlock due to nr_request becoming negative"}},{"before":null,"after":"b2e92b02bd50773636fe308080e58095ef33b3dd","ref":"refs/heads/13.0.0-sultan","pushedAt":"2023-10-04T04:19:53.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"gs201_defconfig: Enable CASS\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"gs201_defconfig: Enable CASS"}},{"before":"b4dc345b1459c0d0fe5a2f58f748c7a228dbbdfa","after":null,"ref":"refs/heads/13.0.0-sultan","pushedAt":"2023-10-04T04:19:09.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"}},{"before":null,"after":"b4dc345b1459c0d0fe5a2f58f748c7a228dbbdfa","ref":"refs/heads/old/13.0.0-sultan-rt","pushedAt":"2023-10-04T04:19:09.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"vh: sched: Fix prev_cpu check in feec()\n\nThe prev_cpu check in feec() incorrectly checks if prev_cpu is present in\nthe allowed mask, though it may not be present in the candidates mask. If\nit's part of the allowed mask but not the candidates mask, then prev_cpu\nwon't have any statistics computed for it and thus the prev_cpu check can\nincorrectly return prev_cpu even though prev_cpu isn't actually equivalent\nto best_cpu.\n\nFix it by checking if prev_cpu is actually part of the candidates mask\ninstead. Since best_cpu is always removed from the candidates mask by the\ntime prev_cpu is checked, this also means that prev_cpu's presence in\nthe candidates mask implies prev_cpu != best_cpu already.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"vh: sched: Fix prev_cpu check in feec()"}},{"before":"c20e3ebe3aa0dea438bc3b7f9c2aada71baf1b24","after":"b4dc345b1459c0d0fe5a2f58f748c7a228dbbdfa","ref":"refs/heads/13.0.0-sultan","pushedAt":"2023-09-18T04:40:39.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"vh: sched: Fix prev_cpu check in feec()\n\nThe prev_cpu check in feec() incorrectly checks if prev_cpu is present in\nthe allowed mask, though it may not be present in the candidates mask. If\nit's part of the allowed mask but not the candidates mask, then prev_cpu\nwon't have any statistics computed for it and thus the prev_cpu check can\nincorrectly return prev_cpu even though prev_cpu isn't actually equivalent\nto best_cpu.\n\nFix it by checking if prev_cpu is actually part of the candidates mask\ninstead. Since best_cpu is always removed from the candidates mask by the\ntime prev_cpu is checked, this also means that prev_cpu's presence in\nthe candidates mask implies prev_cpu != best_cpu already.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"vh: sched: Fix prev_cpu check in feec()"}},{"before":"1f5335b8960eede7a0677d2f2b2e885599edc87b","after":"c20e3ebe3aa0dea438bc3b7f9c2aada71baf1b24","ref":"refs/heads/13.0.0-sultan","pushedAt":"2023-09-18T04:26:16.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"vh: sched: Fix prev_cpu check in feec()\n\nThe prev_cpu check in feec() incorrectly checks if prev_cpu is present in\nthe allowed mask, though it may not be present in the candidates mask. If\nit's part of the allowed mask but not the candidates mask, then prev_cpu\nwon't have any statistics computed for it and thus the prev_cpu check can\nincorrectly return prev_cpu even though prev_cpu isn't actually equivalent\nto best_cpu.\n\nFix it by checking if prev_cpu is actually part of the candidates mask\ninstead. Since best_cpu is always removed from the candidates mask by the\ntime prev_cpu is checked, this also means that prev_cpu's presence in\nthe candidates mask implies prev_cpu != best_cpu already.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"vh: sched: Fix prev_cpu check in feec()"}},{"before":"f017a1d437bba3cb8307d20aa7b6625b95cf5234","after":"1f5335b8960eede7a0677d2f2b2e885599edc87b","ref":"refs/heads/13.0.0-sultan","pushedAt":"2023-09-17T01:57:57.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"eh: Increase hardware fifo size to 4096 pages\n\nWith real-time scheduling priority for the compression thread, empirical\nmeasurements show that a hardware fifo size of 4096 pages results in the\nhardware fifo never getting exhausted under heavy memory pressure. It's not\ndesirable for the hardware fifo to be exhausted because it means that EH\nisn't doing anything. On the other hand, it's not desirable to set the\nhardware fifo size to EH's supported maximum of 32768 pages because that\nwould consume 128 MiB of RAM to reserve for storing the compression buffer.\n\nUsing 4096 pages consumes only 16 MiB of RAM for the compression buffer and\nmakes it possible to keep EH busy nonstop when memory pressure is high,\nimproving EH utilization and thus zRAM performance.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"eh: Increase hardware fifo size to 4096 pages"}},{"before":"aea5c2ea9ed87c4a327eedb09bfbee2a9dab1b80","after":"f017a1d437bba3cb8307d20aa7b6625b95cf5234","ref":"refs/heads/13.0.0-sultan","pushedAt":"2023-09-14T06:44:48.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"eh: Increase hardware fifo size to 4096 pages\n\nWith real-time scheduling priority for the compression thread, empirical\nmeasurements show that a hardware fifo size of 4096 pages results in the\nhardware fifo never getting exhausted under heavy memory pressure. It's not\ndesirable for the hardware fifo to be exhausted because it means that EH\nisn't doing anything. On the other hand, it's not desirable to set the\nhardware fifo size to EH's supported maximum of 32768 pages because that\nwould consume 128 MiB of RAM to reserve for storing the compression buffer.\n\nUsing 4096 pages consumes only 16 MiB of RAM for the compression buffer and\nmakes it possible to keep EH busy nonstop when memory pressure is high,\nimproving EH utilization and thus zRAM performance.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"eh: Increase hardware fifo size to 4096 pages"}},{"before":"b6c2d11107a7b611aace75fabec77e7f9cf53a08","after":"aea5c2ea9ed87c4a327eedb09bfbee2a9dab1b80","ref":"refs/heads/13.0.0-sultan","pushedAt":"2023-09-04T06:23:06.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"arm64: lse: Always use LSE atomics\n\nSince we are compiling for a single chipset that is known to support LSE,\nthe system_uses_lse_atomics() static branch can be eliminated entirely.\n\nTherefore, make system_uses_lse_atomics() always true to always use LSE\natomics.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"arm64: lse: Always use LSE atomics"}},{"before":null,"after":"b6c2d11107a7b611aace75fabec77e7f9cf53a08","ref":"refs/heads/13.0.0-sultan","pushedAt":"2023-09-04T06:06:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"arm64: lse: Always use LSE atomics\n\nSince we are compiling for a single chipset that is known to support LSE,\nthe system_uses_lse_atomics() static branch can be eliminated entirely.\n\nTherefore, make system_uses_lse_atomics() always true to always use LSE\natomics.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"arm64: lse: Always use LSE atomics"}},{"before":null,"after":"b6c2d11107a7b611aace75fabec77e7f9cf53a08","ref":"refs/heads/13.0.0-sultan","pushedAt":"2023-09-04T06:06:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"arm64: lse: Always use LSE atomics\n\nSince we are compiling for a single chipset that is known to support LSE,\nthe system_uses_lse_atomics() static branch can be eliminated entirely.\n\nTherefore, make system_uses_lse_atomics() always true to always use LSE\natomics.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"arm64: lse: Always use LSE atomics"}},{"before":null,"after":"b6c2d11107a7b611aace75fabec77e7f9cf53a08","ref":"refs/heads/13.0.0-sultan","pushedAt":"2023-09-04T06:06:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"arm64: lse: Always use LSE atomics\n\nSince we are compiling for a single chipset that is known to support LSE,\nthe system_uses_lse_atomics() static branch can be eliminated entirely.\n\nTherefore, make system_uses_lse_atomics() always true to always use LSE\natomics.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"arm64: lse: Always use LSE atomics"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAESBH-WQA","startCursor":null,"endCursor":null}},"title":"Activity · kerneltoast/android_kernel_google_gs201"}