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 6D5CDC6FD1F for ; Thu, 16 Mar 2023 19:25:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230287AbjCPTZ0 (ORCPT ); Thu, 16 Mar 2023 15:25:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230252AbjCPTZY (ORCPT ); Thu, 16 Mar 2023 15:25:24 -0400 Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36F6767817 for ; Thu, 16 Mar 2023 12:25:22 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id s4so1272936ioj.11 for ; Thu, 16 Mar 2023 12:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; t=1678994721; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=QO+PaSrCDUmhEeRGRCLwJJ6+iMUfs2kw6XORqJOF2FU=; b=tyyJB2rGfgTXdkY5uxPUUl6UJXFp2KjzHndbE7GxrqZKeayLn/2IXD7Wk1YXoupIWG TrHWD898fZDuj2WAP1y1RQEnynuoCotxkBF+3UtC5CWb3eJnDQvC+WRHPVUFa9Ltj1E7 /xm595/Hxgof25hhAa9NMpCQqRJU2lEThj9anI/hGGm/W4dnfnZDe6fIQ9kGR50nPPGr Da4T8Jjq9ifCGRREKnPAlVfOcaglTzRJaKW1ZEJznUsY88wFmJV5JuXxulx0LzVqv4JT ofQLFJv2V8dfwkUdelAIvHMQ+BGz3Doobt7+fTQNps5Ik0aL911clHwSgXD5rsGlZn39 hlQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678994721; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QO+PaSrCDUmhEeRGRCLwJJ6+iMUfs2kw6XORqJOF2FU=; b=nK4+gBmAErHbBGK3qAYvBggZHf6ah2AH5t0DHR/CtU2lGCvbNpsO8dlUd+kjZyaGqw DnoRaDylSzngr/I9oKdc5eTb9ByIIzlA469nrQoxhiX/C66TosBwIGlRJuRXXCNUywBD jmLvTi5laQ5wE/XzdXhg/r8VsYk91abp9aLjDbjtNkJRGbdUxLfb8X5VU/884dAA7SOl As7wl9wqnGh9BCmjI4SjrUVCCeE2l/l8Nkw5WlsE3r6JIF/DkczxxwatSCIUpgNTA/km f+LqFIAAnyCsYwBvUxkIDAsrgDsmH7tz+ooxs+cMNarycQXuRMDooNjSYuvGX7uP42E6 2jIQ== X-Gm-Message-State: AO0yUKVd1idF8qiwz4GvWC3P5MZhkp16/4p0LT0GlfMSVS3wTEQW/g28 iGQSFIlcMdflFcZpGfEInZGw8w== X-Google-Smtp-Source: AK7set8Fk3p1ZOQ7IU2K/KIsEubzYn7lQGwI7Tgn2VaTpDxrPEljVCjZCSjE1DXclHvS/ubKYnlCaQ== X-Received: by 2002:a5e:c204:0:b0:740:7d21:d96f with SMTP id v4-20020a5ec204000000b007407d21d96fmr2022484iop.1.1678994721545; Thu, 16 Mar 2023 12:25:21 -0700 (PDT) Received: from [192.168.1.94] ([96.43.243.2]) by smtp.gmail.com with ESMTPSA id p5-20020a02b005000000b004063510ba0esm23563jah.142.2023.03.16.12.25.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Mar 2023 12:25:20 -0700 (PDT) Message-ID: Date: Thu, 16 Mar 2023 13:25:19 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH 5.10/5.15] io_uring: avoid null-ptr-deref in io_arm_poll_handler Content-Language: en-US To: Fedor Pchelkin , Greg Kroah-Hartman Cc: stable@vger.kernel.org, linux-kernel@vger.kernel.org, Alexey Khoroshilov , lvc-project@linuxtesting.org References: <20230316185616.271024-1-pchelkin@ispras.ru> <20230316192259.ec46rcfw52ubqxrp@fpc> From: Jens Axboe In-Reply-To: <20230316192259.ec46rcfw52ubqxrp@fpc> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/16/23 1:22 PM, Fedor Pchelkin wrote: > On Thu, Mar 16, 2023 at 08:04:24PM +0100, Greg Kroah-Hartman wrote: >> >> How can you trigger a GFP_ATOMIC memory failure? If you do, worse >> things are about to happen to your system, right? >> >> thanks, >> >> greg k-h > > Well, Syzkaller triggers them with fail slab, and that is more for > debugging purposes to detect improper handling of error paths. > > I agree that if GFP_ATOMIC memory allocation fails then the system is in > more trouble. Do you mean this is the point not to backport it? Now I'm > actually not quite sure about this... It's not clear to me whether such > things should be backported: on one hand, it is a bug which can actually > occur (yes, in very bad situation), on the other - the whole system is not > good anyway. I agree with both of you - the likelihood of this happening outside of synthetic error injection is very small, and if it does, the system has probably gone to shit anyway. On the other hand, this does bring the code in line with what upstream is doing, and I think it's worth adding for that reason alone. -- Jens Axboe