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=-11.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, 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 B06A5C3F68F for ; Fri, 14 Feb 2020 17:26:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8929F24676 for ; Fri, 14 Feb 2020 17:26:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="mvatJYP9" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391159AbgBNRZ7 (ORCPT ); Fri, 14 Feb 2020 12:25:59 -0500 Received: from mail-ot1-f65.google.com ([209.85.210.65]:34064 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391765AbgBNRZ6 (ORCPT ); Fri, 14 Feb 2020 12:25:58 -0500 Received: by mail-ot1-f65.google.com with SMTP id j16so9889837otl.1 for ; Fri, 14 Feb 2020 09:25:57 -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=pSMjarGrsUPgAx4tKo+8H+L0Szt0s9yVAf2VYNsMa0o=; b=mvatJYP90LnHgm4N3PgyesVQnHTRUe3LaAPWZ8NIe/6hGTT9VXzGU4p93LbBGMbcjX /yS+R0dEibti1vzOD9ljhXo77ULGzns2X3pNni2DVSQZLibtfeHATYRWKLw7hUcFvwrb kZvvSwqU8+PCs/3gZBUwSpBAWg2eV6/8nYAhDloNoFzfqXj3FLn0igJIUnlgGxFRnqp7 Yyx9Tbb5VcHJwVWeLWoCCt8BWIUPNSuibtHv9hDWURcgYOJUrI1WjA+YHwa/H24k6Wic UcGcSvj50fKLOtLiH8Xl62mzM2CoJd6JwKQw4ClcmGH5keWOYMc+C2kftdXdx+iFwwWv zolQ== 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=pSMjarGrsUPgAx4tKo+8H+L0Szt0s9yVAf2VYNsMa0o=; b=kl3xbwoLSzfcBAMOQ3W4kcxMPY+kGz3TtetgJy0QSf/yDJ3wUJ8oakNmBzvjr0C4yc b1cFJCWbi6N20iPLLoJUcq7t12KWmbJVKMoseVjy8yRO0OT3RQ5mR/FNTGvrfYAwV4jK lE49Lm+aFIj3sYXNCUNbMG9hjWBcAhvUqYsMosgNiZe8jmyR2XM1r3wKHLmdYMTewubq WQo49KI0UTBR0nnkmltWcTC2iWTf2SuPlTqvNpGHY6I8zqTgiRpMQqRitCfQLYxwSoUZ tJBD29vXTK72SPn9WtAqTxrOrnhPT7F1oUpY2F6OqsPnzceN1b0K2Vh/pXvGi5/Og/N8 sHsw== X-Gm-Message-State: APjAAAUTpmWGERgeTnoarWM/0MoaT91nN59X7Nog2LI5wgorayNKaPO6 1BjuIBSZdC2SjnndX++ADPG4qwd/5dblx2YRrKEY2+brs5Lwig== X-Google-Smtp-Source: APXvYqxPBAMd0tGmcjPd0FZvV4wf35i2R/TBjgEwIelMFvAF+MVxbxS6HVKJ8WwbllYOc5XQ8Fb54aD+vOj9De/2vRU= X-Received: by 2002:a05:6830:1d6e:: with SMTP id l14mr3117234oti.32.1581701156723; Fri, 14 Feb 2020 09:25:56 -0800 (PST) MIME-Version: 1.0 References: <20200214170520.160271-1-minchan@kernel.org> <20200214170520.160271-2-minchan@kernel.org> In-Reply-To: <20200214170520.160271-2-minchan@kernel.org> From: Jann Horn Date: Fri, 14 Feb 2020 18:25:30 +0100 Message-ID: Subject: Re: [PATCH v5 1/7] mm: pass task and mm to do_madvise To: Minchan Kim , Jens Axboe , io-uring Cc: Andrew Morton , LKML , linux-mm , Linux API , Oleksandr Natalenko , Suren Baghdasaryan , Tim Murray , Daniel Colascione , Sandeep Patil , Sonny Rao , Brian Geffon , Michal Hocko , Johannes Weiner , Shakeel Butt , John Dias , Joel Fernandes , sj38.park@gmail.com, Alexander Duyck Content-Type: text/plain; charset="UTF-8" Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org +Jens and io-uring list On Fri, Feb 14, 2020 at 6:06 PM Minchan Kim wrote: > In upcoming patches, do_madvise will be called from external process > context so we shouldn't asssume "current" is always hinted process's > task_struct. [...] > [1] http://lore.kernel.org/r/CAG48ez27=pwm5m_N_988xT1huO7g7h6arTQL44zev6TD-h-7Tg@mail.gmail.com [...] > diff --git a/fs/io_uring.c b/fs/io_uring.c [...] > @@ -2736,7 +2736,7 @@ static int io_madvise(struct io_kiocb *req, struct io_kiocb **nxt, > if (force_nonblock) > return -EAGAIN; > > - ret = do_madvise(ma->addr, ma->len, ma->advice); > + ret = do_madvise(current, current->mm, ma->addr, ma->len, ma->advice); > if (ret < 0) > req_set_fail_links(req); > io_cqring_add_event(req, ret); Jens, can you have a look at this change and the following patch ("[PATCH v5 3/7] mm: check fatal signal pending of target process")? Basically Minchan's patch tries to plumb through the identity of the target task so that if that task gets killed in the middle of the operation, the (potentially long-running and costly) madvise operation can be cancelled. Just passing in "current" instead (which in this case is the uring worker thread AFAIK) doesn't really break anything, other than making the optimization not work, but I wonder whether this couldn't be done more cleanly - maybe by passing in NULL to mean "we don't know who the target task is", since I think we don't know that here?