Skip to content

ci: add daily 15:00 PST kernel build - #30

Merged
Bjordis Collaku (bjordiscollaku) merged 1 commit into
mainfrom
ci/daily-kernel-build
Jul 11, 2026
Merged

Bjordis Collaku (bjordiscollaku) merged 1 commit into
mainfrom
ci/daily-kernel-build

Conversation

@bjordiscollaku

@bjordiscollaku Bjordis Collaku (bjordiscollaku) commented Jul 7, 2026 •

Copy link
Copy Markdown
Contributor

Adds a daily scheduled build so resolute-qcom-devel HEAD is built and its .deb
packages uploaded to S3 every day at 15:00 PST, directly from build-kernel.yml
(no separate workflow).

What changed

A single schedule: trigger, nothing else:

schedule:
  - cron: "0 23 * * *"   # 15:00 PST = 23:00 UTC (GitHub cron runs in UTC)

A scheduled run passes no inputs, so the defaults already on main (from #25) do
the rest:

  • SUITE and the checkout ref fall back to resolute-qcom-devel.
  • The runner is the hardcoded lecore-production host.
  • skip_s3 is unset, so the S3 upload step runs.

Net: the nightly build is identical to a default manual "Run workflow" against
resolute-qcom-devel, and it uploads the .deb packages to S3.

Rebased onto post-#25 main. The suite/checkout/S3-gate tweaks this PR used to
carry are now redundant (delivered by #25), so only the schedule: block remains.

@shoudil

Copy link
Copy Markdown
Contributor

Are we ready to switch to canonical dev branch for nightly ?

Add a schedule trigger to build-kernel.yml so resolute-qcom-devel HEAD is
built and uploaded to S3 daily at 15:00 PST (23:00 UTC).

A scheduled run passes no inputs, so the existing defaults apply: SUITE and
the checkout ref fall back to resolute-qcom-devel, the runner is the hardcoded
lecore-production host, and the S3 upload runs because skip_s3 is unset. No
other changes are needed.

Signed-off-by: Bjordis Collaku <bcollaku@qti.qualcomm.com>
@bjordiscollaku
Bjordis Collaku (bjordiscollaku) merged commit 8ccb117 into main Jul 11, 2026
9 checks passed
@bjordiscollaku
Bjordis Collaku (bjordiscollaku) deleted the ci/daily-kernel-build branch July 17, 2026 03:30
github-actions Bot pushed a commit that referenced this pull request Aug 17, 2026
BugLink: https://bugs.launchpad.net/bugs/2161462

commit 114a116aaa5f0295376cdf12da743c5bce3b20ce upstream.

When a thread exits, binder_thread_release() walks its transaction stack
to clear the t->from and t->to_proc that correspond with the exiting
thread. However, a process dying in parallel might attempt to kfree some
of these transactions. And if one of them has no associated t->to_proc,
the t->to_proc->inner_lock will not be acquired.

This means that transaction accesses in binder_thread_release() after
t->to_proc has been cleared might race with binder_free_transaction()
and cause a use-after-free error as reported by KASAN:

  ==================================================================
  BUG: KASAN: slab-use-after-free in binder_thread_release+0x5d0/0x798
  Write of size 8 at addr ffff000016627500 by task X/715

  CPU: 17 UID: 0 PID: 715 Comm: X Not tainted 7.1.0-rc5-00149-g8fde5d1d47f6 #30 PREEMPT
  Hardware name: linux,dummy-virt (DT)
  Call trace:
   binder_thread_release+0x5d0/0x798
   binder_ioctl+0x12c0/0x299c
   [...]

  Allocated by task 717 on cpu 18 at 67.267803s:
   __kasan_kmalloc+0xa0/0xbc
   __kmalloc_cache_noprof+0x174/0x444
   binder_transaction+0x554/0x8150
   binder_thread_write+0xa30/0x4354
   binder_ioctl+0x20f0/0x299c
   [...]

  Freed by task 202 on cpu 18 at 90.416221s:
   __kasan_slab_free+0x58/0x80
   kfree+0x1a0/0x4a4
   binder_free_transaction+0x150/0x294
   binder_send_failed_reply+0x398/0x6d8
   binder_release_work+0x3e4/0x4ec
   binder_deferred_func+0xbd8/0x104c
   [...]
  ==================================================================

In order to avoid this, make sure that binder_free_transaction() reads
the t->to_proc under the transaction lock. This will serialize the
transaction release with the accesses in binder_thread_release(). Plus,
it matches the documented locking rules for @to_proc.

Cc: stable <stable@kernel.org>
Fixes: 7a4408c ("binder: make sure accesses to proc/thread are safe")
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://patch.msgid.link/20260619185233.2194678-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Alice C. Munduruca <alice.munduruca@canonical.com>
Signed-off-by: Edoardo Canepa <edoardo.canepa@canonical.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants