From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98146C433EF for ; Fri, 8 Apr 2022 20:07:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239384AbiDHUJD (ORCPT ); Fri, 8 Apr 2022 16:09:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232479AbiDHUJA (ORCPT ); Fri, 8 Apr 2022 16:09:00 -0400 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ACF45353AAA for ; Fri, 8 Apr 2022 13:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=j9g5EHdwCeCGiDH+OptcbmwwyDPvJqZc+LesmTwslqM=; b=l7nnbBb2JXVJWhFHQb+EsAebGP x47Ze152fGhFOpyWK4R5wqh8jhw0hHFtRGIWwUcO4il6F7S+6O+9KdyGrlQ+MH0qUQ+1aGTMB8R7/ 5l9rnIsilGJTCn37OedWb1vPTs3WQ6Axn4BcNnHe7N437jh9nTFlKItKUapqNI8BhDYLN40HesuwU 9IIT0hrshy605QKPJ22XfUxprlkRGMDVIJkQ4Fq7xoqZHdnGgCfZBqdiWlZf76QuQCdndE+VsHq/g koGtGFvOwcu3vitJM4HfLFWAGso32D+v9lTGK2URm++MgDxuJs2rKPGFueXPW4xQyxHw6dfKPHi4k klkzmFwA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncusL-00333H-81; Fri, 08 Apr 2022 20:06:33 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id A8BA23000E6; Fri, 8 Apr 2022 22:06:30 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 61A1D3223116A; Fri, 8 Apr 2022 22:06:30 +0200 (CEST) Date: Fri, 8 Apr 2022 22:06:30 +0200 From: Peter Zijlstra To: "Eric W. Biederman" Cc: Oleg Nesterov , Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, Ben Segall , Daniel Bristot de Oliveira , Dietmar Eggemann , Ingo Molnar , Juri Lelli , Mel Gorman , Steven Rostedt , Thomas Gleixner , Vincent Guittot Subject: Re: [PATCH v2] ptrace: fix ptrace vs tasklist_lock race on PREEMPT_RT. Message-ID: References: <20220315142944.GA22670@redhat.com> <20220405101026.GB34954@worktop.programming.kicks-ass.net> <20220405102849.GA2708@redhat.com> <20220407121340.GA2762@worktop.programming.kicks-ass.net> <87v8vk8q4g.fsf@email.froward.int.ebiederm.org> <20220408090908.GO2731@worktop.programming.kicks-ass.net> <874k332wjp.fsf@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874k332wjp.fsf@email.froward.int.ebiederm.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 08, 2022 at 02:40:42PM -0500, Eric W. Biederman wrote: > Peter Zijlstra writes: > > > On Thu, Apr 07, 2022 at 05:50:39PM -0500, Eric W. Biederman wrote: > > >> Given that fundamentally TASK_WAKEKILL must be added in ptrace_stop and > >> removed in ptrace_attach I don't see your proposed usage of jobctl helps > >> anything fundamental. > >> > >> I suspect somewhere there is a deep trade-off between complicating > >> the scheduler to have a very special case for what is now > >> TASK_RTLOCK_WAIT, and complicating the rest of the code with having > >> TASK_RTLOCK_WAIT in __state and the values that should be in state > >> stored somewhere else. > > > > The thing is; ptrace is a special case. I feel very strongly we should > > not complicate the scheduler/wakeup path for something that 'never' > > happens. > > I was going to comment that I could not understand how the saved_state > mechanism under PREEMPT_RT works. Then I realized that wake_up_process > and wake_up_state call try_to_wake_up which calls ttwu_state_match which > modifies saved_state. Correct. > The options appear to be that either ptrace_freeze_traced modifies > __state/state to remove TASK_KILLABLE. Or that something clever happens > in ptrace_freeze_traced that guarantees the task does not wake > up. Something living in kernel/sched/* like wait_task_inactive. The code I posted in the parent will attempt to strip (and re-instate) WAKEKILL from __state and then saved_state, all under pi_lock. I think that preserves the current constraints. > I can imagine adding add a loop around freezable_schedule in > ptrace_stop. That does something like: > > do { > freezable_schedule(); > } while (current->jobctl & JOBCTL_PTRACE_FREEZE); I'm not entirely sure where you're headin with this; but my goal is to get rid of freezable_*() everything. I'll ponder if wait_task_inactive() can simplify things.. > What ptrace_freeze_traced and ptrace_unfreeze_traced fundamentally need > is that the process to not do anything interesting, so that the tracer > process can modify the process and it's task_struct. Agreed, I understand this need. I think I've done this, but I'll centrainly look hard at it again Monday -- the weekend hopefully clearing my brain of preconceptions enough so that I can see my own code a-fresh. Anyway, my current set lives here: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=sched/wip.freezer I meant to post earlier today, but stuff got in between and I've not even done build-tests yet :/