Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1348328pxb; Sun, 22 Aug 2021 14:08:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwiUTcq3/SSIhTqIRSu4YNpWhqFKWQXHAU0KvAQPp3alkJo3w0ttDSDZ0j56s7mpQvEAcSv X-Received: by 2002:a17:906:5f93:: with SMTP id a19mr33530398eju.126.1629666503315; Sun, 22 Aug 2021 14:08:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629666503; cv=none; d=google.com; s=arc-20160816; b=e99CwE8dlefH/SyLWkvWAX4pAIFNA688Y1Pjs97+XzpFr/0dtzAMqwFy/xUlbSMaLT OmuDUBHxxgT0sNJshwcUrePH2vQpnIzkNMaA+CXxvLZ/qsgA9/0HlN0vTUMl0pCayRGF klC0KA43182QDxLse9j4sGH1S6odB4HKYfW+vUQ8slXu/XszZWw0vj/HjuY5G3T5uAQo +H33XQEQTSqKocNTfIDX8Kwfw48dh8ADFNLdL7PdPgRC6yCrcNYbRzmzBRMYMg/pjLSN W0DdjZM3zJCidzm7kN7hun5sMWVtOwnTwUOJ33ckUCnb03w3/ZKSTF6/NnvdWjIxcyeM UzKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:to:from:message-id:date; bh=wqNuNi8QJhK3YYKyzXEqMf8zZly+WcF1onqi07QSmD4=; b=WixFW3485TUjfuWqqEfQ1kD03smLy/1H8P+GlYcVeRWPqALTySyilukfU96Vq3HQSk Inq2/aCQOaJ4prSAyP2c06rlvtp9YdnG34GzbyqhpyZ3O7qSl5eir3cwNnolwypplh6l NnKlAsRe1WRew98fyAcZwRJ7iCSkhzzkjzoUa9RhXw5MvLCKondLvSzcVdHbA8qWKoA0 YRVC0aCWyXbZOgaLp+zBS6zzWH0Fe3rpR+yjdSqM07qdRRsEOQbcarwm8B5GV3VA6kVa 3kFC93qqcwPfJBby76nLIsKAKdJxW03FU/8WQqGUoRpKCebV/Z3ZfEdQPWatwC2Rq/0D +IKw== 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 h15si6155695ede.550.2021.08.22.14.07.45; Sun, 22 Aug 2021 14:08:23 -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 S233019AbhHVVG3 (ORCPT + 99 others); Sun, 22 Aug 2021 17:06:29 -0400 Received: from cloud48395.mywhc.ca ([173.209.37.211]:36020 "EHLO cloud48395.mywhc.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232539AbhHVVG3 (ORCPT ); Sun, 22 Aug 2021 17:06:29 -0400 Received: from modemcable064.203-130-66.mc.videotron.ca ([66.130.203.64]:52706 helo=localhost) by cloud48395.mywhc.ca with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mHuf4-0001qj-4c; Sun, 22 Aug 2021 17:05:46 -0400 Date: Sun, 22 Aug 2021 17:05:44 -0400 Message-Id: From: Olivier Langlois To: Jens Axboe , Pavel Begunkov , Oleg Nesterov , Steven Rostedt , Ingo Molnar , "Eric W. Biederman" , io-uring@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/3] coredump: io_uring: Cancel io_uring to avoid core truncation X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud48395.mywhc.ca X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - trillion01.com X-Get-Message-Sender-Via: cloud48395.mywhc.ca: authenticated_id: olivier@trillion01.com X-Authenticated-Sender: cloud48395.mywhc.ca: olivier@trillion01.com X-Source: X-Source-Args: X-Source-Dir: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Before writing the core dump, io_uring requests have to be cancelled. Also, io_uring cancellation code had to be modified as it could set the TIF_NOTIFY_SIGNAL bit. Few notes about this patchset: 1. My coredump.c proposal puts the io_uring_task_cancel call further down the do_coredump function over what Jens did propose. Considering that this function call can be relatively expensive, I believe that postponing it as much as possible is the way to go. I did place it before coredump_wait which clears signal bits so that seems to be an appropriate location but the logic could possibly be pushed even more with possibly no harm. 2. The current patch proposal only address specifically the issue caused by io_uring. It could reoccur as soon as something else flips the TIF_NOTIFY_SIGNAL bit. Therefore, another solution would simply be to modify __dump_emit to make it resilient to TIF_NOTIFY_SIGNAL as Eric W. Biederman originally suggested. or maybe do both... So making __dump_emit more robust to the TIF_NOTIFY_SIGNAL situation might be something interesting to investigate if it would be a good idea to do on top or in replacement to this patchset. Lastly, Jens did already submit a patch to solve the same problem: https://lkml.org/lkml/2021/8/17/1156 If his patch ends being a superior solution to the problem, the first 2 patches of this set are still relevant. Olivier Langlois (3): tracehook: Add a return value to tracehook_notify_signal io_uring: Clear TIF_NOTIFY_SIGNAL when cancelling requests coredump: cancel io_uring requests before dumping core fs/coredump.c | 3 +++ fs/io_uring.c | 2 +- include/linux/tracehook.h | 8 ++++++-- 3 files changed, 10 insertions(+), 3 deletions(-) -- 2.32.0