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 X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6E91DC11D00 for ; Thu, 20 Feb 2020 22:38:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4222A207FD for ; Thu, 20 Feb 2020 22:38:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="NCZWx6I/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729264AbgBTWis (ORCPT ); Thu, 20 Feb 2020 17:38:48 -0500 Received: from mail-oi1-f194.google.com ([209.85.167.194]:35863 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729006AbgBTWir (ORCPT ); Thu, 20 Feb 2020 17:38:47 -0500 Received: by mail-oi1-f194.google.com with SMTP id c16so75538oic.3 for ; Thu, 20 Feb 2020 14:38:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K5efy4cTAe1W+0RHtVLFAXp5hLcQjz0drJQsLZA78Bc=; b=NCZWx6I/HkxTh/wDEgetZjGtsG2tlOTYTAOwHEW2Cq0zpEN15xZL9Bb0TRW4UXrAQG 9vmtsW7y5u1gJ5gpBghY8rQTzizSzgej3ELvMJt02SRdcNA+ND6WJ3ATqv2ABabcPnEa MtSD0e0VIfAKOWBEWujFQf17WDQoLvxuNWshoSC3CmK1mlMxAFEYqhfCAmUTNEuLhN8s JHfVD7jSA92QsDeYP01DZ/WwqS8X+baWUXX/ekTXMu6ErJZBPokMo/prEqUBC0okZxhm /LZYLU3AVV5+uVf4ZNgfVN6g9SzK9MxpUSrYCaVCc2gcOOPupmzCYv9ILu4UcehwvQjo w0dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K5efy4cTAe1W+0RHtVLFAXp5hLcQjz0drJQsLZA78Bc=; b=hco6CtDZppY9RALNuLG4Fj6OysWVwt7Lb0Hl48F+vYGkYcaU0lvpy+u4Fd/maWMuk1 jRLvMoxLyc2FMyZJG2mXocEJtkw+XMCrGdJCHEQ3gE19CUYw82QXIcO17RHKtwBFX77+ JsiiESfc/niqYXxijxx2TTUoa9NOy5XtTwVjI1T1kPLp9ReLWgoENAPp5lH46orDDev+ NZKFKM2B/49Q2XHTjHrBd0FvLqhZdXsD4OqYZ2M/DAmnU/EQls982Vqy1R2KDMIED1N5 JutfXm9VjN2da+8Ypco5bnMBhiXsYsfmQ8IqecHyCSUiWvu+VDpdaEcTimpvv5Bh+6Pu AeOA== X-Gm-Message-State: APjAAAUd/r4ftl55IGspRo8px7/ELjbeO3N+pzoXwzPh8FoacGu8NHkV LqW7OspASEDVlhGXFwp1Aeng9ZkFRqKuq1W9Fnp+8Q== X-Google-Smtp-Source: APXvYqxOf8fcH1tqnwfHMNWAtfpowDla9UImsx/Tz4joQ2r6fff+97HNLBUbLhtqdmK6jedrRwvPLJEAepyY4y04cB0= X-Received: by 2002:aca:484a:: with SMTP id v71mr3290070oia.39.1582238326991; Thu, 20 Feb 2020 14:38:46 -0800 (PST) MIME-Version: 1.0 References: <20200220203151.18709-1-axboe@kernel.dk> <20200220203151.18709-8-axboe@kernel.dk> <67a62039-0cb0-b5b2-d7f8-fade901c59f4@kernel.dk> In-Reply-To: <67a62039-0cb0-b5b2-d7f8-fade901c59f4@kernel.dk> From: Jann Horn Date: Thu, 20 Feb 2020 23:38:20 +0100 Message-ID: Subject: Re: [PATCH 7/9] io_uring: add per-task callback handler To: Jens Axboe Cc: io-uring , Glauber Costa , Peter Zijlstra , Pavel Begunkov Content-Type: text/plain; charset="UTF-8" Sender: io-uring-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Thu, Feb 20, 2020 at 11:23 PM Jens Axboe wrote: > On 2/20/20 3:14 PM, Jens Axboe wrote: > >>> @@ -3646,46 +3596,11 @@ static int io_poll_wake(struct wait_queue_entry *wait, unsigned mode, int sync, > >>> > >>> list_del_init(&poll->wait.entry); > >>> > >> [...] > >>> + tsk = req->task; > >>> + req->result = mask; > >>> + init_task_work(&req->sched_work, io_poll_task_func); > >>> + sched_work_add(tsk, &req->sched_work); > >> > >> Doesn't this have to check the return value? > > > > Trying to think if we can get here with TASK_EXITING, but probably safer > > to just handle it in any case. I'll add that. > > Double checked this one, and I think it's good as-is, but needs a > comment. If the sched_work_add() fails, then the work item is still in > the poll hash on the ctx. That work is canceled on exit. You mean via io_poll_remove_all()? That doesn't happen when a thread dies, right? As far as I can tell, the following might happen: 1. process with threads A and B set up uring 2. thread B submits chained requests poll->read 3. thread A waits for request completion 4. thread B dies 5. poll waitqueue is notified, data is ready Even if there isn't a memory leak, you'd still want the read request to execute at some point so that thread A can see the result, right? And actually, in this scenario, wouldn't the req->task be a dangling pointer, since you're not holding a reference? Or is there some magic callback from do_exit() to io_uring that I missed? There is a comment "/* task will wait for requests on exit, don't need a ref */", but I don't see how that works...