Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4069511pxj; Mon, 21 Jun 2021 12:49:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwGaqvonSyFaesmEOd5mYYqVgGeLNgVKKMzO/KduBplKLF4JhBekJR+1X1qjenEEDV2pQME X-Received: by 2002:aa7:c799:: with SMTP id n25mr92293eds.16.1624304953248; Mon, 21 Jun 2021 12:49:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624304953; cv=none; d=google.com; s=arc-20160816; b=bIvrfh/RDQitemnWGqxpVyWOXGsCjRSTX5yU1EnhSuHwzrPJIIdDL1sIwfFyMIBMpC XvMeQNZY6hUT9Qt6O4fYNUW6z48tbFl97rIDDtCAodATXo4Y15En4GhD/0fagFND3+Ep Ve2/naBlJJ54BP+FhnBqbY7V213UPCZg7yrTxrcMxJt7pzaJgcKGUONnklSm0IFixinw C+bmjQY5iRFEONqPHziqDklA+ILiVkyirT810+xAsTA79QaDzGRlM0VyoXY1F0ym0KXl 5dQnVhlS6rMHpHL8CKoAN5z2fzmO9cJKy8WTpE6kGDEz2ysxSWJU0fxPuFTA1zpiiB2Y cLYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=RFgBpCmFyaYH+ToI6jXE9GHaedGX9/1piODQeou9FoY=; b=KLglrXWIoF7uUSiQYURZBHhDOd+5zdmTzadJaqg2ls8Rnp4lacCTljHcD1UTyWtcDX 8MZMAZBYU0dtcM8jJXgaZqIaoFlQlX3yYbjxSmQwEclUcIRCnQORaY94w9l8hY+P9dPi 8KQ0Q7i81QnCGlnCGecaqqtGCsfhYnmz7QzlqwF0fbxhqERzAKQbifY5kRc5x/fFBu0o wOQNhgyyalHRl/vnMqKrt9NHrFQrJOVuHV14aUUmoPaCjwi9s1CcPN53fmWbZYdsJTsl IA+3k0A9Z/93cMH40QreEAWWodiZonCK8aBa3XAgVFNdnSuo9z6ftW/5fp1N4FtMywsB aCPQ== 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 p16si269637ejn.713.2021.06.21.12.48.50; Mon, 21 Jun 2021 12:49:13 -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 S231560AbhFUTsI (ORCPT + 99 others); Mon, 21 Jun 2021 15:48:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230347AbhFUTsH (ORCPT ); Mon, 21 Jun 2021 15:48:07 -0400 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 25738C061574; Mon, 21 Jun 2021 12:45:53 -0700 (PDT) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1lvPrW-00AwOu-3b; Mon, 21 Jun 2021 19:45:38 +0000 Date: Mon, 21 Jun 2021 19:45:38 +0000 From: Al Viro To: Linus Torvalds Cc: "Eric W. Biederman" , Michael Schmitz , linux-arch , Jens Axboe , Oleg Nesterov , Linux Kernel Mailing List , Richard Henderson , Ivan Kokshaysky , Matt Turner , alpha , Geert Uytterhoeven , linux-m68k , Arnd Bergmann , Ley Foon Tan , Tejun Heo , Kees Cook , Tetsuo Handa Subject: Re: Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads Message-ID: References: <6e47eff8-d0a4-8390-1222-e975bfbf3a65@gmail.com> <924ec53c-2fd9-2e1c-bbb1-3fda49809be4@gmail.com> <87eed4v2dc.fsf@disp2133> <5929e116-fa61-b211-342a-c706dcb834ca@gmail.com> <87fsxjorgs.fsf@disp2133> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 21, 2021 at 12:22:06PM -0700, Linus Torvalds wrote: > On Mon, Jun 21, 2021 at 11:59 AM Al Viro wrote: > > > > There's a large mess around do_exit() - we have a bunch of > > callers all over arch/*; if nothing else, I very much doubt that really > > want to let tracer play with a thread in the middle of die_if_kernel() > > or similar. > > Right you are. > > I'm really beginning to hate ptrace_{event,notify}() and those > PTRACE_EVENT_xyz things. > > I don't even know what uses them, honestly. How very annoying. > > I guess it's easy enough (famous last words) to move the > ptrace_event() call out of do_exit() and into the actual > exit/exit_group system calls, and the signal handling path. The paths > that actually have proper pt_regs. > > Looks like sys_exit() and do_group_exit() would be the two places to > do it (do_group_exit() would handle the signal case and > sys_group_exit()). Maybe... I'm digging through that pile right now, will follow up when I get a reasonably complete picture. In the meanwhile, do kernel/kthread.c uses look even remotely sane? Intentional - sure, but it really looks wrong to use thread exit code as communication channel there...