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 8B5FBC433F5 for ; Wed, 1 Jun 2022 03:16:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349278AbiFADQF (ORCPT ); Tue, 31 May 2022 23:16:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349272AbiFADQC (ORCPT ); Tue, 31 May 2022 23:16:02 -0400 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3B52915A5 for ; Tue, 31 May 2022 20:16:00 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id k19so470306wrd.8 for ; Tue, 31 May 2022 20:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=XrsyQG46hfKFpC/n788dnmSF1KyRFNfE0olCI8xti3o=; b=Z8C8H3Bcb4sw+hLnFm6ELYF7JkRtcmHt94DEDN9dw/uoIgceQeex8GVkcxd/4b8Jr0 ZBlku+irMR14iNI4YO1P/E0Mw2/KX0ckK6Lf5w7U6QAG93USFKlNKX6g9LOnhVgAeCGd cmpw0kGdcUh0zptQ/Bt1Lxxj1M//ah60M1kUrRDe52J428k3Y06m6zKcYlJExYsEuwCc I/4Ib6mvkU4psj4mKfBpDsb85NaTdJb8LlJO8clLZZAWHyi3/gSSv+PfI9k8ssXhQYf0 3HJgPtPawFixAjMDjj7/GLWtnhrmsfZMJv4Qx7rSxZmiyhzrUnS3KHGlE3XdW5/ZQG21 nlmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=XrsyQG46hfKFpC/n788dnmSF1KyRFNfE0olCI8xti3o=; b=KwFGfF4uA0WGK83g0OSJCQp+fjK58UzEIDBfko3a1lCPvNnPUQYK+cfsAWbNPLMbS1 0SgEylnxlB8Nh2VJprQn1xbn1hd3YwrSDreg8KhBzFNptAXVYzGUCgkLgeQ6ZP1Ir7BF aTN3yGIDAnyFb8AyRngSJMRF8LpNhX8cLbKP5+IJ/kIxLIPJi53hCJhnRsUM6qfmDypz D7MGK9+4JSwJYFk2D+ECn1kDi8FgaiM9LEDcIStCgOCrPirAldDUT4OyIL8YIs1yOM8M YpNnRK5kaxGLAQRT4mK0hIJJWgC5jf6fUOQLBrtCRGy84kNIQleP3KmKRETVCqTBIhRc reNQ== X-Gm-Message-State: AOAM533T2sPHJ71N6p+fMiADM2TmmsTEBBa9+/863t34W/OcKuPMCfT0 MDeH3Xdl78mrEQFqL4HWsQnDig== X-Google-Smtp-Source: ABdhPJzVqSzsO85fNJucH4i22uc4bYFUP8VAEP9et8+fEFwPeeaTZAcOP4+UZPL5mR4op3rPe3foYg== X-Received: by 2002:a5d:64e6:0:b0:20f:a608:9af9 with SMTP id g6-20020a5d64e6000000b0020fa6089af9mr48500273wri.171.1654053359412; Tue, 31 May 2022 20:15:59 -0700 (PDT) Received: from [10.188.163.71] (cust-east-parth2-46-193-73-98.wb.wifirst.net. [46.193.73.98]) by smtp.gmail.com with ESMTPSA id k27-20020a05600c1c9b00b0039750c39fc5sm4588644wms.3.2022.05.31.20.15.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 May 2022 20:15:58 -0700 (PDT) Message-ID: Date: Tue, 31 May 2022 21:15:57 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [RFC] coredump: Do not interrupt dump for TIF_NOTIFY_SIGNAL Content-Language: en-US To: Olivier Langlois , "Eric W. Biederman" , Pavel Begunkov Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, io-uring@vger.kernel.org, Alexander Viro , Oleg Nesterov , Linus Torvalds References: <192c9697e379bf084636a8213108be6c3b948d0b.camel@trillion01.com> <9692dbb420eef43a9775f425cb8f6f33c9ba2db9.camel@trillion01.com> <87h7i694ij.fsf_-_@disp2133> <1b519092-2ebf-3800-306d-c354c24a9ad1@gmail.com> <13250a8d-1a59-4b7b-92e4-1231d73cbdda@gmail.com> <878rw9u6fb.fsf@email.froward.int.ebiederm.org> <303f7772-eb31-5beb-2bd0-4278566591b0@gmail.com> <87ilsg13yz.fsf@email.froward.int.ebiederm.org> <8218f1a245d054c940e25142fd00a5f17238d078.camel@trillion01.com> From: Jens Axboe In-Reply-To: <8218f1a245d054c940e25142fd00a5f17238d078.camel@trillion01.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On 5/31/22 2:06 PM, Olivier Langlois wrote: > On Mon, 2022-03-14 at 18:58 -0500, Eric W. Biederman wrote: >> >> Thank you very much for this. There were some bugs elsewhere I had >> to >> deal with so I am slower looking at this part of the code than I was >> expecting. >> >> I have now reproduced this with the commit reverted on current >> kernels >> and the repro.c from the syzcaller report. I am starting to look >> into >> how this interacts with my planned code changes in this area. >> >> In combination with my other planned changes I think all that needs >> to >> happen in do_coredump is to clear TIF_NOTIFY_SIGNAL along with >> TIF_SIGPENDING to prevent io_uring interaction problems. But we will >> see. >> >> The deadlock you demonstrate here shows that it is definitely not >> enough >> to clear TIF_NOTIFY_SIGNAL (without other changes) so that >> signal_pending returns false, which I was hoping was be the case. >> >> Eric > > I have been away for some time but if this is not resoved yet, I just > want to remind that clearing TIF_NOTIFY_SIGNAL along with > TIF_SIGPENDING won't do it because io_uring may set them asynchronously > to report some io completion while do_coredump() is executing. > > IMHO, just calling io_uring_task_cancel() from do_coredump() before > actually writing the dump, while maybe not the perfect solution, is the > simplest one. > > Otherwise, maybe masking interrupts locally could work but I wouldn't > dare to explore this option personally... Eric, are you fine with doing the cancelation based patch for now? IMHO it's not the ideal approach, but it will resolve the issue. And it'd honestly be great to get some closure on this so we don't have truncated core dumps if they are interrupted by task_work. The best solution would be to make the core dumps resilient to task_work, but a workable solution would be nice at this point... -- Jens Axboe