Date:   Mon, 20 Mar 2023 15:37:31 -0400
From:   Joe Korty <joe.korty@concurrent-rt.com>
To:     lgoncalv@redhat.com
Cc:     linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org
Subject: [PATCH 5.10.162-rt78] Restore initialization of wake_q_sleeper.next
 in fork.c
Message-ID: <20230320193731.GA36840@zipoli.concurrent-rt.com>
Reply-To: Joe Korty <joe.korty@concurrent-rt.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?AWB8opotYcmDIw8fNiCZ7+VtigD2HO9DecfIwzzleICLkmD/sgR5Jf7tisNC?=
 =?us-ascii?Q?rBybFqa8jbZuPrEcEaTngJ79T6915WFhuNihDh8DDKVF1IV/cUyYal7VXkQz?=
 =?us-ascii?Q?j4WGT5jFIW+vmgDBVwSwBWgpGnhECQLv7HiGih4scHrVBgPcZvYcFIo0jTKJ?=
 =?us-ascii?Q?1TKppS60/g66I1kDjb0oPYPkCfAb6egw/5ZHCSNdDxvMomWjQ0tZSfB4dR2M?=
 =?us-ascii?Q?f5j0w+JuatCHUvfSqjDKbQZCsJ/ocyzHDUaHDp2rljf/ZVo/gy9Wlq7wawCC?=
 =?us-ascii?Q?d4CMLUg2LVTSSCaW5hIcH6sEmXu6EriS/ulIZLfgS+8l11dvxV2r/yUt0OOU?=
 =?us-ascii?Q?XXoTp22huIOYiL9WKqgrOp10Aj7zslcS50dR5SXJo1SfsOABWNpMRdPRoqve?=
 =?us-ascii?Q?IvBRnAqxQhMrJbElOBYwPQTM3JXM8ZrFqxyODsXvgOZ0rLzJ8KWUO6RzYGdZ?=
 =?us-ascii?Q?HHoVSmNaJZz/qiZ4H6Hc1iujIEmpStqo8q+Ri46Dq0MTPaCq0H9OGDPByMZq?=
 =?us-ascii?Q?Ufd3/NeEpXqCUV0rbu7/eH6rqQo90MHFfBJjQf8qpOhzpb2nmlvL28bMyUuC?=
 =?us-ascii?Q?h53oWfoiDqo5sf2sf97hRrnfOOeLpZkHuO5jMNlcxTPs3g2NOE1HKjb49L28?=
 =?us-ascii?Q?q35jUPNqQjQaVzduHdaXXEd9zsGk8jjkfQ6IeDZ1Z+fGuH7nS0OfmJmA/auC?=
 =?us-ascii?Q?HDmwscoLSI9ysyBm8a357gAPINjUgaeHJmD2Y49x0vUvjpGGDb0KciZDcRRX?=
 =?us-ascii?Q?cuZVJy2Ujs40OkxT39nLo8VdbPUyJQRd5WlGhf791TjFgrFwVCP/vyN0+asi?=
 =?us-ascii?Q?E3Q85tRDpwKBUF8Djl1rt57MmpVXV/oxsERrlOCSdGek5SkwhjsBeV2iqyd0?=
 =?us-ascii?Q?SjJnDkVkHsOBrsRRzjDhafJmzKKMRpCKJBQPApsKBbu68NLfDNl9HeNED71K?=
 =?us-ascii?Q?rhZnefOHqtspbjTol/QIDWLOnKf+WzEaUXzSZelQRtr1dld5aUIpZvrrPvH2?=
 =?us-ascii?Q?a15BE7/fn46gJCH0RfWFlaPy7z02zGMFBFbdf/5yYHSGT9FXCW/yhwoV40ki?=
 =?us-ascii?Q?vHPuyNMJsuxyH7+sGWlcaoZNYS+KuVLWARK32eTxxBVzY3CZs6L0vqERJceT?=
 =?us-ascii?Q?dU9v0WBjtILgtcbooRZzcQoNYilDMYpsRELs7XlIz2kYLEZgWEFdFGzM5SEt?=
 =?us-ascii?Q?/rP/eWRMypMvaha3k/8UH1xDlTgGOUDcoQ0Ypyiwv3Iwo7weCR2wjy0hZ9c6?=
 =?us-ascii?Q?wLKyguGZTpEA/nXiXNVvUpm+OC8MUQ4Ucil6MxNlYVu51IE6pjyPYjmynw8l?=
 =?us-ascii?Q?tjUoQA3ajkVdJlby/0FEqfhPLJVWezeOKO6xWZWprHjemWKpAUcSRs9INJaP?=
 =?us-ascii?Q?0SyXbU4AnFI8toZprmGqcYH3pfcvg5jxFYaNkEPH/fWr4xq6IGp3Qa2TUs7q?=
 =?us-ascii?Q?2mGSDjUdW51ra3SPoUMqDzKYwI69t8ZdY+SDVTlNv/jNtorVGHpah5J6kTHj?=
 =?us-ascii?Q?HMLh2G5v3g0sW7niaRWQIu5d58zlb0gpm/43QgJtBdXEFk3HpLg89sa9GW3i?=
 =?us-ascii?Q?ep/MDWq3X0+d0jYELFTcsUDIkXV+ZMdlLDp8M5u02ii9KLLDMvN+0G4bXvly?=
 =?us-ascii?Q?ww=3D=3D?=
X-OriginatorOrg: concurrent-rt.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e9d07cb-ef5e-4ab4-c2cc-08db297a8ecb
X-MS-Exchange-CrossTenant-AuthSource: VI1PR09MB3582.eurprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2023 19:37:36.2930
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 6cce74a3-3975-45e0-9893-b072988b30b6
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: eHoJstBkKA2Ia8PbA+MsOGRBbdtwZhDOONENR31U7M4EEZQTjtBYM8FOYEWDBWmG+heD0Dr/VBQ8choUoIOr7lvvPrt30d7mXcXfDJFBpvs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR09MB4065
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

In the transition from 5.10.158-rt77 to 5.10.162-rt78,
the initialization of task_struct::wake_q_sleeper.next
was dropped.  Restore it.

This appears to be only a problem in 5.10.  5.15 does not
have wake_q_sleeper; 4.19 does have it but its initialization
there is still present.

The 5.10.162-rt78 patch that damaged fork.c is:

   0170-locking-rtmutex-add-sleeping-lock-implementation.patch

I do not have a simple test that brings out this problem.
My test consists of a shell script and eight binaries,
all of which were written in Ada.  strace shows that it
does a few thousand forks in rapid succession.  One of the
forks stalls out, after which no fork after that returns.
Eventually the 122 second stallout occurs and a large
number of threads are shown to be waiting for tasklist
lock, either in do_exit or in copy_process.  The kernel
.config has rt and many debug features enabled, lockdep
included.

Signed-off-by: Joe Korty <joe.korty@concurrent-rt.com

Index: b/kernel/fork.c
===================================================================
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -960,6 +960,7 @@ static struct task_struct *dup_task_stru
 	tsk->splice_pipe = NULL;
 	tsk->task_frag.page = NULL;
 	tsk->wake_q.next = NULL;
+	tsk->wake_q_sleeper.next = NULL;
 	tsk->pf_io_worker = NULL;
 
 	account_kernel_stack(tsk, 1);