Received-SPF: pass (google.com: domain of linux-kernel+bounces-215912-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,  Tejun Heo <tj@kernel.org>,
  linux-kernel@vger.kernel.org
References: <20240609142342.GA11165@redhat.com>
	<87r0d5t2nt.fsf@email.froward.int.ebiederm.org>
	<20240610152902.GC20640@redhat.com>
	<20240613154541.GD18218@redhat.com>
Date: Sat, 15 Jun 2024 09:53:21 -0500
In-Reply-To: <20240613154541.GD18218@redhat.com> (Oleg Nesterov's message of
	"Thu, 13 Jun 2024 17:45:42 +0200")
Message-ID: <87ikyamf4u.fsf@email.froward.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [PATCH 0/1] exit: kill signal_struct->quick_threads

Oleg Nesterov <oleg@redhat.com> writes:

> So...
>
> Eric, do you agree with this patch or not?

I really don't.

I think skipping some work if SIGNAL_GROUP_EXIT is already
set is not necessarily wrong.

I think we need the quick_threads count, and related cleanups.
I was hoping to be able to post a patchset with this reply
to explain things, but it looks like that is still a couple
of days off.

Where I was going, and where I think we should go with quick_threads is
an exit path that is much easier to reason about and maintain.  But the
decrement needs to move into the same code that sets SIGNAL_GROUP_EXIT.
Which makes it something very different from signal->live.

Eric