Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1993514ybv; Fri, 14 Feb 2020 09:27:29 -0800 (PST) X-Google-Smtp-Source: APXvYqwEWprz3oKzAtqWYPvKLZAC8nAWKHq5DoocXCjF6v4pNEyb1svEGWuqP6zf+DNdaM9t4Hdt X-Received: by 2002:a05:6808:64d:: with SMTP id z13mr2685288oih.104.1581701249526; Fri, 14 Feb 2020 09:27:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581701249; cv=none; d=google.com; s=arc-20160816; b=FHjHPKLjTVCVmekVy3Ve6Ow3fJmoRSmnKuhRffZhO65gF5lL6+kr9NcH2KreDQhlir 7ThufyNLLRan6NUHxzblDLzU60JLKaRD1wUeYUAz4JUigXrpzBQGvbPFkezIHFbYPNOn Odu5UMvu4gHZpeyEpagO0usIDBe6GmZ9+j3tKQ5NcsFGcYxUZJ0VH3TY7wxRnJe7ZqNg F51Go15b2cGiR1syReU7Z0RdIuV77sqrSWGOGTkJfvyFNDBLF8tSJbhHRWKeqbC4rAl5 iopQ1Laj9K14cpNDegSWYlDa6ww/FIyDvd7id8n75RYGg6EbfPd1AT3fSqNdQiNOcS0T GKgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=pSMjarGrsUPgAx4tKo+8H+L0Szt0s9yVAf2VYNsMa0o=; b=mTSRK2onNHGoNTIIPPoG9o8O0wQlGrW3tWBbpOsenROq37PnkZEAUd4yZDvEfWVJOI KMM7dqCvFdZB01KnZVNFt3/6IZP6yLBWw0JpdQe0d7xV33gfAqzAhwxExAoOtubilHCk pwvZ7jmukTWKCO/ApPRCeYXK2TgWsOkpniLSfWA4S/lUhGOvyREmnIT0/Iyn7jaxwVpZ JfgmYK6kPwf8DC8YGGr1Z90laa4tZBP6zStTxzuPZzBqbephhKtIrvXRMG8EZbF/1ypI bHozRTC6afkNi3G4dHuDcGT1T+ZSdaxGE1UoK55HLgck7w2qeEZhlqZXvF7hyfBY7pg3 IAEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mvatJYP9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e22si3296644oiy.124.2020.02.14.09.27.17; Fri, 14 Feb 2020 09:27:29 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mvatJYP9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391144AbgBNR0A (ORCPT + 99 others); Fri, 14 Feb 2020 12:26:00 -0500 Received: from mail-ot1-f68.google.com ([209.85.210.68]:38184 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391762AbgBNRZ5 (ORCPT ); Fri, 14 Feb 2020 12:25:57 -0500 Received: by mail-ot1-f68.google.com with SMTP id z9so9866205oth.5 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=lwLJXxLVInFe3wP+6SD92OiUjPtAjEzQvRAJhoQSf3cQwYJsEZwZpqtc8yfvKIHks0 07eAcBkSeE4JQXEd8fBjgdzQq0jcZmtSV57aHHPQaylu9w2ZVTedP7ERQs4apFh1Us+d 3MWSgmUhYPWkP3H3jGmHpRDbnPoGypB1uw7WoDoTPbEXCRkz/FJI51mk9AO0hy1ctqrF 30YVHJdmlhyLP4PW4Tn0DPMswm5gpMu0Lz32pCuLLBNeUjVcOZJ5nYSUFFfU2+vNDZ54 XEk7ftZTSLdpFEql6GbM+iVWAhknXLOCltL7L7Q8u/wBMeFBEcP4HoOgZIbf7agUqJYV k7lA== X-Gm-Message-State: APjAAAXZVij6YwKXy2Jgy0nMeDTFn+311qm/oLlePRQVO2eHHsFRpi2W ybYqWQAL08oWpXo2qozUXw0E9cve17CuMLkT6VWn1w== 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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?