Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp988375rwr; Wed, 19 Apr 2023 16:42:01 -0700 (PDT) X-Google-Smtp-Source: AKy350aRfk/dghDDBAREx0BuaXHV5J/wugUQbBorz8WtqPiffWbpmznugYvVGUPwrorYiX9XqV7v X-Received: by 2002:a05:6a00:3017:b0:63d:32a3:b5f7 with SMTP id ay23-20020a056a00301700b0063d32a3b5f7mr3856365pfb.12.1681947720715; Wed, 19 Apr 2023 16:42:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681947720; cv=none; d=google.com; s=arc-20160816; b=dZEpQ6q5cc9/GOZZdXjii1PTLXndr+7byhTnG8TB7NesHWS9oUG3fLokDSosh95f9S 4SXiJ5AgO2jaFtAXlBKHwLhX7jvHmH0KDLuvdvf7Mzzhue3qYubInuoUqCE2DhFaR7C+ iZ31oU7O3eUsCKTv+rAVEcnOC/XQ6QyYBiLyuSGLlWIBIESb9OA580oZ7Zc8DPle9UCZ +xxuGoJOKv4BQfKI1dkZ6ZSoNEYpmY9OR2pnHdQmkANvWed82Pat9ayeR3AkVKoqM1ln PK3Xu0mgkfSlwDyC8P3htZKS5zFS2kmvD/b3lGjzv95/M9WNgnqaAPG9elik+o3LotCH qypA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=XVPu+f8UpKVdX5LhOFNZNUccbpjEUaJMQwYn4eLNppI=; b=ye6LKF/ILkk0UwXrfQS3yOLg9L35xWo95szuuIAQc1xLV5fGEpgo+B7KUynmYXswcs HdnYX7Il7A4f+nnUqDzfJY/T7gOVT6RnBU0rPTPP3yZPeWEpaFP/7poNW/wmeORLILv4 Jiesf5IX5crUoN0hPYv+RZu9OQ5oiIqsCUrr48tecb5zGKVzo2xPJaloHy12Edf2Dchs rkNolED0joj1YDUuL/9e1yEU5FAUoU5sXuotn+BzEnEhbO3fXT/4EeKq2Lu9rd03VQf+ MMuJi0rY3X5+7Yra+Kg8vvouxQHC3bq6s7gBJWYujxebkivqGpS2npWDlZxk+AACRyBB jHNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fromorbit-com.20221208.gappssmtp.com header.s=20221208 header.b=sgqFjkz7; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=fromorbit.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d69-20020a621d48000000b006361df3aa86si17211386pfd.88.2023.04.19.16.41.33; Wed, 19 Apr 2023 16:42:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-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; dkim=pass header.i=@fromorbit-com.20221208.gappssmtp.com header.s=20221208 header.b=sgqFjkz7; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=fromorbit.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229547AbjDSXct (ORCPT + 99 others); Wed, 19 Apr 2023 19:32:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232249AbjDSXcs (ORCPT ); Wed, 19 Apr 2023 19:32:48 -0400 Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5AB8630EA for ; Wed, 19 Apr 2023 16:32:47 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-63d4595d60fso3235686b3a.0 for ; Wed, 19 Apr 2023 16:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20221208.gappssmtp.com; s=20221208; t=1681947167; x=1684539167; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=XVPu+f8UpKVdX5LhOFNZNUccbpjEUaJMQwYn4eLNppI=; b=sgqFjkz74tih5s3kSz9L2uAbFEJqj34+Q/Z2A7BAaNmARaNR+Qzw8OcuMtLHF9beSs RxCFsRAeyUI05/ReeU84siBy3V/xA9JgHXUeV79M6YCgzhhIrhjLGikNO+Elq8L4e85f 3mRXjZwCUCFB5/i0dhSPmxYektdRUsgh2agz0e9rp8VvmfpxXBDJr46SmA3Nx09vMTw0 dfb+c+dGLj2v+cVoGkJlZ55Wd6VpY1Gg0lGZCMh35Pr7Epjr/1+t70VPUwnRk+RaNMZg mG+jgQmR1HLDEQb+/3twq5UdzflC9YrbD0N+t9o7dE9Ik/yTFpDf1f9FQSapiopyIT1W hnNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681947167; x=1684539167; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XVPu+f8UpKVdX5LhOFNZNUccbpjEUaJMQwYn4eLNppI=; b=C6/GfSgXG0IKpF3XWkt1ExUpGzJInidGd0McfBtzzvZhFnEOhEQb5Ox9bzNTAt07Jd KXf5UU+AOIL+s9HLB3ax9e9j+6H8Hbg4JG7WerMy1f0xEaiKsUeGmvk4siFzPcT7bRHp rNUFJFYswyK8SKiFJxbto5F1ex0nGlLGexNHZNnpZuwYMLEme6lE64g+LZ1WK73JnYg0 rFYB/ksK5lAcAN6ifSaBjRuzzZ+9GAEqEDg6A/hfvmeDaQ+7CAvQMs6RImOAitrHhmU+ OkU8QMWBEs2b0249fTxHCremwuaV9cPeJ/zzPAwT97KzXB1oO+X00puK9B/VkLkgkHhJ bXDg== X-Gm-Message-State: AAQBX9c/DtFtDiH6LfSP/cv2xvNW5OKQBDBlebWO8UQeZHBm+ZWzjEHO bhsGi3jaR8Rt/XTojXanHMHdCw== X-Received: by 2002:a17:90a:9e5:b0:246:aeee:e61c with SMTP id 92-20020a17090a09e500b00246aeeee61cmr4269732pjo.11.1681947166775; Wed, 19 Apr 2023 16:32:46 -0700 (PDT) Received: from dread.disaster.area (pa49-180-41-174.pa.nsw.optusnet.com.au. [49.180.41.174]) by smtp.gmail.com with ESMTPSA id b3-20020a170902bd4300b001a67eace820sm32035plx.3.2023.04.19.16.32.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Apr 2023 16:32:46 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1ppHI3-005Rde-DU; Thu, 20 Apr 2023 09:32:43 +1000 Date: Thu, 20 Apr 2023 09:32:43 +1000 From: Dave Chinner To: Chuck Lever III Cc: Tetsuo Handa , Jeff Layton , Frank van der Linden , Linux NFS Mailing List , linux-fsdevel Subject: Re: [PATCH] nfsd: don't use GFP_KERNEL from nfsd_getxattr()/nfsd_listxattr() Message-ID: <20230419233243.GM447837@dread.disaster.area> References: <72bf692e-bb6b-c1f2-d1ba-3205ab649b43@I-love.SAKURA.ne.jp> <4BC7955B-40E4-4A43-B2D1-2E9302E84337@oracle.com> <7246a80ae33244a4553bbc0ca9e771ce8143d97b.camel@kernel.org> <20230416233758.GD447837@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, 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-nfs@vger.kernel.org On Wed, Apr 19, 2023 at 01:51:12PM +0000, Chuck Lever III wrote: > > > > On Apr 16, 2023, at 7:37 PM, Dave Chinner wrote: > > > > On Sun, Apr 16, 2023 at 07:51:41AM -0400, Jeff Layton wrote: > >> On Sun, 2023-04-16 at 08:21 +0900, Tetsuo Handa wrote: > >>> On 2023/04/16 3:40, Jeff Layton wrote: > >>>> On Sun, 2023-04-16 at 02:11 +0900, Tetsuo Handa wrote: > >>>>> On 2023/04/16 1:13, Chuck Lever III wrote: > >>>>>>> On Apr 15, 2023, at 7:07 AM, Tetsuo Handa wrote: > >>>>>>> > >>>>>>> Since GFP_KERNEL is GFP_NOFS | __GFP_FS, usage like GFP_KERNEL | GFP_NOFS > >>>>>>> does not make sense. Drop __GFP_FS flag in order to avoid deadlock. > >>>>>> > >>>>>> The server side threads run in process context. GFP_KERNEL > >>>>>> is safe to use here -- as Jeff said, this code is not in > >>>>>> the server's reclaim path. Plenty of other call sites in > >>>>>> the NFS server code use GFP_KERNEL. > >>>>> > >>>>> GFP_KERNEL memory allocation calls filesystem's shrinker functions > >>>>> because of __GFP_FS flag. My understanding is > >>>>> > >>>>> Whether this code is in memory reclaim path or not is irrelevant. > >>>>> Whether memory reclaim path might hold lock or not is relevant. > >>>>> > >>>>> . Therefore, question is, does nfsd hold i_rwsem during memory reclaim path? > >>>>> > >>>> > >>>> No. At the time of these allocations, the i_rwsem is not held. > >>> > >>> Excuse me? nfsd_getxattr()/nfsd_listxattr() _are_ holding i_rwsem > >>> via inode_lock_shared(inode) before kvmalloc(GFP_KERNEL | GFP_NOFS) allocation. > >>> That's why > >>> > >>> /* > >>> * We're holding i_rwsem - use GFP_NOFS. > >>> */ > >>> > >>> is explicitly there in nfsd_listxattr() side. > > > > You can do GFP_KERNEL allocations holding the i_rwsem just fine. > > All that it requires is the caller holds a reference to the inode, > > and at that point inode will should skip the given inode without > > every locking it. > > This suggests that the fix is to replace "GFP_KERNEL | GFP_NOFS" > with "GFP_KERNEL" /and/ ensure those paths are holding an > appropriate inode reference. If the code that provided the inode to nfsd_listxattr() did not already have an active inode reference in the first place then there are much, much bigger UAF problems to worry about than simple memory reclaim deadlocks. That said, nfsd_listxattr() does: dentry = fhp->fh_dentry; inode = d_inode(dentry); *lenp = 0; inode_lock_shared(inode); len = vfs_listxattr(dentry, NULL, 0); Given that a dentry pointing to an inode *must* hold an active reference to that inode, I don't see how it is possible this code path could be using an unreferenced inode. nfsd_getxattr() has a similar code fragment to obtain the inode as well, so same goes for that... -Dave. -- Dave Chinner david@fromorbit.com