[RFC] Using git-mailbomb as post-commit VCS to email system for glibc-cvs emails?
Checks
Commit Message
Situation:
We currently run AdaCore git hooks to send commit emails when a commit is pushed.
Background:
The AdaCore hooks are large and create a body of code that should be audited
for security because it runs in the most trusted environment when code is committed
and can influence what is committed.
AdaCore Hook configuration has 4 unique stanzas related to sending email from git
hooks, and those stanzas need auditing too.
Assessment:
It is possible to audit the hooks (and all dependencies) to determine if the system
is free from attacker control, but that is a both a costly process, and one which we
aren't doing today.
Recommendation:
It is easiest to remove the hooks for sending email entirely, this reduces the risk
to zero that sending email blocks, fails, or the dependencies of such a system are
used to compromise the VCS.
This avoids any git hooks that need to send email.
If the VCS to email system is compromised it has no access to any other system and
can only send email to the mailing list.
The recommended mechanism after discussion with LF IT, who deploys similar infrastructure
is git-mailbomb:
https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/git-mailbomb-cron.py
For comparison the AdaCore Hooks today output:
https://inbox.sourceware.org/glibc-cvs/20260928155852.3BD464B99F6E@sourceware.org/T/#u
~~~
From: Adhemerval Zanella @ 2026-09-28 15:58 UTC (permalink / raw)
To: glibc-cvs
Subject: [glibc] elf: Only build THP tests for ABIs that define THP-PAGE-SIZE
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=60b925c18fe6436e0885b2be9fde5d8db3688cbb
commit 60b925c18fe6436e0885b2be9fde5d8db3688cbb
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date: Thu Sep 3 13:25:25 2026 -0300
elf: Only build THP tests for ABIs that define THP-PAGE-SIZE
...
~~~
A git-mailbomb example email is as follows:
https://marc.info/?l=git-commits-head&r=1&b=202609&w=2
~~~
From git-commits-head Sun Sep 27 19:49:00 2026
To: git-commits-head
Subject: workqueue: Fix NULL current_pwq deref in flush dependency check
Commit: db6365ced4d5855e321f772b240c0e473bcfcdd5
Parent: 93e257938aa67a6c957217db94091d9d9e5d403f
Refname: refs/heads/master
Web: https://git.kernel.org/torvalds/c/db6365ced4d5855e321f772b240c0e473bcfcdd5
Author: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
AuthorDate: Fri Sep 25 15:25:12 2026 +0530
Committer: Tejun Heo <tj@kernel.org>
CommitDate: Sat Sep 26 22:18:50 2026 -1000
workqueue: Fix NULL current_pwq deref in flush dependency check
check_flush_dependency() uses current_wq_worker() to determine whether
the caller is a workqueue worker and then dereferences worker->current_pwq
to test whether the current workqueue is WQ_MEM_RECLAIM.
current_wq_worker() only means that %current has PF_WQ_WORKER set. A
kworker can reach check_flush_dependency() while it is not executing a
work item. One such path is worker_thread() acting as the pool manager,
where create_worker() does GFP_KERNEL allocation and the allocation path
invokes the OOM notifier. In that state worker->current_pwq is NULL
because current_pwq is set only by process_one_work() and cleared again
after the work function returns.
[ 416.760634][ T375] Call trace:
[ 416.760638][ T375] check_flush_dependency+0x80/0x120 (P)
[ 416.760648][ T375] __flush_work+0x98/0x224
[ 416.760657][ T375] flush_work+0x30/0x44
[ 416.760665][ T375] ...
[ 416.760710][ T375] blocking_notifier_call_chain+0x58/0xa0
[ 416.760719][ T375] out_of_memory+0xb4/0x458
[ 416.760730][ T375] __alloc_pages_may_oom+0x11c/0x1a8
[ 416.760739][ T375] __alloc_pages_slowpath+0x314/0x46c
[ 416.760746][ T375] __alloc_frozen_pages_noprof+0x110/0x1a4
[ 416.760753][ T375] new_slab+0x12c/0x484
[ 416.760759][ T375] ___slab_alloc+0x7a8/0xc7c
[ 416.760765][ T375] __slab_alloc+0x74/0xd8
[ 416.760772][ T375] __kmalloc_cache_node_noprof+0x2ac/0x304
[ 416.760779][ T375] alloc_worker+0x28/0x60
[ 416.760785][ T375] create_worker+0x4c/0x20c
[ 416.760790][ T375] worker_thread+0xe8/0x2b8
[ 416.760796][ T375] kthread+0x1a8/0x200
[ 416.760805][ T375] ret_from_fork+0x10/0x20
Guard the WQ_MEM_RECLAIM-worker warning with worker->current_pwq. If the
kworker is not currently executing a work item, there is no current
workqueue to diagnose with that warning. The PF_MEMALLOC warning is left
unchanged so explicit reclaim context flushing a !WQ_MEM_RECLAIM target
is still reported.
Fixes: fca839c00a12 ("workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
---
kernel/workqueue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
~~~
Two questions:
- Is it acceptable to use git-mailbomb as a solution and stopping using AdaCore hooks?
- Is the output of git-mailbomb acceptable?
The most straight forward isolation is to run this in a cron on a distinct system that
doesn't have any access to the VCS system. The best option is another physical host to
avoid VM escape attacks against high value VCS systems.
Comments
On Mon, Sep 28, 2026 at 4:43 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
> Situation:
>
> We currently run AdaCore git hooks to send commit emails when a commit is pushed.
>
> Background:
>
> The AdaCore hooks are large and create a body of code that should be audited
> for security because it runs in the most trusted environment when code is committed
> and can influence what is committed.
>
> AdaCore Hook configuration has 4 unique stanzas related to sending email from git
> hooks, and those stanzas need auditing too.
>
> Assessment:
>
> It is possible to audit the hooks (and all dependencies) to determine if the system
> is free from attacker control, but that is a both a costly process, and one which we
> aren't doing today.
>
> Recommendation:
>
> It is easiest to remove the hooks for sending email entirely, this reduces the risk
> to zero that sending email blocks, fails, or the dependencies of such a system are
> used to compromise the VCS.
>
> This avoids any git hooks that need to send email.
>
> If the VCS to email system is compromised it has no access to any other system and
> can only send email to the mailing list.
>
> The recommended mechanism after discussion with LF IT, who deploys similar infrastructure
> is git-mailbomb:
> https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/git-mailbomb-cron.py
>
> For comparison the AdaCore Hooks today output:
> https://inbox.sourceware.org/glibc-cvs/20260928155852.3BD464B99F6E@sourceware.org/T/#u
> ~~~
> From: Adhemerval Zanella @ 2026-09-28 15:58 UTC (permalink / raw)
> To: glibc-cvs
> Subject: [glibc] elf: Only build THP tests for ABIs that define THP-PAGE-SIZE
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=60b925c18fe6436e0885b2be9fde5d8db3688cbb
>
> commit 60b925c18fe6436e0885b2be9fde5d8db3688cbb
> Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
> Date: Thu Sep 3 13:25:25 2026 -0300
>
> elf: Only build THP tests for ABIs that define THP-PAGE-SIZE
> ...
> ~~~
>
> A git-mailbomb example email is as follows:
> https://marc.info/?l=git-commits-head&r=1&b=202609&w=2
> ~~~
> From git-commits-head Sun Sep 27 19:49:00 2026
> To: git-commits-head
> Subject: workqueue: Fix NULL current_pwq deref in flush dependency check
>
> Commit: db6365ced4d5855e321f772b240c0e473bcfcdd5
> Parent: 93e257938aa67a6c957217db94091d9d9e5d403f
> Refname: refs/heads/master
> Web: https://git.kernel.org/torvalds/c/db6365ced4d5855e321f772b240c0e473bcfcdd5
> Author: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
> AuthorDate: Fri Sep 25 15:25:12 2026 +0530
> Committer: Tejun Heo <tj@kernel.org>
> CommitDate: Sat Sep 26 22:18:50 2026 -1000
>
> workqueue: Fix NULL current_pwq deref in flush dependency check
>
> check_flush_dependency() uses current_wq_worker() to determine whether
> the caller is a workqueue worker and then dereferences worker->current_pwq
> to test whether the current workqueue is WQ_MEM_RECLAIM.
>
> current_wq_worker() only means that %current has PF_WQ_WORKER set. A
> kworker can reach check_flush_dependency() while it is not executing a
> work item. One such path is worker_thread() acting as the pool manager,
> where create_worker() does GFP_KERNEL allocation and the allocation path
> invokes the OOM notifier. In that state worker->current_pwq is NULL
> because current_pwq is set only by process_one_work() and cleared again
> after the work function returns.
>
> [ 416.760634][ T375] Call trace:
> [ 416.760638][ T375] check_flush_dependency+0x80/0x120 (P)
> [ 416.760648][ T375] __flush_work+0x98/0x224
> [ 416.760657][ T375] flush_work+0x30/0x44
> [ 416.760665][ T375] ...
> [ 416.760710][ T375] blocking_notifier_call_chain+0x58/0xa0
> [ 416.760719][ T375] out_of_memory+0xb4/0x458
> [ 416.760730][ T375] __alloc_pages_may_oom+0x11c/0x1a8
> [ 416.760739][ T375] __alloc_pages_slowpath+0x314/0x46c
> [ 416.760746][ T375] __alloc_frozen_pages_noprof+0x110/0x1a4
> [ 416.760753][ T375] new_slab+0x12c/0x484
> [ 416.760759][ T375] ___slab_alloc+0x7a8/0xc7c
> [ 416.760765][ T375] __slab_alloc+0x74/0xd8
> [ 416.760772][ T375] __kmalloc_cache_node_noprof+0x2ac/0x304
> [ 416.760779][ T375] alloc_worker+0x28/0x60
> [ 416.760785][ T375] create_worker+0x4c/0x20c
> [ 416.760790][ T375] worker_thread+0xe8/0x2b8
> [ 416.760796][ T375] kthread+0x1a8/0x200
> [ 416.760805][ T375] ret_from_fork+0x10/0x20
>
> Guard the WQ_MEM_RECLAIM-worker warning with worker->current_pwq. If the
> kworker is not currently executing a work item, there is no current
> workqueue to diagnose with that warning. The PF_MEMALLOC warning is left
> unchanged so explicit reclaim context flushing a !WQ_MEM_RECLAIM target
> is still reported.
>
> Fixes: fca839c00a12 ("workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> ---
> kernel/workqueue.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index b8bec1689b7a9f..4a73d305d88adf 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -3918,7 +3918,7 @@ static void check_flush_dependency(struct workqueue_struct *target_wq,
> WARN_ONCE(current->flags & PF_MEMALLOC,
> "workqueue: PF_MEMALLOC task %d(%s) is flushing !WQ_MEM_RECLAIM %s:%ps",
> current->pid, current->comm, target_wq->name, target_func);
> - WARN_ONCE(worker && ((worker->current_pwq->wq->flags &
> + WARN_ONCE(worker && worker->current_pwq && ((worker->current_pwq->wq->flags &
> (WQ_MEM_RECLAIM | __WQ_LEGACY)) == WQ_MEM_RECLAIM),
> "workqueue: WQ_MEM_RECLAIM %s:%ps is flushing !WQ_MEM_RECLAIM %s:%ps",
> worker->current_pwq->wq->name, worker->current_func,
>
> ~~~
>
> Two questions:
> - Is it acceptable to use git-mailbomb as a solution and stopping using AdaCore hooks?
> - Is the output of git-mailbomb acceptable?
Does it have 2 forms? One without the patch for the bugzilla or is
there another solution there?
>
> The most straight forward isolation is to run this in a cron on a distinct system that
> doesn't have any access to the VCS system. The best option is another physical host to
> avoid VM escape attacks against high value VCS systems.
Cron jobs is a bad idea. There must be better solutions for that?
Also why not put this into play on sourceware to test out first before
moving it?
>
> --
> Cheers,
> Carlos.
>
On 9/28/26 7:57 PM, Andrea Pinski wrote:
> On Mon, Sep 28, 2026 at 4:43 PM Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> Situation:
>>
>> We currently run AdaCore git hooks to send commit emails when a commit is pushed.
>>
>> Background:
>>
>> The AdaCore hooks are large and create a body of code that should be audited
>> for security because it runs in the most trusted environment when code is committed
>> and can influence what is committed.
>>
>> AdaCore Hook configuration has 4 unique stanzas related to sending email from git
>> hooks, and those stanzas need auditing too.
>>
>> Assessment:
>>
>> It is possible to audit the hooks (and all dependencies) to determine if the system
>> is free from attacker control, but that is a both a costly process, and one which we
>> aren't doing today.
>>
>> Recommendation:
>>
>> It is easiest to remove the hooks for sending email entirely, this reduces the risk
>> to zero that sending email blocks, fails, or the dependencies of such a system are
>> used to compromise the VCS.
>>
>> This avoids any git hooks that need to send email.
>>
>> If the VCS to email system is compromised it has no access to any other system and
>> can only send email to the mailing list.
>>
>> The recommended mechanism after discussion with LF IT, who deploys similar infrastructure
>> is git-mailbomb:
>> https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/git-mailbomb-cron.py
>>
>> For comparison the AdaCore Hooks today output:
>> https://inbox.sourceware.org/glibc-cvs/20260928155852.3BD464B99F6E@sourceware.org/T/#u
>> ~~~
>> From: Adhemerval Zanella @ 2026-09-28 15:58 UTC (permalink / raw)
>> To: glibc-cvs
>> Subject: [glibc] elf: Only build THP tests for ABIs that define THP-PAGE-SIZE
>> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=60b925c18fe6436e0885b2be9fde5d8db3688cbb
>>
>> commit 60b925c18fe6436e0885b2be9fde5d8db3688cbb
>> Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
>> Date: Thu Sep 3 13:25:25 2026 -0300
>>
>> elf: Only build THP tests for ABIs that define THP-PAGE-SIZE
>> ...
>> ~~~
>>
>> A git-mailbomb example email is as follows:
>> https://marc.info/?l=git-commits-head&r=1&b=202609&w=2
>> ~~~
>> From git-commits-head Sun Sep 27 19:49:00 2026
>> To: git-commits-head
>> Subject: workqueue: Fix NULL current_pwq deref in flush dependency check
>>
>> Commit: db6365ced4d5855e321f772b240c0e473bcfcdd5
>> Parent: 93e257938aa67a6c957217db94091d9d9e5d403f
>> Refname: refs/heads/master
>> Web: https://git.kernel.org/torvalds/c/db6365ced4d5855e321f772b240c0e473bcfcdd5
>> Author: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
>> AuthorDate: Fri Sep 25 15:25:12 2026 +0530
>> Committer: Tejun Heo <tj@kernel.org>
>> CommitDate: Sat Sep 26 22:18:50 2026 -1000
>>
>> workqueue: Fix NULL current_pwq deref in flush dependency check
>>
>> check_flush_dependency() uses current_wq_worker() to determine whether
>> the caller is a workqueue worker and then dereferences worker->current_pwq
>> to test whether the current workqueue is WQ_MEM_RECLAIM.
>>
>> current_wq_worker() only means that %current has PF_WQ_WORKER set. A
>> kworker can reach check_flush_dependency() while it is not executing a
>> work item. One such path is worker_thread() acting as the pool manager,
>> where create_worker() does GFP_KERNEL allocation and the allocation path
>> invokes the OOM notifier. In that state worker->current_pwq is NULL
>> because current_pwq is set only by process_one_work() and cleared again
>> after the work function returns.
>>
>> [ 416.760634][ T375] Call trace:
>> [ 416.760638][ T375] check_flush_dependency+0x80/0x120 (P)
>> [ 416.760648][ T375] __flush_work+0x98/0x224
>> [ 416.760657][ T375] flush_work+0x30/0x44
>> [ 416.760665][ T375] ...
>> [ 416.760710][ T375] blocking_notifier_call_chain+0x58/0xa0
>> [ 416.760719][ T375] out_of_memory+0xb4/0x458
>> [ 416.760730][ T375] __alloc_pages_may_oom+0x11c/0x1a8
>> [ 416.760739][ T375] __alloc_pages_slowpath+0x314/0x46c
>> [ 416.760746][ T375] __alloc_frozen_pages_noprof+0x110/0x1a4
>> [ 416.760753][ T375] new_slab+0x12c/0x484
>> [ 416.760759][ T375] ___slab_alloc+0x7a8/0xc7c
>> [ 416.760765][ T375] __slab_alloc+0x74/0xd8
>> [ 416.760772][ T375] __kmalloc_cache_node_noprof+0x2ac/0x304
>> [ 416.760779][ T375] alloc_worker+0x28/0x60
>> [ 416.760785][ T375] create_worker+0x4c/0x20c
>> [ 416.760790][ T375] worker_thread+0xe8/0x2b8
>> [ 416.760796][ T375] kthread+0x1a8/0x200
>> [ 416.760805][ T375] ret_from_fork+0x10/0x20
>>
>> Guard the WQ_MEM_RECLAIM-worker warning with worker->current_pwq. If the
>> kworker is not currently executing a work item, there is no current
>> workqueue to diagnose with that warning. The PF_MEMALLOC warning is left
>> unchanged so explicit reclaim context flushing a !WQ_MEM_RECLAIM target
>> is still reported.
>>
>> Fixes: fca839c00a12 ("workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue")
>> Cc: stable@vger.kernel.org
>> Assisted-by: LLM
>> Signed-off-by: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
>> Signed-off-by: Tejun Heo <tj@kernel.org>
>> ---
>> kernel/workqueue.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
>> index b8bec1689b7a9f..4a73d305d88adf 100644
>> --- a/kernel/workqueue.c
>> +++ b/kernel/workqueue.c
>> @@ -3918,7 +3918,7 @@ static void check_flush_dependency(struct workqueue_struct *target_wq,
>> WARN_ONCE(current->flags & PF_MEMALLOC,
>> "workqueue: PF_MEMALLOC task %d(%s) is flushing !WQ_MEM_RECLAIM %s:%ps",
>> current->pid, current->comm, target_wq->name, target_func);
>> - WARN_ONCE(worker && ((worker->current_pwq->wq->flags &
>> + WARN_ONCE(worker && worker->current_pwq && ((worker->current_pwq->wq->flags &
>> (WQ_MEM_RECLAIM | __WQ_LEGACY)) == WQ_MEM_RECLAIM),
>> "workqueue: WQ_MEM_RECLAIM %s:%ps is flushing !WQ_MEM_RECLAIM %s:%ps",
>> worker->current_pwq->wq->name, worker->current_func,
>>
>> ~~~
>>
>> Two questions:
>> - Is it acceptable to use git-mailbomb as a solution and stopping using AdaCore hooks?
>> - Is the output of git-mailbomb acceptable?
>
> Does it have 2 forms? One without the patch for the bugzilla or is
> there another solution there?
The bugzilla update RFC is here:
https://inbox.sourceware.org/libc-alpha/a1c0fb87-de0f-40da-a917-25520839d209@redhat.com/T/#u
It's a distinct system from the VCS to email solution.
>>
>> The most straight forward isolation is to run this in a cron on a distinct system that
>> doesn't have any access to the VCS system. The best option is another physical host to
>> avoid VM escape attacks against high value VCS systems.
>
> Cron jobs is a bad idea. There must be better solutions for that?
May you please expand on that a bit more?
> Also why not put this into play on sourceware to test out first before
> moving it?
Sorry, do you mean test deploying the solution for a temporary project?
Or do you mean something else?
On Mon, Sep 28, 2026 at 5:04 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 9/28/26 7:57 PM, Andrea Pinski wrote:
> > On Mon, Sep 28, 2026 at 4:43 PM Carlos O'Donell <carlos@redhat.com> wrote:
> >>
> >> Situation:
> >>
> >> We currently run AdaCore git hooks to send commit emails when a commit is pushed.
> >>
> >> Background:
> >>
> >> The AdaCore hooks are large and create a body of code that should be audited
> >> for security because it runs in the most trusted environment when code is committed
> >> and can influence what is committed.
> >>
> >> AdaCore Hook configuration has 4 unique stanzas related to sending email from git
> >> hooks, and those stanzas need auditing too.
> >>
> >> Assessment:
> >>
> >> It is possible to audit the hooks (and all dependencies) to determine if the system
> >> is free from attacker control, but that is a both a costly process, and one which we
> >> aren't doing today.
> >>
> >> Recommendation:
> >>
> >> It is easiest to remove the hooks for sending email entirely, this reduces the risk
> >> to zero that sending email blocks, fails, or the dependencies of such a system are
> >> used to compromise the VCS.
> >>
> >> This avoids any git hooks that need to send email.
> >>
> >> If the VCS to email system is compromised it has no access to any other system and
> >> can only send email to the mailing list.
> >>
> >> The recommended mechanism after discussion with LF IT, who deploys similar infrastructure
> >> is git-mailbomb:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/git-mailbomb-cron.py
> >>
> >> For comparison the AdaCore Hooks today output:
> >> https://inbox.sourceware.org/glibc-cvs/20260928155852.3BD464B99F6E@sourceware.org/T/#u
> >> ~~~
> >> From: Adhemerval Zanella @ 2026-09-28 15:58 UTC (permalink / raw)
> >> To: glibc-cvs
> >> Subject: [glibc] elf: Only build THP tests for ABIs that define THP-PAGE-SIZE
> >> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=60b925c18fe6436e0885b2be9fde5d8db3688cbb
> >>
> >> commit 60b925c18fe6436e0885b2be9fde5d8db3688cbb
> >> Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
> >> Date: Thu Sep 3 13:25:25 2026 -0300
> >>
> >> elf: Only build THP tests for ABIs that define THP-PAGE-SIZE
> >> ...
> >> ~~~
> >>
> >> A git-mailbomb example email is as follows:
> >> https://marc.info/?l=git-commits-head&r=1&b=202609&w=2
> >> ~~~
> >> From git-commits-head Sun Sep 27 19:49:00 2026
> >> To: git-commits-head
> >> Subject: workqueue: Fix NULL current_pwq deref in flush dependency check
> >>
> >> Commit: db6365ced4d5855e321f772b240c0e473bcfcdd5
> >> Parent: 93e257938aa67a6c957217db94091d9d9e5d403f
> >> Refname: refs/heads/master
> >> Web: https://git.kernel.org/torvalds/c/db6365ced4d5855e321f772b240c0e473bcfcdd5
> >> Author: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
> >> AuthorDate: Fri Sep 25 15:25:12 2026 +0530
> >> Committer: Tejun Heo <tj@kernel.org>
> >> CommitDate: Sat Sep 26 22:18:50 2026 -1000
> >>
> >> workqueue: Fix NULL current_pwq deref in flush dependency check
> >>
> >> check_flush_dependency() uses current_wq_worker() to determine whether
> >> the caller is a workqueue worker and then dereferences worker->current_pwq
> >> to test whether the current workqueue is WQ_MEM_RECLAIM.
> >>
> >> current_wq_worker() only means that %current has PF_WQ_WORKER set. A
> >> kworker can reach check_flush_dependency() while it is not executing a
> >> work item. One such path is worker_thread() acting as the pool manager,
> >> where create_worker() does GFP_KERNEL allocation and the allocation path
> >> invokes the OOM notifier. In that state worker->current_pwq is NULL
> >> because current_pwq is set only by process_one_work() and cleared again
> >> after the work function returns.
> >>
> >> [ 416.760634][ T375] Call trace:
> >> [ 416.760638][ T375] check_flush_dependency+0x80/0x120 (P)
> >> [ 416.760648][ T375] __flush_work+0x98/0x224
> >> [ 416.760657][ T375] flush_work+0x30/0x44
> >> [ 416.760665][ T375] ...
> >> [ 416.760710][ T375] blocking_notifier_call_chain+0x58/0xa0
> >> [ 416.760719][ T375] out_of_memory+0xb4/0x458
> >> [ 416.760730][ T375] __alloc_pages_may_oom+0x11c/0x1a8
> >> [ 416.760739][ T375] __alloc_pages_slowpath+0x314/0x46c
> >> [ 416.760746][ T375] __alloc_frozen_pages_noprof+0x110/0x1a4
> >> [ 416.760753][ T375] new_slab+0x12c/0x484
> >> [ 416.760759][ T375] ___slab_alloc+0x7a8/0xc7c
> >> [ 416.760765][ T375] __slab_alloc+0x74/0xd8
> >> [ 416.760772][ T375] __kmalloc_cache_node_noprof+0x2ac/0x304
> >> [ 416.760779][ T375] alloc_worker+0x28/0x60
> >> [ 416.760785][ T375] create_worker+0x4c/0x20c
> >> [ 416.760790][ T375] worker_thread+0xe8/0x2b8
> >> [ 416.760796][ T375] kthread+0x1a8/0x200
> >> [ 416.760805][ T375] ret_from_fork+0x10/0x20
> >>
> >> Guard the WQ_MEM_RECLAIM-worker warning with worker->current_pwq. If the
> >> kworker is not currently executing a work item, there is no current
> >> workqueue to diagnose with that warning. The PF_MEMALLOC warning is left
> >> unchanged so explicit reclaim context flushing a !WQ_MEM_RECLAIM target
> >> is still reported.
> >>
> >> Fixes: fca839c00a12 ("workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue")
> >> Cc: stable@vger.kernel.org
> >> Assisted-by: LLM
> >> Signed-off-by: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
> >> Signed-off-by: Tejun Heo <tj@kernel.org>
> >> ---
> >> kernel/workqueue.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> >> index b8bec1689b7a9f..4a73d305d88adf 100644
> >> --- a/kernel/workqueue.c
> >> +++ b/kernel/workqueue.c
> >> @@ -3918,7 +3918,7 @@ static void check_flush_dependency(struct workqueue_struct *target_wq,
> >> WARN_ONCE(current->flags & PF_MEMALLOC,
> >> "workqueue: PF_MEMALLOC task %d(%s) is flushing !WQ_MEM_RECLAIM %s:%ps",
> >> current->pid, current->comm, target_wq->name, target_func);
> >> - WARN_ONCE(worker && ((worker->current_pwq->wq->flags &
> >> + WARN_ONCE(worker && worker->current_pwq && ((worker->current_pwq->wq->flags &
> >> (WQ_MEM_RECLAIM | __WQ_LEGACY)) == WQ_MEM_RECLAIM),
> >> "workqueue: WQ_MEM_RECLAIM %s:%ps is flushing !WQ_MEM_RECLAIM %s:%ps",
> >> worker->current_pwq->wq->name, worker->current_func,
> >>
> >> ~~~
> >>
> >> Two questions:
> >> - Is it acceptable to use git-mailbomb as a solution and stopping using AdaCore hooks?
> >> - Is the output of git-mailbomb acceptable?
> >
> > Does it have 2 forms? One without the patch for the bugzilla or is
> > there another solution there?
>
> The bugzilla update RFC is here:
> https://inbox.sourceware.org/libc-alpha/a1c0fb87-de0f-40da-a917-25520839d209@redhat.com/T/#u
>
> It's a distinct system from the VCS to email solution.
Why? They basically do the same thing. Why do they have to be
different? Running things twice is a huge waste of resources.
> >>
> >> The most straight forward isolation is to run this in a cron on a distinct system that
> >> doesn't have any access to the VCS system. The best option is another physical host to
> >> avoid VM escape attacks against high value VCS systems.
> >
> > Cron jobs is a bad idea. There must be better solutions for that?
>
> May you please expand on that a bit more?
I am saying there should be some kind of git notifications happening
to sign to another machine that a push has happened. Doing it via
cron seems like a workaround for not having push notifications and a
bad workaround in general.
>
> > Also why not put this into play on sourceware to test out first before
> > moving it?
>
> Sorry, do you mean test deploying the solution for a temporary project?
>
> Or do you mean something else?
Or a permanent solution. Why not move away from Ada-hooks long before
trying to change the hosting env?
That has always been my question. Why merge both things this way? Why
do things in steps?
I keep on asking why do both things at once? That is so much more risk
than doing things in steps and easier to move back if needed at any
step rather than pushing everything at once.
This is standard practice even in development. Why not here?
>
> --
> Cheers,
> Carlos.
>
On Mon, Sep 28, 2026, at 8:13 PM, Andrea Pinski wrote:
> On Mon, Sep 28, 2026 at 5:04 PM Carlos O'Donell
> <carlos@redhat.com> wrote:
>> Sorry, do you mean test deploying the solution for a temporary
>> project? Or do you mean something else?
>
> Or a permanent solution. Why not move away from Ada-hooks long before
> trying to change the hosting env? That has always been my question.
> Why merge both things this way? Why do things in steps? I keep on
> asking why do both things at once? That is so much more risk than
> doing things in steps and easier to move back if needed at any step
> rather than pushing everything at once.
I fully agree with Andrea's position here.
Besides the obvious benefits to doing things in small steps, it seems
to me that the only part of "let's pack up glibc and move to LF IT
hosting and then revamp how the project's infrastructure works so it's
more secure and more maintainable" that's actually *controversial* is
the "move to LF IT" part.
So how about we *postpone* that part, and come back to it after the
uncontroversial "revamp the infra to be more secure and maintainable"
part is *done*? We may discover during the revamp that the move isn't
actually necessary, or contrariwise we may discover any number of
concrete reasons why we *need* more than what Sourceware can give us,
and either way that would ground the argument over whether LF IT is
really so much of an improvement over Sourceware in much harder facts
than have so far been on offer.
zw
* Carlos O'Donell:
> - Is it acceptable to use git-mailbomb as a solution and stopping
> using AdaCore hooks?
Does this apply to just the email-sending functionality in the AdaCore
hooks, or their other functionality as well?
> - Is the output of git-mailbomb acceptable?
How does it handle non-ASCII characters?
Is it really necessary to switch to cron job with its delays? Could we
just use inotify with read-only access to the repository?
Thanks,
Florian
Carlos O'Donell <carlos@redhat.com> writes:
> Situation:
>
> We currently run AdaCore git hooks to send commit emails when a commit is pushed.
>
> Background:
>
> The AdaCore hooks are large and create a body of code that should be audited
> for security because it runs in the most trusted environment when code is committed
> and can influence what is committed.
>
> AdaCore Hook configuration has 4 unique stanzas related to sending email from git
> hooks, and those stanzas need auditing too.
>
> Assessment:
>
> It is possible to audit the hooks (and all dependencies) to determine if the system
> is free from attacker control, but that is a both a costly process, and one which we
> aren't doing today.
>
> Recommendation:
>
> It is easiest to remove the hooks for sending email entirely, this reduces the risk
> to zero that sending email blocks, fails, or the dependencies of such a system are
> used to compromise the VCS.
>
> This avoids any git hooks that need to send email.
>
> If the VCS to email system is compromised it has no access to any other system and
> can only send email to the mailing list.
>
> The recommended mechanism after discussion with LF IT, who deploys similar infrastructure
> is git-mailbomb:
> https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/git-mailbomb-cron.py
OK, so like with Bugspray, not a hook anymore, but still run
server-side. That's important as it serves as a transparent read-only
log of actions.
(We've also found this useful over the years in Gentoo for some ancient
repos or branches that were lost to time, for recovering commits.)
>
> For comparison the AdaCore Hooks today output:
> https://inbox.sourceware.org/glibc-cvs/20260928155852.3BD464B99F6E@sourceware.org/T/#u
> ~~~
> From: Adhemerval Zanella @ 2026-09-28 15:58 UTC (permalink / raw)
> To: glibc-cvs
> Subject: [glibc] elf: Only build THP tests for ABIs that define THP-PAGE-SIZE
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=60b925c18fe6436e0885b2be9fde5d8db3688cbb
>
> commit 60b925c18fe6436e0885b2be9fde5d8db3688cbb
> Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
> Date: Thu Sep 3 13:25:25 2026 -0300
>
> elf: Only build THP tests for ABIs that define THP-PAGE-SIZE
> ...
> ~~~
>
> A git-mailbomb example email is as follows:
> https://marc.info/?l=git-commits-head&r=1&b=202609&w=2
> ~~~
> From git-commits-head Sun Sep 27 19:49:00 2026
> To: git-commits-head
> Subject: workqueue: Fix NULL current_pwq deref in flush dependency check
>
> Commit: db6365ced4d5855e321f772b240c0e473bcfcdd5
> Parent: 93e257938aa67a6c957217db94091d9d9e5d403f
> Refname: refs/heads/master
> Web: https://git.kernel.org/torvalds/c/db6365ced4d5855e321f772b240c0e473bcfcdd5
> Author: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
> AuthorDate: Fri Sep 25 15:25:12 2026 +0530
> Committer: Tejun Heo <tj@kernel.org>
> CommitDate: Sat Sep 26 22:18:50 2026 -1000
>
> workqueue: Fix NULL current_pwq deref in flush dependency check
> check_flush_dependency() uses current_wq_worker() to
> determine whether
> the caller is a workqueue worker and then dereferences worker->current_pwq
> to test whether the current workqueue is WQ_MEM_RECLAIM.
> current_wq_worker() only means that %current has PF_WQ_WORKER
> set. A
> kworker can reach check_flush_dependency() while it is not executing a
> work item. One such path is worker_thread() acting as the pool manager,
> where create_worker() does GFP_KERNEL allocation and the allocation path
> invokes the OOM notifier. In that state worker->current_pwq is NULL
> because current_pwq is set only by process_one_work() and cleared again
> after the work function returns.
> [ 416.760634][ T375] Call trace:
> [ 416.760638][ T375] check_flush_dependency+0x80/0x120 (P)
> [ 416.760648][ T375] __flush_work+0x98/0x224
> [ 416.760657][ T375] flush_work+0x30/0x44
> [ 416.760665][ T375] ...
> [ 416.760710][ T375] blocking_notifier_call_chain+0x58/0xa0
> [ 416.760719][ T375] out_of_memory+0xb4/0x458
> [ 416.760730][ T375] __alloc_pages_may_oom+0x11c/0x1a8
> [ 416.760739][ T375] __alloc_pages_slowpath+0x314/0x46c
> [ 416.760746][ T375] __alloc_frozen_pages_noprof+0x110/0x1a4
> [ 416.760753][ T375] new_slab+0x12c/0x484
> [ 416.760759][ T375] ___slab_alloc+0x7a8/0xc7c
> [ 416.760765][ T375] __slab_alloc+0x74/0xd8
> [ 416.760772][ T375] __kmalloc_cache_node_noprof+0x2ac/0x304
> [ 416.760779][ T375] alloc_worker+0x28/0x60
> [ 416.760785][ T375] create_worker+0x4c/0x20c
> [ 416.760790][ T375] worker_thread+0xe8/0x2b8
> [ 416.760796][ T375] kthread+0x1a8/0x200
> [ 416.760805][ T375] ret_from_fork+0x10/0x20
> Guard the WQ_MEM_RECLAIM-worker warning with
> worker->current_pwq. If the
> kworker is not currently executing a work item, there is no current
> workqueue to diagnose with that warning. The PF_MEMALLOC warning is left
> unchanged so explicit reclaim context flushing a !WQ_MEM_RECLAIM target
> is still reported.
> Fixes: fca839c00a12 ("workqueue: warn if memory reclaim tries
> to flush !WQ_MEM_RECLAIM workqueue")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> ---
> kernel/workqueue.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index b8bec1689b7a9f..4a73d305d88adf 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -3918,7 +3918,7 @@ static void check_flush_dependency(struct workqueue_struct *target_wq,
> WARN_ONCE(current->flags & PF_MEMALLOC,
> "workqueue: PF_MEMALLOC task %d(%s) is flushing !WQ_MEM_RECLAIM %s:%ps",
> current->pid, current->comm, target_wq->name, target_func);
> - WARN_ONCE(worker && ((worker->current_pwq->wq->flags &
> + WARN_ONCE(worker && worker->current_pwq && ((worker->current_pwq->wq->flags &
> (WQ_MEM_RECLAIM | __WQ_LEGACY)) == WQ_MEM_RECLAIM),
> "workqueue: WQ_MEM_RECLAIM %s:%ps is flushing !WQ_MEM_RECLAIM %s:%ps",
> worker->current_pwq->wq->name, worker->current_func,
>
> ~~~
>
> Two questions:
> - Is it acceptable to use git-mailbomb as a solution and stopping using AdaCore hooks?
> - Is the output of git-mailbomb acceptable?
>
> The most straight forward isolation is to run this in a cron on a distinct system that
> doesn't have any access to the VCS system. The best option is another physical host to
> avoid VM escape attacks against high value VCS systems.
A cron seems unfortunate as it isn't immediate.
We use local/post-receive.gentoo-commits [0] to send to the
'gentoo-commits' ML as a hook.
[0] https://gitweb.gentoo.org/infra/githooks.git/tree/local/post-receive.gentoo-commits
sam
On Mon, 28 Sep 2026, Carlos O'Donell wrote:
> Two questions:
> - Is it acceptable to use git-mailbomb as a solution and stopping using
> AdaCore hooks?
> - Is the output of git-mailbomb acceptable?
The present emails include information about who (what user account)
pushed the ref update. Can the new system
(a) log that information for each ref update;
(b) make that append-only log public;
(c) include the information in commit emails resulting from the ref
update?
On 9/28/26 8:13 PM, Andrea Pinski wrote:
> On Mon, Sep 28, 2026 at 5:04 PM Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> On 9/28/26 7:57 PM, Andrea Pinski wrote:
>>> On Mon, Sep 28, 2026 at 4:43 PM Carlos O'Donell <carlos@redhat.com> wrote:
>>>>
>>>> Situation:
>>>>
>>>> We currently run AdaCore git hooks to send commit emails when a commit is pushed.
>>>>
>>>> Background:
>>>>
>>>> The AdaCore hooks are large and create a body of code that should be audited
>>>> for security because it runs in the most trusted environment when code is committed
>>>> and can influence what is committed.
>>>>
>>>> AdaCore Hook configuration has 4 unique stanzas related to sending email from git
>>>> hooks, and those stanzas need auditing too.
>>>>
>>>> Assessment:
>>>>
>>>> It is possible to audit the hooks (and all dependencies) to determine if the system
>>>> is free from attacker control, but that is a both a costly process, and one which we
>>>> aren't doing today.
>>>>
>>>> Recommendation:
>>>>
>>>> It is easiest to remove the hooks for sending email entirely, this reduces the risk
>>>> to zero that sending email blocks, fails, or the dependencies of such a system are
>>>> used to compromise the VCS.
>>>>
>>>> This avoids any git hooks that need to send email.
>>>>
>>>> If the VCS to email system is compromised it has no access to any other system and
>>>> can only send email to the mailing list.
>>>>
>>>> The recommended mechanism after discussion with LF IT, who deploys similar infrastructure
>>>> is git-mailbomb:
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/git-mailbomb-cron.py
>>>>
>>>> For comparison the AdaCore Hooks today output:
>>>> https://inbox.sourceware.org/glibc-cvs/20260928155852.3BD464B99F6E@sourceware.org/T/#u
>>>> ~~~
>>>> From: Adhemerval Zanella @ 2026-09-28 15:58 UTC (permalink / raw)
>>>> To: glibc-cvs
>>>> Subject: [glibc] elf: Only build THP tests for ABIs that define THP-PAGE-SIZE
>>>> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=60b925c18fe6436e0885b2be9fde5d8db3688cbb
>>>>
>>>> commit 60b925c18fe6436e0885b2be9fde5d8db3688cbb
>>>> Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
>>>> Date: Thu Sep 3 13:25:25 2026 -0300
>>>>
>>>> elf: Only build THP tests for ABIs that define THP-PAGE-SIZE
>>>> ...
>>>> ~~~
>>>>
>>>> A git-mailbomb example email is as follows:
>>>> https://marc.info/?l=git-commits-head&r=1&b=202609&w=2
>>>> ~~~
>>>> From git-commits-head Sun Sep 27 19:49:00 2026
>>>> To: git-commits-head
>>>> Subject: workqueue: Fix NULL current_pwq deref in flush dependency check
>>>>
>>>> Commit: db6365ced4d5855e321f772b240c0e473bcfcdd5
>>>> Parent: 93e257938aa67a6c957217db94091d9d9e5d403f
>>>> Refname: refs/heads/master
>>>> Web: https://git.kernel.org/torvalds/c/db6365ced4d5855e321f772b240c0e473bcfcdd5
>>>> Author: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
>>>> AuthorDate: Fri Sep 25 15:25:12 2026 +0530
>>>> Committer: Tejun Heo <tj@kernel.org>
>>>> CommitDate: Sat Sep 26 22:18:50 2026 -1000
>>>>
>>>> workqueue: Fix NULL current_pwq deref in flush dependency check
>>>>
>>>> check_flush_dependency() uses current_wq_worker() to determine whether
>>>> the caller is a workqueue worker and then dereferences worker->current_pwq
>>>> to test whether the current workqueue is WQ_MEM_RECLAIM.
>>>>
>>>> current_wq_worker() only means that %current has PF_WQ_WORKER set. A
>>>> kworker can reach check_flush_dependency() while it is not executing a
>>>> work item. One such path is worker_thread() acting as the pool manager,
>>>> where create_worker() does GFP_KERNEL allocation and the allocation path
>>>> invokes the OOM notifier. In that state worker->current_pwq is NULL
>>>> because current_pwq is set only by process_one_work() and cleared again
>>>> after the work function returns.
>>>>
>>>> [ 416.760634][ T375] Call trace:
>>>> [ 416.760638][ T375] check_flush_dependency+0x80/0x120 (P)
>>>> [ 416.760648][ T375] __flush_work+0x98/0x224
>>>> [ 416.760657][ T375] flush_work+0x30/0x44
>>>> [ 416.760665][ T375] ...
>>>> [ 416.760710][ T375] blocking_notifier_call_chain+0x58/0xa0
>>>> [ 416.760719][ T375] out_of_memory+0xb4/0x458
>>>> [ 416.760730][ T375] __alloc_pages_may_oom+0x11c/0x1a8
>>>> [ 416.760739][ T375] __alloc_pages_slowpath+0x314/0x46c
>>>> [ 416.760746][ T375] __alloc_frozen_pages_noprof+0x110/0x1a4
>>>> [ 416.760753][ T375] new_slab+0x12c/0x484
>>>> [ 416.760759][ T375] ___slab_alloc+0x7a8/0xc7c
>>>> [ 416.760765][ T375] __slab_alloc+0x74/0xd8
>>>> [ 416.760772][ T375] __kmalloc_cache_node_noprof+0x2ac/0x304
>>>> [ 416.760779][ T375] alloc_worker+0x28/0x60
>>>> [ 416.760785][ T375] create_worker+0x4c/0x20c
>>>> [ 416.760790][ T375] worker_thread+0xe8/0x2b8
>>>> [ 416.760796][ T375] kthread+0x1a8/0x200
>>>> [ 416.760805][ T375] ret_from_fork+0x10/0x20
>>>>
>>>> Guard the WQ_MEM_RECLAIM-worker warning with worker->current_pwq. If the
>>>> kworker is not currently executing a work item, there is no current
>>>> workqueue to diagnose with that warning. The PF_MEMALLOC warning is left
>>>> unchanged so explicit reclaim context flushing a !WQ_MEM_RECLAIM target
>>>> is still reported.
>>>>
>>>> Fixes: fca839c00a12 ("workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue")
>>>> Cc: stable@vger.kernel.org
>>>> Assisted-by: LLM
>>>> Signed-off-by: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
>>>> Signed-off-by: Tejun Heo <tj@kernel.org>
>>>> ---
>>>> kernel/workqueue.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
>>>> index b8bec1689b7a9f..4a73d305d88adf 100644
>>>> --- a/kernel/workqueue.c
>>>> +++ b/kernel/workqueue.c
>>>> @@ -3918,7 +3918,7 @@ static void check_flush_dependency(struct workqueue_struct *target_wq,
>>>> WARN_ONCE(current->flags & PF_MEMALLOC,
>>>> "workqueue: PF_MEMALLOC task %d(%s) is flushing !WQ_MEM_RECLAIM %s:%ps",
>>>> current->pid, current->comm, target_wq->name, target_func);
>>>> - WARN_ONCE(worker && ((worker->current_pwq->wq->flags &
>>>> + WARN_ONCE(worker && worker->current_pwq && ((worker->current_pwq->wq->flags &
>>>> (WQ_MEM_RECLAIM | __WQ_LEGACY)) == WQ_MEM_RECLAIM),
>>>> "workqueue: WQ_MEM_RECLAIM %s:%ps is flushing !WQ_MEM_RECLAIM %s:%ps",
>>>> worker->current_pwq->wq->name, worker->current_func,
>>>>
>>>> ~~~
>>>>
>>>> Two questions:
>>>> - Is it acceptable to use git-mailbomb as a solution and stopping using AdaCore hooks?
>>>> - Is the output of git-mailbomb acceptable?
>>>
>>> Does it have 2 forms? One without the patch for the bugzilla or is
>>> there another solution there?
>>
>> The bugzilla update RFC is here:
>> https://inbox.sourceware.org/libc-alpha/a1c0fb87-de0f-40da-a917-25520839d209@redhat.com/T/#u
>>
>> It's a distinct system from the VCS to email solution.
>
> Why? They basically do the same thing. Why do they have to be
> different? Running things twice is a huge waste of resources.
Can you quantify "huge waste of resources."?
In this case it would be at worst a small VM on a distinct host?
Running a git pull every minute or less?
That seems a fairly small amount of resources.
>>>>
>>>> The most straight forward isolation is to run this in a cron on a distinct system that
>>>> doesn't have any access to the VCS system. The best option is another physical host to
>>>> avoid VM escape attacks against high value VCS systems.
>>>
>>> Cron jobs is a bad idea. There must be better solutions for that?
>>
>> May you please expand on that a bit more?
>
> I am saying there should be some kind of git notifications happening
> to sign to another machine that a push has happened. Doing it via
> cron seems like a workaround for not having push notifications and a
> bad workaround in general.
Notification systems are designed to reduce the need to poll when there are
a high frequency of events. A system registers itself as a listener in order
to get notifications and then sleeps on that object to avoid polling.
This kind of notifier and registered listener system is usually only
designed when the update rate is very high, and polling costs a lot of cpu
time. It is also fragile in that missed wakeups cause missed updates.
In the case of the GNU Toolchain the gcc project probably has the fastest
update rate of ~1 commit an hour, so it seems conceptually more than needed
to tie the systems together with a notification loop as you suggest.
The cron could run every minute which means at most 60s delay between push
and VCS email.
Ultimately I think it is more robust to just poll. There is no failure
scenario present when the notifier fails to wake the waiter due to a system
failure or network failure.
Does that make sense to you?
>>
>>> Also why not put this into play on sourceware to test out first before
>>> moving it?
>>
>> Sorry, do you mean test deploying the solution for a temporary project?
>>
>> Or do you mean something else?
>
> Or a permanent solution. Why not move away from Ada-hooks long before
> trying to change the hosting env?
I'm open to going down that path as a way to support Sourceware being able
to use this similar solution with all other projects (and you'll want something
like this for projects converting to the Forge).
I would like to see both the improvement and hosting change, but as part of
this RFC I'm willing to do this part right now with Sourceware.
I am splitting these conversations up so we can make forward progress on
just one aspect of the technology and solution to improve security for the
project.
If we agree that the recommendation here is appropriate, then we would talk
about who has access to additional hosts that could run this VM, and it can
be Sourceware to start, and LF IT later to provide more isolation.
Note that it could be the same VM as the one that runs bugspray, since they
both do non-critical, but important tasks.
> That has always been my question. Why merge both things this way? Why
> do things in steps?
The answer to that is that it is less time for me, because LF IT will
set it up, but I'm willing to put in additional work to break it into
smaller steps.
> I keep on asking why do both things at once? That is so much more risk
> than doing things in steps and easier to move back if needed at any
> step rather than pushing everything at once.
I agree with you that it reduces risk, but it also has added volunteer
time costs, but I'm willing to have that discussion.
If you are happier with break this into:
- Disable glibc hooks on sourceware.
- Add Sourceware VM to run git-mailbomb for glibc
- ... (some more steps here in other RFCs, like move to gitolite when the hooks are gone)
- Shift VM to LF IT to run for added isolation.
> This is standard practice even in development. Why not here?
Cost of my time. But I'm here to talk about it.
@@ -3918,7 +3918,7 @@ static void check_flush_dependency(struct workqueue_struct *target_wq,
WARN_ONCE(current->flags & PF_MEMALLOC,
"workqueue: PF_MEMALLOC task %d(%s) is flushing !WQ_MEM_RECLAIM %s:%ps",
current->pid, current->comm, target_wq->name, target_func);
- WARN_ONCE(worker && ((worker->current_pwq->wq->flags &
+ WARN_ONCE(worker && worker->current_pwq && ((worker->current_pwq->wq->flags &
(WQ_MEM_RECLAIM | __WQ_LEGACY)) == WQ_MEM_RECLAIM),
"workqueue: WQ_MEM_RECLAIM %s:%ps is flushing !WQ_MEM_RECLAIM %s:%ps",
worker->current_pwq->wq->name, worker->current_func,