Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp4251790pxp; Tue, 15 Mar 2022 16:28:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzv8a5ISoTNDCVahapAxR8qXt82JhTZSbuU/gPw3Rznlv/IUM1L/5ubajxkngBZXFNtyFec X-Received: by 2002:a17:902:d4cc:b0:153:44:95f1 with SMTP id o12-20020a170902d4cc00b00153004495f1mr29751742plg.60.1647386882224; Tue, 15 Mar 2022 16:28:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647386882; cv=none; d=google.com; s=arc-20160816; b=Kuwh2gLgduKlbet0wnOmvkBQ2n3e8idhYPosjFTiBxD1wcTuCp9gpquuT3L19OHNOJ 2GBQrrqqsf8lPC9Pa/l9lphtkrVa68Or+HDA1+InSyRBpdCkmmFBPx+hyAxZGE4U0NBB 0Vn6tvvNcyKX2rBordSI1gJEGvETwgLwHJ4PU8LW9ahl3PkRKMZ8mWnoqBMIg3pp6qFO CQGApsTdvkENZLAnFA0ljq3qINuyk/zfgeMzx0SwsXd+JhpE4gwDTKb4D0e99J1zX1w8 0NnuDaoq+FZttJK6Ng26Ktnrd+hLRE1blmFQ/kaeHfQR2dJcVwaa9zjrulAsyAIjKFlI Ghgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=U1s6oz74YF268OGoMUJ4SCDiiyIqohorsMEEkrc0CGA=; b=QV0eVcWFWvLyHtVIwovy1/gDTVEyaEM10/uEQqjLz1YFyFMHFjnUdhBSS9mNZyUpG6 /4ucEHtLzaiIpqUO+dBLWPLIPq8vQhzrz1ldgM0hCQxxrHBQFKw1+3MNAWbzw3TFkMeQ XuxBNbehPPBBYU0Tp5UD8Cd7fzLyiWjtTEAfu3El+dkv4SGa0eRAWUYeF9U4rOEyq23P Im27BC9ujGsedZcbSYl/tytQYGNZEFkB8BbR6cx2f8IK44ybO3ASdNugWtck5hZ6Q7H6 1r0snTU9+V/nDTT+AJJoMCofDrUA7wuNFR0LntJTyLqYfzo9Gi9V6sSCTq4sW+WTbcE2 erxA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z37-20020a630a65000000b003732cdefdabsi518796pgk.379.2022.03.15.16.27.44; Tue, 15 Mar 2022 16:28:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343712AbiCNXhL (ORCPT + 99 others); Mon, 14 Mar 2022 19:37:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59522 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343707AbiCNXhK (ORCPT ); Mon, 14 Mar 2022 19:37:10 -0400 X-Greylist: delayed 1253 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Mon, 14 Mar 2022 16:35:59 PDT Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [142.44.231.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 919C813F63; Mon, 14 Mar 2022 16:35:59 -0700 (PDT) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nTtph-00BJxN-UC; Mon, 14 Mar 2022 23:10:34 +0000 Date: Mon, 14 Mar 2022 23:10:33 +0000 From: Al Viro To: Hao Luo Cc: Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , KP Singh , Shakeel Butt , Joe Burton , Tejun Heo , joshdon@google.com, sdf@google.com, bpf@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH bpf-next v1 1/9] bpf: Add mkdir, rmdir, unlink syscalls for prog_bpf_syscall Message-ID: References: <20220225234339.2386398-1-haoluo@google.com> <20220225234339.2386398-2-haoluo@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 14, 2022 at 10:07:31AM -0700, Hao Luo wrote: > Hello Al, > > In which contexts can those be called? > > > > In a sleepable context. The plan is to introduce a certain tracepoints > as sleepable, a program that attaches to sleepable tracepoints is > allowed to call these functions. In particular, the first sleepable > tracepoint introduced in this patchset is one at the end of > cgroup_mkdir(). Do you have any advices? Yes - don't do it, unless you really want a lot of user-triggerable deadlocks. Pathname resolution is not locking-agnostic. In particular, you can't do it if you are under any ->i_rwsem, whether it's shared or exclusive. That includes cgroup_mkdir() callchains. And if the pathname passed to these functions will have you walk through the parent directory, you would get screwed (e.g. if the next component happens to be inexistent, triggering a lookup, which takes ->i_rwsem shared).