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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58373C36002 for ; Mon, 24 Mar 2025 18:28:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CAD27280002; Mon, 24 Mar 2025 14:28:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C3608280001; Mon, 24 Mar 2025 14:28:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD849280002; Mon, 24 Mar 2025 14:28:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 89A41280001 for ; Mon, 24 Mar 2025 14:28:06 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 46851B992A for ; Mon, 24 Mar 2025 18:28:07 +0000 (UTC) X-FDA: 83257279014.15.88FDD15 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf07.hostedemail.com (Postfix) with ESMTP id 37B1C40002 for ; Mon, 24 Mar 2025 18:28:05 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=QzUlCVO+; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf07.hostedemail.com: domain of oleg@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=oleg@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742840885; a=rsa-sha256; cv=none; b=Ze3u37Wc04O8tABoUrrWdq/aNRQW7TiOwCYPLpUG+H9DaczFCABxqAsZY/Khl0I2NKbii9 gFxOgoSvms0r9oah10cZ9r0BiIsb2sRsc8mt/+rniPoZ27a1A+S6A7MY1pr9Vh7P40dLPu RsnliHuMYQ6msmkOD0rjBtQHoANeKko= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=QzUlCVO+; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf07.hostedemail.com: domain of oleg@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=oleg@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742840885; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xKXLckG3JcEYiJLm25eTT4GpebPkKVPJ6WMyBA2uJV0=; b=RhL9ckZY/SL852Rf0pmtcTdvZrGTfx/gxjlRQ+M4xBh/0jdCVNg4QdwKbFOD2jA16UALyK ah3WSa+M65M/+zrZKDPvdUXs740qJYIgC3cojlaXnJ6feQLzoob8VgSYjPMa3ylno2ynQi +rdou9dczj2p3nHYXlo4mD7MOM8EsT4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1742840884; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xKXLckG3JcEYiJLm25eTT4GpebPkKVPJ6WMyBA2uJV0=; b=QzUlCVO+BaNuRbnIGVnGznBXZtk/XW+N3lfGz+VMu0ENVS2lSuEAPPn86hnmYWThJCeZK/ zPnEFixY0L1MThgGgl49KH4iBkOW6d/QBwBY3T/dNGFU9LijnXTw7tima7TuknnKCE44Gu a8QrmTlj/glOaC4jOTje6XH7nwCi8JI= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-612-Nv2AS9tqP9uVkEWzJ_qCJA-1; Mon, 24 Mar 2025 14:28:02 -0400 X-MC-Unique: Nv2AS9tqP9uVkEWzJ_qCJA-1 X-Mimecast-MFC-AGG-ID: Nv2AS9tqP9uVkEWzJ_qCJA_1742840881 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A1534180AF55; Mon, 24 Mar 2025 18:28:00 +0000 (UTC) Received: from dhcp-27-174.brq.redhat.com (unknown [10.45.224.42]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with SMTP id B5869180B48C; Mon, 24 Mar 2025 18:27:56 +0000 (UTC) Received: by dhcp-27-174.brq.redhat.com (nbSMTP-1.00) for uid 1000 oleg@redhat.com; Mon, 24 Mar 2025 19:27:27 +0100 (CET) Date: Mon, 24 Mar 2025 19:27:22 +0100 From: Oleg Nesterov To: Mateusz Guzik Cc: syzbot , brauner@kernel.org, kees@kernel.org, viro@zeniv.linux.org.uk, jack@suse.cz, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com Subject: Re: [PATCH] exec: fix the racy usage of fs_struct->in_exec Message-ID: <20250324182722.GA29185@redhat.com> References: <67dc67f0.050a0220.25ae54.001f.GAE@google.com> <20250324160003.GA8878@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 37B1C40002 X-Stat-Signature: mp3niqejy9jz4wboqnf7jgp8wpqz9cyo X-HE-Tag: 1742840885-275416 X-HE-Meta: U2FsdGVkX1/Qr5vSelfCQ2ybSwQlLe2XXHV7k+gYRkUqljWfrnk2SGrB9H8iqbCxifCVRfGVyBKITkr/TlC6BVNrXKJshDRYcWVg1O++MXyXANV8xRP1CyrPYMhFd+Hl7wxDezNCxWHOOBfJfHFMiyz+EDKohRdt8u5Iu3xJFIl+m1GCoEIgQOM77tM3XKBvePF5o1bcwjWXux5fiiMx1wttKElx8zkLvV5/zB5L5vZIBx4YfTvqRPYfkmVEav/tUny4UY8OHI6NHwxjIGNk5aOrZtZdWh7Ayearor9/cswimgDvMua4+e/Pah+MTE4uQV6KzJ3qgVwNkkVKhlbcno6w/B0dQQ4xOw6dukHaNBCjLk7fQT66agGf4WcbU0y+JMQNPP9blS97RCitogV5dQtpSIAXK5VQ5Tw6TaopuOmr7KcyWRm2xh3FWY++ltErDv7qbtnSNymsxD4hIwD7JU/eQ0EKP22smgPNcrsS0nTOl4hTWCfjFr+GOTkHOcpyuzqacvpVT8kqYyi08UxfpSQd1kBJWC4gp3rZNaFVtlrC4g1g0yo03CJfuYwCxg5nQL2fgn/37OiprxJ6kRpmnJk8Bcj4ftbfBq5bluRVDP6bVjmgUNM8Rjezt/phpC8gFWlgjWcAqRW5szfs7ciz/ZYXqBBZJh0oYSDAv8o+fJXrkeEgaN3V7prUwTmDVOSHwy6hhqQD/ZrSeiaBz4ce/SePVn1FobgkKkt6f1xw9MLh1GFTMWyf8tWHfm5/yMaWdj5S58VtVCQp/KVpScbpfbnqiBcnRmJM0M/6kpZMFxVTR4wX3ID6B4eRAvyvqE9D2xMpMEPOjOwdWTrely7pLllnNm6LT8J7EGYmVRoOaoRavwQOup9K1jjKAK1o3Jbc8x9H8XWGhnIuAHAlSWuw/zL5oPjvgRD330kmqFZ4jdv219g4U2XytlnyerTycganCEXeOB2sVjYowImp/YE HKx0OmLc aGAVxsTZ8SaWECyvLWH/TMYe0IWYbQXGyJwqqmLSTcFnbzpOheHIs/bfApHZaGavHJGL9i6ABPllbPPLQBS3VXT5G3PFn5KCEMjVGcwB3ZAoPmqJUEFZ9ST9ASPqOUa7ShyGSKs2ec4A2/tUe2NPP41Dpzax/1ExAptoWeh6bvsK+GuEBoAf1k5123yiRQqLLO/st4ruS3dsc1QWlZgmP26ScsIQTfn8fO9odfviPF/G+kLa+0/2/s0oMIxdqKuj5Vcq8P9JbnUFMzq7vTARTN+jNPfGvVE0QnaRR5fxj2EqgWuzl2Y9AlIP6GjX3emPPm8Upbo1NqwfuZHxvxXFNkF54WDnuIr+CgEUNwunn+1JftQeUew/zgEwRam7xYYbzpRFhlP0wp9a2jXh6L8RQwkQA9jp4wFvDBlrN2LSjcO0i/dypNXcb0HjTwcbYfwuK4JeWT615gCxgH7cwaN/ojf4BvQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.034126, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 03/24, Mateusz Guzik wrote: > > I had cursory glances at this code earlier and the more I try to > understand it the more confused I am. You are not alone ;) > Per my other e-mail the obvious scheme would serialize all execs > sharing ->fs and make copy_fs do a killable wait for execs to finish. > Arguably this would also improve userspace-visible behavior as a > transient -EBUSY would be eliminated. I had the same feeling years ago. Why didn't I do it? I can't recall. Perhaps because I found some problem in this idea, but most probably because I failed to make the correct and simple patch. > is there a problem getting this done even for stable kernels? I > understand it would be harder to backport churn-wise, but should be > much easier to reason about? I won't argue with another solution. But this problem is quite old, unless I am totally confused this logic was wrong from the very beginning when fs->in_exec was introduced by 498052bba55ec. So to me it would be better to have the trivial fix for stable, exactly because it is trivially backportable. Then cleanup/simplify this logic on top of it. Oleg.