Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp313445pxf; Tue, 6 Apr 2021 23:29:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy+1K2SboKud4r7cvUyY7kNOx3VKln4yldrnyTCnZeOJ4ZzfzxG6IjHqe8ob6c2qM+Po35v X-Received: by 2002:a92:cd88:: with SMTP id r8mr1632446ilb.152.1617776998962; Tue, 06 Apr 2021 23:29:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617776998; cv=none; d=google.com; s=arc-20160816; b=I74DW/3WcvmLnKLvWj4M14MgIsCKbTb3tWVjTwc+tA7crATw/FUsJ134q2xi6d4vbD 8ea0Pv1mT4LrrEyKHwmRQWLq3aqObLtbD5lQJqqK2D7m1UFy/WO1r9930jXcPnarvmOC xbLQv09gEmTRX3ZBO2EnRg3gcgajl1qoV3d6gcIPmg/IyGnTR21QhwWHJZ9GbBqTol43 Iji7gz0FDT9EKaAisqLJdn1RwCpHrozD3rJ+p03dKXSxVvfBfYPmyrPSY9ESMs+Het3v yot8RdJFXGM4UCBzQJtxVKU+TKDue4F3jWXHXVekv+q1yhciKZGrR+mm0WUtewVeCh0S 0UFg== 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=Q7y4DsAClbuw9+MPVuHdzZ6V5Gw/oLVXzRPA8FvCLCQ=; b=bzZsm7AyUoog6s0qhr9dImIjl4+gNccNGpjIDCBjQjSwwh79Nwtl1df5wIIcyRMFG0 EviCRMsiOjpOtDW6HsjLQGA6Sf7jcWbRErdAbSlfTmXlHosxDnVdfzA2aRiIpxmiykJn IS0YX+X4qbMnECaDRQ4Sg8dY9tkFFNDFzkGwNAWPq+bLPEbv/GD4OoWRlqskr6UCwXKO lLcAp1S1+OM0EMMo9n+tmhrdcP/1yz5caPpfgjDgUN6h76k7pJZ4hs4oFnkMFflMgWTK OnR3IQq5Wr6lneRc5KRE5Jt8trxAPCj7oO8stbgISAOcM/kuARvcW+q3BKCKq6Oy1lIL RY2Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c1si19703491jam.95.2021.04.06.23.29.47; Tue, 06 Apr 2021 23:29:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244668AbhDFOXm (ORCPT + 99 others); Tue, 6 Apr 2021 10:23:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42218 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232556AbhDFOXj (ORCPT ); Tue, 6 Apr 2021 10:23:39 -0400 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 48A3BC06174A; Tue, 6 Apr 2021 07:23:31 -0700 (PDT) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94 #2 (Red Hat Linux)) id 1lTmc4-0037of-6y; Tue, 06 Apr 2021 14:23:28 +0000 Date: Tue, 6 Apr 2021 14:23:28 +0000 From: Al Viro To: Christian Brauner Cc: Jens Axboe , syzbot , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, io-uring@vger.kernel.org Subject: Re: [syzbot] WARNING in mntput_no_expire (2) Message-ID: References: <20210405170801.zrdhnon6g4ggb6c7@wittgenstein> <20210405200737.qurhkqitoxweousx@wittgenstein> <20210406123505.auxqtquoys6xg6yf@wittgenstein> <20210406132205.qnherkzif64xmgxg@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 06, 2021 at 02:15:01PM +0000, Al Viro wrote: > I'm referring to the fact that your diff is with an already modified path_lookupat() > _and_ those modifications have managed to introduce a bug your patch reverts. > No terminate_walk() paired with that path_init() failure, i.e. path_init() is > responsible for cleanups on its (many) failure exits... I can't tell without seeing the variant your diff is against, but at a guess it had a non-trivial amount of trouble with missed rcu_read_unlock() in cases when path_init() fails after having done rcu_read_lock(). For trivial testcase, consider passing -1 for dfd, so that it would fail with -EBADF. Or passing 0 for dfd and "blah" for name (assuming your stdin is not a directory). Sure, you could handle those in path_init() (or delay grabbing rcu_read_lock() in there, spreading it in a bunch of branches), but duplicated cleanup logics for a bunch of failure exits is asking for trouble.