Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1768256pxb; Mon, 11 Oct 2021 12:41:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwcBEr8wgZcR5ebg1hcaX7ZzsGqtH9iB4q/bcCaTwEDIaDQRq82EniISvUKgc5AJWlDzlf8 X-Received: by 2002:a17:90b:388f:: with SMTP id mu15mr1055284pjb.28.1633981291948; Mon, 11 Oct 2021 12:41:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633981291; cv=none; d=google.com; s=arc-20160816; b=Sp5MIivB2kzCErLoNxWngQAWBO34xONCg1ym0/Vrl9NmKTTPj2l++ymPA/BtMKZy7s RYvH5jwzOFwNuWVFBkxaneQk36Y8NjUL55ZphWPb1FlXZ5HfAfpdHdahwJH2+5TTA0Ok oMLJ1RzYefJXjeWQLObeapKgwfkIuCvPlQF0XezdwWk7ht1FLr1Ar0kJftVNQkXq4xbN QVnbuu3aZLKII8Ln+LfLDT8GuzCuM0f8MMnvGGdeAMM8TtWIk/RB8IbD7+++AGmuc4Ys +hNTfl3SdQ9BypN4SaNsgjV18nji1eF1YxIUrJVqAv/nqZRGxR+TOdA/h3kD8+mF1WJ0 2AYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:content-disposition:mime-version :mail-followup-to:message-id:subject:cc:to:from:date; bh=5FOaxfWbkdej0p7Mrpfc2tNLadefBwk6DMInK81U1a8=; b=B5Z3ggGDw/6W9taA4pvFoJqcGhrpl5O5PyPb3dyjbgkgZbCzD6htdhbQHOo5dB5MFl teIDhaZH5MSWeFCzrGJv7tB+s1BuRNuUuOnXC0P67E3y0BxmQUs2h36gvP0rK/2Z6Nd7 trvqj2qyvhmyeocmbVaRZ+GhrSWFne+0ymotsXfZfH8FIVh49D0i0m/USWFGF8JqQur8 5a4/jEtEixdS9riXBMrldZ3PL7NA6CqT7ii3ZTospUEA66uX63M4IOxIuOex0phH+xn9 M3uBKGW9uuQSyRrJkE+0fWDjfWzmur5OB2N2Fg/bBES8PPngVdoaAHQ1mNhc19HdidHA j/Nw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 38si12274826pgm.639.2021.10.11.12.41.19; Mon, 11 Oct 2021 12:41:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234694AbhJKTmW (ORCPT + 99 others); Mon, 11 Oct 2021 15:42:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59860 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234687AbhJKTmV (ORCPT ); Mon, 11 Oct 2021 15:42:21 -0400 Received: from scorn.kernelslacker.org (scorn.kernelslacker.org [IPv6:2600:3c03:e000:2fb::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B976C061570 for ; Mon, 11 Oct 2021 12:40:21 -0700 (PDT) Received: from [2601:196:4600:6634:ae9e:17ff:feb7:72ca] (helo=wopr.kernelslacker.org) by scorn.kernelslacker.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ma19l-00AVhJ-4H; Mon, 11 Oct 2021 15:40:17 -0400 Received: by wopr.kernelslacker.org (Postfix, from userid 1026) id 522E456009C; Mon, 11 Oct 2021 15:40:16 -0400 (EDT) Date: Mon, 11 Oct 2021 15:40:16 -0400 From: Dave Jones To: Linux Kernel Cc: Linus Torvalds , Christian Brauner , Oleg Nesterov Subject: Should EXIT_DEAD be visible to userspace ? Message-ID: <20211011194016.GA16788@codemonkey.org.uk> Mail-Followup-To: Dave Jones , Linux Kernel , Linus Torvalds , Christian Brauner , Oleg Nesterov MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Note: SpamAssassin invocation failed Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org One of our users reported a crash in some userspace tooling this morning, which scrapes /proc/pid to gather stack traces, process states etc of everything running at the time. The crash occurred because it fell over an unexpected task state, which was 'X'. According to the procps man-pages, this state should never be seen, but here it clearly was. The kernel running at the time was kinda old (5.2) but I don't see much change in the EXIT_DEAD space that would explain something that got fixed subsequently. It's also probably going to be difficult to reproduce unfortunately. So my question is, is procps wrong and code should expect to see X state processes in proc ? The code in question is being hardened to handle unexpected inputs, but I'm curious if the kernel is leaking some state that it shouldn't. Dave